You are not logged in.
GQview does not show some of jpeg files (some are shown properly). No error messages. GQview shows the Darkness instead of picture… Recompiling GQview from sources is useless.
Offline
If you open this from console e.g. with 'gqview &', what does the console write to stdout ?
Is the picture resolution, format okay ? WIth another imgae viewer is okay ? Did you tried download manually , and build without any arch related thing ? Which version do you use ?
Offline
Yes, there are some issues with some programs and jpeg-7.
Gqview is and old project (not updated since 2006) But if you try the fork 'geeqie' repo version (beta1) or latest beta2, images that not displayed on gqview are viewed on geeqie but are diffused, some are big diffused like the follow example, others small diffuse. Sometimes not load on "first hit", need a "second click".
Example:
http://archlinux.djgera.com.ar/probeta/geeqie-bad.png (jpeg-7)
http://archlinux.djgera.com.ar/probeta/geeqie-good.png (jpeg-6b)
Test image:
http://archlinux.djgera.com.ar/probeta/programmer.jpg
Under gthumb are viewed OK, firefox, konqueror, qwenview.
Reporting to upstream...
Offline
Offline
This affects more apps: eog, evolution. Looks like gtk is having problems with the new jpeg. This also affects the development version of gtk.
Offline
This affects more apps: eog, evolution. Looks like gtk is having problems with the new jpeg. This also affects the development version of gtk.
yes, the rare part here is that all these gtk+ apps uses the gdkpixbufloader-jpeg
gthumb OK
eog BAD
geeqie BAD
nautilus BAD
So the question is, what are doing (or not doing) gthumb to display OK jpegs via gdk.
Offline
Maybe the gtk also affects gqview and geeqie so that they cannot fit image to screen/monitor any more. I have a wide screen and when I set the prefs to "fit to screen" in full screen mode the photos are centered and become square.
Offline
i have opened a bug report for gqview :
http://bugs.archlinux.org/task/15540?string=gqview
it would be a good idea to also open bug reports for the other programs which seem to have problems
Last edited by mechmg93 (2009-07-17 14:22:43)
Mikes on AUR
Offline
@mechmg92 really, i don't know why you opened.
jgc said clearly in this thread(5th post) that is a gtk problem.
Last edited by wonder (2009-07-17 14:40:58)
Give what you have. To someone, it may be better than you dare to think.
Offline
@mechmg92 really, i don't know why you opened.
jgc said clearly in this thread(5th post) that is a gtk problem.
o opened it because it's a bug. it's so simple.
the last few days developers of arch linux say all the time that we MUST open bug reports, and now you have a problem with this??
Last edited by mechmg93 (2009-07-17 14:47:09)
Mikes on AUR
Offline
open bug reports but do it well. is not a bug in that application. is a gtk problem. so a better bug report would be "gtk2 -2.16.4-1 breaks applications using libjpeg7". in this way we have _only_ one bug report that rule them all.
Give what you have. To someone, it may be better than you dare to think.
Offline
open bug reports but do it well. is not a bug in that application. is a gtk problem. so a better bug report would be "gtk2 -2.16.4-1 breaks applications using libjpeg7". in this way we have _only_ one bug report that rule them all.
i am a simple user of gqview, and i do not know that gtk2 library causes the problem. The one i know is that i cannot see jpeg images with gqview. If someone else is sure and can prove that gtk causes the problem, then it's his turn to open a new bug report or enrich the report i have opened with his knowledge.
Mikes on AUR
Offline
I have noticed this too after the last update, some pics did not display and others are completely distorted and the pics used to show properly before.
Meanwhile I have installed viewnior from the aur, it's not ideal (I don't like some of the behavior) but it's also lightweight and quite fast.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Yeah I noticed this last night. I installed ristretto and problem solved. At the beginning I really hated this viewer; now I'm starting to getting used to it.
They say that if you play a Win cd backward you hear satanic messages. That's nothing! 'cause if you play it forwards, it installs windows.
Offline
So this small pygtk example does not show the issue:
import gtk
import gtk.gdk
w = gtk.Window ()
pixbuf = gtk.gdk.pixbuf_new_from_file ('/path/of/an/image.jpg')
i = gtk.Image ()
i.set_from_pixbuf (pixbuf)
w.add (i)
w.show_all ()
gtk.main ()
Anybody good at gtk and want to create a C version to see if the problem exists in such a simple example? A minimal case may help us track down the issue.
BTW: upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=588740
Offline
Yes, I already tried a simple app with python and directly with C, but as you said, shows OK.
#include <gtk/gtk.h>
int main(int argc, char *argv[])
{
GtkWidget *window, *image;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
image = gtk_image_new_from_file(argv[1]);
gtk_container_add(GTK_CONTAINER(window), image);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
gcc -Wall -O2 ima.c -o ima `pkg-config --cflags --libs gtk+-2.0`
./ima programmer.jpg
and works fine
EDIT: the problem with this sample, is that don't load in the same way the image that in real programs. Need more research, I don't know much more gtk+ than doing these snipets :S
Last edited by djgera (2009-07-18 03:37:08)
Offline
I installed ristretto and problem solved.
Hum. My ristretto (0.0.22-1) does blur images. Did you try it with the image posted above (programmer.jpg)?
the problem with this sample, is that don't load in the same way the image that in real programs.
Looks like the problem only occurs when using a GdkPixbufLoader.
- edit: Ok, so I was wrong. See electropura's post.
I extended your code and did two small and dirty examples in python and C and they both show the blur effect.
Funny detail: I used programmer.jpg as posted above, its size is 277x300. By explicitly setting the correct size, it's still blurry:
loader = gtk.gdk.PixbufLoader()
loader.set_size(277, 300)
loader.write(buf)
loader.close()
But if I increase the size, it's almost sharp:
loader.set_size(277 + 1, 300 + 1)
How about that one? Quite blurry again.
loader.set_size(277 - 1, 300 - 1)
Last edited by Vain (2009-07-18 06:52:38)
Offline
This code shows the issue:
#include <gtk/gtk.h>
#include <gdk-pixbuf/gdk-pixbuf.h>
int main(int argc, char *argv[])
{
GdkPixbuf *pixbuf;
GtkWidget *window, *image;
GError *error = NULL;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
pixbuf = gdk_pixbuf_new_from_file_at_size(argv[1], -1, -1, &error);
image = gtk_image_new_from_pixbuf(pixbuf);
gtk_container_add(GTK_CONTAINER(window), image);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
The problem seems to be with gdk_pixbuf_new_from_file_at_size() and gdk_pixbuf_new_from_file_at_scale(), gdk_pixbuf_new_from_file() is not affected. I could be wrong though, I'm not a programmer.
Offline
Thanks for the comments! researching in the functions gtk+2 functions, maybe....
Offline
gdk_pixbuf_new_from_file_at_size-> gdk_pixbuf_new_from_file_at_scale ... -> gdk_pixbuf__jpeg_image_load_increment
The part related to scaling is:
gtk+-2.16.4/gdk-pixbuf/io-jpeg.c
for (cinfo->scale_denom = 2; cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) {
jpeg_calc_output_dimensions (cinfo);
if (cinfo->output_width < width || cinfo->output_height < height) {
cinfo->scale_denom /= 2;
break;
}
}
jpeg_calc_output_dimensions (cinfo);
mmm I suspect that maybe related to this:
old libjpeg-6b documentation says:
unsigned int scale_num, scale_denom
Scale the image by the fraction scale_num/scale_denom. Default is
1/1, or no scaling. Currently, the only supported scaling ratios
are 1/1, 1/2, 1/4, and 1/8. (The library design allows for arbitrary
scaling ratios but this is not likely to be implemented any time soon.)
Smaller scaling ratios permit significantly faster decoding since
fewer pixels need be processed and a simpler IDCT method can be used.
The new jpeg-7
unsigned int scale_num, scale_denom
Scale the image by the fraction scale_num/scale_denom. Default is
1/1, or no scaling. Currently, the supported scaling ratios are
8/N with all N from 1 to 16. (The library design allows for arbitrary
scaling ratios but this is not likely to be implemented any time soon.)
Offline
I think you are on the right track here given this was the kdelibs fix...
+- cinfo.scale_denom = scaleDown;
++ cinfo.scale_denom *= scaleDown;
I'd try changing cinfo->scale_denom by factors of two after that loop...
Offline
YES!!!!! it here!
Thanks people for making a sample test case!
--- gtk+-2.16.4/gdk-pixbuf/io-jpeg.c.orig 2009-07-18 04:15:05.000000000 -0300
+++ gtk+-2.16.4/gdk-pixbuf/io-jpeg.c 2009-07-18 04:15:12.000000000 -0300
@@ -922,7 +922,7 @@
}
}
- for (cinfo->scale_denom = 2; cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) {
+ for (cinfo->scale_denom = 2; cinfo->scale_denom <= 16; cinfo->scale_denom *= 2) {
jpeg_calc_output_dimensions (cinfo);
if (cinfo->output_width < width || cinfo->output_height < height) {
cinfo->scale_denom /= 2;
Offline
Great - I will fix the package now!
Can you post that patch upstream: http://bugzilla.gnome.org/show_bug.cgi?id=588740
Offline
Submited
This was really cool!
Offline
gtk2-2.16.4-2 is pushed to the repos
Offline