Re: notches on the L*axis
Re: notches on the L*axis
- Subject: Re: notches on the L*axis
- From: Marco Ugolini <email@hidden>
- Date: Sat, 08 Dec 2007 18:30:43 -0800
- Thread-topic: notches on the L*axis
In a message dated 12/8/07 6:42 AM, eugene appert wrote:
> Hello,
>
> I am confused about how file data of equal brightness values are translated
> to the target profile. I assumed that the file data range of 255 brightness
> levels would have to be translated through the 100 L* distinctions in the
> proifle connexion space. Yet I can see brightness distinctions on the screen
> from RGB 1 toRGB 9 which should all translate to L*1 . When I first noticed
> this I thought it was possible BPC was using the RGB data to remap the
> brightness higher, but I notice the same the thing much farther up the
> curve. My monitor regesters a distinction between RGB 72 and RGB 73 ( L* 30)
> which is maintained after converting to a target space. For example after a
> conversion to US swop coated v2, RGB 72 & 73 become 66%, 60% 58% 42% and 66%
> 59% 58% 41%, which both translate as L*30.
>
> This phenomenon seriously challenges my understanding of colour management
>
> Any help out of the rabbit hole would be greatly appreciated.
Eugene,
I may be alone in this, but I cannot quite understand what exactly you are
describing here, and in turn that means that I cannot figure out (a) whether
there is a problem and (b) how it can be solved.
A) "File data of equal brightness values": are you describing an L*a*b*
neutral step wedge here?
B) "File data range of 255 brightness levels": again, a neutral step wedge,
or does this refer to any RGB color file? In the latter case, the 255 steps
are interpreted through the profile's TRC (Tonal Response Curve), which
means that equal numerical steps do not necessarily translate into visually
equal linear steps. Only Gamma 1.0 has a linear TRC.
C) "Yet I can see brightness distinctions on the screen from RGB 1 to RGB 9
which should all translate to L*1": this sounds very vague. What exactly are
you converting, and to what target space? Why should the the RGB steps from
1 to 9 map to L* 1? It would help to know more about the source space.
D) "For example after a conversion to US swop coated v2, RGB 72 & 73 become
66%, 60% 58% 42% and 66% 59% 58% 41%, which both translate as L*30."
Actually, if you tag those same RGB values with AdobeRGB and convert to US
SWOP (Coated) v2 using RelCol with BPC, RGB 72 becomes C67 M60 Y58 K42, and
RGB 73 becomes C66 M59 Y58 K41. A conversion of these US SWOP (Coated) v2
CMYK values to L*a*b* (Rel Col + BPC) gives us L* 30 for the former, L* 31
for the latter in Photoshop (CS3).
Also, in Photoshop the values are rounded up to the nearest integer.
Otherwise, you would see that, if you tag those RGB values with AdobeRGB for
example and convert *directly* to L*a*b*, RGB 72 maps to L* 29.90, whereas
RGB 73 maps to L* 30.36 (all of this using either Relative Colorimetric or
Perceptual).
At any rate, these are all very small differences, and you may be asking of
the process a degree of precision that it was not meant to provide, at least
not using Photoshop with its current capabilities. The day that Photoshop
provides two or more points of decimal precision, that will change, and
subtle differences will be tracked numerically.
Marco Ugolini
_______________________________________________
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