Bug 258985 - digiKam does not store correct color profile in JPEG2000 or TIFF images
Summary: digiKam does not store correct color profile in JPEG2000 or TIFF images
Alias: None
Product: digikam
Classification: Unclassified
Component: ColorManagement-Profiles (show other bugs)
Version: 2.8.0
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2010-12-06 10:10 UTC by Knut Krause
Modified: 2022-02-01 11:19 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.3.0


Note You need to log in before you can comment on or make changes to this bug.
Description Knut Krause 2010-12-06 10:10:50 UTC
Version:           1.6.0 (using KDE 4.5.4) 
OS:                Linux

When I import RAW images into my AdobeRGB workspace profile everything seems to work fine. If I save them later on in an archiving format like .jp2 or .tif the color tab says this is a sRGB image. I tried to save the image once directly to .jpg and this seems to work fine.

Reproducible: Always

Steps to Reproduce:
Import a RAW image as AdobeRGB and save it either as JPEG2000 or TIFF file.

Actual Results:  
The stored file is stored as sRGB image.

Expected Results:  
The file should be an AdobeRGB image.
Comment 1 caulier.gilles 2010-12-06 10:16:05 UTC
And with PNG, PGF, or JPEG format, it's the same problem ?

Gilles Caulier
Comment 2 Knut Krause 2010-12-06 10:24:08 UTC
As I said .jpg seems to work fine (as far as I can see). At the moment I got no clue about PNG and PGF. Can try this at home.

Comment 3 Marcel Wiesweg 2010-12-06 10:42:48 UTC
Gilles, the JP2kloader has these lines:
    // Set ICC color profile.
    // FIXME : doesn't work yet!
and it even crashed inside libjasper when I tried it. Didn't find any documentation for these functions.

The TIFF loader's relevant section is ifdef'ed:
so maybe it needs a certain libtiff version?
Comment 4 caulier.gilles 2010-12-06 10:49:28 UTC
About JPEG2000 and libjasper, yes, i remember to set this comment. It come from ImageMagick codec. I take a look in this code few year ago. I don't know if it's fixed now.

Anyway, I see KDE core switch from Jasper to OpenJPEG to support JPEG2000. Jasper library is not maintained and security problem occur.

We need to plan this switch in the future.

About libtiff, i think 3.9.x from remotesensing.org must support it as well (I'm not sure about 3.6.x from libtiff.org)

Gilles Caulier
Comment 5 Knut Krause 2010-12-06 10:57:35 UTC
As far as I see do I use 3.9.4 from remotesensing.org. I maybe can switch to the 4.0.x beta but I'm not sure if this is clever.

Comment 6 Marcel Wiesweg 2012-07-22 15:04:04 UTC
Just stumbled over this.
Current status: TIFF works, JP2K does not work, PGF does not work.
Regarding JP2k, Gilles mentioned the need to port to OpenJPEG, which is a rewrite.

Regarding PGF, I don't know if it has been discussed before, bug I'd like to ask Raphael if there's any special support in libpgf or the PGF format to embed an ICC profile.
Comment 7 caulier.gilles 2012-07-22 15:13:14 UTC

JP2K API from Jasper lib do not work to store ICC profile. I already tested it. I already implemented this feature, but, it don't work... Jasper lib is not maintained now. OpenJPEG must be used instead...

About PGF, i think it don't support ICC profile storage, but i'm not fully sure. We must ask to Raphael. 

Note that i work a lots recently into libpgf to port to CMake and to improve Binary compatibility :


Comment 8 Raphael Schweizer 2012-07-23 15:03:58 UTC
Marcel, Gilles

PGF in principle supports storing arbitrary unstructured meta-data. This is supposedly not very well suited for ICC profiles (except for use within a bunch of compatible applications). AFAIK Chris made some progress for storing structured data in MS Media Foundation. I will check with him to see whether (and if yes, how) we can incorporate that part into PGF itself.

- Raphael
Comment 9 caulier.gilles 2012-07-23 15:22:26 UTC

In all case, we can use Exif to store ICC profile as well. There is a tag dedicated for that. This will mean than it's not store outside image Exif/IPTC/XMP as TIFF or PNG do, but as we store already Exif in PGF as an empty PNG image container, we can add ICC into it.

Note : i'm not sure if digiKam read this exif tag to extract ICC profile.

Look here for info : http://www.exiv2.org/tags.html

Tag is :

0x8773	34675	Image	Exif.Image.InterColorProfile	Undefined	Contains an InterColor Consortium 
(ICC) format color space characterization/profile

Gilles Caulier
Comment 10 Marcel Wiesweg 2012-07-23 20:01:07 UTC
Yes we do:

IccProfile DMetadata::getIccProfile() const
    // Check if Exif data contains an ICC color profile.
    QByteArray data = getExifTagData("Exif.Image.InterColorProfile");

I though as well to use this for JP2K, better than nothing.
Comment 11 caulier.gilles 2012-07-23 20:41:55 UTC

...and the same for PGF, until libpgf will provide a dedicated solution

Comment 12 Marcel Wiesweg 2012-07-25 20:27:36 UTC
Raphael: I recommend to specify a way to embed the profile somewhere inside the file itself, not as a workaround in the Exif as we do now. Strictly, pixel data are uninterpreted and uninterpretable without an associated profile, only with it they become colors...and the assumption "always sRGB" would make a format unusable for many purposes.
Comment 13 Marcel Wiesweg 2012-07-25 20:30:57 UTC
Git commit 23fd28f99c788a02e071db1debfe7c9870de163b by Marcel Wiesweg.
Committed on 25/07/2012 at 22:29.
Pushed by mwiesweg into branch 'master'.

Store color profile in Exif as a workaround for missing support in the PGF format.

Attempt to do the same for JP2K, but that does not work: When reading, the library successfully
returns an sRGB profile, while we cannot change this when creating a file.

M  +12   -0    libs/dimg/loaders/dimgloader.cpp
M  +1    -0    libs/dimg/loaders/dimgloader.h
M  +8    -0    libs/dimg/loaders/jp2kloader.cpp
M  +11   -0    libs/dimg/loaders/pgfloader.cpp
M  +18   -0    libs/dmetadata/dmetadata.cpp
M  +4    -1    libs/dmetadata/dmetadata.h

Comment 14 caulier.gilles 2014-08-23 11:40:37 UTC
Following commit CC in comment #13, this file is fixed since a while. Reopen if necessary.

Gilles Caulier