Red Hat Bugzilla – Bug 827005
eog fails to display large images where the total image area (width x height) exceeds approximately 30 milion pixels
Last modified: 2016-01-31 20:56:33 EST
Description of problem:
Eog fails to display large images where the total image area (width x height) exceeds approximately 30 milion pixels. I've testes JPG and TIFF formats and different W:H ratios and once the limit is exceeded, I get only black background (JPEG) or gray chessboard (TIFF). Maybe it isn't caused by area limit, but could be caused by some kind of timeout, so that the limit can be eventually dependent on the CPU power / time of the load.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Scan an A4 sized JPG/TIFF color image (600x600 DPI)
2. Try to open it in EOG
Image NOT displayed
Could you file this upstream, please? I could do that for you, but I don't have a reproducer and you'd be in a better position to do that.
Does that mean you were unable to reproduce the issue?
I don't know if it's a good idea to report something to upstream when we're unsure if the upstream source/builds are affected too, but ok. I'll do that.
I just don't have an image with that high pixel count to try reproducing it. Would be great if you could attach one here or upload it somewhere.
Also, one thing to try is to start eog on the command line and see if it's displaying any warning messages on the console when opening a large image. That would be useful information to attach to the upstream bug report.
In any case, I don't think what's in the Fedora packages is much different from source builds. We aren't applying any patches to eog. Might want to first make sure that it's still reproducible with F17/rawhide version of eog, though; perhaps someone has already fixed the issue in a later eog release.
Hope this helps,
There's no need for upload. It would be better to reproduce it with your own image to confirm the issue. Just open GIMP and resize any image you have to 5400x5400 pixels. GIMP would say it's over 128MB limit, but ignore it and resize. Eog should be still able to display it. Then resize the image to 5480x5480 pixels or more. Eog should fail.
Anyway ... I'm attaching two testing files to this bug. I was able to reproduce the issue with them.
If it's a feature, then EOG should display any kind of warning like "Image too big to fit in the built-in size constraints!" But, I believe that any fixed constraints are unnecessary. The only real constraint is the available memory and eog can only check if it's possible to allocate enough memory for the image or not.
I see no error/warning messages in the terminal.
Created attachment 594418 [details]
Created attachment 594419 [details]
Both of the images open fine here with eog-3.5.1-2.fc18.x86_64. Also tried a monster 12000x14675 jpeg (GIMP warned that it would use 1.6 GB of RAM), which opened without issues as well.
Yes, I can confirm ... I just tested that with the rawhide build and it works correctly. The F16 issue seems to be more complicated than I thought. I can open 12000x12000 without problems whilst 5480x5480 can't be opened.
Please, decide, if it's worthy to backport the fix to F16.
I can't see any relevant commits that might have fixed this in eog git and 3.2.1 doesn't exhibit this issue on my rawhide box either. Perhaps the issue you're seeing on F16 is with some other component that eog uses for loading/displaying images?
In any case, looks like it's working better in newer Fedora releases, which is good.
It's really hard to guess. Maybe it's some race condition depending on the hardware. Don't know if eog uses threads or not. I will have to install Rawhide on my workstation to check that.
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
The issue is still present (even with eog-3.6.2 built for F17). I'm going to test f17 in virtual machine.
I have bad news. I'm unable to reproduce the issue on F17 running in a virtual machine, but I can reproduce it on F17 running directly on my workstation. That looks more like a race condition. The question is if the issue is in the eog viewer or any component it uses. I've tested 4 different viewers and they do not suffer from this issue.
It seems we have to debug the eog issue directly on my hardware. Do you have any ideas how to easily debug this?
Not sure what could be going wrong here.
Can you file an eog bug upstream, please? Quite likely that the people there would have ideas why it's not working for you.
Of course I can. Strange thing is, that the miniature shown when I try to drag from the chessboard is displayed correctly.
I've taken few videos demonstrating the problem ...
... and going to report the issue upstream.
I'm unable to reproduce the issue with the example images after the recent F17->F18 upgrade.
You can probably close this one as NEXTRELEASE.
Awesome, I love bugs that fix themselves :)