The same bug/problem still exists in 1.0.0 beta 1 (tested on OpenSuse 11.1 64-bit, compiled form source). In normal viewing mode color management is not used and color profile settings are ignored.

SVN commit 1014769 by mwiesweg:

Enabling color management for previews.
The transform is applied once in the thread, so there is no speed problem
like for color managed view in the editor.
Add support to set a displaying widget for a PreviewLoadThread.

CCBUG: 195050

 M  +1 -1      loadsavetask.cpp  
 M  +11 -0     previewloadthread.cpp  
 M  +7 -0      previewloadthread.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1014769

SVN commit 1014770 by mwiesweg:

Enable color management for thumbnails.
The transformation is done on the final scaled QImage when creating a thumbnail
if an embedded ICC profile was read before. Applying to a very small image is is very fast.
We then store and display the thumbnails as sRGB.
There is so much quality loss already in a thumbnail that the little imperfection of ignoring the monitor
profile should be ok.

CCBUG: 195050

 M  +25 -13    thumbnailcreator.cpp  
 M  +2 -1      thumbnailcreator.h  
 M  +12 -4     thumbnailloadthread.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1014770

SVN commit 1014771 by mwiesweg:

Set displaying widgets to retrieve monitor profile, if set, to preview views.

BUG: 195050

 M  +2 -1      NEWS  
 M  +2 -0      digikam/imagepreviewview.cpp  
 M  +2 -1      utilities/batch/fingerprintsgenerator.cpp  
 M  +2 -0      utilities/lighttable/lighttablepreview.cpp  
 M  +2 -0      utilities/slideshow/slideshow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1014771

Thanks Marcel for working on this bug! It's much appreciatated :-)

However, I hope you could change your fix to apply the display profile to thumbnails too, if colour management is enabled. You said "There is so much quality loss already in a thumbnail that the little imperfection of ignoring the monitor profile should be ok".

However, many new displays are wide gamut displays whose native colour space is *far* from sRGB (most new 24" and larger lcds are wide gamut now, and their prices are dropping fast). On those displays converting to sRGB and ignoring the display profile ensures that the thumbnail looks terrible!

So, I would ask you to consider reopening this bug. Wide gamut displays are becoming the norm with photo enthusiasts, so for thumbnails the current fix does not solve the problems in the long run. If full color management of thumbnails is considered too slow, I suggest either reverting the patch for thumbnails completely, or introducing a new user preference.

Matti Rintala

Marcel,

Matti reflexion is right. I vote for a user settings to turn on/off thumbnails CM.

Gilles Caulier

I will add a user preference. This adds a bit of overhead, maybe not too much, but I'm not sure.

Matti talked about displaying, which is all right; I also talked about storage - so do you agree that we _store_ the thumbnails files (in the thumbnail db) in sRGB?
Converting to monitor profile is done when loading the precreated thumbnail.

(In reply to comment #8)
> Matti talked about displaying, which is all right; I also talked about storage
> - so do you agree that we _store_ the thumbnails files (in the thumbnail db) in
> sRGB?
> Converting to monitor profile is done when loading the precreated thumbnail.

I think storing the thumbnails in sRGB is fine, if they are converted to display profile when displayed. The only loss then are the occasional out-of-gamut colors in part of the thumbnail, but as you said, thumbnails are not meant to be critically viewed, anyway.

I understand that you don't want to store the thumbnails in their original colour space, as that would imply storing their colour profiles as well.

I think storing thumbnails in sRGB is smart! I suggest that conversion to sRGB should happen even with Color Management turned off.

SVN commit 1016022 by mwiesweg:

Enable color managed display of thumbnails if color management in enabled.
Dedicated setup option comes if profiling shows it has a significant impact,
but I found some issues to sort out in the thumbnail loading before.
Allow to set displaying widget for thumbnail color management.
Extend ThumbnailTask for post processing like the other tasks
(could get some refactoring for code reuse in the future)

CCBUG: 195050

 M  +1 -0      digikam/digikamapp.cpp  
 M  +31 -12    libs/threadimageio/thumbnailloadthread.cpp  
 M  +6 -0      libs/threadimageio/thumbnailloadthread.h  
 M  +51 -15    libs/threadimageio/thumbnailtask.cpp  
 M  +5 -0      libs/threadimageio/thumbnailtask.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1016022

SVN commit 1017009 by mwiesweg:

Put previews in color managed form into the cache so that preloading is fast.

CCBUG: 195050

 M  +6 -1      previewtask.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1017009

SVN commit 1017010 by mwiesweg:

Add a settings to enable color managed view for thumbnails and previews

CCBUG: 195050

 M  +3 -0      imageeditor/canvas/iccsettingscontainer.cpp  
 M  +1 -0      imageeditor/canvas/iccsettingscontainer.h  
 M  +15 -5     setup/setupicc.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1017010

Color managed view is now fully implemented for previews and thumbnails. Please test this functionality with the coming beta4. We can close this bug if no problems are found.

I compiled beta4 and tried color management. Mostly things seemed ok, so thanks for this improvement!

However, there's one thing that still makes this unusable for me:

It seems Digikam doesn't recognise the (preview) profile of my Nikon NEF raw files. Based on my screen testing it seems that it (wrongly) assumes that my NEF previews are in sRGB profile even though they are in AdobeRGB.

I know that profile information is in the NEF file, since GQView succesfully recognises and uses the profile.

Matti, can you send me a sample NEF file? (per private mail is ok)

It definitely works and makes using digikam even greater pleasure!

As I was looking at the thumbnails it seems to me, that these are color managed all the time, even when the color management is turned off. Seems like Color Management settings are ignored for thumbnails (though it works perfectly for view mode).

Maybe there should also be menu switch under View tab (like it's in Editor) to turn color management on or off. Although I don't need this really... Great job anyway, thank you!

Thumbnail cache is not cleared currently, probably you switched it off and had still the color managed thumbnails from the cache. I did not expect this setting to be changed all too often.

Oh, so images are stored in monitor color space in cache? This makes sense, right. 

I have one more request. Can we have color management in Slideshow module too? It seems to be last part od digikam which is color management unaware...

Created attachment 36607 [details]
Output of exiftool for several different Nikon image files

Here are outputs of exiftool for several different Nikon image files:
d300-srgb.nef.txt: Nikon D300 sRGB raw from camera
d300-srgb.jpg.txt: Nikon D300 sRGB JPG from camera
d300-adobergb.nef.txt: Nikon D300 AdobeRGB raw from camera
d300-adobergb.jpg.txt: Nikon D300 AdobeRGB JPG from camera
d300-srgb-to-adobergb.nef.txt: Nikon D300 sRGB raw edited in Capture NX2, stored as AdobeRGB raw
d300-srgb-to-adobergb.jpg.txt: Nikon D300 sRGB raw edited in Capture NX2, stored as AdobeRGB JPG
d40-srgb.nef.txt: Nikon D40 sRGB raw from camera
d40-srgb.jpg.txt: Nikon D40 sRGB JPG from camera
d40-adobergb.nef.txt: Nikon D40 AdobeRGB raw from camera
d40-adobergb.jpg.txt: Nikon D40 AdobeRGB JPG from camera
d40-srgb-to-adobergb.nef.txt: Nikon D40 sRGB raw edited in Capture NX2, stored as AdobeRGB raw
d40-srgb-to-adobergb.jpg.txt: Nikon D40 sRGB raw edited in Capture NX2, stored as AdobeRGB JPG

Here are come comments concerning the attacment I just created:

I'll send Marcel the actual image files for further study.

I took the same picture with Nikon D40 and D300 with several settings:
- Raw (nef) and jpg
- Camera set up to store image as sRGB and AdobeRGB
- I edited a raw image with Nikon Capture NX2 and stored it both as nef and jpg with AdobeRGB as working space (NX2 embeds an ICC profile by default)

I compiled digikam from svn trunk and tried the files with it. Here are my findings:

For jpg files, Digikam correctly recognised the jpg containing an ICC profile (edited with Capture NX2). It also correctly recognised the exif color space tag in the sRGB jpg. However, it did *not* recognise the AdobeRGB jpg, it gave debug output: "No input profile: invalid Behavior flags 1048576". Looking at exiftool output it seems that for AdobeRGB Nikon sets exif color space to "Uncalibrated" and sets exif Interoperability Index to "R03 AdobeRGB".

For all raw files I got debug output: "No input profile: invalid Behavior flags 1048576". It seems that Digikam did not try to interpret exif color space or interoperability index tags, nor did it recognise the embedded ICC profile in raw file edited with Capture NX2.

Just a small addition to my findings about Nikon's way to tag colour spaces (this was something I didn't know before):

According to exiftool home page Nikon's practice of using exif Interoperability Index to mark AdobeRGB colour space is correct:

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html

ColorSpace
1 = sRGB
2 = Adobe RGB
65535 = Uncalibrated
(the value of 2 is not standard EXIF. Instead, an Adobe RGB image is indicated by "Uncalibrated" with an InteropIndex of "R03")

(In reply to comment #18)
> Thumbnail cache is not cleared currently, probably you switched it off and had
> still the color managed thumbnails from the cache. I did not expect this
> setting to be changed all too often.

Marcel: what is meant by "cache" - some temporary thing valid only while digiKam is running or the images stored in thumbnail db?

My motivation: I have AdobeRGB display and use it for editing of the "better" pictures. However, I do quite often use it only in the standard sRGB space, since many applications, including the X Window managers, are still not CM-aware and especially the red icons displayed in AdobeRGB make my eyes sore...

> some temporary thing valid only while digiKam is running

Just that. For thumbnails, we cache the pixmap ready to be drawn (loaded from the thumb db, color managed and converted to pixmap). Pregenerated thumbnails in the db are stored in sRGB.
Reduced size previews are cached as color managed images.
Full sized images are color managed after loading from the cache.

Marcel,

If thumbnails have been generated before colour management was turned on, then thumbnails in the db are in their original colour space, not sRGB, right? And if colour management is then turned on, they are wrongly assumed to be in sRGB and conversion to display profile produces wrong results? Or are thumbnails in db always colour managed and in sRGB, even if colour management for preview is turned off?

Is there a way to clear thumbnails from the db without completely rebuilding it?
And should users be notified about this when they enable color management for thumbnails?

For example, I'm thinking about AdobeRGB images (which look acceptable without colour management with many wide gamut displays). If they end up in db in AdobeRGB form (colour management off) and are then used as sRGB (colour management turned on), they saturation is way too low.

I'm running DigiKam on my laptop, hooked up to different monitors at different times (monitor at home, monitor at office, laptop's LCD). Each monitor has a different gamut and color calibration. I wouldn't want to have to flush the db or thumbnail cache every time I switch monitors...

How expensive is it to keep thumbnails in the original colorspace, and convert them on the fly as done for the full images?

(Right now I need to manually switch the colorspace, but work is under way to have the X server's RandR extension report the monitor's color space, and hopefully DigiKam will use this in the future for automatic switching.)

(In reply to comment #26)
I wouldn't want to have to flush the db
> or thumbnail cache every time I switch monitors...

As Marcel explained, it should be sufficient to restart digiKam to refresh the colour managed pixmaps in the cache from thumbnails db.
 
> How expensive is it to keep thumbnails in the original colorspace, and convert
> them on the fly as done for the full images?

As discussed above, it seems to be okay to have thumbnails db in sRGB only and create the cached thumbnails as colour managed pixmaps in the colour space of the current monitor.

We would potentially loose some out of gamut colours, but for thumbnails, this should not be a hot issue. (E.g. the original image is ProPhoto RGB, thumbnail is sRGB, monitor is Adobe RGB - the colours of thumbnail would be colour managed for AdobeRGB, but we would loose any colour outside sRGB gamut but within ProPhoto RGB gamut.)

Matti:

> If thumbnails have been generated before colour management was turned on, then
> thumbnails in the db are in their original colour space, not sRGB, right? And
> if colour management is then turned on, they are wrongly assumed to be in sRGB
> and conversion to display profile produces wrong results? 

Yes, if they have been generated before 1.0-beta4 or if color management (the main option) was turned off.


> Or are thumbnails in
> db always colour managed and in sRGB, even if colour management for preview is
> turned off?

From 1.0-beta4, they are always color managed and in sRGB if color management is turned on, regardless of the settings for color managed view.

> 
> Is there a way to clear thumbnails from the db without completely rebuilding
> it?

rm thumbnails-digikam.db

> And should users be notified about this when they enable color management for
> thumbnails?

If they enable color management, yes maybe...

kde2eran:

> I'm running DigiKam on my laptop, hooked up to different monitors at different
> times (monitor at home, monitor at office, laptop's LCD). Each monitor has a
> different gamut and color calibration. I wouldn't want to have to flush the db
> or thumbnail cache every time I switch monitors...

I will go and implement automatic cache flushing if the monitor profile changes.

> 
> How expensive is it to keep thumbnails in the original colorspace, and convert
> them on the fly as done for the full images?

Pretty unacceptably slow. As explained above, this is not needed. The only complication not covered currently is if someone uses two screens at a time with different profiles. I deliberately decided not to care for this at the moment (it can work for the editor, but is of course not tested.)

> (Right now I need to manually switch the colorspace, but work is under way to
> have the X server's RandR extension report the monitor's color space, and
> hopefully DigiKam will use this in the future for automatic switching.)

Interesting. I am implementing #197817 but I dont know how to detect changes. Worst case is you need to restart the application.

SVN commit 1019823 by mwiesweg:

Clear image and thumbnail cache if relevant color-managed view options changed

CCBUG: 195050

 M  +19 -0     libs/threadimageio/loadingcache.cpp  
 M  +6 -0      libs/threadimageio/loadingcache.h  
 M  +16 -1     utilities/imageeditor/canvas/iccsettings.cpp  
 M  +1 -0      utilities/imageeditor/canvas/iccsettings.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1019823

SVN commit 1019840 by mwiesweg:

Interpret the Exif.Iop.InteroperabilityIndex and Exif.Nikon3.ColorSpace
for AdobeRGB images when main color space is set to uncalibrated.

BUG: 191113
CCBUG: 195050


 M  +17 -2     kexiv2image.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1019840

The AdobeRGB / JPEG issue should be settled.
The NEF issue is different:
1) It seems that the color space tags in the Exif Info of the NEF file apply to the embedded preview, which has no exif information at all.
2) The NX2 edited images RAW images have an actual embedded ICC profile in the RAW file which also obviously applies to the embedded JPEG preview.

Is this NEF-specific? Does anyone know if other RAW formats also specify or even embed color profiles for their embedded previews?

Marcel, 

Look this Exif tags :

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html

0xa001 	ColorSpace 	  int16u
0xc71a 	PreviewColorSpace int32u!

And now Makernotes :

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Nikon.html

0x001e 	ColorSpace 	  int16u

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html

0x00b4 	ColorSpace 	  int16u

etc...

...welcome in this big puzzle...

Gilles

Gilles,

I wouldn't be too worried about the Nikon and Canon specific colour space tags, if Digikam only recognises sRGB and AdobeRGB using those tags. Since standard EXIF specifies how those colour spaces are tagged using ColorSpace and InteroperabilityIndex, Digikam can trust those tags. I think the vendor-specific flags are there in case cameras start using colour spaces not defined by normal EXIF.

It's interesting to notice that there's PreviewColorSpace tag as well! :-)
I would imagine it's safe to trust that for raw files ColorSpace and PreviewColorSpace are equal, since raw files have no native standard colour space.

I forgot to add that it would be REALLY nice if libexiv2 would provide an API function for returning an colour profile for an image (it could do all the dirty work of reading appropriate tags and deciding which profile to use). :-)

Gilles: We support the EXIF and Nikon color space already. The Canon tag doesn't seem to be available from libexiv2 (looked in canonmn.cpp).

Matti: There is getImageColorWorkSpace()

Take a care about JPEG embedded in RAW files and exif data. it's the hell.

To have experimented some problems with rotation tag from my Minolta camera, i have discovered this puzzle : with dcraw, extracted jpeg embedded from raw has exif data, but there are copied from raw part as well. There are not set by camera in jpeg image data.

I checked in pass how dcraw work when jpeg is extracted : it sound like jpeg image is extracted and after to be written to disk, RAW exif are copied to this file as well.

There is a problem here : exif data cannot be exactly the same for both.

Alex can be precise here about this subject...

Gilles

Marcel,

I'm not sure if this is connected with your recent fixes or not, but currently when I start Digikam compiled from trunk, I notice the following error messages (which do not prevent Digikam from starting, though).

Does this maybe happen because AdobeRGB profile is found several times from my profile directories?

digikam(30649) Digikam::IccSettingsPriv::scanDirectories: ("/usr/share/color/icc", "/home/bitti/.local/share/color/icc/", "/home/bitti/.color/icc/", "/home/bitti/config/color/icc")                                                            
digikam(30649)/digikam (core) Digikam::IccProfile::considerOriginalAdobeRGB: The original Adobe RGB (1998) profile has been found at "/usr/share/color/icc/Adobe ICC Profiles/RGB Profiles/AdobeRGB1998.icc"                                    
digikam(30649)/digikam (core) Digikam::IccProfile::considerOriginalAdobeRGB: The original Adobe RGB (1998) profile has been found at "/home/bitti/.color/icc/AdobeRGB1998.icc"                                                                  
lcms: Error #12288; Corrupted memory profile                                    
digikam(30649)/digikam (core) Digikam::IccProfile::considerOriginalAdobeRGB: The original Adobe RGB (1998) profile has been found at "/home/bitti/config/color/icc/AdobeRGB1998.icc"                                                            
lcms: Error #12288; Corrupted memory profile                                    
Starting to load Plugins.

Yes it's several times the same file. No need to worry. (We have no license to redistribute it, but if it is found installed, it is detected by MD5 hash)

Marcel,

I have been thinking about your comment about Nikon NEF files, colour profiles and exif data. First, it's true that the embedded ICC profile in NEF files edited with NX2 is the profile of the embedded full-res jpeg.

This is because in reality, Nikon NEF files are not just "raw sensor data files". To my understanding, Nikon NEF file can contain a source image, transformations applied to it, and then the resulting image (the embedded full-res jpeg). With NEF files straight from camera, source image is the raw sensor data, transformations consist of camera settings in the exif. When a raw image is edited in NX2, additional edit steps are added to the metadata and the embedded jpeg represents the final edited image.

It is even possible to edit a jpeg in Capture NX2 and store the result as a NEF file! Then the source image is the original jpeg (stored inside the NEF file), and file metadata contains all edit steps performed. The embedded jpeg "preview" is the final edited jpeg.

And since you can choose the working colour space freely in NX2 (and change the colour space as an edit step), the ICC profile in the NEF file is that of the final image, i.e. the embedded jpeg.

For this reason the embedded jpeg is so important for Nikon NEF shooters (especially us using Nikon software to edit it).

SVN commit 1022775 by mwiesweg:

Use PreviewThread API properly in slide show so that color management is enabled.

CCBUG: 195050

 M  +6 -6      slideshow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022775

SVN commit 1022778 by mwiesweg:

Read color space from RAW file Exif when extracting embedded JPEG for preview

CCBUG: 195050

 M  +14 -4     previewtask.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022778

Anything left for this bug?

Hi Marcel,

Thanks again for working on this bug, it's much appreciated!

For me, color profiles seem to work for jpegs now, but still each nef raw file looks different depending on the colour profile used.

I tried it by using several versions of the same nef file, converted to different profiles. I stored the files both as nef and jpeg. The files all looked identical in GQView, so profile conversion should be ok. In Digikam (built from trunk after your message) all jpegs look identical, but each raw file looks different, like colour conversion was not performed (or at least the embedded profile was not used).

SVN commit 1022958 by mwiesweg:

Restructure color space detection code (remove code duplication).
Take into account that sometimes Exif.Image.ColorSpace field is missing altogether
when Nikon Makernote color tags are set.

CCBUG: 195050


 M  +55 -70    kexiv2image.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022958

SVN commit 1022966 by mwiesweg:

In preview and thumbnail tasks, when loading an embedded raw preview, read the Icc profile
from metadata if available.
Optimize DMetadata creation in ThumbnailCreator.

CCBUG: 195050

 M  +8 -11     previewtask.cpp  
 M  +8 -6      thumbnailcreator.cpp  
 M  +3 -2      thumbnailcreator.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1022966

Fortunately the ICC profile embedded in the NEF for the embedded preview, which I had not thought of before, is available from libexiv2.

For me (with latest libkexiv2) the three NEF files from the D300 look all three ok now, but the D40 files each look different. For each d40/d300 pair, the same profiles are loaded (Adobe RGB (1998) for -adobergb.nef; sRGB IEC61966-2.1 for -srgb.nef; embedded Nikon Adobe RGB 4.0.0.3000 for -srgb-to-adobergb.nef)

Marcel,

After your latest commits, nef raw files with profiles work, thanks!

I'll have to check again the files stored in-camera as AdobeRGB. Especially with D40 it is possible that the camera does its processing a little bit differently for files stored in AdobeRGB. In addition to AdobeRGB, D40 actually has two sRGB settings with a little colour reproduction. One sRGB setting should produce more pleasing skin tones, the other enhances colours in nature, if I remember properly.

However, in D300 Nikon started using Picture Controls which define colour and tonal settings, and sRGB/AdobeRGB setting was separated from them. That's why  sRGB and AdobeRGB versions should match closely with D300.

With the files converted to AdobeRGB with Capture NX2, it's possible that there are some minor differences compared to the original sRGB nef, since Capture NX2 might use a little bit different (better) raw-decoding algorithm than the camera.


I'll have time to test this better tomorrow, but so far things look good! :-)

Marcel,

I had a little time to do one small test now, and I'm a little bit unsure if AdobeRGB is working properly for me (for both jpeg and raw nef).

For me, the green is paler in AdobeRGB version, which suggests that Digikam would still be interpreting it as sRGB.

I took the photo shot with D300 and stored in-camera as AdobeRGB. I then used ImageMagick's convert-command to convert it explicitly from AdobeRGB to sRGB. in Digikam, the resulting image is practically identical with the image shot in-camera as sRGB, but it does look different from the original AdobeRGB version.

I still get the following messages:

digikam(5934)/digikam (core) Digikam::DImg::load: "/home/bitti/local/edited-photos/nobackup/digikamtest/d300-adobergb.jpg"  : JPEG file identified
digikam(5934)/digikam (core): No input profile: invalid Behavior flags 1048576

I have indeed fixed two or three related bugs. I can't say exactly how this affected you, but it may. For me the d300-adobergb images look identical now. Does it for you with latest trunk?

All remaining issues have been cleared.