16-bit or 15-bit+1?

[BonaireGuy]

I've been searching high and low to get an understanding why Photoshop CS5 (and CS4) only show a range of 0-32,768 for the color picker on a 16-bit per channel image, when in fact for true 16-bit should be showing 0-65,535. And I've not been particularly successful in my search - all I can find is that yes, this is true, but not why, nor why it hasn't been fixed (I understand it's been this way since PS started supporting 16-bits per channel.

The other thing I can't figure out is if this is something that's only in the color picker, or does Photoshop take 16-bpc (Bits Per Channel) images and sample them down to this 15-bit+1 range (effectively reducing the channel range by half) and the color picker just reads what the data has been munged down to?

And yes, before someone asks, there are cameras and backs that produce true 16-bpc images (I have one - a Hasselblad).

Any pointers to documentation or more detailed discussion of this issue would be greatly appreciated, as calling 0-32768 "16 bits" is rather misleading. I'm feeling cheated somehow.

Thanks,

Jake

[Chris Cox · Accepted solution]

Photoshop's internel representation is 0..32768. This gives a midpoint to the range (very useful for blending), and allows for faster math because we can use bit shifts instead of divides.

That is not a bug, just a design decision to make 16 bit/channel run faster.

A search of the forums will reveal more information about that decision.

[BonaireGuy]

Thanks for the official insight.

So, if I bring in a 16-bpc file, and then save it, will it still retain all the original data, or will it have had the channel information compressed from 0-65535 to 0-32768 (and then presumable expanded back to 0-65535 so that other programs read it correctly)? Or is the 0-32768 some sort of abstract intermediate representation that doesn't affect the original data (perhaps until later)?

Just trying to understand where my bits are going, if anywhere.

Thanks,

Jake

PS In this day of GPUs with parallel processing, are divides really still that expensive in terms of processing time?

[Chris Cox]

Once inside Photoshop, the data is converted to the 0..32768 range.  Yes, resaving will alter you data a little, assuming you had full 16 bit data to start with (and except for cooled scientific cameras, you won't have full 16 bits).

PS In this day of GPUs with parallel processing, are divides really still that expensive in terms of processing time?

Yes. GPUs are good at a few things, but still kind of lousy at general processing.

Current processors take 30 to 90 clocks to divide (single throughput), and a single clock (1 to 4 throughput) to shift.

So that's anywhere from 30 to 360 times faster to use the shift, just from a computation standpoint.  Add in the fact that divides tend to stall the CPU pipeline, and it gets worse. Dividing by a constant can be replaced with a reciprocal multiplication, but that needs higher precision than the base type.  So if the compiler does that optimization, then you're talking at least 20 times as slow as the shift (but still faster than the full divide).

Exact performance differences will vary with the processor model, but that should explain the basic picture.

[BonaireGuy]

Chris,

Yeah - I'm familiar with the pain of divides from when I used to write display list processor software back in the late 80s, and yes, using shifts whereever possible was our solution back then too.

Chris & Jeff,

Can you elaborate on the "true" 16-bit comment you both made? I was under the impression that my Hasselblad H3D-II captured a full 16-bpc. Is that somehow incorrect? Your comment suggests it is. (I'm just trying to learn, and you guys certainly know this stuff better than I do.)

Jake

[Chris Cox]

I was under the impression that my Hasselblad H3D-II captured a full 16-bpc. Is that somehow incorrect?

The values may have 16 bits.  The useful values read out are more likely 12 to 14 bits (if that much).

I've only seen a few sensors that could read out useful 16 bit data without cooling, and they were SLOW (and most are line scanners).

(disclosure: one of those sensors is my patent)

Just the amplifier and readout noise on most sensors will make the 2 lowest bits useless. (and I'm talking pro gear, I won't even start on point&shoot or cell phone cameras)

[Jeff Schewe]

Chris Cox wrote:

The values may have 16 bits.  The useful values read out are more likely 12 to 14 bits (if that much).

Pretty sure the Blad back (a Dalsa chip I think) is a full 14 bits so it should be fully contained inside of Photoshop's "16 bit" which is 15+1 precision.

[BonaireGuy]

Jeff and Chris and Noel,

Thank you for extremely detailed and informative responses to my questions. Rationally and technically, I understand the issues quite well and it makes sense.

Emotionally, I feel a little loss that I can't quite verbalize 🙂

Noel - great suggestion. I'll give that a try when I next get home to my Hassie.

Jake

[BonaireGuy]

Jeff,

Looks like the H3DII-39 I have uses the Kodak KAF-39000 39MP sensor:

http://www.kodak.com/global/plugins/acrobat/en/business/ISS/datasheet/fullframe/KAF-39000LongSpec.pd...

http://www.kodak.com/global/plugins/acrobat/en/business/ISS/supportdocs/31Mp_and_39Mp_Full-Frame_CCD...

I can't tell what the actually per-channel color range is from the above, though. Any thoughts?

Jake

[Chris Cox]

Without complete system specs, it appears to be in the 12-13 bit range.

The actual useful range will depend on the output amplifier and ADC details, plus how well they remove dark current noise.

It's a CCD, and the charge transfer can add patterned noise which also needs to be removed in software processing along with manufacturing patterns (small variances in sensitivity/lenses between pixels).

[gener7]

Ok,32768 is 1 + 15 zeros or simply a 16 place (bit?) number,so why call it 15 bit-anything if you must reserve 16 places?

What am I not getting?

[BonaireGuy]

Because a full 16-bit number would allow for a numeric range of 0-65535. A range of 0-32768 excludes access to the other 32767 values possible in a true 16-bit number (i.e. values 32769-65535). Does that help explain what's missing? 🙂

Jake

[gener7]

BonaireGuy wrote:

Because a full 16-bit number would allow for a numeric range of 0-65535. A range of 0-32768 excludes access to the other 32767 values possible in a true 16-bit number (i.e. values 32769-65535). Does that help explain what's missing? 🙂

Jake

Yes indeed. Thanks.

Since Jeff Schewe explained the difference between a full 16 bit and 15+1 is negligible and Chris Cox explained the math is more efficient at that level,then I'm OK with the 16 bpc label for both values. It does explain why my color picker ranges to 32768 instead of 65535.

Now I hope I never have to explain this

Gene

[Noel Carboni]

But Chris!  More bits is better!!!  Just like more megapixels is better. 

Actually, the fact that a gamma correction is applied to the raw data means the 15 bit representation will more than carry all the data in all the parts of the image that really matter, even if the sensor were providing 16 full bits of measurement data.

And let's not forget that while a Bayer-patterned sensor may provide 16 bits of data per photosite, an RGB image in 16 bits/channel mode is actually providing 3 x 16 (15+1) bits of data to represent a pixel (one level each for Red, Green, and Blue).  That would be a net increase from 16 to 45 bits.

A "seat of the pants" test to see if the data format you're using is deep enough is this:  At the lowest ISO your camera will shoot, take a photo of something very smooth.  Convert that image into a 16 (15+1) bit image in Photoshop, making sure to disable all noise reduction during the conversion.

Can you see any noise/grain in the image?  If you can see noise visually, there's probably less than 8 bits of precision in the data!

Because of the gamma correction applied to the linear data, you'll generally find more noise in the dimmer parts of the image (this is why Expose To The Right can produce good results).  Even if you have to enhance (brighten) the image to see the noise, if you can see noise under any amount of enhancement the data format you're using is generally deep enough to carry all the real information.

-Noel

[Noel Carboni]

Re: GPUs...  Photoshop is a giant, old application.  It's unlikely it's going to be completely rewritten quickly to be able to harness the real power of GPUs, though it's getting better with each new version.

Hey Chris, given that memory isn't as precious as it once was, and also that current system architectures do well with 32 bit numbers, for some of my recent software I created a concept where 16 bits of image data get nestled in the middle of a 32 bit number.  This retains integer speed while allowing for up to 8 bits of overflow, and keeping 8 bits of additional precision so multiple operations can be done without significant loss.  The concept worked rather well in actual implementation.

The real future of GPU-based computing is, however, quite clearly in floating point operations.  Remember when a gigaflop was a big deal?  Nowadays GPUs sport teraflop power.

-Noel

[Chris Cox]

Trust me, I've investigated the options.

And we can use GPU for calculation, if it was fast enough for our needs, and always accurate, supported on more cards, etc.

GPU calculation is not quite yet ready for our needs.  But we're working with the vendors closely on it.

[klsteven-qW1idA]

Chris,

I know this might better fit into the ACR forum, but since you are talking about GPUs.....

I recently tried Capture One 6, which supports OpenCL and noticed that it reacts in realtime to every slider movement.

Much faster than without OpenCL and also faster than ACR/Lightroom. What do you think about OpenCL or Cuda for ACR/Lightroom?

[Noel Carboni]

OpenCL (Open Computing Language) is still very, very new.  In a nutshell it's a system for allowing software authors to run their programs on GPUs.

http://en.wikipedia.org/wiki/OpenCL

Because of the newness, and the stil-evolving standards, basing a commercial product on being able to run software on a GPU via OpenCL is still a risky business decision.  One risk is it won't work the same on two different systems; another is that the implementation could still be buggy and using it could destabilize the computer.  Of course the benefit (as being seen in software that uses it) is HUGE potential speed increases of 50x or more over CPU operation.

-Noel

[Chris Cox]

Cuda is still limited to a few cards.

OpenCL is still very, very unfinished and works on only some cards.

We're working with both vendors to advance their capabilities.

[Jeff Schewe]

BonaireGuy wrote:

And yes, before someone asks, there are cameras and backs that produce true 16-bpc images (I have one - a Hasselblad).

Actually, while many of the medium format backs and some scanners claim a full 16 bit, in fact that depends entirely what your definition is of "a full 16 bit" file. In point of fact, the difference between a full 16 bit (and I seriously doubt the "full 16 bit claim) and 15+1 is negligible. You would never see the difference (and Photoshop would prolly be a a different animal in it's processing routines).

Bottom line? Don't worry about it.

You would be far better off learning how to optimize your capture exposure than worrying about less than 16 bit precision...