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: Tue, 11 Dec 2007 21:55:09 -0800
- Thread-topic: notches on the L*axis
In a message dated 12/11/07 6:01 AM, MARK SEGAL wrote:
> Marco,
> You've touched on a very interesting question here. I believe it goes beyond
> what is displayed and into how the program works. You can change the read-out
> alright, but the adjustments still work in discrete intervals of +1 from 0 to
> 255, which implies that every tweak of a curve in "16-bit" mode (say using one
> of the keyboard arrows) is actually moving the value roughly by 32768/255 =
> about 128 levels at a time, or 0.39%. Maybe it's just a bit "anal", but I've
> often come across situations where I would have liked to adjust a curve to a
> value between a pair of tweaks.
Hi Mark.
If you create a *16-bit* RGB file in Photoshop with, say, 4 neutral patches
of varying lightness (e.g., R-G-B values of 25, 50, 75, 100), the internal
value is exactly that of the *integer* you entered, with only zeros after
the decimal point.
But, if you remain in 16 bits and apply a slight curve to the image (for
example one that raises the composite RGB curve from 128 input to 136
output, then save the file, the resulting internal values show non-zero
decimal values. In other words, the RGB values are *decimal*, not integers.
You can verify this by opening the 16-bit RGB files, saved as TIFFs, using
the free ColorLab application, and sampling the patches there. ColorLab only
goes as far as showing one decimal, but it's enough to verify that there is
more to what occurs internally in Photoshop than what the application
reports in its 0-255 integer notation.
So, the conclusion I draw from this is that, working in 16 bits in
Photoshop, the pixel values are fractional, *not* integers -- whereas in 8
bits RGB in Photoshop the pixel values are always integers.
*But* in 8-bit CMYK and grayscale modes, Photoshop *does* use fractional
values, for reasons that are not quite clear to me.
Again, all of this can be verified by saving Photoshop files as TIFFs and
sampling the pixel values in ColorLab.
In a message dated 12/11/07 2:21 PM, Mark Segal wrote:
> Showing values and adjusting values in increments finer than 0-255 are very
> different things,
Indeed. My comments only applied to *showing* the values.
The lack of control finer than the relative coarseness of 0-255 or 0-100
integers is another sore point about Photoshop, as good as it is in so many
other ways.
>and clearly if the latter were possible we'd get the former,
>but do we really know what extent of "internal precision"
>is now programmed into Photoshop and with what ease or
>difficulty that could be amended?
In 16 bits (actually, only 15 bits in Photoshop, as we know), I would
presume that the internal precision would be equal to floating-point
15-bits.
Each level of a 0-255 8-bit scale corresponds to 128 levels in 15 bits:
32,768 / 256 = 128
So a 15-bit level of 18,672, for example, would correspond to a value of
145.875 in 0-255 notation:
18672 / 128 = 145.875
As you can see it's a *very simple* division. I leave it to you to determine
how hard that could possibly be to implement in Photoshop... <g>
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