[Openicc] seeking for advice on rendering intent and black point compensation

Alastair M. Robinson blackfive at fakenhamweb.co.uk
Wed Oct 3 09:03:18 PDT 2007


Hi,

Craig Ringer wrote:

> I do wonder if defaulting to converting mismatched images to the working
> space is the best idea, though. I'm increasingly inclined to leave
> images in their native colour space and let the colour management system
> take care of making sure I get a reasonable view of the image on screen.

In principle I agree with this, but I was under the impression that 
doing so was rather difficult within GIMP's current design - i.e. it 
requires maintaining multiple display transforms, displaying the colour 
selectors correctly, which would involve the colour selectors having 
some concept of current image, etc.  If this is still the case, 
converting everything to the working space is an acceptable compromise.

Just to clarify, as GIMP currently stands, if your working space is set 
to sRGB and you try to load an image with the AdobeRGB profile embedded, 
you're asked if you'd like to convert the image to the working space 
profile via an AdobeRGB -> sRGB transform.

If you decline the offer, will that image be displayed by GIMP using the 
generic sRGB -> Display transform used for regular images, or will a 
separate Embedded profile (Adobe) -> Display transform be used when 
displaying this image?


As for the default intent for such conversions, I would prefer either 
Perceptual or Relative Colorimetric with BPC *ON* to be the default.  If 
you have an image which is in a "print" colour space, its black point 
will be much lighter than the "pure" black of an additive RGB working 
space like sRGB - so a relative colorimetric transform from a printer 
colour space to a working space will result in a washed out, faded look. 
  That's the effect Black Point Compensation is designed to minimise.

It's also entirely possible that an advanced user would want to choose 
the intent on a per-image basis - one might want to treat an image from 
a scanner differently from one that's ready for printing, for instance, 
so I would be in favour of being able to choose the intent when being 
asked whether to convert.

>>> (2) The rendering intent used for the display color correction can be
>>> configured in the Preferences dialog. Would it make sense to reuse this
>>> setting for the conversion when loading an image?

Here I disagree with the consensus so far - conversion from an embedded 
profile to the working space, and conversion from the working space to 
the display profile are two separate operations, and their settings 
shouldn't be tied too closely.

Using the current display settings as a *default* for the conversion 
settings is fine - as long as it can be overridden.

Having to change your *display* settings to force a different intent to 
be used when loading an image is not logical.

>> Be warned about using relative colorimetric without BPC. Your users will 
>> seldom expect such results.

Agreed - although in the case of different working spaces (where both 
profiles have "pure" black) - AdobeRGB -> sRGB for instance it makes no 
difference, the difference with something like USWebCoatedSWOP (or any 
printer profile for that matter) -> sRGB is very pronounced.

> I increasingly think that user interfaces need to offer _five_ rendering
> intents, with a strong emphasis placed on the first two shown, eg:
> 
> Perceptual
> Relative Colorimetric with BPC
> -- Rarely Needed --
> Relative Colorimetric without BPC
> Absolute Colorimetric
> Saturation

Agreed, once again.  I already use five-intents rather than 
four-intents-and-a-checkbox in PhotoPrint, and may well take up your 
idea of emphasising Perceptual and RC/BPC.

> The "Use black point compensation" option would then be removed
> entirely. (Or are there circumstances when it does make sense for other
> intents?)

As far as I know the BPC flag is simply ignored with intents other than 
Relative Colorimetric - at least with lcms.

All the best,
--
Alastair M. Robinson


More information about the openicc mailing list