Bug 827005 - eog fails to display large images where the total image area (width x height) exceeds approximately 30 milion pixels
eog fails to display large images where the total image area (width x height)...
Product: Fedora
Classification: Fedora
Component: eog (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kalev Lember
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-05-31 08:09 EDT by Jaromír Cápík
Modified: 2016-01-31 20:56 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-25 17:54:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test 5400x5400 (696.94 KB, image/png)
2012-06-26 06:02 EDT, Jaromír Cápík
no flags Details
test 5480x5480 (833.62 KB, image/png)
2012-06-26 06:03 EDT, Jaromír Cápík
no flags Details

  None (edit)
Description Jaromír Cápík 2012-05-31 08:09:51 EDT
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):

How reproducible:

Steps to Reproduce:
1. Scan an A4 sized JPG/TIFF color image (600x600 DPI)
2. Try to open it in EOG
Actual results:
Image NOT displayed

Expected results:
Image displayed
Comment 1 Kalev Lember 2012-06-21 14:01:48 EDT
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.

Comment 2 Jaromír Cápík 2012-06-25 11:21:59 EDT
Hello Kalev.

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.

Comment 3 Kalev Lember 2012-06-26 03:31:37 EDT
Hello Jaromír,

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,
Comment 4 Jaromír Cápík 2012-06-26 06:02:13 EDT
Hello Kalev.

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.

Comment 5 Jaromír Cápík 2012-06-26 06:02:57 EDT
Created attachment 594418 [details]
test 5400x5400
Comment 6 Jaromír Cápík 2012-06-26 06:03:34 EDT
Created attachment 594419 [details]
test 5480x5480
Comment 7 Kalev Lember 2012-06-26 07:38:38 EDT
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.
Comment 8 Jaromír Cápík 2012-06-26 07:58:09 EDT
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.


Comment 9 Kalev Lember 2012-06-26 08:43:41 EDT
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.
Comment 10 Jaromír Cápík 2012-06-28 06:26:49 EDT
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.
Comment 11 Fedora End Of Life 2013-01-16 09:26:55 EST
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: 
Comment 12 Jaromír Cápík 2013-01-16 11:33:38 EST
The issue is still present (even with eog-3.6.2 built for F17). I'm going to test f17 in virtual machine.
Comment 13 Jaromír Cápík 2013-01-16 12:25:47 EST
Hello Kalev.

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?

Comment 14 Kalev Lember 2013-01-16 20:39:05 EST
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.
Comment 15 Jaromír Cápík 2013-01-17 11:34:43 EST
Of course I can. Strange thing is, that the miniature shown when I try to drag from the chessboard is displayed correctly.
Comment 16 Jaromír Cápík 2013-01-17 11:38:59 EST
I've taken few videos demonstrating the problem ...


... and going to report the issue upstream.
Comment 17 Jaromír Cápík 2013-05-22 14:17:42 EDT
Hello Kalev.

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.

Comment 18 Kalev Lember 2013-05-25 17:54:40 EDT
Awesome, I love bugs that fix themselves :)

Note You need to log in before you can comment on or make changes to this bug.