Re: absolute luminosity
Re: absolute luminosity
- Subject: Re: absolute luminosity
- From: Roger Breton <email@hidden>
- Date: Sat, 12 Nov 2005 12:14:44 -0500
Eugene,
> I am puzzling over a glitch which is beyond my understanding. There are two
> different paths that have lead me to the same question concerning absolute
> rendering and luminosity.
You mean absolute rendering and Luminance, luminosity is a concept assoiated
with "brightness" and, frankly, I haven't the foggest idea how it is
measured. But reading further what you wrote I think you're actually
refering to Lightness (L*). So, OK.
> The first path concerns gamut warning using absolute.
Know that out of gamut displaying is considered voodoo in color management
as there are no standards on how to do this beyond matrix/shaper clipping.
There are many ways on interpreting a LUT to extract its gamut bounderies,
it is certainly not clear to me how Adobe Photoshop does it, at least it
isn't documented anywhere. That's why I tend to view it as voodoo.
> The fact that Gamut
> warning only seems to reveal out of range tones while soft proofing is
> configured to absolute, puzzles me for three reasons.
I'm not sure I follow, here. If I activate Out of Gamut Warning on an aRGB
image while my convesion options are set to SWOPv2 and RelCol, the areas
that are considered out of gamut do get displayed. So, in my view, absCol
does not need to be selected for this behavior to work. But you are right,
below, when you say that :
> ... the displaying of out of gamut colours is
> independent of conversion settings,
Beats me as to why that is, conceptually?
> secondly if they are not independent then
> why doesn¹t relative rendering without black point compensation reveal the
> same out of range tones,
Right.
> and thirdly this seems to suggest a difference
> between absolute and relative rendering with respect to dynamic range,
> (especially since BPC is unavailable with absolute rendering.)
Yes, it would.
> The second path involves the glitch I am puzzling over. I have two scans of
> the same 4x5 chrome before me in their input profiles, one made with an Epson
> 4900 the other with an Eversmart.
Two completely different beasts.
> Both profiles are homemade using Monaco Proof.
Ah!
> A blocked highlight area of the image scanned by the Eversmart appears
> muddy white on the Epson scan.
So you mean to say that the same overexposed area in the 4x5 chrome got
interpreted down to, say, 240r 240g 240b in the Eversmart scan but got
interpreted further down, say, 230r 230g 230b in the Epson scan?
> With relative rendering configured in my colour settings the bright white
> highlight of the Eversmart reads as L*100 and the muddy white highlight of the
> Epson reads as L*87.
Do you see a difference in RGB in that muddy area across both scans,
regardless of what Photoshop tells you? I don't mind Photoshop telling me
that it sees one area as L* = 100 if this area does read R=G=B=255.
> With absolute configured in my colour settings the bright
> white highlight of the Eversmart scan remains bright white but now reads L*87.
Now, this looks like the Conversion options settings is doing its job: in
RelCol, the whithest area should read L*100, I had many arguments in the
past with Picto about that because that's my understanding of relative
colorimetry for an input profile but it seems I was wrong, what can I say.
> If I convert to a RGB workspace using relative the highlight remains at L*100,
> yet if I convert the file using absolute the highlight (now visually changing)
> becomes L*87.
Now, that would seem to make sense. Because, after all, the relative
brighest area, in terms of CIE Lightness, in your original 4x5 chrome are in
are not completely transparent in all likelihood.
> On the other hand, a conversion of the Epson scan using either
> relative or absolute produces exactly the same luminosity.
The same L* value? Then, if you used Monaco Proof to make the two profiles,
this can only mean that, physically, the two scans are different to begin
with in terms of RGB data in the highlights. I don't see any other logical
explanations.
> This could simply
> be the case of a bad profile, yet again there seems to be a behavioural
> difference between absolute and relative regarding luminosity.
Yes, with regards to the *interpretation* of Lightness or Lightness mapping.
> The good book ( Fraser, Murphy, Bunting), probably because it is written for
> practitioners and not scientists, leads us to believe that the only
> difference between absolute and relative rendering is in the remapping of
> white.
Well, there is a difference converting one way or the other from the same
source profile to, say, a CMYK space. It is plain to see this. In one case
the rendered image becomes lighther overall, not in the other case.
> Are there other differences between relative and absolute that account for
> this behavioural difference with respect to luminosity?
It all has to do, in your case, with how the input RGB is mapped to CIE
colorimetry. But, no, I don't know of other behavioural difference in this
respect others than what's described in the ICC Specs which, I know, are not
always *interpreted* the same way by all the CMS packages.
> Eugene Appert
Roger Breton | Laval, Canada | email@hidden
http://pages.infinit.net/graxx
_______________________________________________
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