S-Log for Canon why not for SxS? at DVinfo.net
DV Info Net

Go Back   DV Info Net > Sony XAVC / XDCAM / NXCAM / AVCHD / HDV / DV Camera Systems > Sony Digital Cinema Camera Systems > Sony XDCAM PMW-F3 CineAlta

Sony XDCAM PMW-F3 CineAlta
HD recording with a Super35 CMOS Sensor.

Reply
 
Thread Tools Search this Thread
Old May 8th, 2011, 01:39 AM   #1
Trustee
 
Join Date: Feb 2006
Location: USA
Posts: 1,684
S-Log for Canon why not for SxS?

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.
Leonard Levy is offline   Reply With Quote
Old May 8th, 2011, 02:10 AM   #2
Inner Circle
 
Join Date: Feb 2006
Location: Belfast, UK
Posts: 6,151
Re: S-Log for Canon why not for SxS?

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

HDSLR Color Grading ? Before or After
Brian Drysdale is offline   Reply With Quote
Old May 8th, 2011, 02:48 AM   #3
Major Player
 
Join Date: Jun 2008
Location: melb.vic.au
Posts: 447
Re: S-Log for Canon why not for SxS?

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

It says this-

Quote:
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.
__________________
www.davidwilliams.com.au
David C. Williams is offline   Reply With Quote
Old May 8th, 2011, 05:54 AM   #4
Trustee
 
Join Date: Mar 2007
Location: Sherman Oaks, CA
Posts: 1,259
Re: S-Log for Canon why not for SxS?

Quote:
Originally Posted by Brian Drysdale View Post
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.
__________________
Avid Media Composer 3.1.3. Boris Red and Continuum Complete. Vegas 8.0c. TMPGEnc Xpress Pro 4.0
Peter Moretti is offline   Reply With Quote
Old May 8th, 2011, 06:32 PM   #5
Regular Crew
 
Join Date: Dec 2006
Location: New York City
Posts: 120
Re: S-Log for Canon why not for SxS?

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.
__________________
Director of Photography - www.timurcivan.com
Sony F3, Cooke lenses, sunny disposition.
Timur Civan is offline   Reply With Quote
Old May 9th, 2011, 02:05 AM   #6
Inner Circle
 
Join Date: Dec 2005
Location: Bracknell, Berkshire, UK
Posts: 4,957
Re: S-Log for Canon why not for SxS?

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.
__________________
Alister Chapman, Film-Maker/Stormchaser http://www.xdcam-user.com/alisters-blog/ My XDCAM site and blog. http://www.hurricane-rig.com
Alister Chapman is offline   Reply With Quote
Old May 9th, 2011, 02:58 AM   #7
Trustee
 
Join Date: Mar 2007
Location: Sherman Oaks, CA
Posts: 1,259
Re: S-Log for Canon why not for SxS?

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.)
__________________
Avid Media Composer 3.1.3. Boris Red and Continuum Complete. Vegas 8.0c. TMPGEnc Xpress Pro 4.0

Last edited by Peter Moretti; May 9th, 2011 at 04:21 AM.
Peter Moretti is offline   Reply With Quote
Old May 9th, 2011, 04:18 AM   #8
Inner Circle
 
Join Date: Dec 2005
Location: Bracknell, Berkshire, UK
Posts: 4,957
Re: S-Log for Canon why not for SxS?

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!
__________________
Alister Chapman, Film-Maker/Stormchaser http://www.xdcam-user.com/alisters-blog/ My XDCAM site and blog. http://www.hurricane-rig.com
Alister Chapman is offline   Reply With Quote
Old May 9th, 2011, 08:09 AM   #9
Inner Circle
 
Join Date: Aug 2006
Location: Poland
Posts: 4,086
Re: S-Log for Canon why not for SxS?

Quote:
Originally Posted by Alister Chapman View Post
. 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
__________________
Sony PXW-FS7 | DaVinci Resolve Studio; Magix Vegas Pro; i7-5960X CPU; 64 GB RAM; 2x GTX 1080 8GB GPU; Decklink 4K Extreme 12G; 4x 3TB WD Black in RAID 0; 1TB M.2 NVMe cache drive
Piotr Wozniacki is offline   Reply With Quote
Old May 9th, 2011, 08:16 AM   #10
Major Player
 
Join Date: Sep 2008
Location: Vancouver, Canada
Posts: 975
Re: S-Log for Canon why not for SxS?

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.
Andrew Stone is offline   Reply With Quote
Old May 9th, 2011, 09:46 AM   #11
Inner Circle
 
Join Date: Dec 2005
Location: Bracknell, Berkshire, UK
Posts: 4,957
Re: S-Log for Canon why not for SxS?

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.
__________________
Alister Chapman, Film-Maker/Stormchaser http://www.xdcam-user.com/alisters-blog/ My XDCAM site and blog. http://www.hurricane-rig.com
Alister Chapman is offline   Reply With Quote
Old May 9th, 2011, 09:52 AM   #12
Inner Circle
 
Join Date: Aug 2006
Location: Poland
Posts: 4,086
Re: S-Log for Canon why not for SxS?

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
__________________
Sony PXW-FS7 | DaVinci Resolve Studio; Magix Vegas Pro; i7-5960X CPU; 64 GB RAM; 2x GTX 1080 8GB GPU; Decklink 4K Extreme 12G; 4x 3TB WD Black in RAID 0; 1TB M.2 NVMe cache drive
Piotr Wozniacki is offline   Reply With Quote
Old May 9th, 2011, 12:11 PM   #13
Trustee
 
Join Date: Feb 2006
Location: USA
Posts: 1,684
Re: S-Log for Canon why not for SxS?

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.
Leonard Levy is offline   Reply With Quote
Old May 9th, 2011, 12:45 PM   #14
Inner Circle
 
Join Date: Dec 2005
Location: Bracknell, Berkshire, UK
Posts: 4,957
Re: S-Log for Canon why not for SxS?

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.
Attached Thumbnails
S-Log for Canon why not for SxS?-s-log-data-curve.jpg  
__________________
Alister Chapman, Film-Maker/Stormchaser http://www.xdcam-user.com/alisters-blog/ My XDCAM site and blog. http://www.hurricane-rig.com
Alister Chapman is offline   Reply With Quote
Old May 9th, 2011, 01:08 PM   #15
Inner Circle
 
Join Date: Dec 2005
Location: Bracknell, Berkshire, UK
Posts: 4,957
Re: S-Log for Canon why not for SxS?

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.
__________________
Alister Chapman, Film-Maker/Stormchaser http://www.xdcam-user.com/alisters-blog/ My XDCAM site and blog. http://www.hurricane-rig.com
Alister Chapman is offline   Reply
Reply

DV Info Net refers all where-to-buy and where-to-rent questions exclusively to these trusted full line dealers and rental houses...

B&H Photo Video
(866) 521-7381
New York, NY USA

Scan Computers Int. Ltd.
+44 0871-472-4747
Bolton, Lancashire UK


DV Info Net also encourages you to support local businesses and buy from an authorized dealer in your neighborhood.
  You are here: DV Info Net > Sony XAVC / XDCAM / NXCAM / AVCHD / HDV / DV Camera Systems > Sony Digital Cinema Camera Systems > Sony XDCAM PMW-F3 CineAlta

Thread Tools Search this Thread
Search this Thread:

Advanced Search

 



All times are GMT -6. The time now is 07:20 PM.


DV Info Net -- Real Names, Real People, Real Info!
1998-2024 The Digital Video Information Network