GNOME Bugzilla – Bug 783910
Color management not working (Fedora 25 / Wayland / JPG images developed with Darktable)
Last modified: 2021-06-19 08:46:44 UTC
Created attachment 353968 [details] Sample picture I use colord in a color-managed photography workflow based on Darktable, on Fedora 25, Gnome 3.22, default login on Wayland. My display is calibrated (ColorHug) and colord in enabled. Darktable is configured to use the system ICC profile - works perfectly. Exported JPGs from darktable look fine in Firefox (54), Chrome (59 - they added color management for linux not too long ago), and in Geeqie. In Eye-of-Gnome / Gnome-image-viewer the colors are completely off, exactly like Shotwell and GThumb. I believe EOG used to support color management at some point and it broke, or perhaps it never worked properly. Not sure if EOG is having problems reading the image profile from JPGs generated from Darktable and/or the System profile, so that it can then do the transformation. I attach a sample JPG picture. Generated from a Nikon D500 raw. I also tested with older images created with AfterShot from a Nikon 7100, same issue, colors are way off in EOG, but OK in DT/Firefox/Geeqie. For the attached picture, Darktable = Firefox = Chrome = Geeqie (with color management activated). Gthumb = Shotwell Viewer = EOG: colors are way off. When I turn off Color Management in Geeqie, then the result looks the same as Gthumb/Shotwell/EOG: this seems to indicate EOG color management is not working for some reason.
Well, color correction not working correctly under Wayland is a known problem, as we cannot "ask" the display for its profile as we do under X: bug 776888. However, it should still do a color transform to sRGB. Apparently the fix for bug 776984 doesn't work as expected. Could you try opening the file with EOG_DEBUG_IMAGE_DATA=1 EOG_DEBUG_LCMS=1 set and post the output?
I tried. Very interesting findings. When I open EOG from the command line, it actually works well, it colors-manages the image. - When I open the same image double clicking in nautilus, then the colors are off. - When I open Image Viewer from GNOME's Activities overview / App list, and then open the image using it, then the colors are off too. - When I run eog using GNOME Shell Alt-F2 and typing eog, and then open the image, the colors are off too. When I run EOG by opening a terminal, and then typing eog in it - then it works well. This is 100% consistent and reproducible, it's very strange. Looks like EOG is missing some environment context unless it is run from a terminal. I post the output of a CLI run just for reference, it actually works well when running it from the command line. This is on Fedora 25, patched as of today, GTK 3.22.15, GLib 2.50.3 Wayland session. ------------------------------ env EOG_DEBUG_IMAGE_DATA=1 EOG_DEBUG_LCMS=1 eog [3.256093 (3.256093)] eog-image.c:522 (check_for_metadata_img_format) Check image format for jpeg: ffd8 - length: 65535 [3.256134 (0.000041)] eog-metadata-reader-jpg.c:237 (eog_metadata_reader_jpg_consume) APPx or COM Marker Found: e0 [3.256141 (0.000007)] eog-metadata-reader-jpg.c:279 (eog_metadata_reader_jpg_consume) Skip bytes: 14 [3.256145 (0.000004)] eog-metadata-reader-jpg.c:237 (eog_metadata_reader_jpg_consume) APPx or COM Marker Found: e1 [3.256149 (0.000004)] eog-metadata-reader-jpg.c:295 (eog_metadata_reader_jpg_consume) Read APP1 data, Length: 39644 [3.256165 (0.000016)] eog-metadata-reader-jpg.c:237 (eog_metadata_reader_jpg_consume) APPx or COM Marker Found: e1 [3.256169 (0.000004)] eog-metadata-reader-jpg.c:295 (eog_metadata_reader_jpg_consume) Read APP1 data, Length: 8004 [3.256174 (0.000005)] eog-metadata-reader-jpg.c:237 (eog_metadata_reader_jpg_consume) APPx or COM Marker Found: e2 [3.256178 (0.000004)] eog-metadata-reader-jpg.c:364 (eog_metadata_reader_jpg_consume) Read continuation of ICC data, length: 8954 [3.256278 (0.000100)] eog-metadata-reader-jpg.c:517 (eog_metadata_reader_jpg_get_icc_profile) JPEG has ICC profile (eog:22655): Gtk-WARNING **: Allocating size to EogStatusbar 0x55f7506e9560 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(In reply to Felix Riemann from comment #1) > However, it should still do a color transform to sRGB. Apparently the fix > for bug 776984 doesn't work as expected. Ah, I totally missed that F25 still has eog-3.20.5, which doesn't contain the fix for bug 776984. But that means there's also nothing to see in the log output about Wayland. It's weird that it works from the console... Maybe eog is pushed into XWayland from there. Could you try eog from the terminal with GDK_BACKEND=x11 and GDK_BACKEND=wayland? The former should use XWayland and provide color correction if your profiles are setup correctly while the latter shouldn't do color correction. Could you also verify the eog version from the app menu when you launch it from the GUI? It should in all cases be 3.20.5 on F25. Not that some newer version slipped in (e.g. via Flatpak).
Tested: env GDK_BACKEND=wayland eog ... does NOT work properly env GDK_BACKEND=x11 eog ... works FINE Clearly a problem with Wayland. That's why running eog from the Applications menu or via Alt-F2 shows the problem. Now one clarification, running eog in my terminal without specifying backend works fine. I realized though that I run my terminal like this: env GDK_BACKEND=x11 tilix Which explains why eog works when launched from a terminal.
The Wayland issue persists on Fedora 26 / EOG 3.24.1 The workaround above still works (changing backend to X11). Geeqie continues to 'just work' on wayland by default.
(In reply to Ariel from comment #5) > The Wayland issue persists on Fedora 26 / EOG 3.24.1 That is weird it should at least to a transform to sRGB. EOG_DEBUG_LCMS should print something like this: [0,029331 (0,029331)] eog-window.c:465 (eog_window_get_display_profile) Not an X11 screen. Cannot fetch display profile. [0,030155 (0,000824)] eog-window.c:472 (eog_window_get_display_profile) No valid display profile set, assuming sRGB [0,123880 (0,093725)] eog-metadata-reader-jpg.c:517 (eog_metadata_reader_jpg_get_icc_profile) JPEG has ICC profile > The workaround above still works (changing backend to X11). Geeqie continues > to 'just work' on wayland by default. Geeqie still uses GTK2 which falls back to XWayland on Wayland and thus is similar to setting GDK_BACKEND=x11.
(In reply to Felix Riemann from comment #6) > (In reply to Ariel from comment #5) > > The Wayland issue persists on Fedora 26 / EOG 3.24.1 > > That is weird it should at least to a transform to sRGB. EOG_DEBUG_LCMS > should print something like this: > > [0,029331 (0,029331)] eog-window.c:465 (eog_window_get_display_profile) Not > an X11 screen. Cannot fetch display profile. > [0,030155 (0,000824)] eog-window.c:472 (eog_window_get_display_profile) No > valid display profile set, assuming sRGB > [0,123880 (0,093725)] eog-metadata-reader-jpg.c:517 > (eog_metadata_reader_jpg_get_icc_profile) JPEG has ICC profile > That's right: env EOG_DEBUG_LCMS=1 eog [0.016351 (0.016351)] eog-window.c:465 (eog_window_get_display_profile) Not an X11 screen. Cannot fetch display profile. [0.016809 (0.000458)] eog-window.c:472 (eog_window_get_display_profile) No valid display profile set, assuming sRGB Good point about geeqie! Darktable though is based on GTK3 and runs native on Wayland, and is able to pick up the color profile from colord 'out of the box' Not sure about firefox or chrome (do they use gtk at all?), but I can confirm that both are able to pick up the system-wide color profile in use.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.