GNOME Bugzilla – Bug 567551
Problem in converting jpeg taken with Kodak RGB to sRGB color map
Last modified: 2009-07-02 19:50:25 UTC
In Ubuntu 8.10 I have gimp 2.6.3-1ubuntu1. I'm not a photo expert, but I've been reading and I believe this problem should not happen. On Celebutopia.net, I found a photo that somebody had taken and when gimp tries to open it, gimp says the color map is Kodak (1998) and it asks permission to convert to sRGB. I always just say "yes" and don't see any damage. However, in this case, the colors become distorted and there is no way to recover them. If you open the image in a viewer such as GQview or F-spot photo viewer, the viewer (apparently) uses the Kodak color map that is saved with the image, but Gimp does not. I downloaded an alternative image editor called "imagej" and with that, I was able to open the image and convert it to tiff, which I could then edit in gimp and then save in jpg format. Almost all the time, Gimp does a good job of converting the colormap. However, as I review a relatively large collection of snapshots, I am suspecting that the Kodak scale is not being converted correctly to sRGB where it concerns the shades of orange/flesh tones. But, then again, I'm not a photo expert. I am looking for an option to upload the image for your analysis. I have seen other bugzilla that allow attachments at a later stage in submission..
Created attachment 126325 [details] jpg image that uses kodak RGB Gimp's conversion to sRGB does not maintain image color quality.
Created attachment 126326 [details] same image opened with gimp, converted to sRGB, and saved
Please report this against the littleCMS library. I am pretty sure we are using it correctly. So the problem, if there is one, is more likely to be found there.
I don't understand what you mean "the problem, if there is one." Don't you see color degradation between the original jpg and the jpg that Gimp creates after converting the colormap? You could at least give me a start by telling me where to report bugs in littleCMS. I'm not a developer, I think I mentioned.
Hi, that's Marti Maria, lcms author. I've tracked the source of this apparent bug, and found the image is embedding Adobe1998, a very common colorspace. The image that comes out from gimp is basically correct, as I've compared against photoshop and results are same (I used a calibrated LaCIE electron22blueIV to do the comparison, they are identical). BUT, the embedded profile on the output image is still Adobe1998, when it should be sRGB. For any non-color savvy app, this make no difference, but an application honoring the embedded profile would try to display the sRGB image as it would be AdobeRGB. Obviously this is wrong. I wonder who has embedded AdobeRGB in the output image.
I will need to check the GIMP code then and make sure that it removes the embedded profile when converting to sRGB, as it should.
I have checked the code and the lcms plug-in does definitely unset the color profile when converting to sRGB. And it embeds the destination color profile when converting to a working space different than sRGB. Also when opening the saved image again, the JPEG plug-in does not see an embedded color profile. I don't quite understand why Marti claims that the output image would have an embedded profile. I can't detect any and the JPEG plug-in can't either. The identify tool from ImageMagick also only detects an ICC profile (Adobe RGB) in the input image, not in the image that was saved from GIMP after converting to sRGB.
Sven, I was talking about the sample image. I don't know what gimp plugin does. If it doesn't embed any profile, that's fine. My point was the sample image were in sRGB space and had AdobeRGB embedded, which is obviously wrong. I wonder if the original poster messed up tools. That is quite frequent, first and most important issue on color management world is miscofigured workflows.
OK, so there is no bug here then. Thanks for the feedback.
Created attachment 137478 [details] Bruna-orig.jpg is the image as it was found.
Created attachment 137479 [details] Bruna-keepColormap results from keeping current colormap Open in Gimp, say NO when asked to convert colormap. Then Save As without making any other changes.
Created attachment 137480 [details] Bruna-convertColormap results from accepting Gimp's invitation to change colormap Open in Gimp, Accept the menu's invitation to convert from the Kodak to the Gimp's colormap. Then Save As without making any other changes. Notice that the colors look awful.
I still think there is something wrong with Gimp. I'm not a programmer, and can't tell you what it is, but I can tell you the result is bad if I say YES when Gimp invites to convert the colormap. Please compare the quality of Bruna-keepColormap against Bruna-convertColormap. The keepColormap result is not visually different from original (except for slight JPEG lossiness), but the convertColomap result is poor. As far as I can tell, there is no way a "user configuration mistake" is causing this problem. Gimp handles the colormap conversion, Gimp saves the image. You do agree the convertColomap result is bad, don't you? pj
Hi Paul Yes, what GIMP does make the image look bad, we can all see that, but the conclusion so far is that it is the source image that is the problem. Apparently, the source image is in the sRGB color space but has an AdobeRGB color profile embedded, which is wrong of course. This is what causes GIMP to make the image look bad. What exactly is it that makes you think the conclusion drawn in this bug report is wrong?
I am just a user, not a programmer. I thought you were saying that I was making a point-and-click mistake in Gimp menus before. I did not realize you were saying the problem was in the image as originally presented, before using the Gimp. If you can look at the file and see there is something wrong, can't you make Gimp fix it?
Not without hugely complex heuristics, if it even is possible. Feeding GIMP properly color managed images is a much better solution to this problem. Closing as INVALID again.
You can make GIMP fix the image for you. Just open it without doing a color conversion. Then unset the wrongly attached color profile and save. Note though that this is a lossy operation as GIMP will recompress the JPEG image. There are tools that allow you to remove the color profile without touching the image data, so I'd suggest you use such a tool instead. If you have further questions, please ask them on the gimp-user mailing-list, not here.