After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 715827 - support color profiles
support color profiles
Status: RESOLVED OBSOLETE
Product: shotwell
Classification: Other
Component: pipeline
unspecified
Other All
: High enhancement
: 0.30
Assigned To: Shotwell Maintainers
Shotwell Maintainers
: 743481 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-12-17 07:36 UTC by Adam Dingle
Modified: 2020-12-19 20:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Charles Lindsay 2013-11-25 21:42:36 UTC


---- 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

####

#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).

####

#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.

####

#3

Updated by Adam Dingle over 2 years ago

  * **Priority** set to _High_

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

####

#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?

####

#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?

####

#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?

####

#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…

####

#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/

####

#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.

####

#10

Updated by Jim Nelson about 1 year ago

  * **Target version** set to _0.14.0_

We'll look into this for 0.14.

####

#11

Updated by Jim Nelson 11 months ago

  * **Category** set to _pipeline_

####

#12

Updated by Jim Nelson 11 months ago

  * **Target version** changed from _0.14.0_ to _0.15.0_

####

#13

Updated by Jim Nelson 8 months ago

  * **Target version** changed from _0.15.0_ to _0.16.0_

####

#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 

Comment 1 Jim Nelson 2015-01-26 20:09:34 UTC
*** Bug 743481 has been marked as a duplicate of this bug. ***
Comment 2 Karsten de Freese 2016-03-06 20:53:51 UTC
It seems this ticket is not considered for an implementation anymore - or is there a more current one to use for shotwell color management?

That's a bit sad. I guess a growing number of people (such as myself) are using wider gamut monitors nowadays, and with these monitors we're seeing heavily oversaturated colors if the picture display is not respecting the monitor profile.

I think one could keep things simple it that helps - it would be great to have a full-featured color management in shotwell, but at least for me it would already help a lot if shotwell's picture display would become aware of Gnome's system monitor profile e.g. in the same way as EOG.

A first step could be to just consider the system monitor profile for picture display, assuming sRGB color space for all pictures. One step further would be to respect embedded profiles within the pictures (as EOG does). Being able to set rendering intents, working color spaces and what else would be needed for a full-featured color management is really lower priority from my point of view..
Comment 3 Ariel 2017-06-18 00:18:14 UTC
Same as Shotwell - also EOG's color management seems broken, at least in my system (Fedora 25 / wayland), bug: https://bugzilla.gnome.org/show_bug.cgi?id=783910

The only color-managed viewer that really works in my system at this point is Geeqie.  Of course, Darktable / GIMP / Firefox & Chrome work fine as well, they pick up the system profile.
Comment 4 Jens Georg 2020-12-19 20:00:51 UTC
Tracked as https://gitlab.gnome.org/GNOME/shotwell/-/issues/69