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: Sun, 21 May 2006 05:26:01 -0500
At 11:09 PM +1000 5/20/06, Graeme Gill wrote:
Dennis W. Manasco wrote:
...
...
Right, so you've illustrated wonderfully
the problem with insisting users enter encoded values :-)
Thank you :-)
The ratio is actually 257. (255 * 257 = 65535)
No. Remember that 0 is a valid and necessary input value. Thus 0..255
has 256 discrete values and 0..65535 has 65536 discrete values.
Thus 256 * 256 = 256 * 2^8 = 65536.
(Though for some stupid reason I typed 2^4 in my original message
instead of 2^8.)
...
Using encoded values puts another "geek" barrier in the way of most
users. Most don't want to know about precise underlying encoding,
whether it's 0..255, 0..65535,
...
Graeme --
That wasn't my point at all.
My point was that 0..100 does not map explicitly onto unsigned
integer, while 0..255 does.
If you enter a number in the range of 0..100 for an input that will
be interpreted as unsigned integer you have _introduced_an_error_ in
the program's evaluation of your intention _from_the_very_beginning_.
An error which the program will compound with every step of its
manipulation and further evaluation.
After all, 30% cyan is 76.5 on a scale of 0..255. If the program is
representing your cyan in 8-bits it's _never_ going to get that right.
Now:
If you want to argue that PhotoShop should allow the entry of color
values in the Color Picker with full 128-bit IEEE accuracy, or even
if you want to argue that it should _never_ represent color with
anything but 128-bit IEEE accuracy except when outputting to an
environment which requires integers (such as printing), you have my
provisional agreement.
...
The nice thing about a real value, is that if you are aware of the
underlying representation, you can specify the value in a way that gets
the precise encoded value you want, and if you don't, you'll get the
closest value to what you asked for.
I am not sure what you mean by a "real value."
If you mean a 64- or 128-bit IEEE REAL then see my paragraph above.
If you mean that entering 40% is somehow more "real" than entering
102 on a scale from 0 to 255 then I don't see how the distinction is
valid.
Yes, 40% is a lot easier to think about and use than 102, but it's
only blind luck that 40% maps directly onto the range of 0..255.
What if you wanted 10%? Oops. That's 25.5 on a 0..255 scale. Your
result will always be off your desired value by 1.96%. I don't know
of any way to ascertain the direction of the error.
If you mean that I should have to enter 49.8039215686275 when I want
a value of 127 on an integer scale of 0..255 then I respectfully
decline.
Consider this, if an application like photoshop let you enter a value
of 50%, then it could automatically apply dithering to a fill, to
achieve that level (just like it does on smooth blends). If you are
forced to choose 127 or 128, this isn't a possibility.
...
This is precisely my point: If the input is going to be represented
as an 8-bit unsigned integer it _doesn't_matter_ how PhotoShop lets
you enter the data.
If the program were to let you enter 50%, and it was representing the
entry as 8-bit data, you would _never_ get 50%:
50% of 255 is 127.5. All that would happen, if the program let you
enter 50%, would be that the _program_ would choose between 127 and
128 rather than you.
A dubious improvement at best.
Again --
Let's argue for floating-point representation of color at every stage
in PhotoShop (including dialog entry), except for output to other
formats and printing.
That's a movement I can get behind.
Unfortunately, I'll probably have better luck tilting at windmills...
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