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

starcentral said:
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.


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.
Click to expand...

Hi Dennis

Look at the S-Log3 chart on the Sony White Paper. In the linear region from (about) -3 to +7 stops above middle gray, the code value for each stop is the same, 64 shades. It does not increase going toward the highlights, but stays the same.


http://community.sony.com/sony/atta...ry_for_S-Gamut3Cine_S-Gamut3_S-Log3_V1_00.pdf
 
To Dennis (OP): where do these charts come from? Why are the values exponential per stop, when we're talking about RAW linear? Is there a source where you're deriving this information?
 
Hi Tom,

I've just had a look at this thread - this page and the first one, so apologies if I'm talking out of turn, but the Sony White Paper doesn't have linear code values on any charts, for the simple reason that linear values are floating points, not integers. S-Log3 is a logarithmic curve, so above mid gray the difference in code values per stop will tend towards a constant.

This is an efficient way to distribute the 'significance' of brightness differences as the overall brightness increases within a limited bit depth (8 or 10). Log curves are well tuned to storing specific data (video here) even through to 12 or 14 bits plus, but when it comes to colour processing things are generally done in linear space. As Dennis' table on the first page demonstrates, integers are rubbish for storing linear values - limited range and no reflection of the significance of brightness changes - within a limited bit-depth codec.

The solution is floating-point values rather than integers.

I'm going to get horribly techie and confusing if I go on here, but I'm told I expressed it reasonably clearly (minimal maths and a some fairly clear charts ;-) ) in an article I was asked to write a little back. Here is a link:
A Bit More Than Everything You Wanted To Know About Shooting Log ;-)

It was comissioned for the UK Guild Of Television Cameramen's magazine Zerb, be they kindly let me link to it provided I mention them!
 
Last edited:
Oops,

realised I forgot the important point - that linear values are actually stored as limited bit-depth floating point numbers (I've edited the previous post to include that!). You can't store any more different values, but the spread is more efficient (dare I say it, it's a form of logarithmic encoding) and the range possible much greater than integers of the same bit depth.

12-bits is about the ragged edge of a useful float; at that point frankly a video-tuned log encoding is going to spread the data better. The standard way that current computers handle numbers is as a 64-bit 'double' float, 16-bit (as used in ACES for transfer and the F5 and F55 for raw) is a standard float form known as a 'half float' and anything below that has a standardised layout but is not in common use outside of specific applications (or cameras!),

Ben.
 
One thing here that says in my muddled head that linear distribution may not be so bad..

consider you had an array of lightbulbs, a very big array of them, 4000 of them. shining at a card that you are filming.

now they are all off and you switch one on, the light starts, you switch a second one on and your image becomes a stop brighter (two bulbs not one- twice as bright)

to record this 'stop one' step you only need one data level to record if lightbulb 2 is on or off.

to make the image another stop brighter (double the light) you dont switch on bulb 3 but bulbs 3 and 4.

but it is entirely possible that you did just switch on bulb 3, and not 3 and 4

so in stop 2 you need to be able to record if 3 is on, or 3 and 4 are on - you need 2 data levels allocated to this stop to record the possible options

now lets move up to the top end.. you have 2000 lightbulbs illuminated, to up the light one more stop you will need to turn on your last 2000 lightbulbs

but you could just turn on 2001, 2356, 2700, or any of the other values between 2000 and 4000

So to record all the possible combinations properly in that last stop you need to allocate 2000 levels of data to it.

--

Im not saying im not a fan of log, or I think 12bit raw works, but from the above demo we can see log must come at a cost of lost of true tonal subtlety in the top stop(s)

S
 
Last edited:
Sam,

two points:

First, in the article I make the analogy of my daughter not having £10 birthday money wanting to buy two toys totalling £11 - £1 makes all the difference in the world - and the chancellor making a budget statement being unlikely to mention savings of £1 in the overall cost of the NHS. In a video signal that is like the difference of one step in the shadows or midtones of a linear signal and one step in the high highlights. Each step is the same value (like the £1), but in the shadows that has greater 'worth' (as with my daughter's toys) than in the high highlights (as with the NHS budget).

The second point is that the talk of linear is generally in realtion to interger values, that's understandable as we all know about 10-bit integer code values for various curves.

Linear values in raw recording are actually stored as floating point values - the ACES approach is that 0.18 = 18% gray, 0.9 = 90% white card etc. Now floats have a particular way of being stored that allows for a much wider spread of values within a given bit depth than an integer approach. The total number of possible values doesn't change though. Again, I think I explain it better and more simply in the article, so I'd better leave it there. The spoiler alert point is that floating point is a form of generalised logarithmic (log) encoding. Also important for me to say I'm not advocating linear or log, just correcting a what seems to be a bit of an assumption which to be honest I made for ages that linear raw recordings were similar to conventional 8 or 10-bit recordings in terms of integer code values,

Ben
 
I wasn't specifically commenting on your article.

I was thinking aloud.

Clearly compressing lightbulbs 2734 and 2735 is probably a good place to 'lose' data because we would find it hard to visually see that difference ourselves when evaluating a 4000 element light array.

Again, clearly having absolute accuracy at level 3-4 is also needed because we could see that difference!

My personal opinion is that 12bit log probably presents a good compromise between data rate and image fidelity.. available in the sweet SR codec? (f5) and probably an underrated element of the C300ii - FS7 and Ody? I dont know.


S
 
Last edited:
Were I to comment on your article I would suggest that it does not really sing the 'upsides' of log/raw

-ability to correct, exposure and wb
-ability to match cameras
-ability to handle wide DR scenes with a smaller light package
-ability to ND skies not with a physical filter but a tracked secondary of exactly the right shape/size/roll off
-abtiliy to colour to brand message, and recolour to a later brand message or bring into a later project with a different look.
etc.
S
 
Last edited:
Doctor Wu said:
To Dennis (OP): where do these charts come from? Why are the values exponential per stop, when we're talking about RAW linear? Is there a source where you're deriving this information?
Click to expand...

The linear RAW data I put together looks exponential because each stop is represented in the binary system where each digital increases with a power of 2. But it looks like Ben might have more details on how Sony might be using the linear in their cameras.

As for charts on slog, etc.. Sony's white paper provides a formula that can be used to calculate scene reflection to S-Log3 IRE and 10-bit code values. If you play around with it and plot the data you can see how S-Log behaves depending on the input reflection.
 
Sam,

sorry, I didn't think you were talking about my article. I just mentioned it here because it goes into the basic difference between log and linear, then after your post I thought I'd mention the £1 analogy because I assumed no one would be bothered to trawl through the whole article!

Thanks,

Ben
 
cameramanben said:
Hi Tom,

I've just had a look at this thread - this page and the first one, so apologies if I'm talking out of turn, but the Sony White Paper doesn't have linear code values on any charts, for the simple reason that linear values are floating points, not integers. S-Log3 is a logarithmic curve, so above mid gray the difference in code values per stop will tend towards a constant.

This is an efficient way to distribute the 'significance' of brightness differences as the overall brightness increases within a limited bit depth (8 or 10). Log curves are well tuned to storing specific data (video here) even through to 12 or 14 bits plus, but when it comes to colour processing things are generally done in linear space. As Dennis' table on the first page demonstrates, integers are rubbish for storing linear values - limited range and no reflection of the significance of brightness changes - within a limited bit-depth codec.

The solution is floating-point values rather than integers.

I'm going to get horribly techie and confusing if I go on here, but I'm told I expressed it reasonably clearly (minimal maths and a some fairly clear charts ;-) ) in an article I was asked to write a little back. Here is a link:
A Bit More Than Everything You Wanted To Know About Shooting Log ;-)

It was comissioned for the UK Guild Of Television Cameramen's magazine Zerb, be they kindly let me link to it provided I mention them!
Click to expand...

I just read the Zerb article. It was excellent. Thank you!
 
Tom Roper said:
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.
Click to expand...

In this particular case i'm coming from the point of view of actual data in front of me, from FS700 DNGs plus also similar DNGs from DBX, BMC etc,.

DNGs are integers. Most are 12 bit (all the above are).

Each has a black level set by the camera, in the case of the FS700 RAW that is around 256 (already a chunk of space gone). Then the greyscale values for each of the pixels increase to clipping. Yes the camera outputs a small S shaped curve but for our purposes lets ignore that because it really is minor.

If you count from clipping down, each stop is a halving of light - all the way down to some definition of black.

So under a halving system then the end of that chain (in code values) will be 8,4,2,1 - that's 16 values for 4 stops. That's what is in the files and that's what you see.

Of course if you take RGB values in those areas and debayer, white balance and matrix them in floating point space you're going to not introduce clipping and those bottom 4 stops can produce more RGB triplets. And if the debayer is any good you can reconstruct highlights too, extending the range.

But i am saying very simply that no matter how you cut it when you're dealing with RAW data (and AFAIK all RAW is always transported as integer values) and from a linear sensor, it's basically as simple as that.

As you say a sensor can count down and reverse that, but it's physics that the shadows are super noisy, you're dealing with single photons of light, so reversing that encoding doesn't make any sense to me?

(Yes, the BMC is sort of log encoded so it can hold more than 12 stops, and the FS700 has a slight S curve so you can almost give it another half stop or so)

Yes, linear raw has been digitised from that initial voltage but in the cases i'm talking about there's no log compression going on. The RAW file appears to be genuinely linear.

cheers
Paul
 
cameramanben said:
I'm going to get horribly techie and confusing if I go on here, but I'm told I expressed it reasonably clearly (minimal maths and a some fairly clear charts ;-) ) in an article I was asked to write a little back. Here is a link:
A Bit More Than Everything You Wanted To Know About Shooting Log ;-)

It was comissioned for the UK Guild Of Television Cameramen's magazine Zerb, be they kindly let me link to it provided I mention them!
Click to expand...

Great article and LUTCalc is awesome.

Although are you suggesting that log files and raw files are half float? Or just saying they ought to be? I don't think that's the case but i could be wrong, the only half float files i see are OpenEXR.

When log files are transported via QT, especially from cameras in codecs like ProRes they're usually YUV pixel formats, 2yuv for LT and r4fl for higher versions. It is my understanding that the actual encoding inside are integers but sure, the Y can have a log compression curve applied before writing (infact it would normally be a shaper LUT somewhere in the chain as that's faster to process)

Sony have released the source curves for SLog2 somewhere, i have them in Nuke. But they're just mathematical transfers. You generally calculate the transfer and that's stored as a LUT so it's super fast to apply.

You may know more about the inside of some RAW formats than i do though, but why, for example would anyone need a negative bit? (unless of course you peg mid grey at 0). In OpenEXR mid grey is normally 0.18 like ACES.

I think you may be referring to the Sony RAW in the F55 etc,. I'd always read that as being marketed as 16 bit linear raw and for some reason i have the word integer next to it but i may well be totally wrong - So i think you're saying that Sony RAW is actually half float?

Just curious!

cheers
Paul
 
In Ben's article he makes reference to some material that was later pulled by Sony but seemed to indicate their 16-bit RAW is half float.

I think how Sony implements linear RAW on their newer line of camera's may forever remain a mystery?
 
Hi Paul and Tom,

when I wrote the article I got into 16-bit half floats because they are included in the ACES spec and because software like Resolve uses floating-point processing (albeit deeper bit depths than 16). It was also a way to explain how computers handle the mathematics of very wide ranges, and the usefulness of logarithmic encoding.

I suggested that Sony 16-bit linear recording might be floating point because of the wording of a bit of marketing that they had at the time. That has now gone from the marketing material and in this thread I managed to come over rather more definite about the Sony encoding. That's not my normal way (sounding definite about something I don't have definite documentation or evidence for) and it seems that I was rather talking out of my bum about floats in Sony's RAW recordings. Paul's post is really useful and backs up with what others have now written to me. I forgot that I was positing a suggestion and not stating a fact. To me that is unforgivable and I am extremely sorry.

Very sorry if I've spread confusion on that, but as far as the article goes, floats are an effective way of storing data, are the way that computers process large ranges and fractional numbers, are in the ACES spec and are also a good demonstration of how general logarithmic encoding can spread limited data in a useful way.

The bulk of the article is about the reasoning behind video-specific log encodings such as S-Log3 LogC, and that is all about much safer integer code values!

Well, lots of humble pie for me to get stuck into - sorry again all - and I'll duck back into the shadows and listen for more suggestions about how to fit 14 stops in 12 bits and call it linear! Tom's counting up / counting down with a crossover sounds interesting, but whilst the sensor voltage is linear, that sounds lioke a very loose definition of linear encoding. No more so than float I suppose!

Embarassed,

Ben
 
Last edited:
starcentral said:
In Ben's article he makes reference to some material that was later pulled by Sony but seemed to indicate their 16-bit RAW is half float.

I think how Sony implements linear RAW on their newer line of camera's may forever remain a mystery?
Click to expand...

I realise that but Bens article suggests that half float is used as a standard storage format. I'm just curious where else images are stored half float (aside from ACES, which i think is basically OpenEXR). Certainly in my limited eco-system i don't see half float, but that is limited of course.

I'm wondering whether ArriRAW is half float for example.

There's nothing incorrect in the article, but it's make me wonder about other RAWs i can't get into, it's the first time i've seen log encoding explained that way and it's certainly one way to encode a log file, but i've usually seen a simple LUT applied to source data in a higher depth to produce a log encoding.

cheers
Paul
 
cameramanben said:
Hi Paul and Tom,

when I wrote the article I got into 16-bit half floats because they are included in the ACES spec and because software like Resolve uses floating-point processing (albeit deeper bit depths than 16). It was also a way to explain how computers handle the mathematics of very wide ranges, and the usefulness of logarithmic encoding.

I suggested that Sony 16-bit linear might be floating point because of the wording of a bit of marketing that they had at the time. That has now gone from the marketing material and in this threadI managed to come over rather more definite about the Sony encoding. That's not my normal way (sounding definite about something I don't have definite documentation or evidence for) and it seems that I was rather talking out of my bum about floats in Sony's RAW recordings. Paul's post is really useful and backs up with what others have now written to me. I forgot that I was positing a suggestion and not stating a fact. To me that is unforgivable and I am extremely sorry.

Very sorry if I've spread confusion on that, but as far as the article goes, floats are an effective way of storing data, are the way that computers process large ranges and fractional numbers, are in the ACES spec and are also a good demonstration of how general logarithmic encoding can spread limited data in a useful way.

The bulk of the article is about the reasoning behind video-specific log encodings such as S-Log3 LogC, and that is all about much safer integer code values!

Well, lots of humble pie for me to get stuck into - sorry again all - and I'll duck back into the shadows and listen for more suggestions about how to fit 14 stops in 12 bits and call it linear!

Embarassed,

Ben
Click to expand...

You may well be correct because it is a good way of doing it. I've been routing through the Arri docs and they're a little vague on ArriRaw too. I'm sure anyone with the SDKs is NDA'd up to the hilt anyway.

It's also a good way to explain log encoding.

As you say floats are a the best way to work with light values, Nuke as a pipeline is ground up float based. But in camera hardware i suspect they're more integer based, simplicity and speed.

The term linear has been abused by marketing for many years.

Please don't head back into the shadows! You're posts are super insightful and there are so few bits in those shadows to represent you correctly...

cheers
Paul
 
Cameraman Ben.. you are an extreme highlight.. ! who retains alot of data and detail .. you must not,to the shadows go..
 
You must log in or register to reply here.
Back
Top