Levels: highlight cut off

[anton_foy]

Hello,

I do not understand why is this: Levels(0, 1, 65280, 0, 65280, coring=false, dither=false)
is cutting off my highlights?

http://www.imagebam.com/image/7cf4ca1355130247

If I use this line Levels(0, 1, 65280, 0, 235*256, coring=false, dither=false) it keeps the highlight intact
http://www.imagebam.com/image/6309cc1355130248
but do I really need to do this to not loose my highlight information? I want to keep as much information as possible.

Thanks!

[poisondeathray]

It's cut off by the limited range RGB conversion. The Y values are still there , you just don't "see" them in an RGB image

235*256 = 60160

In the 1st image, for 16bit values you have bright cloud values in the Y=60160-65280 range. (This is analogous to Y 235-255 in 8bit values when converted to RGB for display using limited range, they get clipped by the RGB conversion)

The 2nd example with levels depresses the output high to 60160 (analgous to 235 in 8bit) before the RGB conversion, so those values are not clipped, but the whole waveform is compressed from the top, so entire image is darker. This applies range compression from the top (squishes the waveform)

[anton_foy]

@poisondeathray
Thanks so what would you suggest would be the best option to keep the info in the image as much as possible?

[Cary Knoop]

@poisondeathray
Thanks so what would you suggest would be the best option to keep the info in the image as much as possible?
Use float32 for processing.

But the more interesting question is why do you think you need to use the Levels function in the first place?

Also, out of curiosity what lens are you using?

[poisondeathray]

@poisondeathray
Thanks so what would you suggest would be the best option to keep the info in the image as much as possible?

Depends on what you want to do with it, and/ or how it's going to be viewed

If you're keeping it as limited range video, then definitely bring the "superbrights" down. But just compressing the highlights darkens the image. But maybe that's the look you're going for. Maybe not. Maybe you want to bring midtones up a bit . You have more control in other programs such as resolve or NLE's

[anton_foy]

Use float32 for processing.

But the more interesting question is why do you think you need to use the Levels function in the first place?

Also, out of curiosity what lens are you using?

Thanks, I will try to do the processing in 32 bit float (although I would suspect my computer cannot handle it until I upgrade as even in 16 bit my export crashes due to "out of memory").

Regarding levels, if I do not use it at all I get blown out highlights and the only solution I could come up with was this:
Levels(0, 1, 65280, 0, 235*256, coring=false, dither=false)

The lens is a Tamron 10-24mm f/3.5-4.5. Not so sharp but nice for the wide angles. In this test clip the focus is off tho.

[anton_foy]

Depends on what you want to do with it, and/ or how it's going to be viewed

If you're keeping it as limited range video, then definitely bring the "superbrights" down. But just compressing the highlights darkens the image. But maybe that's the look you're going for. Maybe not. Maybe you want to bring midtones up a bit . You have more control in other programs such as resolve or NLE's

Thanks, the look does not matter too much (it is in Slog2) since I will be color grading it in Resolve and I want to keep as much info as possible when it gets imported into that. But if I keep it as limited range video it will have "unused" margins (16*256 steps up for black and 20*256 steps down for white) right?

[Cary Knoop]

Regarding levels, if I do not use it at all I get blown out highlights and the only solution I could come up with was this:
Levels(0, 1, 65280, 0, 235*256, coring=false, dither=false)

That's odd.

I can take a look at things if you provide an out of camera clip compared to your results after processing.


The lens is a Tamron 10-24mm f/3.5-4.5. Not so sharp but nice for the wide angles. In this test clip the focus is off tho.
Quite a heavy chromatic aberration at the edges.

[anton_foy]

That's odd.

I can take a look at things if you provide an out of camera clip compared to your results after processing.


Quite a heavy chromatic aberration at the edges.

Thanks! I did another test and found out that when I import the frames in Photoshop the highlights are lost / blown out but I found that when I import the processed clip into Davinci Resolve and change levels from "auto" to "full" under "Clip attributes" the highlights are back. So Resolve interprets the clip incorrectly and I have to manually set this on each clip I import. Well that solved it. No more need to use Levels.

Yes it is quite some chromatic aberration on this one but I like the lens in some situations :)

Here are the clips:
https://we.tl/t-nWFpkdzzCT

[Cary Knoop]

So Resolve interprets the clip incorrectly and I have to manually set this on each clip I import.
Not necessarily.

Resolve loads video levels by placing the visible range between 0.0 and 1.0 float32.
If the clip has WTW, you can pull it in using highlight roll off, as Resolve never clips.

As a matter of fact Resolve interprets your sheep clip as full, not even the transients go out of range even when I interpret the clip under video levels, so I do not understand how you observe any clipping.

Assuming the clip was recorded Rec709 the video is underexposed and the temperature is a bit on the cold side.

The other clip is also full range and interpreted correctly by Resolve. This clip is overexposed, and you have blown out highlights that cannot be recovered.

Check the camera options because for Rec709 videos you should really use video levels.

[anton_foy]

@Cary Knoop

As a matter of fact Resolve interprets your sheep clip as full, not even the transients go out of range even when I interpret the clip under video levels, so I do not understand how you observe any clipping.
I meant the processed clip not the original ones. But good then I can just pull it back either way then.

[Cary Knoop]

@Cary Knoop


I meant the processed clip not the original ones. But good then I can just pull it back either way then.
Unfortunately, there is really nothing to pull back on either clip.

[anton_foy]

Unfortunately, there is really nothing to pull back on either clip.

I think you misunderstood. Did you watch the images I uploaded? In one of them the highlights are more blown out and the other is not as much. So when I switched to levels "full" in Clip Attributes in Resolve I did not have that problem anymore. So that is what I meant by "pull back".

[Cary Knoop]

I think you misunderstood. Did you watch the images I uploaded? In one of them the highlights are more blown out and the other is not as much. So when I switched to levels "full" in Clip Attributes in Resolve I did not have that problem anymore. So that is what I meant by "pull back".
We seem to have a misunderstanding, the sheep clip is underexposed and there are no blown-out highlights while the test clip is overexposed, no processing will be able to recover those.

[anton_foy]

We seem to have a misunderstanding, the sheep clip is underexposed and there are no blown-out highlights while the test clip is overexposed, no processing will be able to recover those.

Yes they are underexposed and overexposed, out of focus and not correct white balanced etc. hence "test clips". But I used them not to impress you but for the purpose to demonstrate my problem with "clipped highlight" (the castle clip anyway) that is caused by how Resolve displays the clip depending on if full, video or auto settings on levels. Now it is working and I am happy :)

[Cary Knoop]

You are missing the point, the point is that the test clip is clipped beyond repair:

https://www.dropbox.com/s/nhb2136xthuymze/clipped.jpg

It is not a full versus video levels issue.

[WorBry]

Also checked out the clips in Resolve and agree with Cary - the 'test' clip is full range and over-exposed i.e. when brought into Resolve at 'Full' data levels the highlights are clipped - there is no latitude for 'highlight pull-down'.

You could have a go at softening the margins of the clipped patches of sky with a qualifier mask, but I think I'd be more inclined to import the clip at 'Video' levels, darken it with a Layer Node and 'Multiply' composite blend ('opacity' = Key Output Gain around 0.30 to 0.35) and apply a Soft Clip with the Curves Tool (H.S around 39) to bring the clipped highlights just into range. Maybe add some Mid-Tone Detail and adjust Saturation to taste.

[anton_foy]

You are missing the point, the point is that the test clip is clipped beyond repair:

https://www.dropbox.com/s/nhb2136xthuymze/clipped.jpg

It is not a full versus video levels issue.

...once again, I know it is clipped beyond repair, it is white totally in some places in the castle clip BUT that is NOT the point. Look at the first images I uploaded and compare them side by side. Then you will see that one is more blown out the other and that is the same exact frame, that was the POINT of this thread of how to process without clipping even more.
I could use a non blown out highlights to demonstrate the problem but that would not make much sense since there are not enough brights in the image.

http://www.imagebam.com/image/7cf4ca1355130247
http://www.imagebam.com/image/6309cc1355130248

[anton_foy]

Also checked out the clips in Resolve and agree with Cary - the 'test' clip is full range and over-exposed i.e. when brought into Resolve at 'Full' data levels the highlights are clipped - there is no latitude for 'highlight pull-down'.

You could have a go at softening the margins of the clipped patches of sky with a qualifier mask, but I think I'd be more inclined to import the clip at 'Video' levels, darken it with a Layer Node and 'Multiply' composite blend ('opacity' = Key Output Gain around 0.30 to 0.35) and apply a Soft Clip with the Curves Tool (H.S around 39) to bring the clipped highlights just into range. Maybe add some Mid-Tone Detail and adjust Saturation to taste.

Thanks yes as I explained in my earlier post I am not interested in highlight "pull down" or "roll off". This is just a test clip showing the difference that was bothering me and (see previous or first post for image comparison) between different settings (levels) on the same frame. The solution for me was to remove the levels line in my avs-script and use "full" levels in Resolve and the blown out highlights were no more double blown out.

Poisondeathray

It's cut off by the limited range RGB conversion. The Y values are still there , you just don't "see" them in an RGB image
he replied this and that was the answer, I just did not know how to make it visible again until now.

[Cary Knoop]

And again, I would update the camera settings to use video levels for Rec709 instead of full levels.

[age]

These test clips are slog2 and not rec709, full range is the correct encoding level for slog2.

[Cary Knoop]

These test clips are slog2 and not rec709, full range is the correct encoding level for slog2.
If they are slog2 then the poster should refrain from using most of the avisynth/vapoursynth filters unless he converts it first to Rec709 or (in some cases) linear.

I checked with Resolve and you a probably right, it is slog2, not sure what to think of the gamut, using S-Gamut I get problems with the colors in the blue and red.
I don't know this camera does it support slog2 using a Rec709 gamut, similar to the V-Log-L in Panasonic using a Rec709 instead of a V-Gamut?

But the highlight roll-off on the castle clip definitely works better if we interpret the clip as slog2:

https://www.dropbox.com/s/oi0h7nhp126iu1o/castle_1.2.1.jpg?dl=0

But notice the exaggerated red and blue on the edges.
The lens does have a lot of natural chromatic abberation but those colors are not natural.
It's definitly not a normal S-gamut.

[anton_foy]

If they are slog2 then you should refrain from using most of the avisynth/vapoursynth filters unless you convert it first to Rec709 or (in some cases) linear.

Because of the logarithmic distribution in Slog2? Do you mean that the washed out image of Slog2 is not good for filtering in Avisynth/Vapoursynth?

[anton_foy]

These test clips are slog2 and not rec709, full range is the correct encoding level for slog2.

Thanks, yes that was what I thought too.

[Cary Knoop]

Because of the logarithmic distribution in Slog2? Do you mean that the washed out image of Slog2 is not good for filtering in Avisynth/Vapoursynth?
Let's make the question broader, since you are using Resolve what exactly do you need Avisynth for?

[anton_foy]

These test clips are slog2 and not rec709, full range is the correct encoding level for slog2.

Let's make the question broader, since you are using Resolve what exactly do you need Avisynth for?

Simple, denoising, clean up chroma, sharpening and various other filters of my own concoction. Denoising and cleaning the chroma to be able to use certain 3d Luts. If I do not clean it up I cannot possibly use these Lookup tables, too much noise and blockiness/compression artifacts. It works very well now and I just have to tweak and make the scripts more efficient.

[FranceBB]

Hi there.
I'm the one who "helped" Anton with the script last time, so I kinda wanted to jump in the topic.
I took a look at the sample and they're indeed in Slog2.
Since it's a logarithmic curve, the camera is gonna try to retain as many stops / nits as possible from the sensor, therefore it will be flagged as Full Range.
The Rec.709 value can be easily ignored as I've received tons of "fake" BT709 files which were indeed in Slog2.
Namely, highlights and other things are gonna be in the middle of the waveform if you look at it using a Waveform Monitor, same goes for blacks which are pushed up a lot in the middle.
The reason for that is to keep as many nits as possible without clipping both the low values (the ones in the black) and the high values (the ones in the white).
Of course, recording in Log doesn't mean you're not gonna clip anyway, but that's actually different from how we think about clipping in a normal waveform.
Since the logarithmic curve is generally enough to map everything the sensors receives, if a sensor doesn't have enough stops / nits, it will end up with "clipped" values even if they're in the middle of the waveform and NOT at the very high end of it.
If we take a look at the clip uploaded you can clearly see that the Slog2 curve still has some room spare, but the sensor doesn't have enough stops / nits to fill it:

https://i.imgur.com/WKGWrRn.png

Therefore, you end up with clipped values.
It would be much more pronounced with Slog3, but Anton actually used Slog2 which is much more closer to the capability of the sensor of its Sony camera.
Now, if we were to apply a matrix of linear transformation to bring it to Linear BT709 SDR 100 nits, we would get something like:

https://i.imgur.com/fOibxjJ.png

As you can see, highlights have been completely cut off; this is because the Linear BT709 SDR 100 nits can only handle... well... 100 nits, therefore all the high values that were captured in Slog2 have been cut off.
Playing around a bit with it, we can lower the high values so that our reference white peak in the Slog2 given by the 10.6 stops (roughly speaking 400 nits) it's gonna be mapped to our Linear BT709 Peak of 100 nits.
If we do that, what we would get is:

https://i.imgur.com/YVJw0WO.png

which is a much better representation of our input signal.


Now, up to the Anton question about Avisynth.
Although Avisynth doesn't understand different color curves like Slog, Slog2, Slog3, Clog, Log-C, F-Log, HLG, PQ etc, it also handles them as long as you know what you're doing.
For instance, in the case of Anton, he's asking help for post-processing the input in Avisynth so that it can denoise it and deband it in order then to apply a custom made matrix of linear transformation in his favorite Non Linear Editor.
In this case, it does actually make sense to use Avisynth to filter out those things and give a much better result to the non linear editor.
Why does he need this in the first place, you might ask.
Well, Sony did a terrible job on NOT allowing many cameras to actually shoot in 10bit, therefore pretty much everything coming out of Sony shoots in H.264 8bit.
This would be fine if someone was going to shoot in BT709 SDR in Limited TV Range, however it would have been a waste to allow users only to shoot like this, given that many of the sensors of these cameras are actually pretty good; for instance, if I recall correctly the Sony A7 III has a 15 stops sensors which can get roughly 680-700 nits, which is much more than the standard 100 nits allowed by BT709 SDR.
So, Sony allowed users to shoot in Slog, Slog2, Slog3 and even HLG so that they could either go to HDR or use a matrix of linear transformation to go to SDR in a more pleasant way (like I did in the second example; i.e if he was going to record in BT709 in the first place, everything would have been clipped out). This may sound good, but it creates a lot of issues, 'cause 8bit are definitely NOT enough for those enormous color curves to be properly represented, even if Sony engineers tried to make use of all the 0-255 values available. Unfortunately, we have to live with this, so performing some kind of 16bit planar post-processing comes in handy.



A few side notes:
1) those comparisons were made for the sake of illustrations, however I gotta say that matrices of linear transformation can be applied inside Avisynth as well (https://forum.doom9.org/showthread.php?t=176091), so one could use Davinci Resolve as a reference by linking the clip and then use Avisynth to apply the custom-made matrix as well.
2) I generally suggest people to shoot underexposed when they're working in Log with a camera that doesn't have many stops / nits. This is because I personally find noise in the low values much more pleasant than completely clipped out high values, provided that they're shooting landscapes and that there aren't people in the footage, otherwise we're gonna have to sacrifice something anyway...
3) Shame on you Sony... Shame on you... Even the Sony A7 III used by one of my colleagues is limited to 8bit only... I mean, HLG and Slog3 in 8bit? It's not even officially supported by the documents defining the HDR standard, what were you thinking...?! Shame on you Sony, shame on you...

[Cary Knoop]

I generally suggest people to shoot underexposed when they're working in Log with a camera that doesn't have many stops / nits. This is because I personally find noise in the low values much more pleasant than completely clipped out high values, provided that they're shooting landscapes and that there aren't people in the footage, otherwise we're gonna have to sacrifice something anyway...

My suggestion is to expose just right, especially when you shoot log.

I would not use log when you only have 8-bits, just stick to Rec709.

The new Sony A7s III however uses 10-bit 4:2:2 and is a very decent camera that handles log just fine.

[anton_foy]

Hi there.
I'm the one who "helped" Anton with the script last time, so I kinda wanted to jump in the topic.
I took a look at the sample and they're indeed in Slog2.
Since it's a logarithmic curve, the camera is gonna try to retain as many stops / nits as possible from the sensor, therefore it will be flagged as Full Range.
The Rec.709 value can be easily ignored as I've received tons of "fake" BT709 files which were indeed in Slog2.
Namely, highlights and other things are gonna be in the middle of the waveform if you look at it using a Waveform Monitor, same goes for blacks which are pushed up a lot in the middle.
The reason for that is to keep as many nits as possible without clipping both the low values (the ones in the black) and the high values (the ones in the white).
Of course, recording in Log doesn't mean you're not gonna clip anyway, but that's actually different from how we think about clipping in a normal waveform.
Since the logarithmic curve is generally enough to map everything the sensors receives, if a sensor doesn't have enough stops / nits, it will end up with "clipped" values even if they're in the middle of the waveform and NOT at the very high end of it.
If we take a look at the clip uploaded you can clearly see that the Slog2 curve still has some room spare, but the sensor doesn't have enough stops / nits to fill it:

https://i.imgur.com/WKGWrRn.png

Therefore, you end up with clipped values.
It would be much more pronounced with Slog3, but Anton actually used Slog2 which is much more closer to the capability of the sensor of its Sony camera.
Now, if we were to apply a matrix of linear transformation to bring it to Linear BT709 SDR 100 nits, we would get something like:

https://i.imgur.com/fOibxjJ.png

As you can see, highlights have been completely cut off; this is because the Linear BT709 SDR 100 nits can only handle... well... 100 nits, therefore all the high values that were captured in Slog2 have been cut off.
Playing around a bit with it, we can lower the high values so that our reference white peak in the Slog2 given by the 10.6 stops (roughly speaking 400 nits) it's gonna be mapped to our Linear BT709 Peak of 100 nits.
If we do that, what we would get is:

https://i.imgur.com/YVJw0WO.png

which is a much better representation of our input signal.


Now, up to the Anton question about Avisynth.
Although Avisynth doesn't understand different color curves like Slog, Slog2, Slog3, Clog, Log-C, F-Log, HLG, PQ etc, it also handles them as long as you know what you're doing.
For instance, in the case of Anton, he's asking help for post-processing the input in Avisynth so that it can denoise it and deband it in order then to apply a custom made matrix of linear transformation in his favorite Non Linear Editor.
In this case, it does actually make sense to use Avisynth to filter out those things and give a much better result to the non linear editor.
Why does he need this in the first place, you might ask.
Well, Sony did a terrible job on NOT allowing many cameras to actually shoot in 10bit, therefore pretty much everything coming out of Sony shoots in H.264 8bit.
This would be fine if someone was going to shoot in BT709 SDR in Limited TV Range, however it would have been a waste to allow users only to shoot like this, given that many of the sensors of these cameras are actually pretty good; for instance, if I recall correctly the Sony A7 III has a 15 stops sensors which can get roughly 680-700 nits, which is much more than the standard 100 nits allowed by BT709 SDR.
So, Sony allowed users to shoot in Slog, Slog2, Slog3 and even HLG so that they could either go to HDR or use a matrix of linear transformation to go to SDR in a more pleasant way (like I did in the second example; i.e if he was going to record in BT709 in the first place, everything would have been clipped out). This may sound good, but it creates a lot of issues, 'cause 8bit are definitely NOT enough for those enormous color curves to be properly represented, even if Sony engineers tried to make use of all the 0-255 values available. Unfortunately, we have to live with this, so performing some kind of 16bit planar post-processing comes in handy.



A few side notes:
1) those comparisons were made for the sake of illustrations, however I gotta say that matrices of linear transformation can be applied inside Avisynth as well (https://forum.doom9.org/showthread.php?t=176091), so one could use Davinci Resolve as a reference by linking the clip and then use Avisynth to apply the custom-made matrix as well.
2) I generally suggest people to shoot underexposed when they're working in Log with a camera that doesn't have many stops / nits. This is because I personally find noise in the low values much more pleasant than completely clipped out high values, provided that they're shooting landscapes and that there aren't people in the footage, otherwise we're gonna have to sacrifice something anyway...
3) Shame on you Sony... Shame on you... Even the Sony A7 III used by one of my colleagues is limited to 8bit only... I mean, HLG and Slog3 in 8bit? It's not even officially supported by the documents defining the HDR standard, what were you thinking...?! Shame on you Sony, shame on you...

Thank you FranceBB! Looking nice! Very thorough and good explanation. I agree with you and I usually underexpose somewhat to keep away from too blown out highlights. And shame on Sony for the Slog3 in 8 bit, its just unusable. I made a quick grade in Resolve after being processed in Avisynth+ and also I did a little dirty trick. I "regained" highlight information with some lines I put together the other day :D

Here is the result:
http://www.imagebam.com/image/d2d26d1355240829

[FranceBB]

M
The new Sony A7s III however uses 10-bit 4:2:2 and is a very decent camera that handles log just fine.

Finally a good news. :)

I made a quick grade in Resolve after being processed in Avisynth+ and also I did a little dirty trick. I "regained" highlight information with some lines I put together the other day :D

Here is the result:
http://www.imagebam.com/image/d2d26d1355240829

Looks good. ;)

[anton_foy]

Finally a good news. :)



Looks good. ;)

Thank you :) These lines was used to regain the blown out highlights:


### UNBLOW ###
Levels(0, 1, 65280, 0, 235*256, coring=false, dither=false)
clip1 = last
clipB = converttorgb24().chanmix(r=0.0, g=0.0, b=1.0)
clipR = converttorgb24().chanmix(r=1.0, g=0.0, b=0.0)
clipG = converttorgb24().chanmix(r=0.0, g=1.0, b=0.0)
RBD = clipB.Overlay(clipR, mode="darken", opacity=1.0)
GRD = RBD.blur(1.58).blur(1.58).blur(1.58).blur(1.58).blur(1.58).blur(1.58).blur(1.58).blur(1.58).Overlay(clipG, mode="darken", opacity=1.0).converttoyuv444().convertbits(16)
umask = mt_binarize(threshold=220*256, paramscale="i16").mt_expand().fastgaussblur(64)
mt_merge(clip1, GRD, umask, Y=3, U=2, V=2, chroma="copy first", w=-1, h=-1)
Levels(0, 1, 65280, 0, 275*256, coring=false, dither=false)

Very ugly I know but it does the job in some cases.