FAQ S-log2 vs. S-log3 for HDR grading: which is better?

For HDR it doesn't matter between S-Log2/3 for HDR. Both can work, both can have banding. When it is said to overexpose 2 stops to the right, or the other way to protect your highlights, I would pay no attention to such a trivial debate because how you expose is your creative decision. But from a purely technical standpoint, if you have so much overexposure latitude that you can just follow an arbitrary rule like that then you surely don't have a high dynamic range scene to even be concerned with it; should instead consider STD gamma for a much cleaner low key. Do you have mixed footage on the timeline? Are your input levels right? Are you mastering in Data or Video? Variables get magnified in the log-like nature of the display referenced PQ-EOTF transfer function. You are not forced into SLog by a choice to grade HDR. You ARE forced into 10 bits or more.

There are far more important decisions to make about HDR10 than SLog2/3. The choice between ACES or YRGB color managed, (yes it's different), and how you deliver. Are you just handing off prores from Resolve to a post house? Are you viewing HDR10 with a decklink via SDI connected monitor? It's not even a discussion of HDR without HEVC level 5.1, ST.2084, VP9/AV1/MKV/HLG/WCG/HDMI 2.0a, and not even mentioning ST.2100 and dynamic metadata.

Have you been given conflicting specs by the director, and told to adhere strictly? How is that 2020NC matrix working out for you? What are you monitoring THAT on? Colors a little garish? Welcome to HDR10. Have you graded an interview with 3 point lighting with HDR10? So different! Get it wrong and not only will the talent chase after you with a stick, you'll never work again in the industry. There is so much color volume in the high key; spot reflections on faces will illuminate her cosmetic makeup foundation into a visible layer bordering on neon if you are not careful. Shooting trees in a park, looks great cranked. Human skin, you better know what you are doing and work with the HDR scopes in Resolve Studio. You should not have to force *anything* into the range above 100 nits. If it's not already there, you may be making the first mistake trying to put something up there that didn't start there.

I got my first paid job grading for HDR distribution a year ago this month. The discussion is welcome and long overdue.

/Rant_not-directed_at_anyone
 
broughtonfilm said:
Out of curiosity, what is the hardware that you are you using to monitor the HDR images from DaVinci?
Click to expand...


I'm interested in this too. I thought I could do some playback grading on my HDR television with HDMI 2.0a as it's supported on my graphics card. It havn t had any luck.
 
stokstad said:
Omg Tom I dont like the future!
Click to expand...

It can be a beautiful thing but did I mention the SDR copy that the other 99.9% of your viewers will see? Start by putting your HDR finish grade back on a 709 2.4 gamma timeline. Choose a 1000 nit st.2084-to-2.4 gamma st.709 Lut. Begin grading for the SDR copy scene by scene from the HDR master. Save it as a Lut. Sound like fun? it's twice the work because you need both copies, and because whenever you transform from a larger color volume (2020) to a smaller one (709) in either a very bright or very dark scene, you will get out of gamut Ycbcr code values that need to be corrected. Nice! Attach the Lut to the HDR copy inside an MKV container. This is how YouTube works but the same need and process exists for HDR10 and Dolby Vision to create the mezzanine level.
 
Tom Roper said:
For HDR it doesn't matter between S-Log2/3 for HDR. Both can work, both can have banding. When it is said to overexpose 2 stops to the right, or the other way to protect your highlights, I would pay no attention to such a trivial debate because how you expose is your creative decision. But from a purely technical standpoint, if you have so much overexposure latitude that you can just follow an arbitrary rule like that then you surely don't have a high dynamic range scene to even be concerned with it; should instead consider STD gamma for a much cleaner low key. Do you have mixed footage on the timeline? Are your input levels right? Are you mastering in Data or Video? Variables get magnified in the log-like nature of the display referenced PQ-EOTF transfer function. You are not forced into SLog by a choice to grade HDR. You ARE forced into 10 bits or more.

There are far more important decisions to make about HDR10 than SLog2/3. The choice between ACES or YRGB color managed, (yes it's different), and how you deliver. Are you just handing off prores from Resolve to a post house? Are you viewing HDR10 with a decklink via SDI connected monitor? It's not even a discussion of HDR without HEVC level 5.1, ST.2084, VP9/AV1/MKV/HLG/WCG/HDMI 2.0a, and not even mentioning ST.2100 and dynamic metadata.

Have you been given conflicting specs by the director, and told to adhere strictly? How is that 2020NC matrix working out for you? What are you monitoring THAT on? Colors a little garish? Welcome to HDR10. Have you graded an interview with 3 point lighting with HDR10? So different! Get it wrong and not only will the talent chase after you with a stick, you'll never work again in the industry. There is so much color volume in the high key; spot reflections on faces will illuminate her cosmetic makeup foundation into a visible layer bordering on neon if you are not careful. Shooting trees in a park, looks great cranked. Human skin, you better know what you are doing and work with the HDR scopes in Resolve Studio. You should not have to force *anything* into the range above 100 nits. If it's not already there, you may be making the first mistake trying to put something up there that didn't start there.

I got my first paid job grading for HDR distribution a year ago this month. The discussion is welcome and long overdue.

/Rant_not-directed_at_anyone
Click to expand...

Hi Tom - it's been a long time since our last discussion over in the other forum!

All your considerations are extremely important. I will not even try to address them here, though - for a simple reason: I (luckily) do not have a producer, director etc. influencing or examining my work. After I became partially disabled due to my neck spine condition, I'm indulging a very comfortable position of doing it all as my "serious hobby" only - so I'm my own Producer, Director, and Client :) Also, I "deliver" my products to myself, and play them back on the very same monitor I use for grading - this way I do not need to care for all the possible kinds of display devices my audience could possibly be using.

That said, I'm proud to say that even with a rather high quality criteria I'm always imposing upon anything I do in my life, the final results I'm getting (in the form of ffmpg-encoded, 10 bit HEVC clips from Resolve-exported masters) are excellent. I'd say they are on par with a couple of demo HDR10 clips I downloaded from the Internet, including the UHD Premium TV "teaser" clips by LG and Sony (the last 2 clips at the bottom of the list here: http://www.4ktv.de/testvideos/).

So if I started this thread is not because I'm unsuccessfully trying to get results remotely resembling HDR material one can see on Netflix and alike; I dare to say I'm already "almost there". And I will repeat one thing that we apparently have different opinions about: while I agree the bit depth of the source footage is the most important prerequisite to even start dreaming about producing proper HDR10 content, being limited to what our FS7 can offer (recording internally), the choice between the 2 Log curves* is the next most important limiting factor to how good (or bad) the HDR10 output can be in Resolve (of course I mean strictly technical terms - again, I'm not even touching the vast subject of colorist's creativity)...

Cheers, my Friend :)

Piotr

* Of course, this is not to say that a HDR picture cannot be created in Resolve using even Hyper- or Std-Gamma footage, but this will always be sort of artificial content creation... But with all those grading tools Resolve offers, it's absolutely possible!
 
Last edited:
DerekDock said:
I'm interested in this too. I thought I could do some playback grading on my HDR television with HDMI 2.0a as it's supported on my graphics card. It havn t had any luck.
Click to expand...

If you are interested how to encode HDR10-compliant content that will trigger the HDR mode on your TV automatically, and play back in full HDR10 glory (assuming of course you started with proper HDR masters from a grading system like Resolve Studio) - feel free to read through all 123 posts of my discussion with a very friendly and knowledgeable soul over the BMD Resolve Forum: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=53139.

Without Andrew's help, I'd never be able to get as far as I'm now with actually producing HDR10 deliverables!

Piotr

PS. Of course - as Tom mentioned - within the "YT HDR initiative" another workflow is used and documented, but never using YT I didn't even care to learn it. You may prefer to go this route though.
 
Last edited:
Piotr,

Will you try something? Download the linked full 16 bit tiff image (47MB), not the reduced/resized hosted picture. Download link in upper RH corner of Google download page.

Link here --> https://drive.google.com/file/d/0B7wNrNfr-UB4bVgtUXNISU5CM3c/view?usp=sharing

ITCOW_resized.jpg

View the image from a photo viewer. Pay attention to the green grass, the skin tone, and the yellow of the sun. This is just to get an idea of what the colors should look like.

Next create a timeline in Resolve using the tiff image. Enable HDR output and look at the picture on the SUHD with ST2084 gamma and 2020 gamut. Still look the same as the photo viewer? Pay close attention to the green.

Now do 2 things, using your usual workflow create (2) HEVC files in st.2084 that trigger the SUHD into HDR mode, each 5 seconds long, one using using matrix 2020NC and one leaving the matrix undefined.

Example metadata #1
--colorprim "bt2020" --colormatrix "bt2020nc" --transfer "smpte-st-2084" --master-display "G(13200,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" --max-cll "1419,520"

Example metadata #2
--colorprim "bt2020" --colormatrix "undef" --transfer "smpte-st-2084" --master-display "G(13200,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" --max-cll "1419,520"

Question #1: Which HEVC file, example #1 or #2 (if either) played from HEVC/USB looks most like the Resolve/Decklink -->HDMI-->SUHD?
Question #2: Which HEVC file, example #1 or #2 (or neither) has colors most closely aligned with the tiff image as seen with the photo viewer?
 
I need to see to it closer, as - for reasons I don't understand yet - both "2020nc" and "undef" values for the colormatrix parameter yielded exactly the same results (with Color primaries : BT.2020 even for the clip version encoded with colormatrix "undef"). See attached Mediainfo report.

Piotr
 

Attachments

Also Tom - I can see the "Masterdisplay" parameters used in your proposed syntax for ffmpeg differs slightly from what I'm using:

master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" (matching P3-DCI and max brightness of my SUHD)
-vs
master-display "G(13200,34500)B(7500,3000)R(34000,16000)WP(15635, 16450)L(10000000,50)" --max-cll "1419,520" (in your syntax).

While the P3 and White Point parameters are the same, I haven't used the max-cll "1419,520" part. Where does it come from?

Of course this has nothing to do with Colormatrix, but please elaborate. Thanks,

Piotr
 
Tom Roper said:
Question #1: Which HEVC file, example #1 or #2 (if either) played from HEVC/USB looks most like the Resolve/Decklink -->HDMI-->SUHD?
Question #2: Which HEVC file, example #1 or #2 (or neither) has colors most closely aligned with the tiff image as seen with the photo viewer?
Click to expand...

OK, so I'm waiting for you to discuss with me why specifying undef colormatrix still results with 2020 in the encoded h.265 clip. As to your questions:

Ad #1: As both HEVC clips look exactly the same, all I can say is they look just a tad less bright and contrasty than my Resolve timeline through Decklink does. This probably has to do with the master-display settings.

Ad #2. None of the h.265 clips has colors "aligned" with the tiff picture displayed in a photo viewer; both has way more vivid, bright and saturated colors.

Sorry Tom - this sounds like a beginning of a very interesting discussion - unfortunately I'll be travelling in business starting early morning tomorrow, so will only be able to contribute when I'm back home. Till then,

Piotr
 
moldcad said:
Also Tom - I can see the "Masterdisplay" parameters used in your proposed syntax for ffmpeg differs slightly from what I'm using:

master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" (matching P3-DCI and max brightness of my SUHD)
-vs
master-display "G(13200,34500)B(7500,3000)R(34000,16000)WP(15635, 16450)L(10000000,50)" --max-cll "1419,520" (in your syntax).

While the P3 and White Point parameters are the same, I haven't used the max-cll "1419,520" part. Where does it come from?

Of course this has nothing to do with Colormatrix, but please elaborate. Thanks,

Piotr
Click to expand...

Good catch on the G' (x) primary. Your number is the correct one for P3-DCI as you know. Probably a typo, I've been using it for a long time.

max-cll = max content light level, the maximum brightness of a single pixel (1419) and the (520) is max-fall = maximum frame average level. Their significance above carries no special importance, they were parameters given to me; not to exceed.

Did the crayon colors you saw with the HEVC encodes look the same as photo viewer? There should have been some difference in how they were perceived between the SUHD and your regular PC monitor using the photo viewer, since they are using different color spaces, sRGB/adobeRGB versus 90%P3 on the SUHD, I would think.

I am going to repeat the test you just did with the Gx=13250.

Edit I am just now seeing your latest post. Let me think about that.
 
Last edited:
moldcad said:
Ad #1: As both HEVC clips look exactly the same, all I can say is they look just a tad less bright and contrasty than my Resolve timeline through Decklink does. This probably has to do with the master-display settings.
Click to expand...

I am thinking this is possibly a mismatch in DATA vs VIDEO levels someplace. In your media info attachment color range was listed as limited, i.e. 64-940, by itself neither right nor wrong. There are many places where a discrepancy can creep into the production/display chain. E.g., the SUHD is expecting code values 64-940, with 64 being black. Don't make any assumptions about right or wrong however because there are several paths, one is you grade between 0-1023 and output VIDEO level, the other is you grade, between 64-940 and output DATA level. And you have DATA/VIDEO input levels to consider as well. You are correct to specify one or the other in your HEVC parameters as you did, because otherwise the HEVC encoder makes a conversion to VIDEO for RGB outputs and leaves it as DATA for YUV outputs. The surest way to wrangle this is to put your encoded file back on the Resolve timeline and compare it to the source with the waveform monitor to make sure it didn't get converted during processing.

In a DATA encoding, 0 is black with 64 being a very dark gray. But when received by the SUHD that is expecting 64 to be black, it turns your dark gray 64 into black (clipping everything below it) and your bright gray 940 into white, making for a punchier, more contrasty appearance than it should be.

How you choose to grade, whether 0-1023 or between 64-940, or to export DATA or VIDEO is your decision to choose, the end result being all that matters.

Ad #2. None of the h.265 clips has colors "aligned" with the tiff picture displayed in a photo viewer; both has way more vivid, bright and saturated colors.
Click to expand...

This is frontier territory. In your case no problem because you are just going to plop your footage on the timeline and grade it on the SUHD monitor the way you like and be done. Nice! But for those of us less fortunate, it happens that the director hands off to me some Red Epic footage, it's already been graded usually so I am receiving the desired look already, now he says "turn it into HDR and follow the listed specs I gave you."

Suddenly those vivid, bright and saturated colors are heroic in the scenes with the exploding powder kegs, but you're in big trouble on more intimate scenes, faces and skin get pushed up to 200 nits where they didn't belong at all. So you have to re-grade all the scenes preserving the original intent on some while changing it on others for more HDR.

Then with some productions wanting to monetize on YouTube, which requires one grade from which YT automatically generates an SDR copy that is functionally way more important than the HDR grade that it was made from since 99.9% of the viewers will be seeing the SDR version; it better be good! How do you insure that when you are not in control? Well, one mechanism is you include a cube Lut for SDR that you create and attach to the HDR delivery, to give the YT encoder hints as to your intent for SDR. It's a burden and not perfect, but I guess that is why we get this work.
 
Tom, just a single-sentence comment as I'm hitting the road in half an hour: when grading in Resolve, I'm always using Full rather than Video levels (I always enter clip attributes- before creating a timeline - and explicitly check the the Full data option). Same with exporting from Resolve. So if the HEVC clips are video levels they must get converted during ffmpeg rendering.

Piotr
 
moldcad said:
Tom, just a single-sentence comment as I'm hitting the road in half an hour: when grading in Resolve, I'm always using Full rather than Video levels (I always enter clip attributes- before creating a timeline - and explicitly check the the Full data option). Same with exporting from Resolve. So if the HEVC clips are video levels they must get converted during ffmpeg rendering.

Piotr
Click to expand...

Yes. It implies that what you are rendering to is RGB source and not YUV. That's the behavior that triggers the x265 encoding library in ffmpeg to convert to video levels (limited). You can parse this x265 parameter --range "full"
You can see in your mediainfo text file that range is limited.

Safe travels and Merry Christmas.

Tom
 
Last edited:
Not to derail whatever you guys have going, but, if shooting for HDR10, I'd be really tempted to use HG7&8. I'm pretty sure their measured dynamic range is around 9.6, or close to 10 stops. And, given that I can only think of 3 different consumer TV panels that can authentically show correctly produced HDR10 content right now (LG's model year 2016 OLED panel, Samsung's "9800" series panel, and Sony's ZD9 panel-- with relatively few existing in the wild), HG7&8 seem like the safest and most robust way to fit that 10 stops into 10 bits. As far as the color gamut is concerned, I'd be a little surprised if "standard" or "cinema" really limited what you could capture vs S-Gamut3. Maybe it would, but the camera's CFA seems to be the true bottleneck regarding color. I could be wrong though... Just thought I'd throw it out here since the thread began with how best to expose for HDR10 using the FS7.
 
You must log in or register to reply here.
Back
Top