After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756063 - Eye of Gnome (EOG) displays images at lower quality than other applications
Eye of Gnome (EOG) displays images at lower quality than other applications
Status: RESOLVED NOTABUG
Product: eog
Classification: Core
Component: image viewer
3.18.x
Other Linux
: Normal major
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-04 22:06 UTC by Audrey Toskin
Modified: 2015-12-08 00:45 UTC
See Also:
GNOME target: ---
GNOME version: 3.15/3.16



Description Audrey Toskin 2015-10-04 22:06:31 UTC
## The Problem

The GNOME Image Viewer / Eye of GNOME (eog), displays images at a lower quality than Firefox or other image viewers do. In EOG, the brightness, noise, and artifacts / color blocking increase.

Images render poorly for me in Eye of MATE too, but they look better in Shotwell, Mirage, Ivy, Firefox, and others. 

This has been a consistent problem for me for a while, but at least a few other users on reddit have confirmed the issue on their systems -- https://www.reddit.com/r/gnome/comments/3nezim/anyone_else_having_this_issue_eye_of_gnome_eog/


## My system setup

I'm running Eye of GNOME v3.16.3 on Fedora 22 (64-bit), using GNOME Shell 3.16 as my desktop. My graphics card is a Nvidia GeForce 9600 GT, and I'm using the proprietary drivers from RPM Fusion -- akmod-nvidia-340xx.x86_64 -- although I noticed this problem before when I was still using the open-source drivers. 


## Example screenshots

Some images look worse than others, so let's look at a specific example.

Bugzilla doesn't directly directly embedding the images, so I think it will be easier to just link the images.

Here's the *original* version of one of the images that I tested -- https://ia902303.us.archive.org/25/items/A-Crown-of-Lights--by-Andrew-Toskin/NIC_0595-sd.jpg

Here's a screenshot of that same image, as seen in Firefox -- https://farm1.staticflickr.com/713/21461035106_73cb9878f5_o.png

And here's a screenshot of the image, as seen in EOG -- https://farm1.staticflickr.com/732/21487277555_17888cff5d_o.png

You'll notice that in EOG, the brightness, noise, and artifacts / color blocking increase.


## What I've tried

I tried checking and unchecking EOG's image enhancement settings, and I can't really see any difference.

I used to think this was a problem in how EOG scaled large images, but the original image I tested this is small enough to fit on my screen without scaling.

Bug 737440 -- https://bugzilla.gnome.org/show_bug.cgi?id=737440 -- is similar, but my issue goes beyond brightness and saturation; the GNOME Image Viewer is actually adding noise and artifacts.
Comment 1 Audrey Toskin 2015-12-03 05:56:46 UTC
I'm starting to think this might be an issue of supporting the various color spaces.

I noticed similar a similar problem when exporting an image I created in the digital painting program, Krita. *All* desktop image viewers that I tried rendered the image as darker and noisier than it appeared when I was working on it in Krita. Firefox still rendered the image correctly, however.

Krita, by default, uses the sRGB-elle-V2-g10 color space. When I converted the image to "sRGB built-in", the exported images looked normal in all applications.

Perhaps Eye of GNOME doesn't support whatever color space used by the photo in my original post? I honestly don't know a whole lot about color profiles, but I checked the image properties in EOG, and it says the color space is just plain "sRGB." The photo was shot with a Nikon D700 (digital SLR camera), and the raw file developed with the program Darktable.
Comment 2 Audrey Toskin 2015-12-03 05:58:29 UTC
The issue persists in EOG and GNOME version 3.18, by the way.
Comment 3 Felix Riemann 2015-12-04 18:56:38 UTC
Yes, it's probably a matter of the color profiles. On my system the image looks like your Firefox example.

The image has no color profile embedded, so eog assumes the image is in the sRGB (aka "sRGB builtin") color space. So, now it pretty much depends on whether there's one set for your display. Can you open the image from the console like this and post the output:

EOG_DEBUG_LCMS=1 eog NIC_0595-sd.jpg

You can also check int the "Color" widget in the gnome settings panel if there's a profile set for your display.
Comment 4 Audrey Toskin 2015-12-05 04:30:43 UTC
I looked at Color in GNOME Settings, and there's a profile for my monitor: "Automatic - SyncMaster." (My monitor is a Samsung SyncMaster P2250.) When I clicked View Details, it showed that I have a file at ~/.local/share/icc/edid-27f32dde3a469e0599af58fc79bc0167.icc. So I guess do have a profile, but I never manually installed one, and haven't been able to calibrate the screen.

Here's what I got when I ran the EOG commandline you suggested.

$ EOG_DEBUG_LCMS=1 eog NIC_0595-sd.jpg
[0.534762 (0.534762)] eog-metadata-reader-jpg.c:545 (eog_metadata_reader_jpg_get_icc_profile) JPEG is sRGB
Comment 5 Felix Riemann 2015-12-06 12:59:22 UTC
Yes, eog is using the set profile to color correct your image.

The profile has been autogenerated using the EDID data gnome-color-manager can query from your monitor. Maybe it contains some values that are not quite fitting.
If you disable the profile the image should look as expected as the color conversion is a no-op then (sRGB -> sRGB).

However, I would have expected that the image looks somewhat the same if you view it in Darktable as it (IIRC) does color profiling as well. What are your color profile settings in Darktable? (IIRC they are split into input and output settings)
Comment 6 Audrey Toskin 2015-12-06 23:22:48 UTC
Interesting: Disabling the monitor color profile *does* make EOG render the image the way that it should. Does this mean that the problem was that EOG checks the monitor's crappy color profile, but the other image viewers ignore the profile or use their own? Should I keep the monitor profile turned off permanently?

Darktable does split color profile settings into input and output. The input color profile I used is "enhanced color matrix", but I think that's just the starting point, before I make any adjustments to the image. The output color profile is "sRGB (web safe)".
Comment 7 Felix Riemann 2015-12-07 18:33:12 UTC
(In reply to terrycloth from comment #6)
> Interesting: Disabling the monitor color profile *does* make EOG render the
> image the way that it should. Does this mean that the problem was that EOG
> checks the monitor's crappy color profile, but the other image viewers
> ignore the profile or use their own? Should I keep the monitor profile
> turned off permanently?

Yes, I think the profile is likely the problem here. 

> Darktable does split color profile settings into input and output. The input
> color profile I used is "enhanced color matrix", but I think that's just the
> starting point, before I make any adjustments to the image. The output color
> profile is "sRGB (web safe)".

Haven't heard of that matrix-profile before. On my system the input color profile field says "sRGB (e.g. JPEG)" in Darktable.

The interesting setting is the "display profile" field in the output settings. If it says "system display profile" Darktable should apply your display profile as well which should produce an image similar to eog. You should also see a difference if you switch to the other options (esp. sRGB).
Comment 8 Audrey Toskin 2015-12-08 00:45:10 UTC
Yeah, Darktable's "display profile" wasn't rendering the image quite as well as the output, but I'd always thought it just didn't have a very good image preview, or that it was scaling the large original file poorly, or it was an issue of too little RAM. Still, Darktable's preview actually wasn't as bad as EOG was.

Either way, the color profile *for my monitor* was the problem, so I guess I'll keep it disabled unless or until I can get a colorimeter to properly calibrate the monitor.