Photography - "16-bit" mode.

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
---^----^---------------------------------------------------------------