Sorry, you must live in a different universe to me.
In my universe 0 has been recognized as a number for several thousand years.
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
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
(You've let the fact that there are 256 8 bit values, and 65536 16 bit values
lead you astray.)
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
My point was that 0..100 does not map explicitly onto unsigned
integer, while 0..255 does.
I'm not sure what you mean by "explicitly"
I mean that integers in the range 0..100 cannot be mapped onto
integers in the range 0..255 without introducing _error_. in most of
I thought that this was what the conversation was about.
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
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.
When you choose a value that cannot be explicitly mapped onto the
range without rounding you are letting the computer decide for you.
The quantization error does not get "compounded".
The earlier an error is introduced the more influence the error has.
We both know this from elementary statistical analysis.
A ruler cannot be more accurate than half its smallest marking. No
analysis of its measurements can be more accurate than that metric.
If the initial measurement is compromised then any conclusion is
compromised by, at the _very_ least, the value of the original
Every manipulation of that "measurement" will compound the error.
I am not sure what you mean by a "real value."
As in, not an integer.
And there we are.
Through a really weird dance we have agreed.
I too would _really_ like PhotoShops' input dialogs to accept a
greater degree of "accuracy."
But it will not matter a whit if they do.
Their input will have to be translated into their underlying data
format, and that format will be either 8-bit, or 16-bit, integer
unless PhotoShop goes to IEEE 64-bit or 128-bit.
But then, as been pointed out, this would make for some uselessly large files.
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.
By convention you round up.
Consistently rounding up on 0.5 is even worse than re-initializing a
random-number generator. Or even using some obfuscated trick to make
the generator more "random.:
IEEE mathematical compliance requires that you always round to even
(or odd, though even is preferred) on 0.5.
Rounding up (or down) consistently on 0.5 will introduce easily
demonstrable statistical errors.
Please DO NOT always round up (or down) on 0.5.
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
You can enter 49.8, or 49.7, but why do you want 127 ? What's
special about it ?
It _is_ an integer ; -:
But what is gained by entering 50% ?
I would posit that _nothing_ is gained which cannot be more
adequately obtained by knowing what you are doing.
Nothing can be achieved by entering numbers which cannot be used.
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?
It comes down to whether you are prepared to pay the price in terms
of performance and memory usage (and possibly disk space.)
With bells on.
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.
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