Bug 165650

Some more information...

I can see the problem, when I open the file afterwards in the gimp, it asks to keep or convert the color profile. When converting it, the colour issue shows up.

The shop was quite considerate of my problem, but they told me to throw away the software, because next time they won't pay for my problem ;-)

Apparently the problem is that the output JPEG file contains two references to a color profile and they are different from each other. This should not be the case, but due to the way programs read JPEGs, the viewed version seems ok, but the colours change after the color profile is converted (which happens in the printer)

/Simon

Created attachment 25921 [details]
screenshot of problem case

In this screenshot, you can see an image, converted from .ARW in digikam's
editor, saved to .jpg and then opened in the gimp. The Gimp notices a color
profile and offers to keep or convert it. I choose convert and then you get the
image shown in the screenshot. (When I choose keep, it looks the same)

Created attachment 25922 [details]
the keep/convert dialogue shown by the gimp

the jpeg in question is too big for uploading, it can be found here:
http://margo.student.utwente.nl/simon/temp/DSC01940-dk.jpg  (3.1MB)

The same raw file processed using ufraw and the gimp:
http://margo.student.utwente.nl/simon/temp/DSC01940-gimp.jpg

Created attachment 25923 [details]
example image

I can confirm this, look at my images here. I opened the JPEG (not converted
from RAW) into Gimp and digiKam, looks good in both programs. After that, I
sharpened the image in digiKam and created a new copy of it. Now I loaded both
images in Gimp, the second one has a color profile that doesn't match the
original image.
Also I noted that if I use filters in digiKam, not only sharpness but all kind
of image manipulation, the resulting images seem to be zoomed in a little bit.
For example I do color cast correction and safe the image in a new copy. Now I
watch both images in fullscreen inside of digiKam. When switching between both
images, the second image (the new copy) is slightly bigger, but not in the
overall dimensions. So it looks like the image has been cropped and scaled back
to the original size.

Possibly related:

I have a cheap digital camera that only produces JPG files. When opened in DigiKam, it says it has a sRGB profile with a 5000K whitepoint, and asks me if I want to convert the image to my editing profile (which is aRGB). When I do so, the images all show way too cold colors. But when I open the same image in CinePaint, it says the image does NOT have a profile and asks if I want to assign one to it. So, I assign sRGB to it, and the image looks fine. Weird...

I have no experience printing these images yet.

I can confirm this bug with .94 final. Reproduce as follows:

1. Save file from UFRaw using default sRGB output which tags file as sRGB color, but does not embed a color profile. sRGB tags without embedded profiles are also commonly output from many cameras.

2. Open file in Digikam (with color management off) and save.

3. Open and save the file with Imagemagick using the option -profile Path/sRGBprofile.icc and observe a drastic blue color shift.

OR

Upload file to Zenfolio, which converts and embeds sRGB profiles by default, and observe a drastic blue shift.

AND/OR

Use Jeffry's online EXIF viewer to see warnings regarding color profile not matching the color profile tag.

http://regex.info/exif.cgi

Hopefully this will be fixed in 0.95?

At the moment, this bug is this there in 0.9.5-svn. I do hope this will be fixed before a release candidate is tagged.

Cheers

Simon

I just noticed the problem isn't limited to saved JPEG files, I also saw it in a PNG file.

Bug still present in 0.10.0. 

As mentioned above by Dik Takken, while saving digikam adds a wrong profile to the picture. This profile claims to be sRGB, but has a shifted white point. Instead of the normal D65 (6500 K) it says D50 (5000 K). 

So opening it with a software that can read and use icc profiles (e.g. photoshop, firefox) causes a nasty colour shift. It also affects image printing services. Two days before I sent 50 pictures to http://saal-digital.de and about a dozen were edited with digikam. I was about to exhibit them this weekend, but now all edited pictures have this nasty shift.

Digikam is a great tool to organise, edit and correct pictures, but this bug causes a lot of extra work for me because now I must rework my pictures with other programs to work around this bug.

I also added a bug report yesterday containing roughly the same: https://bugs.kde.org/show_bug.cgi?id=189250
I think it's now obsolete and could be closed, I just don't know how to do that.

I am having the same issue with the Ubuntu package (2:0.10.0-1ubuntu3).  I don't mess with color management settings but DigiKam is tacking on a bad ICC profile when I save images to disk.  Here's a very clear sample image: http://greg-kennedy.110mb.com/img/666656.jpg

Very frustrating, I never would have noticed until I enabled Firefox's new ICC profile option.  Hopefully there's an easy workaround.

As a workaround, you can use "mogrify +profile 'icc' filename" to strip the offending color profile from an image.

A lots of work have been done by Marcel recently about digiKam color management code.

Please test current code from svn 1.0.0-beta4.

Gilles Caulier

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

The root of all the problems here is indeed the defective sRGB profile that we shipped until bug #189250 got fixed. This profile was - most unfortunately - not the one referred to when cameras tagged their images as sRGB. With the color management dialog from current SVN you can clearly see the difference in the DSC01940 file when you choose to discard the embedded profile and assign sRGB IEC61966-2.1 instead. The profile currently shipped with libkdcraw in identical to the one distributed by Adobe in its ICC profiles package. DSC01940-gimp has the correct profile embedded.
The testcase from #12 has no embedded profile.