Accuracy of Photoshop’s 16 bit greyscale mode

I think I found some inaccuracies in the 16 bit greyscale mode of Adobe Photoshop CS (8.0.1) – and I am not talking about the internal use of ‘only’ 2^15 values which is the subject of many threads.
To reproduce my findings, do the following:
===========================================

In Photoshop press F8 to open the Information panel.
In the Info panel choose "pixel" as the unit for coordinates Expand the Info panel to see the palette options and tick "show 16 bit values"
Create a new document with the following settings:
Width: 32768 Pixels
Height: 500 Pixels
Color mode: Greyscale, 16 bit
In the Tools palette, select default colors for foreground & background (yields full black, resp. full white)
In the Tools palette, select the gradient tool and use it (by drawing a horizontal line from pixel coordinate (X=0) to (X=32768) – or as close as you manage to) to create a gradient from left to right. In the Tools palette, select the color sampler tool and inspect the gradient (choose a suitable magnification to be able to move the tool via your mouse with a 1 pixel resolution).

Strange things to see:
1) For most pixels, the values for the color components R, G, B are not identical – but should be on a greyscale picture.
2) On the right and left rim of the picture we have the expected values of (0,0,0) resp. (32768,32768,32768), but the gradient is NOT smooth. Instead, some horizontally neighbouring pixels do have the same RGB-values, then going further yet one more pixel the RGB values ‘jump’ to another value – and we are not taking about a single skipped value, but in the order of six.

Hold the color picker tool over some random pixel in the image, remember the RGB value displayed and double-click on the pixel to make its color the new foreground color.
Move the color picker tool over the rectangle for the foreground color in the tools palette to verify that the new foreground color has the same RGB values as previously displayed.
Now create a new image in 16 bit greyscale mode and use the fill-tool to fill it with the current foreground color.

Strange things to see:
The color in the newly created image is different from the current foreground color.

Please help and tell me what I am doing wrong, if Photoshop really behaves like this or if there is some workaround.

If I’m re-creating your procedure correctly, this is both an 8 and 16 bit behavior, due to two gradient tool settings – dithering and smoothness. Dithering is a checkbox in the options bar, and smoothness is controlled in the gradient editor. Turn both of these options off and you should see a clean, linear gradient with equal RGB values.

Hold the color picker tool over some random pixel in the image, remember the RGB value displayed and double-click on the pixel to make its color the new foreground color.
Move the color picker tool over the rectangle for the foreground color in the tools palette to verify that the new foreground color has the same RGB values as previously displayed.
Now create a new image in 16 bit greyscale mode and use the fill-tool to fill it with the current foreground color.

Strange things to see:
The color in the newly created image is different from the current foreground color.

The match is spot on for my system. Make sure you have the transparency of the fill tool set to less than 100%.

Please help and tell me what I am doing wrong, if Photoshop really behaves like this or if there is some workaround.

Photoshop is a Byzantine edifice, and so there are a number of dark corners with interesting puzzles like this. Color mode layers in CMYK, for example, have a brown tinge, Lightness and Brightness are not the same thing, and a Lightness of 50% is not the same as an RGB value of 128, or a gray value of 50%. What, exactly, does the combine RGB colors in linear space do, and which tools are affected? Then there is color management, and the difference between the various rendering intents, with and without black and white point compensation. And CMYK ink limits and GCR/UCR settings. The only way to understand eacy of these things is to experiment, and very few do this with the amount of detail you have.

I made sure to have turned off color management, dithering, smoothness and the like. Still, the non-smooth gradient persists.
You are right on 8 bit greyscale gradients: on a new document with widht=256 pixels, there too some values are being skipped, yielding x-Coordinate color value seen color value expected
0 0 0
1 13 1
2 13 2
3 22 3
4 22 4
5 28 5
…
128 188 128
…
252 254 252
253 255 253
254 255 254
255 255 255
What is going on here?

martin wrote:
[re lumps in grayscale gradients]

I made sure to have turned off color management, dithering, smoothness and the like. Still, the non-smooth gradient persists.
You are right on 8 bit greyscale gradients: on a new document with widht=256 pixels, there too some values are being skipped, yielding x-Coordinate color value seen color value expected
0 0 0
1 13 1
2 13 2
3 22 3
4 22 4
5 28 5
…
128 188 128
…
252 254 252
253 255 253
254 255 254
255 255 255
What is going on here?

I’m seeing the same behavior, and I now have a different explanation in addition to the dither and smoothness settings, though those also played a part. The actual numeric values in your file are almost certainly linear. It’s the RGB values you are displaying that skip, and this is because, even with "Color Management Off" the color values are converted from your grayscale to your working RGB space before being displayed. You may verify this by saving the image as a raw file, and dumping the contents with a hex viewer.

"Mike Russell" wrote in message
news:<N2wQd.4042$>…

martin wrote:
[re lumps in grayscale gradients]

I made sure to have turned off color management, dithering, smoothness
and the like. Still, the non-smooth gradient persists.
You are right on 8 bit greyscale gradients: on a new document with widht=256 pixels, there too some values are being skipped, yielding x-Coordinate color value seen color value expected
0 0 0
1 13 1
2 13 2
3 22 3
4 22 4
5 28 5
…
128 188 128
…
252 254 252
253 255 253
254 255 254
255 255 255
What is going on here?

I’m seeing the same behavior, and I now have a different explanation in
addition to the dither and smoothness settings, though those also played a
part. The actual numeric values in your file are almost certainly linear.
It’s the RGB values you are displaying that skip, and this is because, even
with "Color Management Off" the color values are converted from your grayscale to your working RGB space before being displayed. You may verify
this by saving the image as a raw file, and dumping the contents with a hex
viewer.

I checked the values in the file by inspecting it with a hex viewer and found that the values are NOT linear.
But THERE IS an additional setting in Photoshop to yield true linear gradients in 8 bit pictures:
* from the tool box palette select the gradient tool
* on the tool options palette double click on the 2nd drop down field * change the value for "Smoothing" from the default 100% to 0%

On 8 bit pictures this gives the gradient as desired.

On 16 bit pictures, I found that in an area filled with the gradient tool all colors are multiples of 8, hence neighbouring colors differ by 0, 8, 16 ….
So it comes down to the fact that the gradient in Photoshops so called 16 bit mode (color spectrum 0..32767 i.e. 15 bit) is effectively only 14 bit.

Was your picture 32K wide? If the image was smaller than that, you would naturally get skips.

Was your picture 32K wide? If the image was smaller than that, you would

Image width was 32768 pixels, so I got rows of 8 pixels of identical color