Inside DNG Files

paulcurtis

Veteran
I've said endlessly that i'd write up some of my research and finally i've managed to get the first post together which is an overview of how the DNGs work internally along with some exposure tests and the nature of Linear RAW. This is my reverse engineering and thoughts. YMMV

I've a bunch of other posts half written but i can only squeeze them in between the stuff that pays. So i will get there. There's one about colourspaces that i think is very important to us 700 users and Resolve.

I hope this is of use to people here:

http://blog.inventome.com/Blog/2014/7/insidecdng/Inside-cDNG-Files

Feel free to comment, i shall be donning a flame retardant suit

cheers
Paul
 
I'll be interested to follow this topic. Admittedly, much of this is over my head but I like reading it in hopes that something will soak in and I'll learn something!

Interesting observation about the white balance. I was actually just talking to someone today about how the WB is "baked in" to the FS700 RAW, but it appears that this isn't the case.
 
I'll be interested to follow this topic. Admittedly, much of this is over my head but I like reading it in hopes that something will soak in and I'll learn something!

On the other hand maybe i could explain clearer, so if there's anything that doesn't make sense it might be more to do with me - i'm not a writer afterall!

thanks
Paul
 
We've talked a bit about this in another thread. But the Digital Bolex 12 bit DNG file is recognized and reads out as 16 bit linear code values in Resolve and in Scratch Play. It has far more deep shadow resolution showing as discrete gray scale values in the 2nd and 3rd stops above black than a straight 12 bit linear scale can reproduce.These values are not created out of nothing in the debayer process, they are recorded from the sensor and preserved in the data.
In Scratch Play the file description showed it as 12 bit and it automatically set the white clip point at a code value of 3850. This clipped virtually all of the image to white. I had to manually set the white point data to 65530 and black point to 20 to fully recover image value range.
The meta data tag readout in Scratch shows the file as being produced by a Drastic Technologies software codec with GRBG compression. A 12 bit linear data file cannot resolve 12 stops of DR with adequate gray scale resolution in the deep shadow values. At best it can do about 9 stops.
 
Last edited:
I know Mitch Gross for one has stated that WB is baked into the RAW signal.. so I just trusted it was true.

You're saying it's not the case? If so, that is great news.
 
I know Mitch Gross for one has stated that WB is baked into the RAW signal.. so I just trusted it was true.

You're saying it's not the case? If so, that is great news.

WB is not part of the recorded image data, it is attached as a default meta data tag that a raw processor uses to interpret the image. It can be changed at will. Not baked in like it is in an encoded video image.
 
WB is not part of the recorded image data, it is attached as a default meta data tag that a raw processor uses to interpret the image. It can be changed at will. Not baked in like it is in an encoded video image.

Yes, I know that's generally true for most RAW types. However, this is not what has been reported to be the case with FS700 RAW.
 
We've talked a bit about this in another thread. But the Digital Bolex 12 bit DNG file is recognized and reads out as 16 bit linear code values in Resolve and in Scratch Play. It has far more deep shadow resolution showing as discrete gray scale values in the 2nd and 3rd stops above black than a straight 12 bit linear scale can reproduce.These values are not created out of nothing in the debayer process, they are recorded from the sensor and preserved in the data.
In Scratch Play the file description showed it as 12 bit and it automatically set the white clip point at a code value of 3850. This clipped virtually all of the image to white. I had to manually set the white point data to 65530 and black point to 20 to fully recover image value range.
The meta data tag readout in Scratch shows the file as being produced by a Drastic Technologies software codec with GRBG compression. A 12 bit linear data file cannot resolve 12 stops of DR with adequate gray scale resolution in the deep shadow values. At best it can do about 9 stops.

I'd spoken with one of the engineers of the DBX and he said it was 12 bit linear. To me, that sounds like end of story. But, things can change so:

Anything you are seeing is going to be upstream applications doing different things. It's pretty simple to see what's actually inside the DNG, try it for yourself, download a trial of raw digger or download the DNG sdk (there's a command line tool) and have a look yourself.

For example the basic adobe sdk produces a 16 bit result, but that's because internally it is either scaling a 12 bit to 16 or using the DNGs built in LUT if there is one. Again check the actual data to see what's happening. Do not trust any other application. The scratch thing sounds like a bug with their interpretation.

You are right that a 12 bit file cannot really produce >12 stops without the top and bottom being slightly curved (which is it in the 700) but i have plotted the values empirically. And i have done this multiple ways and multiple times. I've given the resulting values and ask that you try yourself.

One thing to remember though is that i am talking about 12 bit RAW data. So whilst the bottom 4 stops is held in 16 values once you have white balanced those RGB values (with the green being more sensitive) then the resulting actual luma values in the debayered image will hold more detail than 16 steps because the WB math will mix that all up. That is what you are seeing. You are not looking at the data from the camera but post white balanced data. This is the essence of RAW processing, which is why this stuff is debayered into higher bit depths. All noise at this level is making the ability to discern shadow detail very difficult too.

I've all along been talking about what the camera is outputting not what various applications are doing with this data, that's why the camera is called 12 bit linear.

(just adding: it's my understanding that you cannot rely on Resolves tools for display because they are adding a subtle dither/interpolation to the data. You just have to compare a SpeedGrade histogram with a Resolve to see that it hides any true banding in a file. From a visual perspective this may be what you want but it should really be up to the user to decide - however from the perspective of testing it makes it useless)

hope this clears this up?

cheers
Paul
 
Last edited:
Same goes for BMD DNGs.

The BMD DNGs are unique in that each frame contains a 1D LUT. So the raw data for BMD is actually not linear but it is still 12 bit. I'm not sure what the LUT is, it doesn't appear to be a simple log but whatever it is it's making the best of those 12 bits for the camera. (in other words it's adding more shadow detail at the expensive of the highlights)

BMD are, to my knowledge, the only ones doing this and they're doing it right. It's a much more sensible approach to maximising those 12 bits.

However see the comment to Razz about being careful about RAW data vs the image that comes out of a particular debayer process.

cheers
Paul
 
I know Mitch Gross for one has stated that WB is baked into the RAW signal.. so I just trusted it was true.

You're saying it's not the case? If so, that is great news.

It's not the case now for sure, but in defence of Mitch i think it might have been the case at one point, or at least written down officially as that.

cheers
Paul
 
I'd spoken with one of the engineers of the DBX and he said it was 12 bit linear. To me, that sounds like end of story. But, things can change so:

Anything you are seeing is going to be upstream applications doing different things. It's pretty simple to see what's actually inside the DNG, try it for yourself, download a trial of raw digger or download the DNG sdk (there's a command line tool) and have a look yourself.

For example the basic adobe sdk produces a 16 bit result, but that's because internally it is either scaling a 12 bit to 16 or using the DNGs built in LUT if there is one. Again check the actual data to see what's happening. Do not trust any other application. The scratch thing sounds like a bug with their interpretation.

You are right that a 12 bit file cannot really produce >12 stops without the top and bottom being slightly curved (which is it in the 700) but i have plotted the values empirically. And i have done this multiple ways and multiple times. I've given the resulting values and ask that you try yourself.

One thing to remember though is that i am talking about 12 bit RAW data. So whilst the bottom 4 stops is held in 16 values once you have white balanced those RGB values (with the green being more sensitive) then the resulting actual luma values in the debayered image will hold more detail than 16 steps because the WB math will mix that all up. That is what you are seeing. You are not looking at the data from the camera but post white balanced data. This is the essence of RAW processing, which is why this stuff is debayered into higher bit depths. All noise at this level is making the ability to discern shadow detail very difficult too.

I've all along been talking about what the camera is outputting not what various applications are doing with this data, that's why the camera is called 12 bit linear.

(just adding: it's my understanding that you cannot rely on Resolves tools for display because they are adding a subtle dither/interpolation to the data. You just have to compare a SpeedGrade histogram with a Resolve to see that it hides any true banding in a file. From a visual perspective this may be what you want but it should really be up to the user to decide - however from the perspective of testing it makes it useless)

hope this clears this up?

cheers
Paul

It is not a straight 12 bit linear data = 12 bit linear light values with the D16. The D16's first stage AD is 16 bit, and the full range of 16 bit values is preserved in the 12 bit file. The actual resolution of shadow values shows as 16 bit linear light however the DVR codec is accomplishing that. Scratch file data shows the original as 16 bit linear float in a 12 bit compressed file. Regardless of what the image processor does, it is not mathematically possible to produce fine step resolution of gray scale values that aren't captured in the original. When Resolve and Scratch show the image data range as 16 bit, they are not making it up. The D16 produces more than 60 discrete grayscale values in a linear light range where 12 bit data can only resolve 6. It is not a log gamma encoded 12 bit file like the BMD cameras, but it is 16 bit linear light data in a lossless compressed 12 bit file.
 
Last edited:
Truly Paul! You may not have made me a better PB&J sammich, but you DID show me what kind of peanut butter was used. In this case it seems to be Super Chunky.

:thumbsup:
 
It is not a straight 12 bit linear data = 12 bit linear light values with the D16. The D16's first stage AD is 16 bit, and the full range of 16 bit values is preserved in the 12 bit file. The actual resolution of shadow values shows as 16 bit linear light however the DVR codec is accomplishing that. Scratch file data shows the original as 16 bit linear float in a 12 bit compressed file. Regardless of what the image processor does, it is not mathematically possible to produce fine step resolution of gray scale values that aren't captured in the original. When Resolve and Scratch show the image data range as 16 bit, they are not making it up. The D16 produces more than 60 discrete grayscale values in a linear light range where 12 bit data can only resolve 6. It is not a log gamma encoded 12 bit file like the BMD cameras, but it is 16 bit linear light data in a lossless compressed 12 bit file.

I've mentioned before but please can you send me one of these DNGs then i can have a look at the actual data values in the file. The ones i'd looked at previously were 12 bit straight. And as i mentioned this is a quote from the engineer himself:

>Yes- the max range is about 12 stops.
>It is fairly linear across the range. Our optical black is around 30 so this is the start, so the first 4 stops are not quite 0 to 16.
>There is a slight toe but not too much in the darks.

In the face of evidence suggesting otherwise and a direct quote from the people responsible i don't know how you can carry on saying this!!

Thanks everyone else for the nice compliments, i do have a lot more to write up.

I've also noticed that the images don't link on iDevices, so i will need to make some changes to the site - each image has a bigger version which has a lot more detail.

cheers
Paul
 
Hi Paul,

Quick question for you. If 12-bit linear is limited to 12 stop, how are people like Art Adams able to shoot 14 stops on his tests? Are they false stops? If you look at his chart, you can clearly see 14, even the beginning of a 15th stop. I'm confused a bit by the various reports as Art says about 13 useable stops in his article. Also, Sony specs the FS700 at 14 stops. Really confusing.

DR_Test.jpg

http://www.dvinfo.net/article/acquisition/sonyxdcam/fs700-the-4k-story-from-my-perspective.html/4

Also, many people are claiming the A7s as having around 14 stops of DR. I would image that the A7s S-Log 2 would be similar to the FS700s. So does the A7s not have linear RAW?
 
Slight off topic: how did you got all of your technical knowledge? School, or personal learning and reading books? If so, can you recommend some?
 
Sony will say 14 because the math and tests say it is. And my car is rated to go up to 170mph and does if you put it on a track. Real world testing would say that I can never get my car over 150mph even on a back road because of the amount of space needed. But the manufacturer would want it to "look" cooler on paper than someone else's. Product advertising. Real world tests have it that the FS700 will give you 12 stops of range, though. Especially with needing to keep down the noise in the blacks in post. Technically Sony is right but at the end of the day it is best for ourselves, our videos, and our clients if we are just honest with what the camera can really do.

I've heard the A7 is a bit "lacking" when it comes to its RAW capabilities. But I wouldn't even blink at that price tag.
 
Back
Top