Re: Decimal precision in Photoshop's info palette
Re: Decimal precision in Photoshop's info palette
- Subject: Re: Decimal precision in Photoshop's info palette
- From: "Dennis W. Manasco" <email@hidden>
- Date: Sat, 20 May 2006 04:09:25 -0500
At 5:03 PM +1000 5/20/06, Graeme Gill wrote:
Actually, I regard the way Photoshop (and lots of other applications)
handle RGB to be rather "backwards". CMYK is typically 8 bit too, yet
it's manipulated as 0 .. 100%, not 0 ... 256, so why is RGB different ?
Graeme --
(With all due respect to someone who knows a lot more about color
theory than I do.)
I think that it is CMYK that Photoshop (and lots of other
applications) handle "rather backwards" in this instance.
I would ask why CMYK uses 0..100% and I would posit that it is
because printers think of it this way and any other approach would be
unacceptable to them.
The trouble with using the actual device encoding values to observe and
set device values, is that they vary so much. 8 bit, 12 bit, 16 bit - a
number in one encoding doesn't map to another.
But, in terms of their underlying representation they _do_ map
directly without rounding error.
RGB values in 8-bit range from 0 to 255 (not 256) and thus are
represented as binary unsigned integers from
0000 0000 to 1111 1111.
In 16 bit they range from
0000 0000 0000 0000 to 1111 1111 1111 1111.
Every integer from 0 to 255 is represented and there is no error from
rounding when processing the input.
Since there are 256 discrete values in the range 0 to 255, and 65536
values in the range 0 to 65535, and the ratio is 1 to 256 (or 2^4),
the mapping of an 8-bit space to a 16-bit space is fairly straight
forward.
(_My_ problem is that the input dialogs you get when working in
16-bits don't allow you to enter values in the range of 0..65535, but
insist on 0..255.)
I _hope_ that all of Photoshop's internal calculations are done by
converting the integers to 64- or 128-bit floating-point numbers and
then converting back on final output, but I have no way of knowing
the internals of the program (and the act of conversion to
floating-point, when it is unnecessary, introduces its own
inaccuracies).
It's easier in many situations to normalize the device values, either
to the range 0.0 .. 1.0, or 0.0 .. 100%. The device value is then
independent of the encoding.
Yes. It _is_ easier to get your head around when thinking about
changes in the values, and it is easier to programmatically
manipulate, but it introduces error at the _start_ of the process
because 0 to 100 cannot be mapped onto the underlying binary
representation of 0 to 255 (or 0 to 65535) without rounding error.
Best wishes,
-=-Dennis
.
_______________________________________________
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