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: Graeme Gill <email@hidden>
- Date: Thu, 25 May 2006 23:50:31 +1000
Dennis W. Manasco wrote:
Thus 256 * 256 = 256 * 2^8 = 65536.
Which is irrelevant, since 8 bits can't represent 256, and
16 bits can't represent 65536.
8 bits can represent 0 to 255, and 16 bits can represent 0 to 65535.
The maximum value an 8-bit number can have is 255 == 1111 1111.
Since zero is _also_ a number, an 8-bit number can have 256 _different_
values:
All the numbers from 1 to 255 _plus_ the number _0_ equals 256 different
numbers.
16-bit numbers range from 0 to 65535.
Since 0 is also a number when represented by 16-bits, a 16-bit number
can have 65536 different values.
Do the pseudo-code in the language of your choice:
y = 0
for x = 0 to 255
count = y + 1
next x
print count
And so what ? It's irrelevant. The CPU doesn't
interpret binary values 0..255 as numbers 1..256, it
interprets then as numbers 0..255.
If the CPU is given an 8 bit value (representing 0.. 255)
and needs to convert it to a 16 bit value (0..65536) it
has to multiply by 257. The maths is simple, but not
intuitively obvious. [You're now trolling - right ?]
This was one of the points I was trying to make:
8-bit to 16-bit mapping is fairly straight forward. Mapping the range
0..100 onto a binary integer range is a nightmare filled with inaccuracies.
I can't agree with you. I've shown that it is straightforward, and
for many purposes, there is a user interface advantage in letting
the computer do the conversions from familiar range (say 0.. 100%),
to the binary representation.
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_.
That's too broad a generalization. You're assuming that for some reason
I want to specify an 8 bit integer. You haven't justified that
assumption. Perhaps I want to specify a number "about 50%", give
or take a percent. It's too light, so I'll try a bit less, say "40%".
If I switch from 8 bits to 16 bits rasters, I don't have to change
how I specify my intentions. If I want a very precise number
for some reason, I'll specify: "I want exactly 50.12656%"
Not at all. You have specified what you want, the program interprets
it in light of what's possible. If I specify 50.0%, and the underlying
system is 8 bits, I get 128, and error of about 0.2%
This is my primary point.
When you choose a number from 0..255 for an 8-bit number at least you
know that your wishes will be followed.
Oh, you do ? Lets see :- you specify "16 bits" in Photoshop,
and enter a value of 127. You actually get a value of 16319,
instead of the exact value of 16319.74901960.... :-)
But I'm not disagreeing that it should be possible to see and
enter the underlying value if it is an integer, just that it's
not an interface that most people really need to use most of
the time.
I mess about with ICC profiles all the time, but I very, very
rarely go looking at the binary representation, it doesn't mean
much. What does 0x5676 mean ? Is it a big number or a small number ?
Is it negative or positive ? I'm far happier seeing the value
as 0.3377431 (unsigned 16 bit) or 86.4627 (7.8 bit). That's what
the number actually means.
If the initial measurement is compromised then any conclusion is
compromised by, at the _very_ least, the value of the original inaccuracy.
You are continuing to assume that there is some reason everyone
wants to enter 8 bit numbers. I don't think that assumption is
justified most of the time. You are assuming that I can only
enter integers between 0 and 100. I never suggested such a limitation.
By convention you round up.
No.
That's the arithmetic rounding convention, and it is widely
used.
IEEE mathematical compliance requires that you always round to even (or
odd, though even is preferred) on 0.5.
Actually there are 4 IEEE rounding modes you can pick, but they
apply to to discarded bits of precision, not rounding to
integers. You can implement any integer rounding rule you
like using IEEE compliant arithmetic.
Rounding up (or down) consistently on 0.5 will introduce easily
demonstrable statistical errors.
Yes, but irrelevant in this particular situations.
Please DO NOT always round up (or down) on 0.5.
Too late. Lots of general software float to int conversions
round up on 0.5, because that's the arithmetic convention,
it's consistent, and it has no statistical impact because
it's not being used for statistical purposes.
Well...
It _is_ an integer ; -:
But what is gained by entering 50% ?
Because in determining a value for a particular purpose,
it's a good place to start.
If your input is normalized to 8- (or 16-) bit before it is applied to
the 8- or 16-bit representation of the data then what purpose can be
achieved by entering it in in different formats?
Ease of comprehension, and independence from the implementation details.
Saving all color values as IEEE 64- or 128- bit reals would create huge
files and be deadly slow on today's computers.
Still, in 1984 my company paid what I considered a small fortune for a 5
megabyte Apple Profile hard disk. Who's to say that in 10 years
PhotoShop files smaller than a gig. won't be considered an anomaly.
Sorry, I think you're wasting your time for most situations. For a well
adjusted image (output rendered), the quantization of 8 bits is rarely
visible. 16 bit's is more than enough (10-14 bits has been demonstrated
to be adequate for typical edits). 64 or 128 bit float is
complete and utter overkill. Even HDR images can be stored in more
compact forms than pure floating point. The input devices, color
instruments, color profiles, output devices, and our eyes, simply
aren't close to needing the sort of dynamic range and precision
provided by 32 bit floating point, never mind 64 or 128.
Graeme Gill.
_______________________________________________
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