FS7: FS7 RAW woes & data distribution between: 12-bit RAW, 16-bit RAW, & 10-bit S-Log

[paulcurtis]

I'm not sure of exactly how this works, or if it applies to the FS7 12 bit raw, but the linear 12 bit file from my D16 is written from a 16 bit first stage AD processor and unpacks as 16 bit values in every raw processor I've used. There are discrete pixel gray scale values in the lower ranges that are not possible with 12 bit linear AD. In any case 12 bit linear places middle gray at 512 with 3 stops of headroom.
With REC709, which is HD display values standard, you have an absolute maximum theoretical DR of 9.5 stops regardless of bit depth. Anything outside of that range on either end is hard clipped. REC709 video digital code values are not linear, they are gamma 1 log encoded, equal code value steps per stop of light value.
Other camera log curves are compression schemes to bring sensor data into display value ranges.

Last time i spoke to one of the engineers he was pretty convinced it was 12 bit linear out of the camera he'd help create

This was a while back, perhaps they've changed their hardware but it was clear in rawdigger that the D16 was outputting simple, clean 12 bit linear files.

Is there a recent D16 sample DNG to look at?

cheers
Paul

 

[yoclay]

You know the other possibility is that the color of this sweater falls into a part of the gamut that this sensor can't deal with. I have seen that before in the green blue part of the spectrum once you get to the shadow section. This culprit usually shows up in grassy landscapes. I also wonder if a Black Balance would have helped, because I have seen exactly these type of issues on RED cameras when black shading was not done. Did you do this?

By the way Ben, no doubt about your level of experience. You most certainly have nothing to prove to myself or anyone else here. We're probably mostly artsy-fartsy types parading around, pretending to be technicians anyway.

 

[Tom Roper]

There was some discussion on excessive banding occurring with the FS7 using the 12-bit RAW output to the Odyssey recorder. An odd behaviour when the same issue did not seem to exist on the FS700 with 12-bit RAW output.

In the thread, I had written that with the way linear RAW works and assuming Sony's 12-bit RAW is a pure linear gamma curve there would actually not be enough data bits left at the lower end of the sensor's overall dynamic range of 14 stops. Sony would have to apply some rounding or bending of the linear gamma to help get some data bits covering the lower end of the tonal range.

This table of mine helps to illustrate what I'm talking about. As everyone knows with 12-bit you have 4096 total levels of grey. The highest stop takes 2048 of these levels (so half what is available overall) and then the 2nd highest stop takes 1024 levels, the third stop takes 512 levels, and so on and so on. By the time you get to the bottom you do not have any bits left to even cover the entire dynamic range of the sensor (14 stops). You'll actually notice the table only covers the first 12 stops and doesn't even get to the 13th and 14th stops as there would be no data available for them.

I wanted to answer this last night when there were no replies, but it was past bed time. Now there are 5 pages! So how do I say it..you're confusing linear gamma which is the transfer characteristic of encoded luma to image luminance. It is NOT the number of gray shades! The number of shades per stop is more or less equal. Obviously 16 bits gives more shades to each stop than 10 bits. If the number of shades was allocated as a power-law relationship where all the shades were at the top, and almost none at the bottom, we would never see banding in bright blue skies, which we know is not true.

 

[Ben Scott]

You know the other possibility is that the color of this sweater falls into a part of the gamut that this sensor can't deal with. I have seen that before in the green blue part of the spectrum once you get to the shadow section. This culprit usually shows up in grassy landscapes. I also wonder if a Black Balance would have helped, because I have seen exactly these type of issues on RED cameras when black shading was not done. Did you do this?

By the way Ben, no doubt about your level of experience. You most certainly have nothing to prove to myself or anyone else here. We're probably mostly artsy-fartsy types parading around, pretending to be technicians anyway.

Sorry I wasn't being arsey, I was just making the point that my findings in the field for how I work is of more importance to me than someone I don't know's streess test where I don't know the methodology of the person doing it.

Pretty sure the issue is luma based by the way as other items of clothing exhibit it from the shoot.

Oh and yes, if working Reds taught me anything, it's to regularly black balance

 

[Nirv]

Rumours of compressed RAW for FS cameras.

http://www.sonyalpharumors.com/sr3-...pressed-raw-set-of-codecs-for-the-fs-cameras/

 

[paulcurtis]

I wanted to answer this last night when there were no replies, but it was past bed time. Now there are 5 pages! So how do I say it..you're confusing linear gamma which is the transfer characteristic of encoded luma to image luminance. It is NOT the number of gray shades! The number of shades per stop is more or less equal. Obviously 16 bits gives more shades to each stop than 10 bits. If the number of shades was allocated as a power-law relationship where all the shades were at the top, and almost none at the bottom, we would never see banding in bright blue skies, which we know is not true.

Dennis's diagram is correct, although mid grey is being pegged in different places for different bit depths.

The diagram is showing the number of grey shades or code values between stops in a linear sensor output. It's the nature of linear sensors that they record a doubling of light per stop, it's physics. When you record raw you're just getting these basic values. So in a 12 bit system the bottom 4 stops are represented by just 8 code values. Of course they're basically noise anyway. The brightest stop before clipping would be represented by 2048 values. A huge waste. hence log encoding evens out the distrubtion to give roughly the same number of values per stop.

The reality is that the sensor out is never totally linear, nor are log curves straight either. Nor is there 4096 values (black levels eat into that). But broadly speaking what's the issue you see with the message?

cheers
Paul

 

[paulcurtis]

Rumours of compressed RAW for FS cameras.

http://www.sonyalpharumors.com/sr3-...pressed-raw-set-of-codecs-for-the-fs-cameras/

That would be awesome...

The RAW out is compressed anyway, so it might even be possible to get better RAW on board internally with a suitable codec..

cheers
Paul

 

[mainstreetprod]

ETTR is all relative but you still need to work on your light/contrast ratios within the scene with all light sources and THEN see how mush you can push the exposure to have a 'safe zone' for the shadows without blowing out highlights. It's a balancing act.


EDIT: Sam I don't think it is flippant at all. The most important thing in our job is control of the photons. Buy a light is probably the best advice I can give to people wanting to get into this game. Buy many lights. Hire lights. Get used light. Get work lights. Get whatever you have to to be able to make enough photons hit that sensor to make pictures that can tell a story. Then you can concentrate on making it look sexy.

Way too much disregard for lighting going on today. Just watched an indy film, probably 100K budget that looked relatively devoid of color or contrast compared to Hollywood fare and assumed it was shot on DSLR in mostly available light. Looked it up on IMDB and nope, shot on Alexa.

 

[Ben Scott]

Yup. I can't believe in this day and age people don't get it. People assume 'good low light performance' means you don't actually have to light your films anymore.


Light a scene shot on a 5D mk2 properly and it can look amazing.

Underlight a film shot on Alexa 65 and it will look appalling.

 

[Nirv]

My feeling on the jumpers girls is that the white bg should have been above clip*.. white was the intention, and then rest lit so the skin was at about 90.


I think the image would then be clean.

+1 for ETTR.

I've been ETTR and it has stood up well and I've been very pleased with the output especially the clean blacks e.g. I'll normally be shooting in 500 ISO in CineEI and any loss of dynamic range is usually far less obvious than noisy blacks would be.

I've come a cropper with HFR, XAVC and noise myself and this is the triumvirate of evil for this camera. The aliasing from HFR combined with the heavy compression in the black zone plus noise equals a shitstorm so you have to pick your battles when shooting HFR. If you have good SNR and important detail is out of the clutches of the compression you've only got to deal with pixel binning which can be mitigated to some degree with filters.

 

[Razz16mm]

Last time i spoke to one of the engineers he was pretty convinced it was 12 bit linear out of the camera he'd help create

This was a while back, perhaps they've changed their hardware but it was clear in rawdigger that the D16 was outputting simple, clean 12 bit linear files.

Is there a recent D16 sample DNG to look at?

cheers
Paul

You are correct, the 12 bit file is linear as it reads in raw digger. At 200 ISO if I remember correctly black cutoff is at code 8, and analog white clip is at code 3560. Digital clip is not allowed at either end of the scale. It is a third party DNG codec. Scratch play identified it, but I don't remember the source. Scratch Play identifies it as 12 bit DNG, but one has to set the code range to 16 bit to recover the full range of values in the image. Same is true of ACR, Raw Therapee, and Capture 1. There are discrete gray scale pixel values recovered in the 16 bit readout, including low level detail, that are physically impossible with a straight 12 bid AD. The first stage AD of a D16 is 16 bit. So how this is all accomplished is a mystery to me. It is not done with any form of gamma or log encoding. Perhaps there is some form of linear data compression between the 16 bit input and 12 bit output.

This is a 12 bit linear image readout from Scratch Play:

And the same image with 16 bit readout:

Sorry, don't mean to hijack the thread. But this is just to point out that raw file encoding is not always as simple and straight forward as we may think. How does one record usable values for higher than 12 stop DR sensors to a 12 bit file?

 

[starcentral]

How does one record usable values for higher than 12 stop DR sensors to a 12 bit file?

The only way I can see is to apply some level of gamma encoding (bending linear) before digitizing the data into a file. How much or how little will vary from camera maker to camera maker. RED was 12-bit from the onset but the RED ONE was around 11-12 stops from what I recall so they probably didn't need to do a lot of bending. The MX sensor offered 13.5 stops which would have been pushing the limits of 12-bit REDCODE unless they were doing a little bending. Once RED went to 16.5 stops with the Dragon sensor they also switched over to a 16-bit file format in 2013 from what I remember. Again there may have been some level of small bending just to keep the total dynamic range in the file.

This theory is the same as how Sony puts 14 stops from the FS7/F5/F55 into their 10-bit XAVC file format which is REC709; i.e. by using S-Log which is a super hyper gamma curve squeezing a lot of dynamic range into a smaller space. But with LOG, unlike linear, the other benefit becomes more equalized data distribution so with log its sort of a win-win situation. This would be one of the reasons ARRI created Log C for their method of encoding sensor data into REC709 as well.

I'm definitely open to hearing other theories however, my expertise is limited. I have never designed or built a digital cinema camera.

 

[paulcurtis]

You are correct, the 12 bit file is linear as it reads in raw digger. At 200 ISO if I remember correctly black cutoff is at code 8, and analog white clip is at code 3560. Digital clip is not allowed at either end of the scale. It is a third party DNG codec. Scratch play identified it, but I don't remember the source. Scratch Play identifies it as 12 bit DNG, but one has to set the code range to 16 bit to recover the full range of values in the image. Same is true of ACR, Raw Therapee, and Capture 1. There are discrete gray scale pixel values recovered in the 16 bit readout, including low level detail, that are physically impossible with a straight 12 bid AD. The first stage AD of a D16 is 16 bit. So how this is all accomplished is a mystery to me. It is not done with any form of gamma or log encoding. Perhaps there is some form of linear data compression between the 16 bit input and 12 bit output.

This is a 12 bit linear image readout from Scratch Play:

And the same image with 16 bit readout:

Sorry, don't mean to hijack the thread. But this is just to point out that raw file encoding is not always as simple and straight forward as we may think. How does one record usable values for higher than 12 stop DR sensors to a 12 bit file?

Well the *actual* data in that file is 12 bits, that's what's coming out of the camera.

What each application decides to do with that afterwards is up to them.

I suspect that what's happening between your switch 12/16 is that the matrix math is being done in 12 bit in one (really really stupid to even have that choice) and 16 bit in another, so basically after matrixing those raw values that 12 bit option has just clipped everything. Remember that those values are pre white balanced. So the general math goes something along the lines of

RGB(camera space) -> XYZ Colourspace (inc white balancing) -> RGB (destination space).

If you do any of those math operations in a 12 bit integer space then that's just utterly silly. You should take those 12 bit integer values at the beginning and move them into 32 bit floating point and do all your colour math in that space.

So even if you had source RGB code values of 2,4,1 for example. When whitebalaced they would become floating point values. So the difference between 2,4,1 and 2,4,2 and 2,3,1 would actually be quite different and in terms of final tonality it would be greater than 12 bit. Especially if that debayer is futzing values as well (which they all are)

If you do that math in a limited space then you'll just quantise the results and end up with banding. Your final values you see are the results of math in higher spaces, no magic in the source data. And that's kinda the point about FS7 RAW is that by being white balanced at source you remove some of those possibilities.

So either that or scratch is doing something really daft.

I have never seen any debayer operate like that!

cheers
Paul

 

[paulcurtis]

+1 for ETTR.

I've been ETTR and it has stood up well and I've been very pleased with the output especially the clean blacks e.g. I'll normally be shooting in 500 ISO in CineEI and any loss of dynamic range is usually far less obvious than noisy blacks would be.

I've come a cropper with HFR, XAVC and noise myself and this is the triumvirate of evil for this camera. The aliasing from HFR combined with the heavy compression in the black zone plus noise equals a s*%tstorm so you have to pick your battles when shooting HFR. If you have good SNR and important detail is out of the clutches of the compression you've only got to deal with pixel binning which can be mitigated to some degree with filters.

One of the arguments against ETTR is narrative is simply scene to scene consistency, your noise floor would change from scene to scene but actually i just think that's a non issue these days as cameras are damn good as a whole. So i'd agree in general here. There are so many post stages that footage goes through, any one of them can screw it up completely.

I don't know if anyone caught last weeks final downton abbey. But i'm convinced they got the wrong gamma on the whole grade. The black toe crushed to buggery. I can't believe it could go through the pipe like that, compared to some stunning tonality a few weeks back. I'd love to have been a fly on the wall in the grading suite on that one.

cheers
Paul

 

[starcentral]

Hm, I find myself hardly ever if ever use ETTR. It might be okay for a one off shot but go shoot a narrative like that and I'd say the benefit of ETTR outweighs the efforts of what will be spent in post. Maybe once metadata can be used off the Sony's better it will be a non-issue?

I could be wrong but I'd say that DP's working on TV and film with multiple setups and shooting days aren't using ETTR. More simple to do is just rate the camera lower in ISO thus overexposing by a set amount usually determined by performing several tests well in advance of shooting.

Tell me one camera that doesn't look better when rated lower and overexposed by a stop? So if going for consistency maybe it's just best to go about exposure that way?

 

[morgan_moore]

There are some obsessives (technically correct of course) that take ETTR to mean putting the histo on the absolute right for every shot.. blowing their consistency between shots and creating grade hell

Sensible 'ETTR'ers would just rate the FS7 (slog to internal card) at 800-1000 and always use a Red/BMC at its lowest iso and have the hump sit a bit right where possible.

E a bit R


S

 

[Tom Roper]

Dennis's diagram is correct, although mid grey is being pegged in different places for different bit depths.
The diagram is showing the number of grey shades or code values between stops in a linear sensor output. It's the nature of linear sensors that they record a doubling of light per stop, it's physics. When you record raw you're just getting these basic values. So in a 12 bit system the bottom 4 stops are represented by just 8 code values. Of course they're basically noise anyway. The brightest stop before clipping would be represented by 2048 values. A huge waste. hence log encoding evens out the distrubtion to give roughly the same number of values per stop.
The reality is that the sensor out is never totally linear, nor are log curves straight either. Nor is there 4096 values (black levels eat into that). But broadly speaking what's the issue you see with the message?
cheers
Paul

Hi Paul,
The issue broadly speaking is the oversimplification in saying there aren't bits to represent enough shades, and that the number of shades has to increase unchecked as brightness goes up. I can give at least 3 examples of why this is not so:
The first one is that A/D converters don't have to just count up, they can also count down. So a 12 bit A/D could output code value 4096 @ 0V and 0 @ 1V. That gives you lots of shades in the dark areas, and fewer up top where the eye is less sensitive to them. But that too is just an over simplification.
Consider:
Let a = word length of raw recorder = 12
Let b = number of f-stops = 14
Let c = word length of A/D converter = 16
f-stop = doubling of light; so 2
2^a = 4,096
2^b = 16,384
2^c = 65,536
Assume noise floor of c is (LSB+2) = 04h
The first f-stop of c is (LSB+3) = 08h
That gives 4 shades for first f-stop, 8 for the 2nd, 16 for the 3rd, 32 for the 4th. A total of 60 shades (or code values) representing the first 4 stops. Is this so very far off? I don't think so. Just last week Alister Chapman wrote in his blog there were 80 shades for the first 4 stops of S-Log3.
Next assume a 16 bit table addressed by the A/D, containing 12 bit code values; Map your code values representing the number of shades for the 14 stops this way; 4+8+16+32+64+128+256+512+1024+1024+512+256+128+128 = 4092.
Output 12 bit code values as linear raw.
That's two examples.
I am not saying that the camera or recorder under discussion is properly implementing raw recording, I'm just saying it isn't due to a lack of bits.
The third example is that the first two didn't consider that the sensor is probably non-linear anyway, nor gave any consideration to analog gain/offset/summing with operational amplifiers that could redistribute the number of shades or code values within the table.

In the end, the only true raw is sensor voltage itself. Linear raw has been digitized and the distribution of shades normalized.

 

[starcentral]

These are good points, but we know that the highest data in the file storage of the image is going towards the highlights for linear RAW as well as for S-Log.

Just last week Alister Chapman wrote in his blog there were 80 shades for the first 4 stops of S-Log3.

Yes, for S-Log3 there are 74 shades over the first bottom stops. They can be added up from the table I posted on the first page. These values can be mathematically calculated using the white paper for slog3 provided by Sony so there shouldn't be any dispute on that.

As for linear RAW, there is nothing published so I do admit my writings are quite speculative in nature but in line with what users seem to be experiencing with the FS7 using the 12-bit RAW stream. Alister also recently defended the FS7 on the Sony forums saying that consumers shouldn't have expected the 12-bit RAW stream to be all that good so I think he agrees that 12-bit RAW isn't enough of a container for the 14 stops. But then there is the FS700 which also employed 12-bit RAW and some tests showed up to 13 stops, in some cases I read 15 stops but I personally have never tested it myself.

This is all good discussion Tom, don't get me wrong. I'm definitely not trying to be defensive or anything. I enjoy the conversation.

 

[DLD]

(this is slighly above my pay grade, so I try not to sound like an idiot ... but, nonetheless) Don't these various conversion algorithms basically add numbers to what they get off the sensor itself and then redistribute all the information according to what they designers want to see in the output? In that sense, wouldn't the limitation with any model lie not with the sensor itself or even the delivery format but on the processing power and the algorithms?

 

[starcentral]

This is a good primer on understanding gamma correction:

http://www.cambridgeincolour.com/tutorials/gamma-correction.htm