"16-bit" mode.
 

First I thought it was strange when I found out that Photoshop's 16-bit
mode was actually 15-bit. Then, I though it was stranger still when I
found out there was one additional level (32768; it was explained that
this made certain types of math faster). Now, this evening, I was
writing an applet to extract RAW data from the uncompressed output of
the DNG converter, and decided to create a raw greyscale bitmap 256*256,
containing every possible 16-bit value, to see what PS would do with
them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
etc, but it does not. This is a sample of what it does:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

2044 19128
2045 19131
2046 19131
2047 19131
2048 19131
2049 19131
2050 19131
2051 19134
2052 19134

4085 32762
4086 32762
4087 32766
4088 32766
4089 32766
4090 32766
4091 32766
4092 32766
4093 32768
4094 32768
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

This is basically about 13.5 bits of level-resolution.
--


John P Sheehy

wrote:
First I thought it was strange when I found out that Photoshop's 16-bit
mode was actually 15-bit. Then, I though it was stranger still when I
found out there was one additional level (32768; it was explained that
this made certain types of math faster). Now, this evening, I was
writing an applet to extract RAW data from the uncompressed output of
the DNG converter, and decided to create a raw greyscale bitmap 256*256,
containing every possible 16-bit value, to see what PS would do with
them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
etc, but it does not. This is a sample of what it does:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

2044 19128
2045 19131
2046 19131
2047 19131
2048 19131
2049 19131
2050 19131
2051 19134
2052 19134

4085 32762
4086 32762
4087 32766
4088 32766
4089 32766
4090 32766
4091 32766
4092 32766
4093 32768
4094 32768
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

This is basically about 13.5 bits of level-resolution.

Hi John...

Just quickly off the top of my head... is it possible
that they've used a base 1 array?

Take care.

Ken

wrote:
First I thought it was strange when I found out that Photoshop's 16-bit
mode was actually 15-bit. Then, I though it was stranger still when I
found out there was one additional level (32768; it was explained that
this made certain types of math faster). Now, this evening, I was
writing an applet to extract RAW data from the uncompressed output of
the DNG converter, and decided to create a raw greyscale bitmap 256*256,
containing every possible 16-bit value, to see what PS would do with
them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
etc, but it does not. This is a sample of what it does:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

2044 19128
2045 19131
2046 19131
2047 19131
2048 19131
2049 19131
2050 19131
2051 19134
2052 19134

4085 32762
4086 32762
4087 32766
4088 32766
4089 32766
4090 32766
4091 32766
4092 32766
4093 32768
4094 32768
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

This is basically about 13.5 bits of level-resolution.

Hi John...

Just quickly off the top of my head... is it possible
that they've used a base 1 array?

Take care.

Ken

wrote:
First I thought it was strange when I found out that Photoshop's 16-bit
mode was actually 15-bit. Then, I though it was stranger still when I
found out there was one additional level (32768; it was explained that
this made certain types of math faster). Now, this evening, I was
writing an applet to extract RAW data from the uncompressed output of
the DNG converter, and decided to create a raw greyscale bitmap 256*256,
containing every possible 16-bit value, to see what PS would do with
them. I assumed that PS would make 0 and 1 0, 2 and 3 1, 4 and 5 2,
etc, but it does not. This is a sample of what it does:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

2044 19128
2045 19131
2046 19131
2047 19131
2048 19131
2049 19131
2050 19131
2051 19134
2052 19134

4085 32762
4086 32762
4087 32766
4088 32766
4089 32766
4090 32766
4091 32766
4092 32766
4093 32768
4094 32768
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

This is basically about 13.5 bits of level-resolution.

Hi John...

Just quickly off the top of my head... is it possible
that they've used a base 1 array?

Take care.

Ken

Kibo informs me that stated that:

16-bit PS values
[...]
0 0
1 0
[...]
2052 19134

4085 32762
[...]
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

Off the top of my head, my #1 guess would be that it's a colour-space
conversion. (There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Kibo informs me that stated that:

16-bit PS values
[...]
0 0
1 0
[...]
2052 19134

4085 32762
[...]
4095 32768

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

Off the top of my head, my #1 guess would be that it's a colour-space
conversion. (There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

In message ,
wrote:

Kibo informs me that stated that:

16-bit PS values
[...]
0 0
1 0
[...]
2052 19134

4085 32762
[...]
4095 32768

Sorry; I messed up on that chart. I had 12-bit values in my head when I
wrote that. The numbers in the "real 16-bit column" should have been
starting at zero, around 32768, and around 65535, like so:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

32764 19128
32765 19131
32766 19131
32767 19131
32768 19131
32769 19131
32770 19131
32771 19134
32772 19134

65525 32762
65526 32762
65527 32766
65528 32766
65529 32766
65530 32766
65531 32766
65532 32766
65533 32768
65534 32768
65535 32768



Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

Off the top of my head, my #1 guess would be that it's a colour-space
conversion.

Can't be in this case. This is "open as .raw"

Even if there were a color space, I can't think of any reason to
posterize in it. Color space is about things like gamma, saturation,
combinations of primary colors, not about quantization.

(There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

..raw

The things you are asking about would affect curves, not quantization.
--


John P Sheehy

In message ,
wrote:

Kibo informs me that stated that:

16-bit PS values
[...]
0 0
1 0
[...]
2052 19134

4085 32762
[...]
4095 32768

Sorry; I messed up on that chart. I had 12-bit values in my head when I
wrote that. The numbers in the "real 16-bit column" should have been
starting at zero, around 32768, and around 65535, like so:

real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

32764 19128
32765 19131
32766 19131
32767 19131
32768 19131
32769 19131
32770 19131
32771 19134
32772 19134

65525 32762
65526 32762
65527 32766
65528 32766
65529 32766
65530 32766
65531 32766
65532 32766
65533 32768
65534 32768
65535 32768



Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

Off the top of my head, my #1 guess would be that it's a colour-space
conversion.

Can't be in this case. This is "open as .raw"

Even if there were a color space, I can't think of any reason to
posterize in it. Color space is about things like gamma, saturation,
combinations of primary colors, not about quantization.

(There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

..raw

The things you are asking about would affect curves, not quantization.
--


John P Sheehy

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
..raw.
--


John P Sheehy

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
..raw.
--


John P Sheehy

Kibo informs me that stated that:

In message ,
wrote:
[...]

Sorry; I messed up on that chart. I had 12-bit values in my head when I
wrote that. The numbers in the "real 16-bit column" should have been
starting at zero, around 32768, and around 65535, like so:

real
16-bit PS values
0 0
9 5
32772 19134
65535 32768
(etc)

Okay, that seems a much better choice of data set. ;)

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

Off the top of my head, my #1 guess would be that it's a colour-space
conversion.

Can't be in this case. This is "open as .raw"

But what kind of .raw? - You obviously don't mean a Canon (etc) camera
RAW file. ISTR that PS has some sort of generic, simple binary image
format. Is that what you mean?

Even if there were a color space,

Unless you've disabled it, PS colour-manages by default, & will convert
to your working space, or bitch about your input file, etc. If it were
me, I'd check the colour-management settings & ensure that they're set
to ask what to do when opening a file that doesn't have an embedded
colour-space, or one that doesn't match your working space.

I can't think of any reason to
posterize in it. Color space is about things like gamma, saturation,
combinations of primary colors, not about quantization.

I don't know if this is what's happening to you, but if your working
space is (for example) sRGB, & your image file is maxing out the
absolute limits of what PS can process (which it does, because that's
the whole point of your test!), then I woldn't be greatly surprised if
PS rescales/transforms that data to fit within the working colour-space.
Think about it from the point of view of the PS programmers - your test
image is the very definition of a pathological program input, & it has
to do *something* to shrink the input gamut into something that won't
choke the image-processing functions.

(There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

.raw

The things you are asking about would affect curves, not quantization.

Same difference in this context. Your problem, as you've stated it, is
that you are inputting a data set containing the maximum & minimum
possible data values allowable (we assume, at least) by the file format.
If that data is transformed in any way whatsoever, (offsets, scaling,
curves, anything at all), you'll lose the 1:1 correspondance that you're
expecting to see.
What I suspect is that it'll turn out that PS doesn't /really/ permit
pixels to stretch from the -2^15 to +2^15 range implied by the signed 16
bit/channel/pixel data format, & that at minimum, it transforms any data
that pathological into some internal pseudo-colour-space that's bigger
than any of the standard spaces.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Kibo informs me that stated that:

In message ,
wrote:
[...]

Sorry; I messed up on that chart. I had 12-bit values in my head when I
wrote that. The numbers in the "real 16-bit column" should have been
starting at zero, around 32768, and around 65535, like so:

real
16-bit PS values
0 0
9 5
32772 19134
65535 32768
(etc)

Okay, that seems a much better choice of data set. ;)

Does anyone have any idea why they posterize the data even more than the
15-bit limitation?

Off the top of my head, my #1 guess would be that it's a colour-space
conversion.

Can't be in this case. This is "open as .raw"

But what kind of .raw? - You obviously don't mean a Canon (etc) camera
RAW file. ISTR that PS has some sort of generic, simple binary image
format. Is that what you mean?

Even if there were a color space,

Unless you've disabled it, PS colour-manages by default, & will convert
to your working space, or bitch about your input file, etc. If it were
me, I'd check the colour-management settings & ensure that they're set
to ask what to do when opening a file that doesn't have an embedded
colour-space, or one that doesn't match your working space.

I can't think of any reason to
posterize in it. Color space is about things like gamma, saturation,
combinations of primary colors, not about quantization.

I don't know if this is what's happening to you, but if your working
space is (for example) sRGB, & your image file is maxing out the
absolute limits of what PS can process (which it does, because that's
the whole point of your test!), then I woldn't be greatly surprised if
PS rescales/transforms that data to fit within the working colour-space.
Think about it from the point of view of the PS programmers - your test
image is the very definition of a pathological program input, & it has
to do *something* to shrink the input gamut into something that won't
choke the image-processing functions.

(There are plenty of other possibilities, but that seems by
far the most likely.)

Questions:
What format are you using to store your artificial data?
What colour-space have you got PS configured to work in?
What rules have you told PS to use when loading a file with a different
model to the default, or no model at all?

.raw

The things you are asking about would affect curves, not quantization.

Same difference in this context. Your problem, as you've stated it, is
that you are inputting a data set containing the maximum & minimum
possible data values allowable (we assume, at least) by the file format.
If that data is transformed in any way whatsoever, (offsets, scaling,
curves, anything at all), you'll lose the 1:1 correspondance that you're
expecting to see.
What I suspect is that it'll turn out that PS doesn't /really/ permit
pixels to stretch from the -2^15 to +2^15 range implied by the signed 16
bit/channel/pixel data format, & that at minimum, it transforms any data
that pathological into some internal pseudo-colour-space that's bigger
than any of the standard spaces.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Kibo informs me that stated that:

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
.raw.

Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself. ;)

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Kibo informs me that stated that:

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
.raw.

Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself. ;)

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

In message ,
wrote:

Kibo informs me that stated that:

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
.raw.

Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself. ;)

I just wrote an applet in C that stripped the RAW data out of
uncompressed .dng files and multiplied them by 16 so that there wouldn't
be any quantization (the .dng files use the numbers 0 to 4095 in 16-bit
space) . I modified it slightly to create a string of 65536 2-byte
integers, 0 to 65535, and loaded it into PS as a 256*256 16-bit
greyscale bitmap. I placed the "Info" cursor over it, and got those
values.
--


John P Sheehy

In message ,
wrote:

Kibo informs me that stated that:

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
.raw.

Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself. ;)

I just wrote an applet in C that stripped the RAW data out of
uncompressed .dng files and multiplied them by 16 so that there wouldn't
be any quantization (the .dng files use the numbers 0 to 4095 in 16-bit
space) . I modified it slightly to create a string of 65536 2-byte
integers, 0 to 65535, and loaded it into PS as a 256*256 16-bit
greyscale bitmap. I placed the "Info" cursor over it, and got those
values.
--


John P Sheehy

In message ,
wrote:

Kibo informs me that stated that:

In message ,
wrote:

What format are you using to store your artificial data?

A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
.raw.

Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself. ;)

I just wrote an applet in C that stripped the RAW data out of
uncompressed .dng files and multiplied them by 16 so that there wouldn't
be any quantization (the .dng files use the numbers 0 to 4095 in 16-bit
space) . I modified it slightly to create a string of 65536 2-byte
integers, 0 to 65535, and loaded it into PS as a 256*256 16-bit
greyscale bitmap. I placed the "Info" cursor over it, and got those
values.
--


John P Sheehy

In message ,
(Mitch Alsup) wrote:

This looks like somebody is applying the gamma correction to the RAW data
ouptut = input**2.2 / some-fixed-scaling

No; it's totally linear. 6 sequential 16-bit values become one "PS
16-bit" value (except for the highest and lowest values, which are 3 to
1).

I think its time for Adobe to realize that people have fast machines,
and that they need to stop cutting corners on quality for speed.
--


John P Sheehy

In message ,
(Mitch Alsup) wrote:

This looks like somebody is applying the gamma correction to the RAW data
ouptut = input**2.2 / some-fixed-scaling

No; it's totally linear. 6 sequential 16-bit values become one "PS
16-bit" value (except for the highest and lowest values, which are 3 to
1).

I think its time for Adobe to realize that people have fast machines,
and that they need to stop cutting corners on quality for speed.
--


John P Sheehy

what the hell are you talking about?!!! :(

what the hell are you talking about?!!! :(

"Mike Engles" wrote in message
...
SNIP
There was a discussion about this kind of thing on the scanner
group,
comp.periphs.scanner. Post your observation there. You might get a
explanation.

You probably are referring to these:
1. Chris Cox's 'explanation' of the internal format of 15bits+1:
http://groups.google.nl/groups?selm=...25ccox%40minds
pring.com&output=gplain
2. The way Photoshop converts (16-bits to 8-bits)
http://groups.google.com/groups?selm...%25ccox%40mind
spring.com&output=gplain

Bart

"Mike Engles" wrote in message
...
SNIP
There was a discussion about this kind of thing on the scanner
group,
comp.periphs.scanner. Post your observation there. You might get a
explanation.

You probably are referring to these:
1. Chris Cox's 'explanation' of the internal format of 15bits+1:
http://groups.google.nl/groups?selm=...25ccox%40minds
pring.com&output=gplain
2. The way Photoshop converts (16-bits to 8-bits)
http://groups.google.com/groups?selm...%25ccox%40mind
spring.com&output=gplain

Bart

In message ,
wrote:

wrote:

(Mitch Alsup) wrote:

This looks like somebody is applying the gamma correction to the RAW
data
ouptut = input**2.2 / some-fixed-scaling

No; it's totally linear.

Form your own table:

32764/19128 = 1.713

65525/32762 = 2.000

So it isn't exactly linear. From these two points (essentially all
you posted) it looks like there is a gamma-esque hump in the transfer
function. You should fetch gnuplot or a similar plotting tool and
plot the entire "real" vs "photoslop" correspondance you obtained.

Yes, you're right; it isn't perfectly linear, due to color management.
It is almost linear (gamma close to 1), but that isn't the most
disturbing problem. The problem is that the data is severely
posterized. Even with color management disabled, this only happens with
greyscale; 16-bit RGB bitmaps transfer very simply; they are
psvalue=int((inputvalue+1)/2)). Greyscale only uses 1/3 as many levels
as RGB; 6 input values become 1 PS value, as opposed to 2 becoming 1.
--


John P Sheehy

In message ,
wrote:

wrote:

(Mitch Alsup) wrote:

This looks like somebody is applying the gamma correction to the RAW
data
ouptut = input**2.2 / some-fixed-scaling

No; it's totally linear.

Form your own table:

32764/19128 = 1.713

65525/32762 = 2.000

So it isn't exactly linear. From these two points (essentially all
you posted) it looks like there is a gamma-esque hump in the transfer
function. You should fetch gnuplot or a similar plotting tool and
plot the entire "real" vs "photoslop" correspondance you obtained.

Yes, you're right; it isn't perfectly linear, due to color management.
It is almost linear (gamma close to 1), but that isn't the most
disturbing problem. The problem is that the data is severely
posterized. Even with color management disabled, this only happens with
greyscale; 16-bit RGB bitmaps transfer very simply; they are
psvalue=int((inputvalue+1)/2)). Greyscale only uses 1/3 as many levels
as RGB; 6 input values become 1 PS value, as opposed to 2 becoming 1.
--


John P Sheehy

In message ,
"Bart van der Wolf" wrote:

"Mike Engles" wrote in message
...
SNIP
There was a discussion about this kind of thing on the scanner
group,
comp.periphs.scanner. Post your observation there. You might get a
explanation.

You probably are referring to these:
1. Chris Cox's 'explanation' of the internal format of 15bits+1:
http://groups.google.nl/groups?selm=...25ccox%40minds
pring.com&output=gplain
2. The way Photoshop converts (16-bits to 8-bits)
http://groups.google.com/groups?selm...%25ccox%40mind
spring.com&output=gplain

The slight gamma turned out to be from color management, but what I am
talking about appears to be slightly different from what is discussed in
the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly
posterized. With color management turned off, the count starts:

0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ...


Where is 2? You can't be skipping numbers while others are being
repeated multiple times; that makes no sense whatsoever.

The sad fact of the matter is that not only is PS' "16-bit" RGB only
15-bit, but its "16-bit" greyscale has even less effective bits. Even
if you perform a bicubic upsampling, you can't get the missing values.
--


John P Sheehy

In message ,
"Bart van der Wolf" wrote:

"Mike Engles" wrote in message
...
SNIP
There was a discussion about this kind of thing on the scanner
group,
comp.periphs.scanner. Post your observation there. You might get a
explanation.

You probably are referring to these:
1. Chris Cox's 'explanation' of the internal format of 15bits+1:
http://groups.google.nl/groups?selm=...25ccox%40minds
pring.com&output=gplain
2. The way Photoshop converts (16-bits to 8-bits)
http://groups.google.com/groups?selm...%25ccox%40mind
spring.com&output=gplain

The slight gamma turned out to be from color management, but what I am
talking about appears to be slightly different from what is discussed in
the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly
posterized. With color management turned off, the count starts:

0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ...


Where is 2? You can't be skipping numbers while others are being
repeated multiple times; that makes no sense whatsoever.

The sad fact of the matter is that not only is PS' "16-bit" RGB only
15-bit, but its "16-bit" greyscale has even less effective bits. Even
if you perform a bicubic upsampling, you can't get the missing values.
--


John P Sheehy

In message ,
"Roger N. Clark (change username to rnclark)"
wrote:

In my testing of photoshop on real images, I find the following
equation:

PS = int(IP/2),

Are you sure it isn't "PS = int((IP+1)/2)"?

where PS = the photoshop "16-bit" value and
IP = the 16-bit output from ImagesPlus.

--


John P Sheehy

In message ,
"Roger N. Clark (change username to rnclark)"
wrote:

In my testing of photoshop on real images, I find the following
equation:

PS = int(IP/2),

Are you sure it isn't "PS = int((IP+1)/2)"?

where PS = the photoshop "16-bit" value and
IP = the 16-bit output from ImagesPlus.

--


John P Sheehy

wrote:

In message ,
"Bart van der Wolf" wrote:


"Mike Engles" wrote in message
...
SNIP

There was a discussion about this kind of thing on the scanner

group,

comp.periphs.scanner. Post your observation there. You might get a
explanation.

You probably are referring to these:
1. Chris Cox's 'explanation' of the internal format of 15bits+1:
http://groups.google.nl/groups?selm=...25ccox%40minds
pring.com&output=gplain
2. The way Photoshop converts (16-bits to 8-bits)
http://groups.google.com/groups?selm...%25ccox%40mind
spring.com&output=gplain


The slight gamma turned out to be from color management, but what I am
talking about appears to be slightly different from what is discussed in
the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly
posterized. With color management turned off, the count starts:

0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ...


Where is 2? You can't be skipping numbers while others are being
repeated multiple times; that makes no sense whatsoever.

The sad fact of the matter is that not only is PS' "16-bit" RGB only
15-bit, but its "16-bit" greyscale has even less effective bits. Even
if you perform a bicubic upsampling, you can't get the missing values.

John:
Can you send me your 256*256 raw file? I'll take a look at it
with my tools, including some custom image processing
unix programs and compare to photoshop and ImagesPlus.

Roger

wrote:

In message ,
"Bart van der Wolf" wrote:


"Mike Engles" wrote in message
...
SNIP

There was a discussion about this kind of thing on the scanner

group,

comp.periphs.scanner. Post your observation there. You might get a
explanation.

You probably are referring to these:
1. Chris Cox's 'explanation' of the internal format of 15bits+1:
http://groups.google.nl/groups?selm=...25ccox%40minds
pring.com&output=gplain
2. The way Photoshop converts (16-bits to 8-bits)
http://groups.google.com/groups?selm...%25ccox%40mind
spring.com&output=gplain


The slight gamma turned out to be from color management, but what I am
talking about appears to be slightly different from what is discussed in
the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly
posterized. With color management turned off, the count starts:

0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ...


Where is 2? You can't be skipping numbers while others are being
repeated multiple times; that makes no sense whatsoever.

The sad fact of the matter is that not only is PS' "16-bit" RGB only
15-bit, but its "16-bit" greyscale has even less effective bits. Even
if you perform a bicubic upsampling, you can't get the missing values.

John:
Can you send me your 256*256 raw file? I'll take a look at it
with my tools, including some custom image processing
unix programs and compare to photoshop and ImagesPlus.

Roger