Re: CoreImage rendering intent - no word about it on the docs ?
Re: CoreImage rendering intent - no word about it on the docs ?
- Subject: Re: CoreImage rendering intent - no word about it on the docs ?
- From: Mark <email@hidden>
- Date: Tue, 17 Jul 2007 21:04:36 +0200
Hello Ralph
that does indeed clarify things - thanks. You mentioned the first
conversion (to working color space) to the does not clamp values.
What about the second one (from working to output) will it just clamp
values - which I guess would mean CI does gamut mapping with some
sort of colorimetric rendering intent, or will CI shrink the entire
image until no clamping is necessary, which would mean it uses a
perceptual rendering intent.
On 17.07.2007, at 19:16, Ralph Brunner wrote:
How sure are you that CIFilters are applied to XYZ components? I
can't recall having read that on the docs. My impression is that
actually we have:
input color space -> working color space -> CIFilters -> output
color space
That is correct: All images get converted from their respective
color space to the working space, then all the filters are applied,
and the result is converted from the working color space to the
output color space in the end. Note that the first conversion to
the working space does not prevent color values from going outside
the 0.0-1.0 range. This is done to allow working with HDR data and
to avoid gamut reduction.
which would mean all CIFilters are applied to gamma corrected (and
not linear) color codings.
That is not the default behavior. You can get this behavior if you
set the kCIContextWorkingColorSpace explicitly (to sRGB, for
example); but by default Core Image uses the 'Generic RGB Linear'
color space (kCGColorSpaceGenericRGBLinear in Leopard), which has
the same primaries as Generic RGB, but is indeed a linear transform
off XYZ.
Does this only mean the CGColorSpace gamma values are set to 1.0 or
is there more involved?
Hope this clarifies things,
- Ralph
On Jul 16, 2007, at 6:16 PM, Mark wrote:
Hi Brendan, Raphael
I will try to answer these questions as best I can since you've
asked them several times and no one else has replied. However,
my information is mostly conjectural since, as you've noted, none
of this is spelled out in the documents.
On Jul 15, 2007, at 6:17 AM, Mark wrote:
I have some questions about how CoreImage can fit a color
managed workflow.
Core Image supports three color spaces:
One can be supplied at creation of the CIImage - I name it the
input color space
Two can be supplied at creation of the CIContext - the working
and output color space
My understanding (and please correct me if I'm wrong) is that
before applying any filter, Core Image will transform all images
from the input color space to the working color space.
Then all filters get applied and as a last step CI will convert
the final image from the working color space to the output color
space.
This is correct, as far as I know.
But there's no mention on the rendering intent used for the
color space conversions done by CI. What is it? Why was it omitted?
For a Quartz Images (CGImage) I see the rendering intent can be
chosen by the user.
Recall that rendering intents are only useful if you're gamut
clipping. Perhaps this makes more sense if you view it as:
unknown input color space -> XYZ -> CI filters -> XYZ -> unknown
output color space. Since the samples from which you create a
CGImage might be some very strange color space (i.e. a
nonadditive one like CMYK), you'll need a rendering intent to map
it on to XYZ components even though CI allows for XYZ values <
0.0 and > 1.0. The CI filters are then applied to the XYZ
components (or some suitable transform of them like Adobe RGB)
with no clipping whatsoever performed. Hence there is no need to
specify a rendering intent. Now, when they are transformed to
the output color space, they may be gamut mapped, but I believe
ICC output profiles usually have rendering intent already
specified in them.
How sure are you that CIFilters are applied to XYZ components? I
can't recall having read that on the docs. My impression is that
actually we have:
input color space -> working color space -> CIFilters -> output
color space
which would mean all CIFilters are applied to gamma corrected (and
not linear) color codings.
Also, CoreImage defaults to using the GenericRGB colorspace,
unless another is specified. Is it correct to say that using
GenericRGB is terribly wrong when drawing to a calibrated
screen. Shouldn't one always use the screen colorspace as output
so CoreImage can try to match the colors "as good as possible"
to the screen.
You're trying to do too much here. The output colorspace is for
forcing gamut mapping (for soft proofing and the like), and
doesn't bear any resemblance to the monitor colorspace. Once CI
passes your color data through the output colorspace's gamut, it
will correct it for display on the monitor (using the CGContext's
rendering intent).
I am actually rendering to an OpenGL context, and there's no way
to tell/set the color space of an OpenGL context (as far as I
know). That lead me to believe the results will be converted to
the CI output color space and thus the need to set the output
color space to the monitor profile (unless we are drawing to an
offscreen context).
Are you sure that the output color space should not match the
monitor profile in this case?
The whole of this can be summed up as: CI doesn't actually do any
gamut mapping except possibly when converting to the output
colorspace so there's no need to specify the rendering intent.
The CGImage rendering intent is simply for converting from an
arbitrary color space to and XYZ-based one and the context's
rendering intent is what determines the gamut mapping to the
screen (or printer's or whatever's) device space.
Brendan Younger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden