Bug 182272

Might be the same with the images mentioned here:
http://www.harald-hoyer.de/personal/blog/color_management

another example for a wide gamut profile:

$ wget http://www.harald-hoyer.de/files/IMG_2387-wide-gamut.JPG
$ identify -verbose IMG_2387-wide-gamut.JPG
...
  Profiles:
    Profile-exif: 8412 bytes
    Profile-icc: 560 bytes
      Wide Gamut RGB
...

see the image with wrong colors
$ display IMG_2387-wide-gamut.JPG

now we convert it to sRGB
$ jpegicc IMG_2387-wide-gamut.JPG IMG_2387-sRGB.JPG

and we can see the image with the correct colors
$ display IMG_2387-sRGB.JPG

digikam does not even show that there is an embedded profile in the image browser nor does showFoto in the "convert to workspace color profile" dialog.

This problem still appears in 0.10.0-rc1, AFAICS.  The same photo
viewed using Gimp looks visibly more warm than in Digikam's Editor,
when using the exact same Workspace and Monitor Color Profiles.
Only when switching off Color Management in both, Gimp and Digikam,
the photo loks identical between the two.

*** Bug 197353 has been marked as a duplicate of this bug. ***

I think part of the problem is that embedded profiles in jpeg are not read and that an embedded profile is not used as input profile when converting the image.
The attached patch fixes these problems, at least to the extent that the test image looks good. I don't know if useBuiltin should be tested before embedded or not.

Created attachment 35069 [details]
Patch to fix some icc problems

SVN commit 1009011 by mwiesweg:

Patch by David Eriksson:
Fix very subtle bug in the JPEG loader preventing embedded ICC profiles to be read because
the reading structure was destroyed before.
Awesome that you have found that bug!

CCBUG: 182272

 M  +1 -1      jpegloader.cpp  


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

Harald,

Can you test patch applied by Marcel in current implementation from svn (1.0.0-beta4) ?

Thanks in advance

Gilles Caulier

I have tested the current svn - embedded profiles in JPEGs are now recognised correctly by the editor (I have tested an image in the synthetic BRG.icc space so that misbehaviour is clearly visible).

One remaining thing is that digiKam still asks once, twice or even three-times about conversion/assignment/do nothing on ICC profile mismatch with the working space - I do not know if that is related or not. (I have not found what triggers the number of pop-up windows.)

Yes the code is in a sort of intermediate state currently there are some new bugs in it but I am preparing some more changes still. It's work in progress until the next beta.

The original bug is fixed. All proposed testcases here are displayed correctly on the image editor (img_2387 is not strikingly different, but I can see a difference) The problem of showing three dialogs is a different problem, I will fix that at the weekend.