# Thread: Canon 60D bit depth vs 32-bit RAW

1. ## Re: Canon 60D bit depth vs 32-bit RAW

Siegell has it correct.

Your dslr uses a Bayer array of single color sensors red green blue green

Yes there are as many greens as red and blue combined

Photoshop then calculates the missing colors at each sensor position to create a red blue green color pixel.

This is called debayering. There are a variety of algorithms but they all basically look at the surrounding sensors to determine the missing data.

Beyond that, to create an image in Photoshop, a white balance is calculated and a tone curve, along with some sharpening, noise reduction, saturation, and other stuff like map into a color space.

To avoid round off error it is best to do this with more bits.

I think your real question is it better to stay with 32 bit for color in Photoshop or is it ok to use 16 bit.

My guess would be 16 is fine but I would do the really heavy stretching with 32 bit and finish 16 bit

You might even try using a 32 bit workflow and comparing with a 16 bit workflow.

2. ## The Following User Says Thank You to Purdyd For This Useful Post:

bobharmony (04-26-2016)

3. ## Re: Canon 60D bit depth vs 32-bit RAW

Originally Posted by seigell
Sparweb provides a very good explanation of the value of using a 32-bit RGB Format over a 16-bit RGB Format. (even though his examples use 24-bit and 48-bit Data as examples)

But...

The OP was actually asking about the difference between a 14-bit RAW Format (there is no 32-bit RAW for the Canon 60D), and a 32-bit Photoshop Format (actually an RGB Format whether TIFF or PSD or other).
One must remember that the RAW Format is "pre-Debayering" (Pixel Values are still for individual Pixel-Cells behind the Colored Filters of the Bayer Mask), and so those 14-bit are a measure of Intensity of a Single Color. If all that data were carried into an RGB Format, one would need 14x3=42 bits.
It is the Debayering Process which mathematically samples the values of the nearby Pixels in order to assign an RGB Value to each Output Pixel. And the Math which is used usually produces 48-bit RGB data which is then down-scaled to 32-bit or 16-bit.
I think you have clarified this for me, if I combine this with the information in the link Scott (Hondo) included earlier in the thread (sort of). I have to figure out DeepSkyStackers role in this as well. According the the old thread DSS takes the individual RAW subs and averages them by some mystical (to me) means and produces a 32 bit result which has it's own set of issues, due to a bug in DSS. The thread states that the result set has 14 bits of data padded with zeroes to fill out the 32 bit space. When I have a block of free time I will lay this out and try to figure out which black box in the process is doing what.

I have a grasp on what the 60D produces - a 14 bit representation of the photons hitting each cell on the sensor where each cell if filtered by red, green, or blue lens. De-bayering takes that raw data and and generates pixels with RGB values - if the same number of pixels are generated that would generate three times as much data. I'm not convinced yet this is additive to make 42-bit data, or if there is three times as much 14 bit data in the resulting data point set.

The more I think about this the less I think I "know". There is a lot of interesting reading out there. I suspect in my process it is DSS that does the de-bayering. It has tools to manage the RGB output from the stacking process so it must have done something to allow that type of manipulation. Maybe there is a way to let it produce a raw output, I am not familiar enough with it to answer.

If I thought my head was spinning before...

Bob

4. ## Re: Canon 60D bit depth vs 32-bit RAW

I misstated something above - when I open a sub in Photoshop it opens as 16 bit, not 32. I'm sure that will not be a surprise to PurdyD or Camelhat . It makes sense to me - 16 bits is the next natural data storage boundary above 14.

What I don't know is if the individual sensor values get multiplied by 4 to keep the relative intensity the same. 14 bit has a range from 0-16383; 16 bit has a range of 0-65535. My assumption is that a reading of 5000 in 14 bit is equivalent to a reading of 20000 in 16 bit. If the original value is kept, the image would be darker in 16 bit than it is in 14 bit.

I am restacking some shots I took of M31 last November - I will play with some of the save options in DSS and see which give a file that can be worked in Photoshop. If I get any decent results I will share them in the photo subforum. I will report back on results here.

Bob

5. ## Re: Canon 60D bit depth vs 32-bit RAW

Originally Posted by bobharmony
I guess my question becomes what is the point of storing the result in 32 bits if all the data can be encoded in 14 bits to begin with. I will continue reading the link Scott provided and the new links Paul gave, and see if I can find the answer there. As you said, 0.11 and 0.11000 are the same number, so why would I write it in the longer version?
The benefit is is compatibility: the software is ready for cameras with greater bit depth. For the last several years, for example, GIMP, one of the most popular free image editing programs was a problem for AP because it only accepted 8 bits. If manufacturers start pushing 32-bit formats, the software makers will respond, and then everyone will be ready when cameras start saving 18-, 20-, and 24-bit data.

Originally Posted by bobharmony
What I don't know is if the individual sensor values get multiplied by 4 to keep the relative intensity the same. 14 bit has a range from 0-16383; 16 bit has a range of 0-65535. My assumption is that a reading of 5000 in 14 bit is equivalent to a reading of 20000 in 16 bit. If the original value is kept, the image would be darker in 16 bit than it is in 14 bit.
The extra bits are tacked on at the least-significant end of the number. So the effect is indeed that the numerical values are multiplied by 4. To store a 14-bit number in a 32-bit format, the numerical values are multiplied by 262144. (!) That way, a half-scale value remains a half-scale value; a quarter-scale value remains a quarter-scale value, and the relative brightness does not change.

6. ## The Following User Says Thank You to KathyNS For This Useful Post:

bobharmony (04-28-2016)

7. ## Re: Canon 60D bit depth vs 32-bit RAW

Originally Posted by KeithBC
The extra bits are tacked on at the least-significant end of the number. So the effect is indeed that the numerical values are multiplied by 4. To store a 14-bit number in a 32-bit format, the numerical values are multiplied by 262144. (!) That way, a half-scale value remains a half-scale value; a quarter-scale value remains a quarter-scale value, and the relative brightness does not change.
Thanks for the validation, Keith. I don't know if it makes any difference to most of us how these things are done, but to a geek like me not knowing drives me nuts - and makes me start threads that put most people to sleep!

I went back to DSS and restacked my 30 minutes of M31 (60 subs of 30 seconds) and saved the file as a 16 bit tif, a 32bit rational tiff, and a 32bit integer tif. All open in PS and none of them look special as is. Now I will search to see what "rational" and "integer" formats represent.

There is always something else to learn here!

Bob

8. ## Re: Canon 60D bit depth vs 32-bit RAW

Originally Posted by bobharmony
I went back to DSS and restacked my 30 minutes of M31 (60 subs of 30 seconds) and saved the file as a 16 bit tif, a 32bit rational tiff, and a 32bit integer tif. All open in PS and none of them look special as is. Now I will search to see what "rational" and "integer" formats represent.
Rational: Floating Point Numbers - storing with the fractional digits carried through the Calibration and Stacking Functions

Integer: Integer Numbers Only - rounding the fractional digits carried through the Calibration and Stacking Functions before writing the output

DSS works at 32-bit Floating POint data internally for the Calibration and Stacking Functions, and then formats the Output into the File Format selected by the User.

9. ## The Following User Says Thank You to seigell For This Useful Post:

bobharmony (04-28-2016)

Page 2 of 2 First 12

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
Powered by vBulletin® Version 4.2.0
Powered by vBulletin®
All times are GMT. The time now is 09:28 AM.