GNOME Bugzilla – Bug 740994
colord screen profile change print output with EoG
Last modified: 2021-06-19 08:48:05 UTC
First I'm using Eog 3.14.1 to print. I've been printing since years on an Epson 3880 with a proper screen profile for my display. I'm using an home made printer profile to convert my tiff before sending it to the printer using EoG. Since 3 or 4 months (I cannot remmeber now!) I had print issues. That is the print is not good with a string pink/red tint. I've been suspecting CUPS at some point (see Debian bug tracker #763517). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763517 After analysis we've been suspecting colord (see colord bug tracker #86881) https://bugs.freedesktop.org/show_bug.cgi?id=86881 After many tries I have now found the issue. The screen profile set with gnome-color-manager and handled by colord mess with the print. This seems an EoG issue has colord analysis has not revealed something wrong and further more the print is ok when done with shotwell for example. I've conducted 3 experiments to be sure: 1. I've created a new user on my machine and I have printed a picture. The print is ok. 2. In this new user I have assigned the display profile I use for my account. The display was then correct but then the print has this redish color cast. 3. In my account, where the print was not correct, I have disabled the screen profile. This display is wrong but the print is now correct. So this seems to indicate that somehow the screen profile is used by EoG. Let me know if you need more information.
I had a look at the code and I'm wondering if the issue is not because: 1. in eog_job_load_cb we apply the display profile to the image #ifdef HAVE_LCMS eog_image_apply_display_profile (job->image, priv->display_profile); #endif Where job-image is the EogImage. 2. in eog_window_print we print the window->priv->image and window->priv->image is the image above with the display profile. Now, I don't know why this is happening only now as this code is there since a long time, or maybe the code has been activated recently HAVE_LCMS? I'm on Debian. Do you think the above could effectively be the problem? I'm no expert on profile handling (even if I do understand good part) but is it really necessary to apply a display profile to an image? Isn't it sufficient to send the pixels as-is to the display which is properly calibrated?
Just wanted to add that I'm setup to build eog, so if you want me to test some patch let me know.
(In reply to comment #1) > I had a look at the code and I'm wondering if the issue is not because: > > 1. in eog_job_load_cb we apply the display profile to the image > > #ifdef HAVE_LCMS > eog_image_apply_display_profile (job->image, > priv->display_profile); > #endif > > Where job-image is the EogImage. > > 2. in eog_window_print we print the window->priv->image > > and window->priv->image is the image above with the display profile. > > Now, I don't know why this is happening only now as this code is there since a > long time, or maybe the code has been activated recently HAVE_LCMS? I'm on > Debian. > > > Do you think the above could effectively be the problem? Yeah, the thing is that eog only recently started to color correct TIFF images, which is why you saw no effect before. So the image was printed as it was. Now the image is color corrected and unfortunately that corrected image data is sent to the printer. Since there is no way for us to get a color profile for the printer, we have two options. Color correcting the printed data to sRGB or sending the image data as it is in file, which I think can be false as well. Hmm, let me think about that. > I'm no expert on profile handling (even if I do understand good part) but is it > really necessary to apply a display profile to an image? Isn't it sufficient to > send the pixels as-is to the display which is properly calibrated? That would only be correct if your display has the same color space the image has. So, usually images have the sRGB color space. If your display is calibrated for sRGB you won't see a difference between a color corrected and a not corrected image. However, if your display has a different colorspace the colors will be different between the two images as well. At least, that's my understanding.
Hello! > Yeah, the thing is that eog only recently started to color correct TIFF images, > which is why you saw no effect before. So the image was printed as it was. Now > the image is color corrected and unfortunately that corrected image data is > sent to the printer. Ok, that explains why it was ok before. > Since there is no way for us to get a color profile for the printer, we have > two options. Color correcting the printed data to sRGB or sending the image > data as it is in file, which I think can be false as well. > > Hmm, let me think about that. I think it should be sent to the printer as-is. This leave at least the possibility to users to do cm before hand. I'm doing that using tificc to change my picture to a home-made ICC for my printer. Also if I understand correctly this is exactly what was done before by eog, right?
(In reply to comment #4) > I think it should be sent to the printer as-is. This leave at least the > possibility to users to do cm before hand. I'm doing that using tificc > to change my picture to a home-made ICC for my printer. Also if I > understand correctly this is exactly what was done before by eog, right? Partially. For TIFF images this would return to the previous behaviour. PNGs can however display the same behaviour for quite some time now. JPEGs are a bit different as they are wrapped as is into a PDF container and sent to the printer (and thus would in theory require the printer to color correct). The problem with sending the image as is, is that eog would have to reload the image as the only image data still available is the color corrected data. That would effectively double the memory requirements for printing quite a lot (a decoded TIFF image requires wxhx4 Bytes)
I understand for the memory needed, but do you see another option? The memory needed is only at the time of the print and can be deallocated just after.
Any news about this issue? Thanks.
I am not really sure about what's the right way yet. Actually I currently think that the image should be converted to sRGB at first before printing as the image might look off, if it has a different color profile embedded. However, that makes me wonder about what happens with JPEGs. They don't use the decoded image data, but are sent to CUPS as is (the PDF container has information about the rotation if necessary). Somewhere an embedded profile would have to be applied (either in the printer or in CUPS).
> the image should be converted to sRGB at first before printing as the > image might look off, if it has a different color profile embedded. I'm not sure this is a good idea, again I'm no expert but from what I understand CUPS is now color-managed and can use embedded profile in an image. Won't this break the CUPS's color-management? > Somewhere an embedded profile > would have to be applied (either in the printer or in CUPS). Right, CUPS will do that. All these color-management issues are very delicate, so I may be confused.
Hello Felix, any news to share on this issue? I don't think this is fixed in 3.16 do you think that a fix is possible for the 3.18 release? Thanks.
Hi Pascal, unfortunately I didn't find the time to look deeper into this again yet. So, I can't promise you a real fix for 3.18 right now. I found some webpages that indicate that CUPS in fact is able to do color correction now. So, I'll guess I'll try to look into that direction. However, I doubt that having eog make use of that will be a small change.
Sorry to ping you again :) Just wanted to know if this has been fixed in 3.18 (just released)? The issue is really bad as every people printing from EoG to create a printer profile (for example) are just messing the chain of color management. This happened to me! Anyway, crossing fingers for 3.18! Thanks.
Unfortunately not. I didn't manage to accomplish a lot this cycle due to my limited time in the last months. :(
I'm back here to have some news! This issue is very annoying. Any chance to see this fixed or is it already fixed in 3.22 to be out soon.
No, sorry. I entirely missed the 3.22 cycle which is why GNOME 3.22 still has eog 3.20.
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.