Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
I confess I don't fully understand it Sam
I did a test scene a while back and tested slog3 slog2, logC, arriraw, 8K red helium and a few more.
My conclusion was that while I could get colors into a very similar starting point between slog2 and 3, and that slog2 had slightly nicer highlights, the difference in end result was not worth making a workflow more complicated. Slog3 looks better (in my eyes) straight away after conversion LUTs (I tried about 5 different LUTs in three different EI values, +0, +2, -2) where slog2 need manual tweaking for skin, saturation etc. Best results was with going from sgamut to sgamut3.cine and then grading or another LUT but the internal codec does not always take dual LUTs with grace.
Basicly my experience is in line with Grug.
Completely. If you looked at the chart sony issued you would expect that from the off.
Slog2 chunky highlights, narrow DR, odd to grade
Slog3 just all a bit more in the middle.
S
That's not correct. Skin tones look bad in the knee because the effective OOTF with the knee applied is shifting hues, as well as reducing contrast and saturation. Skin tones shift towards green, which doesn't look good.(You will know that sony 'knee' in old school profiles gives odd highlights and ruins skin tone if you expose skin in the 'knee' zone.. this is because the knee zone is not allocating many data points to a stop of light.. which looks odd)
The camera manufacturers all provide specification of their camera log curves. If you know how to interpret that specification, you know how to properly de-log the footage.The chance of Joe the Nerd coming up with a proper de-logging LUT is almost zero
What you've exposed is differences between the LUTs you tried, not differences between S-Log2 and S-Log3. The only difference in the highlights between S-Log2 and S-Log3 is how they're represented in each of those color spaces. The underlying image is the same. If you want to prove that to yourself, go to LUTCalc and make LUTs that convert between S-Log2 and S-Log3. Shoot S-Log3, convert it to S-Log2, and process it like you would any other S-Log2 footage. You'll see that it behaves like any other S-Log2 footage. (or do the reverse, shooting S-Log2 and convert to S-Log3)I did a test scene a while back and tested slog3 slog2, logC, arriraw, 8K red helium and a few more.
My conclusion was that while I could get colors into a very similar starting point between slog2 and 3, and that slog2 had slightly nicer highlights, the difference in end result was not worth making a workflow more complicated. Slog3 looks better (in my eyes) straight away after conversion LUTs (I tried about 5 different LUTs in three different EI values, +0, +2, -2) where slog2 need manual tweaking for skin, saturation etc. Best results was with going from sgamut to sgamut3.cine and then grading or another LUT but the internal codec does not always take dual LUTs with grace.
That's not correct. Skin tones look bad in the knee because the effective OOTF with the knee applied is shifting hues, as well as reducing contrast and saturation. Skin tones shift towards green, which doesn't look good.
If you're not grading for theatrical projection, save yourself the trouble and use a color managed workflow with support for your camera's color space. When you do that, the differences between S-Log2 and S-Log3 practically disappear.
Possibly too but if this was true then you would not see the effect of the knee in black and white images but you clearly see it. This is not about color primarily. While I know what Sam means I agree that it's not necessarily about data levels either because in analog video this was equally a problem. It's rather about how curve is shaped in the area of the "cheating", increase of luminance does not correspond with increase of IRE the same as in the "linear" part of the curve and we are particularly sensitive about how human skin is render therefore we notice it.
The curve is data levels so we completely agree![]()