Version: 0.9.4 (using KDE 3.5.9) OS: Linux Installed from: Gentoo Packages When I use DigiKam to prepare images for printing, I always compare the final result using both DigiKam, CinePaint and the GIMP. All applications are configured to use the same color management profiles, rendering intent and blackpoint compensation. Often, it strikes me how different images look in DigiKam compared to the GIMP and CinePaint. The same image viewed using the GIMP and CinePaint look identical, while it looks quite different in DigiKam. When I print my images using a color managed printing lab, both GIMP and CinePaint are spot on. The print matches the display of both applications. So I guess that something is wrong with the color managed view of DigiKam. I will attach some screenshots of photographs shown in all three applications. The screenshots show that the view of DigiKam is quite a bit brighter, and the colors are much warmer.
Created attachment 27694 [details] photo 1 in digikam
Created attachment 27695 [details] photo 1 in cinepaint
Created attachment 27696 [details] photo 1 in GIMP
Created attachment 27697 [details] photo 2 in digikam
Created attachment 27698 [details] photo 2 in cinepaint
Created attachment 27699 [details] photo 2 in GIMP
Despite the fact that I don't see a difference in the provided images (maybe my laptop screen isn't that good), I also think color management is sometimes not working correctly. Often I correct a photo in digiKam and save the results in a new (jpg) image. If I open this image in another software, the colors look always wrong. For example GIMP says that there is an embedded profile and that I can import it. If I do so, colors are wrong. The colors are also wrong if I don't import the profile, so it really doesn't matter what action I'm choosing, images that have been corrected in digiKam are not opened correctly in other software. Same discussion happened here #165650 a while ago...
Hmm shortcut isn't working... http://bugs.kde.org/show_bug.cgi?id=165650
Can you provide me with a testcase, or test current trunk / 1.0-beta4? On my laptop monitor, the colors in the given example images all look the same to me. And I can't test because they are screenshots.
You don't really need an accurate monitor. You can also compare the histograms of the screenshots (only the image areas of course) and you'll see what I mean. On an accurate monitor, the differences you see in the histograms translate into a different looking image. The difference is subtle, but definitely noticeable. So, anyone can test by creating screenshots of their own display and compare histograms. That's much easier and more accurate than looking at the images themselves. Unfortunately I can't test latest digikam at this moment.
Yes, the difference between digiKam and the other two is quite slight, but existing (it also helps to look at them as at a slide-show rather then one next to another). Later this week, I will try myself with the current trunk and report the findings.
That would be great. The color management code has in some parts been rewritten, so old bugs may have been fixed (and new one created...). My problem with this report is that it does not give me a hint at what is wrong (in other reports, digikam did broad things like not using an embedded profile) so if you notice any problem at least provide me with the original image and a hint at the used profiles.
Created attachment 36472 [details] Comparison of AdobeRGB image displayed to sRGB display with various apps It seems that digiKam 1.0.0 beta4 svn as of yesterday does not suffer the described bug anymore (see the attached screenshot and compare with colour checker tool in GIMP. The settings were: AdobeRGB embedded, sRGB working space, sRGB display and "keep the embedded profile"). When I tested with ver. 1.0.0 beta3, digiKam failed to recognise the embedded AdobeRGB and displayed it incorrectly. Dik did not mention what was his setup (embedded profile, display profile, working space profile) and did not provide the original image, so we can just guess if the colour tint was just a result of wrong recognition of the embedded profile or something else. Unless anyone else reports problems, I would suggest to close the bug.
I think this bug entry is still valid. I found a example image at http://www.locus-caementitium.de/download/lcf_galerie.jpg Digikam show other colors than krita (krita is more natural, look for the red seat in front and the wall in the background). The colors of krita also match the colors of windows photo viewer. Applications also wrong: gwenview, XnView. So please reopen this entry.
Created attachment 39312 [details] comparison of digikam and krita
Which color profile is embedded in the photo and how can I access it?
There is no ICC profile embedded. It seems to use some Adobe's markers. Exif.Colorspace is unknown (i.e. not sRGB) and exiftool -v reports: JPEG APP14 (12 bytes): + [BinaryData directory, 7 bytes] | DCTEncodeVersion = 100 | APP14Flags0 = 16384 | APP14Flags1 = 0 | ColorTransform = 2 Some googling results in: JPEG Adobe Tags The "Adobe" APP14 segment stores image encoding information for DCT filters. Index Tag Name Writable Values / Notes 0 DCTEncodeVersion N 1 APP14Flags0 N Bit 15 = Encoded with Blend=1 downsampling 2 APP14Flags1 N 3 ColorTransform N 0 = Unknown (RGB or CMYK) 1 = YCbCr 2 = YCCK I do not know what it means from the viewpoint of colour management. Both CinePaint and GIMP display the image the same (probably like Krita). GIMP assigns sRGB and CinePaints assigns uncoated FOGRA CMYK profile (by argyllcms) to the decoded image. Non-colour managed ImageMagick's display command shows the channels swapped (like CMYK). Eye Of Gnome and DigiKam show the channels right, but oversaturated as in the attachment by Jens.
Sorry, i dont know what color profile is embedded in this image. It is not a image of mine, i found it in another bug entry, #105006. But I think the hint is here that the image is encoded in cmyk colorspace compared to "normal" srgb digitalcamera images.
It is a question what to do in case of a CMYK image without embedded ICC profile. There is no straightforward transform to RGB model, hence the ICC profile of the device (printer) for which the image was created is needed. Interestingly, only CinePaint and Krita work with the image as with CMYK. GIMP probably does internal conversion (how?) to RGB and assign sRGB profile then. CinePaint assigns coated FOGRA CMYK profile (I mistyped in my above comment) and Krita some internal CMYK profile (Offset printing, ISO/DIS 12647-2:2004, which is also default CMYK printer profile in the settings). I wonder whether the Adobe APP14 markers refer to a particular CMYK standard or not.
I just checked with our JPEG loader. The YCCK->CMYK conversion is done by libjpeg internally. We then convert to RGB using a simplistic routine that we took from Qt's JPEG loader: int k = ptr[3]; ptr2[3] = 0xFF; ptr2[2] = k * ptr[0] / 255; ptr2[1] = k * ptr[1] / 255; ptr2[0] = k * ptr[2] / 255; Not more. I dont know if assigning any CMYK ICC profile and later converting to sRGB would improve the general case of any given CMYK image here.
The routine is a general way to get the rgb components out of the cmy components multipilied with the back component. But for real color vision they have to be adjusted by a cms. The problem with the testfile is that there is no icc embedded as milan already pointed out (this should not be the case, especially for offset printing prepared images). 'identify -verbose' say that the image was edited by photoshop 7. So i don't know if other applications make some assumptions about adobe markers. And what are they?
I found a realy good example showing wrong colors in preview widget but not in thumbnail-view and edit-mode. Look for http://scummos.sc.funpic.de/upload/farbkreis.jpg from #157200. The words should match the colors, Red should be on top for not english speakers. But thats only the case in thumnail-view, thumbnail-bar and when you click on edit image.
Created attachment 39347 [details] showing wrong colors in digikam preview (red should be on top)
(In reply to comment #23) > Created an attachment (id=39347) [details] > showing wrong colors in digikam preview (red should be on top) Jens - this is something different. The image farbkreis.jpg is in RGB colorspace with a specific ICC profile, which helps the user to see quickly when Colour Management does not work. In DigiKam, when CM is off, it is expected to see the RGB image as is, without any colour transform. The question is, whether thumbnails should still be generated as if CM is on, I think they should as it is now.
Milan you are right, that are two separate problems. - The second showing a bug with not applied cms in preview (cms is turned on!). - The first is a special case of cmyk image data with no embedded icc. But both are problems with inaccurate color management view. But properly it is better to put them in different bug reports next time.
(In reply to comment #20) > I dont know if assigning any CMYK ICC profile and later converting to sRGB > would improve the general case of any given CMYK image here. I have done more testing with GIMP, CinePaint, EoG, Krita (and digiKam). Basically, all of them display the CMYK image w/o any ICC profile differently. CinePaint: somehow selects a default CMYK ICC profile (even that not set in settings). I guess it is related to Oyranos project, which was implemented for CinePaint as a show case (even that I have it switched off). Of course, the user can assign a different profile in the editor. Krita: automatically assigns a CMYK ICC profile (internal). The user can assign another profile manually in the editor. GIMP: automatically converts the image from CMYK to RGB using the default CMYK profile from the Settings. If none chosen, it probably does something similar to the current digiKam's implementation. (Yet, the displayed images are different.) Out of these, GIMP converts the image to RGB, while CinePaint and Krita continue to work with the image in CMYK. I have not found any information on APP14, whether there is an assumed CMYK / Offset standard or not. I assume not and that the ICC profile should be ideally embedded. For digiKam, I would propose similar behaviour like in GIMP: If the CMYK image has an embedded profile, it should be used (for thumbnail, preview and editor). If the CMYK image does not have embedded profile, digiKam should use the default one from Settings (does not exist yet...). Further, in case digiKam editor being set to ask when there is a mismatch between the embedded and working profiles, the user should have a chance to select CMYK profiles from drop-down list. (Now CMYK profiles are not listed.) If the user does not set a default CMYK profile or does not use colour management, then the current method of simple CMY -> (s)RGB conversion could be used.
I follow Milans suggestion of digikam behaviour for cymk images in all cases. From point of implementation i have one notice. What about the following chain: first convert the cmyk image to internal buffered rgb dimg by standard approach. Set the contained profile (from the embedded one or a standard one if no one exists). In a second strep: for all use cases do the cmstransform from rgb to display/working profile (normally srgb). I dont know if that is possible, but with the cms on/off selection the second step can simply omitted. Questions that rise (sorry i dont know much about icc): -is icc data justified for one special colorspace? In that case the embedded icc must be adopted for rgb. Is that possible?
(In reply to comment #27) > first convert the cmyk image to internal buffered rgb dimg by standard > approach. Set the contained profile (from the embedded one or a standard one if > no one exists). I do not think so. ICC profiles are specific to colour model (RGB, CMYK). Change of colour model from CMYK to RGB is done by littleCMS during the colour transform from CMYK ICC profile to RGB ICC profile.
Argh, for the problem with testimage farbkreis.jpg I did'nt see the unset checkbox 'use color managed view for previews ...' on the second tab in settings. Sorry about that.
I created a new entry for the CMYK issues, bug #220312.