[sane-devel] Rendering Intent for Color Management in XSANE Setup
ku.b at gmx.de
Thu Jul 29 14:32:37 UTC 2010
Am 28.07.10, 23:08 +0200 schrieb Stephan Maier:
> On 07/28/10 13:28, Kai-Uwe Behrmann wrote:
>>> Date: Wed, 30 Jun 2010 13:59:33 -0400
>>> From: Stephan Maier <stephan at bwh.harvard.edu>
>>> I found a clear discrepancy between the profiling results
>>> achieved with XSANE and the Argyll (www.*argyllcms*.com)
>>> converting routine cctiff. The Argyll profiling results
>>> agree perfectly with the expected values for my target image.
>>> I was able to reproduce the XSANE results with Argyll's cctiff
>>> by using the same rendering intent, i.e. perceptual, for both input
>>> profile (XSANE: Scanner default color ICM-profile) and output profile
>>> (XSANE: Working color space ICM-profile).
>> ICC profiles typical connect to the Profile Connection Space (PCS). This is
>> eigther Lab or XYZ encoded. During a colour trasnformation your input
>> profile connects to PCS and then goes to output profile, the working or
>> editing space. For a colour trasnformation is only one rendering intent
> I agree with the first part. Thus we have
> raw data (scanner) --> PCS --> output
> Now, as I understand it, each arrow represents a color transformation with
> its own rendering intent. In XSane does the rendering intent apply to both
> transformations or only the second one? One could of-course set
> the first to 'absolute colorimetric' by default and the user defined
> rendering intent would then only apply to the second one.
While using distinct profile colour transforms for the above conversion
is technical possible, the intention is to use the tables in pairs.
>>> This leads me to believe the Rendering Intent choice in XSANE setup
>>> applies to both in input and output profile. This approach is not correct,
>>> however. The rendering intent of the input profile, which corrects errors
>>> of the scanner, has to be set to "Absolute colorimetric", since all other
>>> choices perform a white point correction. XSANE lacks the option
>> "Absolute colorimetric" results in a native input whitepoint on the output
>> media. E.g. the colour cast of the device would be projected into D50 or
>> whatever the editing space is and would appear there in. This is useful
>> mostly in pedantic reproduction. Normaly relative colorimetric with black
>> point compensation performs more desirable.
> Yes, I agree that 'absolute colorimetric' is the least useful for output and
> that it keeps the whitepoint coordinate and that perceived whites appear
> no longer white. However, for the input calibration profile it is different
> since we indeed need a pedantic transform, since the raw data is not
> in a color space yet.
The device colour space should be described by the device ICC profile.
Assigning the profile to the image or embedding is enough for defining the
colours of the raw data.
>>> to set this rendering intent independently of the rendering intent
>>> for the output profile (typically the desired output profile intent is
>>> perceptual or relative colorimetric).
>> If there is no thierd profile involved in the colour workflow, there can by
>> definition be no second rendering intent.
> This is may be my misunderstanding, but as I outlined above, the raw data to
> PCS transform
> I consider to be separate profile, which should have it's own rendering
> or at least a suitable default value, like "absolute colorimetric".
It makes no sense to me. Absolute colorimetric is delivered by the
AToB1Tag and the mediaWhitePointTag. The system is not designed to be used
with different rendering intents per transform. From and to PCS does not
count. inProfile -> PCS -> outProfile is considered one transform.
The PCS is not defined to have an additional step.
The PCS is designed to build the transform in a predictable,
CIE*XYZ/CIE*Lab is well known, and a exchangable way. PCS allowes to
combine different profiles without knowing in advance of them.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the sane-devel