RAW and Photoshop..... 12 bits

Ok, I am still mentally processing why I should shoot more RAW. In another thread a very detailed explination was given that with canon 12 bit raw, you get many more levels of color rendition because of RAW. It was something like 256 levels versus 16 in JPEG. And that sounds interesting when trying to perserve shadow detail best you can. But where I get lost is when I open that file in PS, it is going to automatically upsample that to 16 bits. There is no 12 bit format for editing. I know from my 16 bit work I get 64,000 levels... so where and how does that upsampling happen? When you change Gamuts there are all kinds of different ways to derive the right dirstribution of color bandwidth so that it doesn't loose it relativity to the rest of the colors. Yet when I am done in my RAW setup and click "open", I don't get any options for color handling or rendering intent. So when I click open, to fill in the blanks, PS is doing what to fill in that extra color depth that just became available?

Educate me some of you RAW gurus. I have sort of bought off on this - but there still is color change going on that seems your are not in control of. Also, just to be clear - when you do JPEG compression at levels like 10+, it isn't necessarily dumbing down any colors rather it is looking for color patterns repeated in the image, and then referencing that pattern multiple times rather then storing that pattern multiple times. The higher the level of compression, the more generic those color patterns become and yes then you loose detail. But from what I remember from readings in the original jpl documents, it is referential, not distructive. Just a side note.

RAW files contain 12 bits of data put into a 16-bit file format. When the RAW file is written, think of it as putting 12 people into a 16-person bus. There's room for more.

There's no color change when you store 12 bits in a 16-bit format. There definitely is a color change when you convert 12 bits of data into an 8-bit format like JPEG. You will lose color information, since the conversion process basically finds colors that are very similar and makes them the same so that they'll all fit in 8 bits.

JPEG at 10+ is doing very little *noticable* changes to the image, but it is changing the image by reducing the colors as above.

A conversion to JPEG is generally destructive, even if converting an 8-bit TIFF to an 8-bit JPG. This example will have very very little destruction, but it does happen. Paint Shop Pro is excellent to test this. Open an 8-bit TIFF or convert a 16-bit TIFF to an 8-bit one. In PSP use the Count Colors menu item. Then save that as JPG at maximum quality, and do Count Colors again. Chances are very good that you will not notice a difference, but the computer does.

Are you sure about this? I am not totally sure how color bit depth is written, but were talking essentially about word lenght here, and you can't just have null values as part of the word. Every bit signifies something - there is no "blank" as far as I know - it must have a bianary representation - 1 or 0. So maybe 101010101010 does equal 1010101010100000... but I am not sure of that (forgive the simplified example here).

Croasdail wrote in post #2164663
Are you sure about this? I am not totally sure how color bit depth is written, but were talking essentially about word lenght here, and you can't just have null values as part of the word. Every bit signifies something - there is no "blank" as far as I know - it must have a bianary representation - 1 or 0. So maybe 101010101010 does equal 1010101010100000... but I am not sure of that (forgive the simplified example here).

Actually it would be like this, 101010101010 is the same as 000010101010. By placing zeros at the beginning you have not changed the value. Just like 01 is the same as 001.

In2Photos wrote in post #2164716
Actually it would be like this, 101010101010 is the same as 000010101010. By placing zeros at the beginning you have not changed the value. Just like 01 is the same as 001.

Yup, that sums it up very nicely. Leading zeros in front of numbers, no matter how many you put in there, is not going to change the value of those one and zero combinations one iota.

Like Scott said, it's like "putting 12 people into a 16-person bus".

Croasdail wrote in post #2164663
Are you sure about this? I am not totally sure how color bit depth is written, but were talking essentially about word lenght here, and you can't just have null values as part of the word.

How do you represent 1 in a byte? 00000001. In a word? 0000000000000001.

Lotsa zeroes that mean nothing in the end.

Consider it as percentages of the total channel depth.

So 2048 is 50% of the 4096 possible values for 12 bit and 32 768 is 50% of the 65 536 possible values for 16 bit. Those extra four bits just give you the potential for further gradation which you're currently not using.

If you really wanted to you could compare the raw data (which is linear in nature) and use a linear curve for an export to a 16-bit TIFF.

e-k

In2Photos wrote in post #2164716
Actually it would be like this, 101010101010 is the same as 000010101010. By placing zeros at the beginning you have not changed the value. Just like 01 is the same as 001.

But if you do it that way your image would end up being darker. A simple shift operation by 4 bits would give you a better representation. So 1111 1111 1111 would become 1111 1111 1111 0000. That is they both represent a high value.

I might be wrong, but this makes more sense to me.

e-k

Scottes wrote in post #2164740
How do you represent 1 in a byte? 00000001. In a word? 0000000000000001.

Lotsa zeroes that mean nothing in the end.

But you're not representing 1. By the time you have developed the raw image that 1 is representing a relative intensity for a given pixel on a given channel.

Say instead of 1 the value was 1024. Now 1024/4096 is more intense than 1024/65536 I would think.

e-k

E-K wrote in post #2164846
But you're not representing 1.

No, I am representing 1.

Scottes wrote in post #2164864
No, I am representing 1.

Maybe we're talking about two different things here. If you are simply talking about the raw data itself and some internal temporary representation then yes a 1 is a 1 is a 1, whether it's stored in a byte, word, or double word.

I'm talking about the representation after a curve has been applied to the raw data.

What I'm saying is that if PhotoShop is representing the tuple (0xffff, 0xffff, 0xffff) as pure white then (0x0fff, 0x0fff, 0x0fff) is not pure white, even though it was in the original 12 bit format.

e-k

E-K wrote in post #2164999
Maybe we're talking about two different things here. If you are simply talking about the raw data itself and some internal temporary representation then yes a 1 is a 1 is a 1, whether it's stored in a byte, word, or double word.

I'm talking about the representation after a curve has been applied to the raw data.

What I'm saying is that if PhotoShop is representing the tuple (0xffff, 0xffff, 0xffff) as pure white then (0x0fff, 0x0fff, 0x0fff) is not pure white, even though it was in the original 12 bit format.

e-k

What you are talking about is the normalization of the image, when you take that 12-bit raw data and apply a tone curve and convert it to 16-bit data. So, yes, although 0x0FFF in 16-bit is not the same as 0xFFFF, 0x0FFF in 12-bit is exactly 0xFFFF in 16-bit. As are 0x0000 12-bit and 0x0000 16-bit. Of course, the same can't be said of the in-between values since the 12-bit data has been normalized to 16-bit data.

However, if you convert the 12-bit raw image to linear data, where no curve nor normalization has been applied to it, you'll see that 0x0FFF of the 12-bit data is exactly 0x0FFF in the 16-bit data, as are all the other values inbetween, because, after all, you only have 12 bits of data to start with and putting it into a 16-bit "bucket".

PacAce wrote in post #2165104
What you are talking about is the normalization of the image, when you take that 12-bit raw data and apply a tone curve and convert it to 16-bit data. So, yes, although 0x0FFF in 16-bit is not the same as 0xFFFF, 0x0FFF in 12-bit is exactly 0xFFFF in 16-bit. As are 0x0000 12-bit and 0x0000 16-bit. Of course, the same can't be said of the in-between values since the 12-bit data has been normalized to 16-bit data.

Exactly. I was responding to this:

Croasdail wrote in post #2163557
Yet when I am done in my RAW setup and click "open", I don't get any options for color handling or rendering intent. So when I click open, to fill in the blanks, PS is doing what to fill in that extra color depth that just became available?

I don't use PhotoShop, but if it is similar in concept to what I use then the implication is that a tone curve has been applied already when you click open. The point being that when you click open the data is normalised so you are not just taking the 12-bit value and dumping it into a 16-bit bucket.

Right, if you're just copying the value then it remains the same.

e-k

Ok guys... excuse my ignorance here. But what were talking about here is a digital representation here of an analog value. For example, if were talking RGB, you have Red, Green and Blue values to which you can apply a certain value of a whole color to - from 0 to 100 percent of that colors potential. If the camera measure a value that is 1/3 of the maximum number of 4,096, that numerical representation would be different then the numerical representation of 1/3rd of 65,536. It would not be 1/3rd x, it would be a whole number, so you can't just add zeros to the end of the number. At least that is my simplified understanding. I know that RAW data has not been normalized, so it is a digital representation of an analog reading, with the bit depth being a variable scale. In some ways my example above isn't even that accurate as raw doesn't even have the whole value for the colors defined yet - as I understand it. Were just placing a value along sliding scale representing analog values - which have yet to be assigned to a specific color value in RGB. Clue me in here.

Croasdail wrote in post #2165466
Ok guys... excuse my ignorance here. But what were talking about here is a digital representation here of an analog value. For example, if were talking RGB, you have Red, Green and Blue values to which you can apply a certain value of a whole color to - from 0 to 100 percent of that colors potential. If the camera measure a value that is 1/3 of the maximum number of 4,096, that numerical representation would be different then the numerical representation of 1/3rd of 65,536. It would not be 1/3rd x, it would be a whole number, so you can't just add zeros to the end of the number. At least that is my simplified understanding.

Ideally you are right you wouldn't just be adding zeros. It's just the computer programmer in me when I say shifting 4 bits (multiplying by 16 effectively) is good enough (65536/4096 = 16). There is only a 0.02% difference between the ideal value of 65535 and the approximate value of 65520. But I honestly don't know what the Adobe programmer's did.

The sensor accumulates charge which is then discharged at the end of the exposure and amplified. The voltage passes through an analog to digital converter. Anything above a certain voltage is clipped. I'm not sure what you mean by the bit depth being a variable scale. The bit depth is fixed at 12 bits as that is what the ADC provides. They are all whole values as well. What the raw data doesn't have is any interpretation of the data. It's basically the values as read from the ADC.

The raw converter provides the interpretation. It takes the linear capture and makes it logarithmic, it does the bayer interpolation, and it adjusts the relative intensities of the colours. You are generally able to adjust some of these things in you raw converter.

I'm not sure of your background but if you happen to know C (the programming language not the letter ) then you can take a look at the source for dcRAW to get an idea of how it all works.

Bottom line is that raw will give you more lattitude as 12 is greater than 8. This means you can pull more out of the shadows with less posterisation than if doing the same with a JPEG image. Going from 12 to 16 doesn't give you much of anything unless you're creating information as part of you editing or you need the headroom for your edits.

It's late though and my brain is fried so I may think differently in the morning

e-k