GNOME Bugzilla – Bug 163090
gdk-pixbuf scalers fall over when image dimensions > 32768
Last modified: 2018-05-22 13:02:43 UTC
Attempt to use gdk_pixbuf_composite on any pixbuf with one of the dimensions greater than 32768. You either get image corruption or a crash. Repeatable on GTK+ 2.2.4 and 2.6.0
Sorry, but why was this WONTFIXed without even any short comment explaining that?
I think its not worth worrying about images of this size, really. But if you have a patch, feel free to attach it here.
*** Bug 303698 has been marked as a duplicate of this bug. ***
*** Bug 475621 has been marked as a duplicate of this bug. ***
*** Bug 592880 has been marked as a duplicate of this bug. ***
*** Bug 618843 has been marked as a duplicate of this bug. ***
*** Bug 622527 has been marked as a duplicate of this bug. ***
It's funny how people think only about their daily lives and don't think there could be others with different task and uses for the things. E.g. the image viewer that some use to look at their vacation photos others use the same viewer to look at scientific data :) Saying "its not worth worrying about images of this size, really" is pretty funny and narrow minded. And yes I need images over 32768 even over 100 000 and even more ;)
I agree with iasenkk's comment 8. I frequently try to use GNOME's various image viewers to view scientific data, and they frequently are broken for this purpose. e.g. I was trying to view an image that was something like 80,000 pixels wide by 1000 pixels high just the other day, and it was quite amusing to see the weird ways each of the different viewers would break on this image at different zoom settings.
I also agree, I run into this problem all the time.
Btw why is this "UNCONFIRMED" when it's a long (years) known bug of Microsoft type ;)
Iasen: Status of a bug does not reflect when it will be fixed.
I meant - why the status is not set to "CONFIRMED" when it's a know bug for 5+ years ? BTW gimp works fine with those large images, can't You use the scaling code from there ?
Iasen: Not a question of just copy/pasting. Patch appreciated, but focus is not at all on this by the current developers. Unconfirmed is just a helping hint for triagers. Nobody in GNOME Bugzilla cares about the status of a bug. Because Bugzilla sends an email when the status is changed, triagers often refrain from changing the status if that is the only thing which should be done. If you want to discuss the latter further, please email bugmaster@gnome.org and I'll explain.
(In reply to comment #14) > Iasen: Not a question of just copy/pasting. Patch appreciated, but focus is not > at all on this by the current developers. I thought the focus is on usability ? If the users can't use it why develop it at all as users will switch to something else sooner or later ?
Created attachment 180251 [details] panorama bug 32768 pixel
Bug appeared when trying to view a 360 degrees panorama image combined of 12 images from a DSLR with > 10 Megapixels. This is not a very special case. And it affects multiple Imageviewers as it seems. Bug Link: https://bugs.launchpad.net/gthumb/+bug/714275
Very annoying for panoramas indeed. I had a look, and the problem is in the scaling functions in gdk-pixbuf/pixops/pixops.c : the constant SCALE_SHIFT which is set to 16. So for instance in function pixops_process when you execute: run_end_x = (((src_width - filter->x.n + 1) << SCALE_SHIFT) - scaled_x_offset); with src_width > 32768 and run_end_x of type int, you get an overflow. What I did as a temporary local workaround is to define SCALE_SHIFT to 12 instead of 16, but a cleaner fix would probably be to use gint64 variables instead of int wherever it is necessary (as it only affects local variables). Hope this could motivate a developer to fix it properly...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/5.