support color profiles

Submitted by Adam Dingle

Description

---- Reported by adam@yorba.org 2009-12-17 11:36:00 -0800 ----

Original Redmine bug id: 1175
Original URL: http://redmine.yorba.org/issues/1175
Searchable id: yorba-bug-1175
Original author: Adam Dingle
Original description:

We should consider supporting color profiles like GIMP does. Useful links:

Color Management with GIMP â€“ !http://docs.gimp.org/en/gimp-imaging-color- management.html

GNOME Color Manager â€“ !http://projects.gnome.org/gnome-color-manager/

---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----

History

Comment 1

Updated by Paweł Rumian about 3 years ago

I'll say more: proper color management is a must for a DAM application nowadays, when almost every new display is wide-gamut and digital cameras support not only sRGB colour space. And shotwell has not only cataloguing but also photo editing features, which are useless without CMM.

That means: shotwell really, really do need not only support for in-photo embedded color profiles, but also (which seems to be even more important) support for using monitor profiles.

Geeqie is a good example of application with correct implementation of this (ofc gimp. digikam, and so on â€“ as well).

Comment 2

Updated by jsbb - about 3 years ago

I fully agree with the following post.

Wide gamut monitors are more and more common and cheap, so the implementation of color management will be more and more important.

I use shotwell for managing my photo collection but I use geeqie to view them because I have a wide gamut monitor and I shoot in adobe rgb.

I really like Shotwell for its speed and absence of bloat but I find the lack of this feature to be really annoying.

Comment 3

Updated by Adam Dingle over 2 years ago

Priority set to High

#3335has been marked as a duplicate of this ticket.

Comment 4

Updated by Bruno Girin over 2 years ago

Here's an attempt at a quick spec based on what I understand of the problem.

Each image source (typically file on disk) and image destination (typically screen or printer) has a colour profile. When sending the source to the destination, the image needs to be transformed from the source colour profile to the destination one.
If the colour profiles of both source and destination are the same, no transform is necessary.
Some sources or destinations may not have a colour profile, in which case a sensible default should be used:
Simple implementation: default to sRGB;
Extended implementation: have different defaults for different types of devices.
Some destinations will be colour profile aware, in which case no transformation is necessary if the colour profile can be specified to the destination.
Support colour profiles embedded in image file.
When importing from a camera, if individual images don't have a colour profile specified but the camera has, use the camera's profile.
When exporting, embed the colour profile in the file.
When doing the transformation from source to destination colour profiles, it is possible that the destination profile has a smaller colour gamut than the source profile in which case the colour of some of the pixels may not be displayable by the destination:
There is a need to notify the user that this is the case; GIMP will mark the relevant pixels in grey so could do something similar;
Or choose the closest colour that the destination will support and notify the user that the output cannot faithfully represent the source.
Avoid multiple transformations: always go from initial source to final destination to avoid intermediate profiles that have a smaller gamut.
Is any specific support required when adjusting colour channels and doing any transformation on the image?

Comment 5

Updated by Paweł Rumian over 2 years ago

Replying to [comment:5 brunogirin]:

When doing the transformation from source to destination colour profiles, it is possible that the destination profile has a smaller colour gamut than the source profile in which case the colour of some of the pixels may not be displayable by the destination:

There is a need to notify the user that this is the case; GIMP will mark the relevant pixels in grey so could do something similar;

Or choose the closest colour that the destination will support and notify the user that the output cannot faithfully represent the source.

There is no need to reinvent the wheel -- there are four methods of squeezing the colour space: relative colorimetric, absolute colorimetric, perceptual and saturation. Two links that may be interesting:

http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

http://en.wikipedia.org/wiki/Color_management#Color_transformation

Avoid multiple transformations: always go from initial source to final destination to avoid intermediate profiles that have a smaller gamut.

I'm not sure, but probably having really huge intermediate profile (like ProPhoto) won't hurt.

Is any specific support required when adjusting colour channels and doing any transformation on the image?

What do you exactly mean?

Comment 6

Updated by Bruno Girin over 2 years ago

Replying to [comment:6 gorky]:

Replying to [comment:5 brunogirin]:

When doing the transformation from source to destination colour profiles, it is possible that the destination profile has a smaller colour gamut than the source profile in which case the colour of some of the pixels may not be displayable by the destination:

There is a need to notify the user that this is the case; GIMP will mark the relevant pixels in grey so could do something similar;

Or choose the closest colour that the destination will support and notify the user that the output cannot faithfully represent the source.

There is no need to reinvent the wheel -- there are four methods of squeezing the colour space: relative colorimetric, absolute colorimetric, perceptual and saturation. Two links that may be interesting:

http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

http://en.wikipedia.org/wiki/Color_management#Color_transformation

Good, thanks! I knew that someone smarter than I am must have considered that sort of problems before :-) So to handle this in a simple way, it would be a case of choosing one of the standard rendering intents or allowing users to specify it.

Avoid multiple transformations: always go from initial source to final destination to avoid intermediate profiles that have a smaller gamut.

I'm not sure, but probably having really huge intermediate profile (like ProPhoto) won't hurt.

True, you could use a PCS as suggested in the Wikipedia article you linked to; whichever is easier to do in code.

Is any specific support required when adjusting colour channels and doing any transformation on the image?

What do you exactly mean?

The range of possible values for different colour channels will differ depending on the colour profile: I presume a green channel adjustment to 80% doesn't mean the same thing for sRGB and ProPhoto, or does it? So should such tools be enhanced to handle this? And if yes in what way?

Comment 7

Updated by Paweł Rumian over 2 years ago

Replying to [comment:7 brunogirin]:

Good, thanks!

No problem :)

So to handle this in a simple way, it would be a case of choosing one of the standard rendering intents or allowing users to specify it.

One should definitely allow users to specify it â€“ there is no 'optimal' rendering intent, so it must be chosen according to the appliance.

True, you could use a PCS as suggested in the Wikipedia article you linked to; whichever is easier to do in code.

AFAIK the coding has been done at least once: http://www.littlecms.com (this is the standard CMS used in all Linux applications I know).

The range of possible values for different colour channels will differ depending on the colour profile: I presume a green channel adjustment to 80% doesn't mean the same thing for sRGB and ProPhoto, or does it? So should such tools be enhanced to handle this? And if yes in what way?

Well, I have no real knowledge about the underlying structure of color-aware applications â€“ it woud be really good to ask someone who did some coding (maybe the guys from RawTherapee, Gimp, Geeqie or DigiKam would help?).

From the user's point of view you have 'working colour space' and you're applying changes to this one. It is then (or rather constantly) converted to monitor colour space (when displaying), printer colour space (when printing) or some standard, chosen colour space, like aRGB/sRGB/ProPhoto/whatever (when saving a file).

Did this help you?

As I mentioned before, I'm just an amateur, so all more specific questions should be discussed with someone with real experienceâ€¦

Comment 8

Updated by Bruno Girin almost 2 years ago

Description updated (diff)

To make this progress, I asked the question during the OpenICC talk at FOSDEM today and they did suggest using littlecms as pointed out by Paweł above. More details here: http://www.freedesktop.org/wiki/OpenIcc/

Comment 9

Updated by Matthias Völlinger about 1 year ago

This is one of the features that I'm dearly missing from shotwell, so I looked a little into lcms2 today and how the color management is implemented in eog. Using the library it comes down to

cmsHPROFILE hScreenProfile;

cmsHTRANSFORM hTransform;

// load display profile

hScreenProfile = cmsOpenProfileFromFile("/usr/share/color/icc/display_profile.icc", "r");

if(hScreenProfile!=null) {

// Assume that the image is in the sRGB colorspace. The profile could also be read from

// the image metadata

transform = cmsCreateTransform (cmsCreate_sRGBProfile(),

TYPE_RGB_8,

hScreenProfile,

TYPE_RGB_8,

INTENT_PERCEPTUAL,

0);

cmsCloseProfile(hScreenProfile);

int rows = gdk_pixbuf_get_height (pixbuf);  
    int width = gdk_pixbuf_get_width (pixbuf);  
    int stride = gdk_pixbuf_get_rowstride (pixbuf);  
    char *p = gdk_pixbuf_get_pixels (pixbuf);

for (row = 0; row < rows; ++row) {  
        cmsDoTransform (transform, p, p, width);  
        p += stride;  
    }  
    cmsDeleteTransform (transform);  
}

I have no ideas how to create the bindings for the lcms2 library though. I tried to read a little about it, but I didn't get too far - so if someone who did this before would be willing to answer me some questions, I could give it a try.

Comment 10

Updated by Jim Nelson about 1 year ago

Target version set to 0.14.0

We'll look into this for 0.14.

Comment 11

Updated by Jim Nelson 11 months ago

Category set to pipeline

Comment 12

Updated by Jim Nelson 11 months ago

Target version changed from 0.14.0 to 0.15.0

Comment 13

Updated by Jim Nelson 8 months ago

Target version changed from 0.15.0 to 0.16.0

Comment 14

Updated by Jim Nelson 6 months ago

Target version deleted (<strike>0.16.0</strike>)

--- Bug imported by chaz@yorba.org 2013-11-25 21:43 UTC ---

This bug was previously known as bug 1175 at http://redmine.yorba.org/show_bug.cgi?id=1175

Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution

Resolution: RESOLVED OBSOLETE