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: Wed, 18 Jul 2007 11:18:01 +0200
Hi Raphael, Brendan,
though I've learned a lot I didn't know about CoreImage's inner
workings through this discussion (many thanks to you both), my
original question remains unanswered.
So I'm thinking about how to best setup a test that shows how
CoreImage is mapping gamut. As I am pretty new to all this color
space messiness, I ask you once more to help me a bit so I setup my
test correctly.
So I have a TIFF file in Adobe RGB that simulates the ColorChecker
(downloaded from babel color). It does only have one color that falls
outside the sRGB gamut so I'm thinking about modifying it a bit so I
have more colors outside sRGB.
I then plan to generate copies of the file mapped to sRGB through
different rendering intents. I would do that using PhotoShop (which
uses Adobe's CMM), Quartz (which uses Apple's CMM) and lastly CoreImage.
I would then write down the L*a*b values of all images for comparison
in a Excel sheet for comparison.
Does this sound reasonable? Would this be enough to qualify
CoreImage's rendering intent?
Do you have any recommendations for the input image's colors - is
what I described above good for the test?
Good to know that! So if I understand it correctly CI will
reverse the gamma of the input image color space -> convert to
working color space (without gamma) -> apply filters -> convert to
output color space and apply gamma
so if working == output color space CI will just apply the final
gamma before returning, else it will apply the matrix that
converts working to output AND then apply the gamma difference
between the two.
Is that it?
So while working on a filter, 50% gray is always R=G=B=0,5?
Well no, because as you've stated just before, the image will be
converted
to the equivalent space linear to light intensity before you arrive
in a CI kernel.
Therefore a 50% gray of generic gray space will give on r, g, b
around 0.28 in the kernel. but a 68% gray would give 0.5 on r, g, b.
A picture is always easier to figure things out :
<http://raphael.dinge.free.fr/coreimagelinearity.png>
On entry an image which is a linear gradient of values with
respect to aRGB (*not* linear to light intensity)
the kernel will clip the values upper to 0.5.
The clip does not occur at the middle of the image, but around
70%, so at least in this example (which is the default case
described in the CoreImage documentation), the values
are first linearized with respect to light intensity.
My fault - I've been reading too much about L*a*b lately and mixed
all up. Thanks the clarification!
Mark
_______________________________________________
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