Sony FS7's 12 bit linear RAW?

Hi gurus

I'd like to ask you for your comments on the discussion that soon after the RAW recording was enabled on this camera (with the additional XDCA extension unit) was very hot here:

https://community.sony.com/t5/FS7/Raw-o ... m-p/494586

Even though there are no more activity in that thread (other than my own questions under the nickname of "MoldCAD", and a couple of inconclusive answers), the matter has become very important to me as I got the XDCA extension to my FS7 as well as Atomos Shogun Inferno, and of course I'm expecting the best possible quality of the footage I'm grading in Resolve...

I still don't understand the most important conclusion of that thread - which is that with only 12bit and linear RAW, information is missing in shadows and hence people are seeing lots of noise and banding there; some even say the picture is more like 8bit... While as a matter of fact, in order to activate the RAW SDI output the camera must be set to Cine EI mode, and one of the log gammas must be applied (S-Log2 or S-log3). My question may sound naive, but with the S-Log gamma applied we're not getting "linear" RAW data any more, are we?

As the CDNG recording will only be enabled on the Inferno with future fw upgrade in the summer, I set my Shogun to encode and record the Sony's RAW signal into DNxHR HQX format clips, which to my eye are of extremely high quality. Some people say it's the Atomos recorder which actually applies the S-log gamma before encoding, and that it's S-log3 by default - but frankly, I didn't find any official confirmation of this... Also, what If I preferred my DNxHR footage to be S-log2 instead? There is no option on the Shogun to select the gamma for recording!

So, to me it seems like it's only the camera itself which applies one of the 2 S-log curves (you cannot activate the RAW output w/o selecting one), so is it still a linear RAW signal? Any comments will be appreciated, TIA

Piotr

I haven't used the specific Sony RAW format you're describing, but I think you might be confused about how RAW works.

RAW isn't video and has no gamma. It's just raw sensor data. RAW can't be linear or SLog3. You have to choose into which gamut and gamma you want to "develop" it from the RAW data.

Have you read the section on RAW in the manual, starting at p. 101 in the March 2017 edition?


Sent from my iPhone using Tapatalk

If you record RAW with Shogun then it's RAW- no gamma, etc. S-log etc can be applied to preview, but this is irrelevant what you record.
When you record DNxHR HQX then this goes through debayering etc and can have S-log2/3 LUT applied- depending what you can set (or is set automatically in Shogun). I would rather have it without any LUT applied as then you have more control over it in Resolve etc. Shooting LOG an applying LUT in recording device almost negates whole point of shooting LOG. LUTs are normally applied only for preview so you can easier judge what is recorded.

Thanks guys.

I do know what RAW is (I'm coming from Vegas Pro which has supported RED RAW for a while now, and I did have RED camera footage among the many cameras we used for shooting the classical music concerts; I remember "developing" the R3D files in Vegas and guess the process is similar in Resolve).

I'd be grateful if you commented on these aspects of my OP:

- what do you make of the discussion at the link I posted, and their concept of "linear RAW" and how it might be the reason for noise/banding in shadows some people see?
- why do you think the FS7 camera will only output RAW if one of the S-log curves is selected in the output format?
- could it be (my long shot guess) that selecting one of the log gammas on the FS7 is for monitoring purposes only (you cannot monitor RAW, as it's not video per se), and it's actually the Shogun itself which - seeing this "flag" in the RAW SDI output - applies its own S-log3/2 gamma before encoding to Prores/DNxHR? Once CDNG is enabled by Atomos and chosen by the user, no gamma curve will be applied of course...

And of course I do not grade RAW yet, as it will only come to the Shogun in a later firmware update. Thanks,

Piotr

There are two sides to this raw thing. One side is the raw data itself, the other is outputting this data to a file or some standardized stream that does not explicitly support raw.

Raw data in itself is the sensor data after it has been quantized. There are no "very large numbers", the data lies between sensor photosite minimum and maximum analog signal that is quantized into certain bit depth. Depending on camera the AD quantizer can output 14bit data, 12bit, 10bit etc. Quantizers usually are linear, meaning the output digital binary value has linear relationship to analog signal strength. The maximum value an AD quantizer puts out is what its bit depth allows, but it always relates to sensor maximum signal. With linear quantizer each bit is as good as it gets, it is the most direct mapping of sensor capture to digital data, no additional curve can pull out any more meaningful data.

With CMOS sensors there is only one image plane in raw data, as there is only one sensor. This is the reason why uncompressed raw data is 1/3 the size of debayered RGB (or 444YUV) data. Bayer pattern can be thought of as something like hardware 2:1:1 chroma subsampling, although the subsampling numbering schema does not really fit the bayer pattern logic. This one image plane can be dumped into a file and this is what we usually get as raw frame. But these raw RGB values can also be ripped out from the pattern and re-organized into four image planes, two G, one R and one B. These four planes can be compressed using some neat algorithm and dropped into a file container, something in the lines of red raw.

The question is, if our quantizer is 14bit, but our maximum possible recording bit depth is 10 or 12, what should we do. One solution is to discard the least significant bits. Another solution would be to do some interesting transform on these 14 bits before discarding, like applying a log or gamma curve on them, to keep more relevant information. This is a non-standard way of handling raw data and specific to the capture system.

The thing gets interesting when someone tries to transport this raw data over some video feed like HD-SDI, which does not explicitly support raw. As HD-SDI serializes the video data into streams of Y Y' and Cb Cr samples, it is possible to drop the raw data into these values as if it were already debayered (to RGB and from there to Y'CbCr) while it is not. And on the receiving end we can record the data as raw or do the debayering. If raw data is masked as Y'CbCr it can be viewed on monitors etc, how much sense the image does is another thing, but it should be viewable (it will be dark if it is linear raw).

I'm not familiar with FS7, but simply doing some guesswork I would guess that:
- raw output is either raw data masked as Y'CbCr signal or not raw at all;
- it is a non-standard logic and finding true support for it is questionable;
- raw output only when S-log curve is enabled could be for applying the S-Log transfer function to raw data to keep more data in shadows that would be lost in bit truncation, but as there are reports of heavy banding in shadows it probably is not the case.

The discussion of floating point representation of data values goes a bit beyond me, as I can't see any real benefit in using floating point to represent data in fixed range (as sensor output is). Floating point numbers lose one bit to represent sign (but we don't have negative values on sensor) and thus are not better than integer storage for fixed range input. What floats can achieve is similar relative precision over entire range, but that can also be achieved with interger storage and proper transfer function (log etc curve).

A related discussion is here:
Let's talk about linear to log, A-to-D in digital cameras

It is an interesting read, although gets a bit lost in the discussion of whether a linear data dumped into binary number encoding is linear or log. I would skim that part because it is a question of data representation in digital form, not what that data means (which is important). We don't say that decimal numbers are logartihmic although they are log encoded on base 10...

There is also a good quote (on page 3 by Ivon Visalli) about an issue, that seems to be misunderstood frequently:

The problem, as someone has already stated, is the initial assumption that bit-depth determines the dynamic range. It does not. Bit depth determines the precision or granularity of the light values being recorded, not their overall range.

All very true, but the basic issue with FS5/7 RAW is the low bitrate.
If you put 13 stops into 12bit linear, the resulting image would be a mess.

That's why there's a general consensus not using RAW but XAVC-I with the highest bitrate log encoded instead.

Piotr now thinks that the Shogun does some interesting thing with Sony's RAW data because it looks so good.

What I'd like to see is a side by side of the same image in XAVC-I from Sony's internal recording AMD in DNxHD from the Shogun.

There are significant differences between FS5/FS700 and FS7 in raw passed through SDI to third party recorders. All these output compressed raw (decompressed on the recorder side), but the FS7 bakes white balance in. In theory this has some advantages when using a limited bandwidth channel or limited bit precision, but for whatever reason Sony's implementation results in reduced image density. FS5/FS700 have around 1 bit more precision in raw than the FS7.

"Linear" raw isn't really linear. There are non-linearities at the extremes, so nominally the range is bigger than 12 stops. What of this is "usable" DR is another story.

I, personally have seen big differences between FS7 RAW and FS700 RAW.
The FS700 looks much better to me.

I'm not sure there is much rawness left when white balance is baked in. This would mean that there has already a gamut transform from sensor virtual primaries to XYZ and XYZ to some RGB set taken place, plus the WB operation itself. If it is still called raw, it would mean that debayering is done after all these ops..? But in this case the result is not raw any more, it is a developed bayer pattern RGB image with a clearly set gamut. Otherwise the WB would be scaling on sensor primaries, which is definitely not white balancing in its classical sense but rather a custom scaling of data for better recording/transmitting.

Thanks guys for your invaluable input. So the general consensus is that FS7's RAW will not present the greatest picture quality... However, quite frankly, I wasn't really going to record and grade RAW; if I purchased the Shogun Inferno (and the XDCA module which enables RAW SDI output from FS7) is that the HDMI video output being 10bit 422 only up to 30p (8bit 420 at higher framerates), the only way of recording full 10bit 422 at 50p externally was to go via XDCA. My 4KDCI@50p clips from the Shogun have bitrate over 1,500 Mbps and the picture is sooo much better than the internal XAVC-I, at only some 500 Mbps!

I guess that even after Atomos enables CDNG recording, apart from some trials I will stick to my current workflow, if for file size considerations only. But: I'm still uncertain how to toggle between S-log2 and S-log3 in DNxHR clips recorded this way! Cheers

Piotr