• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

Photoshop and 16-bit TIFF files

Doug Kerr

Well-known member
Warning: Today's theory lecture might possibly have some practical implications on our photographic work.

**********

An 8-bit number has a range of (in decimal) 0-255. Its span, then, is 255 units (2^8-1). A curious implication of this is that, from a number theory standpoint, an 8-bit number represents values to a "precision" (defined with respect to the maximum value) of about 7.989 bits (not 8 bits). [log2(255)=7.989...]

There are innumerable standards, specifications, algorithms, and protocols that have anomalies in then as a result of some quantity being divided or multiplied by 128 when it should have been divided or multiplied by 127, or vice-versa.

Photoshop, in its "16-bit" color space mode, averts this problem by having a range of 0-32768, a span of 32768 units (2^15). It thus represents color coordinates to a precision of exactly 15 bits (not 16 or even close).

One interesting side effect of this is that if we look at an image held in 8-bit RGB form, but ask the Info box to report the color coordinate values on both 8-bit and 16-bit bases, the 16-bit report is always almost exactly 128.5 times the 8-bit report. [32768/255=128.502...]

What then happens if we take an image held in some RGB color space in "16-bit" mode and save it as a 16-bit RGB TIFF file? (In such files, the range of the color coordinates is 0-65535 - 0 to 2^16-1.)

Well, Photoshop will not allow us to save a file in its "16-bit" RGB mode as a 16-bit RGB TIFF file - we can only save it as an 8-bit file (with precision 7.989 bits). That takes care of that!

Suppose we want to take a Photoshop "16-bit" image and write it to a 16-bit RGB TIFF file. Well, we can have Photoshop convert the image to its 32-bit mode (that does not of course increase its precision, which is still 15 bits, but it is now held in 32 bits), and then write that as a 16-bit RGB TIFF file (which Photoshop is willing to do). Of course, the actual precision of the coordinates for the image is still only 15 bits, but that is perhaps better than not quite 8 bits.

Best regards,

Doug
 
Hi Doug,

Maybe your breakfast hasn't kicked in yet, or I am misunderstanding something.

An 8 bit range goes from 0 to 255, and thus represents 256 discrete values. Zero is also a value to be reckoned with.

Photoshop's "15 bit" internal values are actually 15 bits (0..32767) plus 1 (so 32768). That scheme is apparently chosen to allow faster image data math while avoiding calculation over- or underflow, and support other undisclosed (blending) tricks.

Saving as a 16-bit/channel file does result in 16-bit values being saved (but with slightly reduced precision, and AFAIK a flag in the TIFF header that it's not containing regular unsigned 16-bit values) which is understood by other programs importing that data through the appropriate library calls. TIFFs can also hold other types of values. I assume your mentioning 8-bit values in this context is a typo?

Saving a 32-bit/channel image does allow to save 32-bit per channel files.

Cheers,
Bart
 

Doug Kerr

Well-known member
Hi, Bart,

Hi Doug,

Maybe your breakfast hasn't kicked in yet, ...
A recent blood glucose measurement suggests it has, but who knows.
. . . or I am misunderstanding something.

An 8 bit range goes from 0 to 255, and thus represents 256 discrete values. Zero is also a value to be reckoned with.

True, there are 256 values. But this is not about counting numbers of possible values, but about values and their manipulation, and the sizes of increments. The span between the smallest value (0) and the largest (255) is 255 units (not 256). And that has to be taken into account in the math. For example, if we scale the range to 0-1.0 (as we often do in making color space calculations), each increment is 1/255 (0.003922...), not 1/256 (0.00390625)*.

*You can even see this in Bruce Lindbloom's color calculator. If we enter 3 (on the 0-255 scale) it becomes 0.011765 (on the 0-1 scale) (3/255).​

I know its confusing - that's why there are so many errors resulting from this!

The classical metaphor is making a fence with 100 posts at 10 foot increments. It is 990 feet long (we make no allowance for the width of the posts). Or, make a 1000 foot long fence with 100 posts evenly spaced - they will be 1.001001... feet apart. (In fact, the corresponding misadventure in programming is often spoken of as the "fencepost problem".)

Photoshop's "15 bit" internal values are actually 15 bits (0..32767) plus 1 (so 32768).
Well, I would say that Photoshop's "16-bit" representation is doubtless in 16 bits but with the range limited to 0-2^15

That scheme is apparently chosen to allow faster image data math while avoiding calculation over- or underflow, and support other undisclosed (blending) tricks.
I suspect so.

Saving as a 16-bit/channel file ...
How would you do that? I am unable to tell Photoshop, when the working space is 16-bit RGB, to write a 16-bit TIFF file. Am I missing some hidden button?

. . .does result in 16-bit values being saved (but with slightly reduced precision, and AFAIK a flag in the TIFF header that it's not containing regular unsigned 16-bit values) which is understood by other programs importing that data through the appropriate library calls.
A fascinating notion, which would seem to be valuable. I'm unable to find any provision for such in the TIFF spec, but of course there is much voodoo in there!

TIFFs can also hold other types of values.

Sure. For example, they can hold YCbCr data, or L*a*b data.

I assume your mentioning 8-bit values in this context is a typo?
Where?

Best regards,

Doug
 

Doug Kerr

Well-known member
Hi, Bart,

Could you please send me a 16-bit TIFF file written by Photoshop from an image in a "16-bit" RGB color space. I'd like to see what various apps here do with it. It could be just a tiny part of an image.

Maybe you could e-mail it to:

doug.kerr@att.net

Thanks so much.

Best regards,

Doug
 

Doug Kerr

Well-known member
Now, for whatever it's worth, my main editor (Picture Publisher 10) has a 16-bit RGB working space mode, with a value range of 0-65535 (0 through 2^16-1).

It will gladly make 16-bit RGB TIFF files. (In fact, when starting with that kind of image, that's the only kind of TIFF file it will make.)

Best regards,

Doug
 

Doug Kerr

Well-known member
Well, evidently Bart was right, my breakfast hadn't kicked in (although not with regard to the issue he mentioned, but a later one).

I am all wet about Photoshop not making 16-bit TIFF files from images held in "16-bit" RGB form. Of course it does. That is in fact the only kind of TIFF file it will make from such an image.

My suspicion is that it takes its 16 bit values (which are never above 2^15), doubles them, and (if they are above midscale) subtracts one from the result, then writes that to the file.

(The subtracting one is of course so that the highest possible Photoshop "16-bit" value, when doubled, doesn't get too big for a 16-bit number.)

Bart, thanks for your help on this.

Sorry for the false alarm.

Best regards,

Doug
 
Top