Tag Archives: clipping

cinematography, Shooting Tips

Log and Raw Don’t have highlight a highlight roll off.

3 Comments

This just keeps coming up over and over. Almost all log gamma curves and the majority of raw recording formats don’t have a highlight roll-off. Any roll off that you might see is probably in the LUT’s that you are using.

The whole point of log and raw is to capture as much information about the scene that you are shooing as you can. Log normally achieves this by recording every stop above middle grey with a constant amount of data, so even the very brightest stop has the same amount of recording data as the ones below it – there is no roll off.

In conventional limited range recordings such as Rec-709, hypergamma, cinegamma etc, highlight roll-offs work by reducing the contrast in the highlights to make the amount of data needed to record the very brightest stops much smaller than used for the rest of the image. This allows 2 or 3 stops to be squeezed into a very small recording range, keeping most of the recording data available for a nice bright high contrast image. The reduction in contrast in the extreme highlights helps hide any highlight handling problems and makes it appear as though the sensors clipping point is reach in a more pleasing soft manner.

But you don’t want this in a log or raw recording as it makes grading much harder as the footage will contain different contrast ranges, each needing it’s own grading adjustments. Also by reducing contrast in the highlights you are reducing the data. It would be very difficult to un-pick a highlight roll off and if you did want to expand the data back out you will get issues such as banding.

Chart showing S-Log2 and S-Log3 plotted against f-stops and code values. Note how little data there is for each of the darker stops, the best data is above middle grey and there is no highlight roll-off. Note that current sensor only go to +6 stops over middle grey so S-Log2 and S-Log record to different peak levels.

S-Log2 and S-Log3 like almost all log gammas have no highlight roll-off. The only roll off is from middle grey and down. So if you underexpose you will start to roll away the data in your scenes mid range and that’s not good. Expose for the mid range, this is the most important part of any image. If your highlights are a bit clipped don’t worry about this too much. In post production you can add a roll off in the grade that will make any clipped highlights roll away gently. Adding a bit of highlight diffusion in post will also nicely mask any clipped highlights and make them look natural.

Uncategorized

Convergent Design Gemini throws up a ProRes Issue. NOT THE PROBLEM I THOUGHT IT IS

4 Comments

OK, I wrote about this without digging deep enough. If you read the original article I claimed that ProRes was clipping my files at 104%. Well it’s NOT. The ProRes files are just fine, BUT some Quick Time applications are clipping the files at playback. In FCP the files are OK. Premiere appears to be reducing the level of the files a little and Quick Time player is clipping the files at approx 104. So this isn’t as big an issue as I thought, but you do need to keep an eye out as to what is happening with highlights and super whites depending on what software you are using. I was wondering why I hadn’t seen this before. In part it because I am no longer using FCP.

Uncategorized

Whites, Super Whites and other Bits and bobs.

2 Comments

Do you know how your NLE is handling your video, are you whites white or whiter than white or does this sound like a washing powder add?

In the analog world you shot within the legal range of black to 100% white. It was simple, easy to understand and pretty straight forward. White was white at 100% and that was that. With digital video it all gets a lot more complicated, especially as we now start to move to greater and greater bit depths and the use of extended range recording with fancy gamma curves becomes more common. In addition computers get used more and more for not just editing but also as the final viewing device for many videos and this brings additional issues of it’s own.

First lets look at some key numbers:

8 bit data gives you 256 possible values 0 to 255.

10 bit data gives you 1024 possible values, 0 to 1023.

Computers use bit 0 to represent black and bit 255 or 1023 to represent peak white.

But video is quite different and this is where things get messy:

With 8 bit video the first 16 bits are used for sync and other data. Zero or black is always bit 16 and peak white or 100% white is always bit 235, so the traditional legal black to white range is 16 to 235, only 219 bits of data. Now in order to get a better looking image with more recording range many cameras take advantage of the bits above 235. Anything above 235 is “super white” or whiter than white in video terms, more than 100%. Cinegammas and Hypergammas take advantage of this extra range, but it’s not without it’s issues, there’s no free lunch.

10 bit video normally uses bit 64 as black and 940 as peak white. With SMPTE 10-bit extended range you can go down to bit 4 for undershoot 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 super white.

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 as the computer will take the 100% video range (16-235) and convert it to the 100% computer RGB range (0-255). So you run the risk of loosing your super whites altogether. Encoding to another codec can also lead to clipping. FCP and most NLE’s will display super blacks and super whites as these fall within the full 8 or 10 bit ranges used by computer graphics, but further encoding can be problematic as you can’t always be sure whether the conversion will use the full recorded range or just the black to white range. 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. So as we can see it’s important to be sure that your workflow is not truncating or clipping your recorded range back to the nominal legal or 100% range.

On the other hand if you are doing stuff  where the full 0 to 255 (1023) are used then you often need to use the illegal video levels above 100% 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 Alexa HDSDi output will output extended range.

This is also an issues when using computer monitors for monitoring in the edit suite. When you look at this web page or any computer graphics white is set at bit 255 or 1023 (a lot will depend on the gamma that the monitor is set to). 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, clipping, or smply an image that does not look right on a TV or video monitor. You really need to be very careful to ensure that if you shoot using extended range that your workflow keeps that extended range intact and then you need to remember to legalise you video back to within legal range if it’s going to be broadcast.