S-Log for Canon why not for SxS?

[Leonard Levy]

There is a new Technicolor S-Log curve for the Canon DSLR's and people are raving about with almost no one I've seen complaining that the codec can't handle it. Maybe I've just missed the bad reports though.

So I'm wondering if the crappy DSLR 4:2:0 H.264 codec seems to be OK with out banding etc, shouldn't it be better on an F3 (or EX-1) even when recorded to an SxS card? In other words it really true that S-Log won't work on an 8-bit 4:2:0 codec, and if it will shouldn't Sony make it available in their upcoming free upgrade.

[Brian Drysdale]

Phil Rhodes gives his take on the downside of doing this on a DSLR:

HDSLR Color Grading ? Before or After

[David C. Williams]

If you read through the updated manual it appears you can record S-Log to XDCAM EX on SxS.

It says this-

Select the MLUT (Monitor Look Up Table) to be applied to the video signals with S-LOG except for the signals of DualLink output (signals recorded on the camcorder, and signals output from the SDI output, HDMI output, Video output, and i-LINK output)

Off: MLUT not applied (original S-LOG is output)

So LUT off appears to mean the original S-Log gamma curve unchanged.

Now you still have the issue off 10 bits of log luminance quantized down to 8 bits, and reversing that back to linear will inevitably introduce posterization.

I doubt the Canon log curve is as aggressive as S-Log, and it certainly has 3 or maybe even 4 fewer stops to capture. It will be interesting to see just how far XDCAM EX S-Log can be pushed with 13 or more stops squeezed in there.

[Peter Moretti]

Originally Posted by Brian Drysdale

Phil Rhodes gives his take on the downside of doing this on a DSLR:

HDSLR Color Grading ? Before or After

Thank God someone has posted this! The whole shoot washed out to give you more grading options trend made no sense. As long as you don't over saturate or blow out, it's best to get close to the desired image, not wash it out so you can grade it more later.

[Timur Civan]

Lets say for argument sake the F3 records 13 stops of dynamic range in sLog.

8bit = 256 gradations from clipped black to clipped white.
10 bit - 1024 gradations from clipped black to clipped white.

@ 8bit XDcam, thats 19.6 gradations per stop, which will inevitably be extended in the grade. 19 gradations is going to look bad, especially with a clean noise free image. grain will cover up the "banding" but then whats the point.

sLog has to be recorded in at least 10bit to be a functional tool because at 10 bit you will get 85 gradations per stop. Almost 1/3 of the total gradations for all 13 stops in 8 bit altogether.

[Alister Chapman]

It's worse than that as 0-100% 8 bit video only has 219 bits as zero starts at bit 16 and 100% is bit 235 (10bit uses bits 64-940). S-Log, Cinegammas and Hypergammas do go upto 109% which is bit 255, but you still loose those first 16bits.

Anyway Tim is right, S-log at 8 bit will not grade well. There is a strong argument that using a good 8 bit to 10 bit conversion tool prior to grading will give a result closer to 10 bit as it is possible to calculate what the extra 10 bit in between values should be by interpolation. But I have not tried this and it adds complexity to the workflow. I don't believe it would ever be as good as recording 10 bit, but it might come close.

[Peter Moretti]

Alister, can't you change the black level of the camera to record black at 0 or 4 (the first legal SMPTE 10-bit extended range level)?

Timur, S-Log is logarithmic, so more bits are used for the shadows and mids than for the highlights. You're conclusion is correct, you really need more than eight bits to record 13 stops ;). (But your math is off b/c each stop does not get the same number of bits w/ log recording.)

[Alister Chapman]

With 8 bit the first 16 bits are used for sync and other data. Zero is bit 16. With SMPTE 10-bit extended range you can go down to bit 4 for undershoot, but then bit codes 1020 to 1023 are used for sync and you can go up to bit 1019 for overshoots but the legal range is still 64-940. So black is always bit 64 and peak white always bit 940. Anything below 64 is a super black or blacker than black and anything above 940 is brighter than peak white or superwhite.

At the moment the big problem with 10 bit extended (SMPTE 274M 8.12) and also 8 bit that uses the extra bits above 235 is that some codecs and most software still expects to see the original legal range so anything recorded beyond that range, particularly below range can get truncated or clipped. If it is converted to RGB or you add an RGB filter or layer in your NLE it will almost certainly get clipped. Encoding to another codec can also lead to clipping. FCP and most NLE's will display super blacks and superwhites as these fall within the full 8 or 10 bit ranges used by computer graphics, but further encoding can be problematic. Baselight for example will only unpack the legal range from a codec so you need to bring the codec into legal range before going in to baselight.

On the other hand if you are doing stuff for the web or computer display where the full 0 to 255 (1023) are used then, you need to use the video legal levels above white to get whites to look white and not bright grey! There are so many different standards across different platforms that it's a complete nightmare. Arri with Alexa for example won't allow you to record extanded range using ProRes because of these issues, while the HDSDi output will output extended range.

This is one of the issues with using computer monitors for monitoring. When you look at this web page or any computer graphics white is set at bit 255 or 1023. But that would be a super white or illegal white for video. As a result in-range or legal range videos when viewed on a computer monitor often look dull as the whites will be less bright than the computers own whites. The temptation therefore is to grade the video to make the whites look as bright as the computers whites which leads to illegal levels or clipping, or smply an image that does not look right on a TV or video monitor...... nightmare!

[Piotr Wozniacki]

Originally Posted by Alister Chapman

. There is a strong argument that using a good 8 bit to 10 bit conversion tool prior to grading will give a result closer to 10 bit as it is possible to calculate what the extra 10 bit in between values should be by interpolation.

Dear Alister,

I don't know what specifically you mean by "a good 8 bit to 10 bit conversion tool" - but I'd like to seek your expert advise on the following:

I'm capturing my EX1 stuff on the nanoFlash 8 bit, 422. For low light recording, I routinely use the NeatVideo plugin for my first trans-code, in order to get rid of that noise... Now, more often than not, it results in the noise-free material (e.g XDCAM 50), suffering from severe color banding instead (with the original noise masking the banding, through sort of dithering I guess).

So, I tried to render to a 10-bit codec (using Vegas, this can be the Sony 10bitYUV, or DNxHD). To my great surprise, the output is now free of banding - but I'm very uncomfortable with not being able to answer this question:

- if the 10 bit information was not there in the first place, what it really is what I'm getting from rendering to a 10-bit codec with NeatVideo plugin? I mean, where is the extra color information (to smooth the banding) taken from? Is it a valid information, or just a (positive) side-effect of what I'm doing?

TIA for some enlightenment,

Piotr

[Andrew Stone]

Thank you Timur for posting a clear explanation as to why SLOG in 8 bit is a bad idea. The posterization of your material could easily result once a LUT is applied.

[Alister Chapman]

Piotr: Rendering to 10 bit gives a positive side effect. When you transcode from 8 bit to 8 bit you will almost always have some issues with banding if there are any changes in the gamma or gain within the image. As you are starting with 8 bits or 240 shades of grey (256 - 16) and encoding to 240 shades the smallest step you can ever have is 1/240th. If whatever you are encoding or rendering determines that lets say level 128 should now be level 128.5, this can't be done, so it's rounded up or down to the closest bit. This rounding leads to a reduction in the number of shades recorded overall and can lead to banding.

DISCLAIMER: The numbers are for example only and may not be entirely correct or accurate, I'm just trying to demonstrate the principle.

Consider these original levels, a nice smooth graduation:
128, 129, 130, 131, 132, 133.
Imagine there is some noise and neatvideo (or whatever) has calculated that these are the smoothed values:
128.5, 129, 129.4, 131.5, 132, 133.5

But we cant record half bits, only whole ones so for 8 bit these get rounded to the nearest bit:
129, 129, 129, 132, 132, 134
You can see how easily banding will occur, our smooth gradation now has some marked steps.

If you are rendering to 10 bit you would get more in between steps:

If you render to 10 bit then when step 128 is determined to be be 128.5 by the plugin this can now actually be encoded as the closest 10 bit equivalent because for every 1 step in 8 bit there are 3.9 steps in 10 bit, so (approximately,translating to 10 bit) level 128 would be 499 and 128.5 would be 501

128.5 = 501
129 = 503
129.4 = 505
131.5 = 513
132 = 515
133.5 = 521

So you can see that we now retain in-between steps which are not present when we render to 8 bit so our gradation remains much smoother.

Hope that helps.

[Piotr Wozniacki]

Thank you so much, Alister - with your explanation of what's going on with the signal, it all makes sense to me!

Piotr

PS Oh, and Alister - one more question if you don't mind (this one is really so dumb that my silly ego would prevent me from asking that anyone but a true expert like yourself):

- what really is the relationship between acquiring 8 vs.10 bit accuracy, and rendering in 8 vs. 32 floating point bit precision?

Cause you see, also in Vegas, I can get much less banding when editing/encoding using the 32-bit accuracy. Of course, banding is used here just as an example of differences (levels, etc. being others, clearly visible on output).

My problem is that I don't know any obvious relationship between 8-10bit image acquisition, and 8-32bit rendering...

TIA,

Piotr

[Leonard Levy]

Thanks for an enlightening discussion as always. When I posted this at first I was hoping for a clear response to all the excitement about S-log for the Canon, though I'm still surprised by how many people claim to be getting results from it. perhaps the technicolor gamma curve they're raving about isn't as radical as S-log though it seems the same issues would pertain.

If anyone has the time though I don't quite understand how people describe different gammas as distributing more or less pixels to shadows or highlights. My non engineer assumption would just be that pixels are assigned equally as light values - i.e. in 8 bit there being 240 shades and one pixel per step. Gamma curves & codecs don't change that relationship do they? I assume they just change where on the curve the exposure lies.

I've had a colorist tell me once he would rather work with DSLR footage that was bright (not overexposed though) because he had more pixels to work with and it was easier to grade, even if he was making darker eventually. Perhaps he just meant there would be a wider range from black to white if he had full exposure but he didn't describe it that way. ( He was grading in 10 bit BTW)

Why is S-log described by many as giving more pixels to the shadow area? Is that just because the curve is flat and most Log curves don't give as much exposure to shadow areas - hence fewer steps. So is more pixels the same as more steps? That would imply that an ordinary Rec 709 curve is putting most steps /pixels in the midrange right?

Last question. When Alister talked about transcoding from 8 to 10bit - is that what happens in Final Cut when we choose "render in High precision 10 bit" for a timeline?

Thanks - Hope that isn't to convoluted.

[Alister Chapman]

Leonard: That's pretty easy to explain please take a look at the attached graph. It easier to look at the graph than me try to explain it. The graph is not accurate, I just threw it together to explain the principle. Its the way the curve becomes flatter that alters the data distribution. A standard gamma curve by comparison could be considered as a near straight line.

[Alister Chapman]

Piotr. If you render 8 bit using just 8 bits for your calculations then the accuracy is restricted by the amount of data bits available for calculations. ie 256 and the size of each step. When you use 32 bit then there is plenty of headroom for large calculations and the calculations are more accurate due to the smaller steps so less rounding is required. This is a big help when doing multiple calculations in one pass, perhaps because you have applied several filters at the same time.