Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[FenceMan]

Sorry FenceMan I'm not sure I understand your question?  I don't have HDR Toys installed so I was just comparing your three screen shots as posted.

Sorry I meant the tests Movieman was doing, wondering if HDR Toys does better on those.  Clearly it can be done correctly just a matter of them getting together and sorting it out.

[JimH]

I just checked and, according to Wikipedia, 1 in 12 males have some degree of color blindness.

https://en.wikipedia.org/wiki/Color_blindness

A lot of well regarded painters intentionally "twist" colors.  If you look closely at the snow they paint, there is a lot of blue and pink.  Shadows are blue and purple.  The overall effect is quite pleasing.

Trying to get skin tones to look right seems like a pretty subjective subject for discussion.

Just wanted to throw that in to the mix since I can barely follow the discussion.

But I do appreciate the efforts.

[jmone]

Sorry I meant the tests Movieman was doing, wondering if HDR Toys does better on those.  Clearly it can be done correctly just a matter of them getting together and sorting it out.

I'm sure they will.  They are pretty smart cookies!  I'm happy enough to test some screen shots etc but I'm well out of my depth regarding how to code any of this. 

[jmone]

@JimH - FWIW, I did a 4 day colour grading course for resolve with a professional colourist.  What was interesting is that when it came to skin tones, the grading was all done on the scopes (and then visually checked on the actual Image).  And not these "inbuilt ones" but big dedicated ones taking a clean HDMI feed.  It was very ... obsesive.  He would even grade parts of the faces when needed.  When grading other aspects of the clip it was done looking at the image as adjustments were made.  It also made me well aware of my own grading limits.  I tend to check stuff in, bump up the saturation, expand it to cover the luminance range, and call it good (I'd never get hired that is for sure!).

Like all my hobbies, I know just enough to be dangerous (you should see me with my metal casting )

[jmone]

Just tried to send a donation and Paypal complained it could not find a "paypal_at_haasn.xyz"!  But "nigerian_prince" worked fine

I'm also keen to buy haasn some beers, if anyone can confirm his paypal address that would be great.

[JimH]

I'm also keen to buy haasn some beers, if anyone can confirm his paypal address that would be great.

Just replace _at_ with @

The xyz is an odd extension but it's right.

[jmone]

Thanks!  that worked.  Beer $ sent (also to Hendrik).

[JimH]

What about me?

[jmone]

00428:  Overall bit rate                         : 7 723 kb/s
00429:  Overall bit rate                         : 8 661 kb/s

Not sure about these two clips.  Both have reduced gamuts.  If I had to guess, I'd say
00428 is 709 in 2020 ?
00429 is P3 in 2020 ? but with a bit clipped off as well?

I'll stick with 00430. 

[jmone]

What about me?

https://www.youtube.com/watch?v=OzQKECQgjW8

Now what was the website that delivers chickens again?

[JimH]

Music: See what I mean?

Pythons:  Normally, I'd say, "Bring it on."  However, I've been on the receiving end of a few of your "gifts".  I'll just say, "Thanks, Nathan.  Have you heard of Rattlesnakes?"

[jmone]

Ahh what's life without a bit of fun?  & Good luck getting those through Customs!

[mattkhan]

And yet, on this screen and to my eyes and independent of the madvr take, hdrtoys looks way too red. How can a scope know what the right skin tones are for a specific scene though? Particularly one with a fire raging in the background. Seems impossible to me.

[jmone]

They use masks (something like attached) when grading to isolate the relevant parts (eg face) for grading so it only changes the face and not the rest of the scene (or vice versa, or a combination of both).

I've only looked at the screen shots that FenceMan has taken with various renderers doing the tone mapping (here and at AVS) on two different movies.  I don't have the original HDR video clip (or either movie in my library) to see what the actual HDR scene looks like on the scopes.  Who knows, they could have been graded more to the yellow side for Vin's face.  I've also no idea what settings he has used in madVR / HDRToys in these screen shots.  So I've no idea which tone mapped version looks the most like the original.  Hoping he will provide at some point a 1sec cut of the original HDR material and then we will know more. 

[jmone]

It's crazy how much grading power they have.  One of the examples on my course, was the grading of a commercial for a UK Gambling Company that had a bright red logo.  The DP had deliberately shot the commercial with parts of the rest of the scene in the same hue (Red Dress, Store Dressage etc).  Once shot the company then changed their mind and just wanted their logo in that hue, so the colorist put moving masks around all the other red stuff and moved them to other colours and hues.  Even worked as the Red Dress walked through the scene and the camera was panning.  You would never know that her dress was not originally blue. 

[Hendrik]

Just subjectively, the yellow madVR shot looks way too yellow. Maybe somewhere in between is better. I like to compare to the output on a HDR screen for comparison, although of course you are also at the mercy of the screens processing then.

[jmone]

And yet, on this screen and to my eyes and independent of the madvr take, hdrtoys looks way too red.

I'm guessing it's the additional Saturation rather than Tint that looks poor with the HDRToys tonemap screenshot.  The madVR screenshot is definitely pushed towards yellow but the the hdrtoys has heaps more saturation.  So here is the HDRtoys  screen shot with the saturation reduced to be about the same as the madVR one.

EDIT:  All three Vin screenshots have issues with clipping highlights (madVR is the best) but HDRToys also has a part of it's chromaticity crushed around red (600nm) of the 2020 colour space (that ain't good). 

[jmone]

Just subjectively, the yellow madVR shot looks way too yellow. Maybe somewhere in between is better. I like to compare to the output on a HDR screen for comparison, although of course you are also at the mercy of the screens processing then.

Maybe he had Jaundice!  Once I have that original HDR clip, I should be able to get something out. 

[jmone]

I missed that MovieMan did post a video grab earlier in this thread.  Something is a bit off as Resolve says it's only 8-Bit but Media Info says it's 10-Bit.  Not sure about that.  The original skin tone is towards yellow.  I also tonemapped it in DR to SDR 2020 and attached is the screen export with the scopes.  Nothing is clipped (either luminance or gamut) which is good (and unlike the other tone mapped samples).

[jmone]

I'm also no closer to working out how to get an HDR Still Image for posting.  I can "save" out a single frame as DPX, Cineon, Tiff, JPEG, PNG, PPM, BMP, and XPM Files if that helps.

[haasn]

HDR Toys skin tones sit on that line.  madVR is too yellow.  Makes me wonder if we have been "conditioned" after all these years that madVR is the "right" look when it is just too cool.

To be honest, I also thought that the madVR image looked very washed out and undersaturated, and that the libplacebo image looked best. But that may either be personal bias, or alternatively, maybe the reason libplacebo is designed the way it is is because it was designed to match my aesthetic preferences...

[haasn]

So, to me the most obvious thing about this clip is just how little tone mapping is actually happening here. I mean, have a look at this screenshot:



This is the output of conversion to SDR BT.709 via libplacebo. Tone-mapping is completely disabled (the cyan regions show areas where the source shadow detail falls below the 1000:1 contrast black floor target), so it does not influence anything here. Gamut-mapping is replaced by a no-op which simply highlights out-of-gamut pixels and leaves in-gamut pixels completely untouched.

So, for areas of this image which are "preserved" (not clipped) this is basically a direct conversion from the HDR BT.2020 source to the SDR BT.709 target. This is the skin tone exactly as it would appear on a HDR/BT.2020 reference monitor, for those parts of the image. So it represents a definitive baseline for artistic intent. Any deviation from this by the tone/gamut mapper is a perceptual distortion of the image.

Attached below this is a version of the same output configuration (BT.709 SDR) but with libplacebo default tone/gamut mapping settings in use (which, for this clip, consults HDR10+ metadata for tone-mapping), and finally, a version that ignores HDR10+ metadata and uses only our own built-in HDR scene evaluation and dynamic tone-mapping (spline). (Note for the curious: the reason spline is so much brighter here is because I am running it on only the single exported frame, which does not contain any bright highlights, whereas the dynamic HDR10+ metadata is calculated for the whole scene. In a fair comparison, this would be less of a factor, so take the brighter image with a grain of salt)

So, what's the take-away here? It seems obvious to me that libplacebo's tone-mapping is exactly on the money with respect to what the shot is supposed to look like in HDR. It may not subjectively reproduce that SDR "hollywood graded" feel that madVR apparently produces, but personally, I think it's rather silly to introduce such extreme aesthetic choices into what should be an as-objective-as-possible piece of software. If anything, libplacebo gives you the tools to recreate any such distortion yourself if you want to, by doing all tone/gamut mapping in a perceptually uniform color space.

[haasn]

Oh, for completeness' sake, here is the output of the "linear desaturate" gamut mapper, which simply reduces saturation globally until the image is in-gamut. So it should preserve ratios exactly. I always think it looks way too undersaturated, but it's a good one to compare against if only to understand better what the dynamics in the original image looked like.

[FenceMan]

So, to me the most obvious thing about this clip is just how little tone mapping is actually happening here. I mean, have a look at this screenshot:

This is the output of conversion to SDR BT.709 via libplacebo. Tone-mapping is completely disabled (the cyan regions show areas where the source shadow detail falls below the 1000:1 contrast black floor target), so it does not influence anything here. Gamut-mapping is replaced by a no-op which simply highlights out-of-gamut pixels and leaves in-gamut pixels completely untouched.

...

@jmone has a theory that maybe MadVR is doing it wrong and we have all gotten used to it being the way they do it.

Here is another clip and some screens if anyone is interested. https://www.dropbox.com/sh/eu6kf0epqtm3o5n/AADNMMK-AMeWY2V6Ct4qciFua?dl=0

[haasn]

Here is a treatment of the Mamma Mia sample by the same process. The first image again shows the reference (1:1 reproduced) colors for everything in-gamut. Second image is the libplacebo default TM (with peak detection enabled) to this same target. Finally, the same image passed through the static ST2094-40 tone mapping curve. (This clip has no HDR10+ dynamic metadata)

We clearly lose some of the contrast/detail in the face, as a result of the auto spline tone-mapping. But there is almost no gamut mapping happening after this, the skin is entirely in-gamut so it is directly passed through untouched. So this, slight differences in the highlights notwithstanding, still a very faithful representation of the source image. The skin tone is spot-on with the HDR source.

[haasn]

@jmone has a theory that maybe MadVR is doing it wrong and we have all gotten used to it being the way they do it.

It wouldn't surprise me given how in love people are with 24 Hz movies despite them being objectively worse than 60/120/240 Hz motion video (and giving me headaches...)

[FenceMan]

It wouldn't surprise me given how in love people are with 24 Hz movies despite them being objectively worse than 60/120/240 Hz motion video (and giving me headaches...)

So to sum up your thoughts on what we have shown you if we have -

tone-mapping=auto
gamut-mapping-mode=auto

You are confident we are seeing what was intended?

What about the scopes "issue" did you figure out what was going on there?  BTW we all greatly appreciate your efforts and that you are taking time to discuss this.

[Hendrik]

Real world examples since everyone is looking here -

On a hint from another developer, it seems like the madVR shot is using BT.2020 output, which makes it tinted this way, while the other shots are BT.709. Comparing in madVR locally, I get a shot much similar to the other two with madVR set to BT.709.

[haasn]

What about the scopes "issue" did you figure out what was going on there?  BTW we all greatly appreciate your efforts and that you are taking time to discuss this.

I'm still investigating I think there's a real bug there, it should not produce such obvious artefacts especially in PQ output mode.

[FenceMan]

On a hint from another developer, it seems like the madVR shot is using BT.2020 output, which makes it tinted this way, while the other shots are BT.709. Comparing in madVR locally, I get a shot much similar to the other two with madVR set to BT.709.

That's a great call I do have my MadVR set to output 2020.

Funny thing is a lot of people said they prefer that shot which is what makes everything so confusing.

[SirMaster]

In the spirit of this thread's title about comparing tone-mapping to madVR, do the developers here have any advice on the following?

I have been using madVR for about 13 years and exploring other tone-mapping systems and trying to compare them to the madVR settings that I use, because in order to switch I would need to see at least parity, if not an improvement.

The problem I always keep running into is that other tone-mappers don't seem to talk much or do much about lower nit outputs.

I speak for myself, but lots of other home theater projector owners who I know use madVR with pretty much the same settings that I use.  In the well under 100 nits range, some down to ~50 nits (which has been a standard for SDR calibration in home theaters for a long time).

I made some screenshots between madVR and mpv using libplacebo, and keep in mind this is only a baseline using the target-peak=auto since it seems to be recommended for HDR to SDR?

But (unsurprisingly) this looks very dim and flat on a 50 nit display compared to madVR set to 50 nit DPL.

How should someone go about increasing the brightness of the tone-mapping output using libplacebo for targeting a 50 nit display?  When I try target-peak=50 things look pretty wrong and oversaturated for example.  I am not quite sure how to proceed and what settings should be modified to get a brighter image that looks right.

https://nicko88.com/misc/compare/madVR-mpv/greatest_showman/

[haasn]

So, to eliminate the question of whether 3DLUT color space encoding aggravates these artefacts, I made a series of examples, each targeting a 99x99x99 3DLUT with BT.2020->BT.709 PQ colorimetric clipping on the HSV sweep:

• ICh trilinear (what we currently use)
• IPT tetrahedral
• LMS-PQ tetrahedral
• BT.2020 PQ RGB tetrahedral

Seems to be our current choice (ICh trilinear) is the most accurate by a slight margin, and none of the modes gets rid of the strange ringing/comb-like artefacts, which leads me to suspect they're part of the gamut mapping algorithm itself and not introduced by 3DLUT precision losses.

[haasn]

OTOH, here is a comparison against of a 3DLUT-based saturation mapping versus a pure GLSL implementation of the same. It seems clear to me that this mode suffers from some sort of severe regression as a result of being fed through the 3DLUT. Will investigate further.

[haasn]

So, to eliminate the question of whether 3DLUT color space encoding aggravates these artefacts, I made a series of examples, each targeting a 99x99x99 3DLUT with BT.2020->BT.709 PQ colorimetric clipping on the HSV sweep:

• ICh trilinear (what we currently use)
• IPT tetrahedral
• LMS-PQ tetrahedral
• BT.2020 PQ RGB tetrahedral

Seems to be our current choice (ICh trilinear) is the most accurate by a slight margin, and none of the modes gets rid of the strange ringing/comb-like artefacts, which leads me to suspect they're part of the gamut mapping algorithm itself and not introduced by 3DLUT precision losses.

I implemented tricubic interpolation, it looks substantially better. Unfortunately, it is also slower, bringing gamut mapping from 0.8ms to 1.4ms on my fairly powerful GPU. I'll make it a configurable option for now, I think.

[FenceMan]

I implemented tricubic interpolation, it looks substantially better. Unfortunately, it is also slower, bringing gamut mapping from 0.7ms to 1.5ms on my fairly powerful GPU. I'll make it a configurable option for now, I think.

FWIW you use much less GPU than MadVR to get similar or better results....

[danbez]

Attached below this is a version of the same output configuration (BT.709 SDR) but with libplacebo default tone/gamut mapping settings in use (which, for this clip, consults HDR10+ metadata for tone-mapping), and finally, a version that ignores HDR10+ metadata and uses only our own built-in HDR scene evaluation and dynamic tone-mapping (spline).

@haasn, I have a question about how MPV uses the DV RPU (dynamic tone-mapping). Are the below assumptions correct?
1. If a movie has DV metadata, the DV metadata will be the preferred way to tone-mapping, assuming Tonemapping is set to Auto and Dolbyvision is not set to "no".
2. hdr-compute-peak will be ignored (even if set to yes?) and DV will be used to calculate the peak.

If these are correct, I am afraid we may have wrong results with FEL titles where the FEL layer changes the brightness of the BL, since the RPU will assume that the FEL layer enhancements were applied. As of today, we are aware of over 100 movies with such FEL specific brightness changes. In order to avoid that, I see the following options (please confirm):

1. Set Dolbyvision=no and always ignore DV metadata.
2. Force HDR-Peak-Detection=yes to be respected even when DV metadata is present, and use it together with Spline tonemapping. (there is an open issue at the MPV GitHub tracking that). Basically same results as #1 above.
3. Add new functionality to LibPlacebo and detect the presence of FEL vs MEL Layer. If FEL, don't consume the dynamic metadata.
4. Ideally - Fully support the FEL layer so we can claim maximum quality from individual titles. :-).

Is that correct?

[Hendrik]

Dolby Vision metadata is not used for tone mapping yet, other then the dynamic scene peak information. Please also don't hijack the thread for random questions about libplacebo.

[danbez]

Dolby Vision metadata is not used for tone mapping yet, other then the dynamic scene peak information. Please also don't hijack the thread for random questions about libplacebo.

Ah, I missed that part. Thanks for confirming and I will stay quiet for now :-).

[haasn]

As a side note, I added multi-threading to the 3DLUT generation to speed it up by well over an order of magnitude (on typical systems with 8+ cores). Now we can crank up the settings much higher, in theory.

I've pushed all of my refinements to https://code.videolan.org/videolan/libplacebo/-/merge_requests/481 and will merge into master in a couple of days. But for now, maybe Hendrik can put out a new JRVR build incorporating this, for testing?

[mattkhan]

@haasn the statement regarding projectors is confusing (i.e. https://github.com/haasn/libplacebo/issues/175#issuecomment-1608061311), I don't see how that can work for a projector (which is surely a non trivial number of people who want to use this)

[Hendrik]

Please don't spill discussions into multiple places. Just sign up and answer if you want to engage in a particular thread over there.

[jmone]

OTOH, here is a comparison against of a 3DLUT-based saturation mapping versus a pure GLSL implementation of the same. It seems clear to me that this mode suffers from some sort of severe regression as a result of being fed through the 3DLUT. Will investigate further.

BTW, The saturation-glsl screen shot looks perfect on the scopes (cropped in to full screen and taking into account that there is a bit of a grey box in the upper left).

[jmone]

It wouldn't surprise me given how in love people are with 24 Hz movies despite them being objectively worse than 60/120/240 Hz motion video (and giving me headaches...)

Yup it's 100 years of conditioning in thinking the 24fps @ 180 degree shutter looks good.  I now shoot (being PAL) 50fps @ 360 degree shutter instead (instead of 25fps @ 180).  You get twice the temporal resolution but the same cadence (eg when you playback on a 50hz TV each 2nd frame is identical but yet you get twice the # of unique frames as the 25/180 is going through a 2:2 pulldown)

While people seem to like the idea of increasing spacial resolution (eg UHD over FDH) or gamut, or luminance, but not temporal.  Weird as a doubling of temporal from what is commonly shot is "free" giving our monitors all run at frequencies at least twice the common acquisition rate.

Here are some examples of 25fps/180 vs 50fps/360 side by side.  Needs to really be viewed at 50hz.  I've got NTSC examples as well.

Anyway, different rant!

[jmone]

Also, while on related topics, here is a good read on the differences between using LUTS Vs Transforms for colour space conversions. 

[Hendrik]

The tone mapping LUTs in libplacebo are generated on the fly when parameters change. They are used to allow more flexibility in creating as complex mappings as desired, and just writing it into a LUT to process the image against, quickly and painlessly. So these dynamic LUTs can be smart, as they are generated for the content you are currently watching.

BTW, The saturation-glsl screen shot look perfect on the scopes (cropped in to full screen and taking into account that there is a bit of a grey box in the upper left).

Saturation mapping makes for nice scopes, but it shifts the hue on real content.

[jmone]

Saturation mapping makes for nice scopes, but it shifts the hue on real content.

Good to know, thanks.

BTW the grading industry (aka ACES/Resolve) is moving away from LUTS to Transforms for technical colour space adaptation.  LUTS are still used but after the colour space transformation creative options (add Film Stock grain, Orange/Teal look etc).

Fenceman also posted some screens shots of ShowGirls and it was interesting to see that the foreground characters skin tones were graded to the yellow (I'm guessing that Orange/Teal look) to make them POP VS the background characters were on the Skin Tone line.  Anyway, the takeaway (if there is any) is shots like Vin etc have a deliberate creative grade to move the tones so trying to put them back on the skin tone line is not the directors intent.  The issue with the "red push" is just more an oversaturation one when tone mapping.

Anyway, enough of peaking at random screenshots till the next JRVR version.

[mattkhan]

Can I check 2 points about configuration here

1) for UHD content with a display in DCI-P3 mode and using a 3dlut generated for dci-p3, is it correct to say both screen gamut and source gamut (in the 3dlut settings) to dci-p3?

2) how does the nits setting in jrvr relate to the target-peak setting described in https://github.com/haasn/libplacebo/issues/175#issuecomment-1608061311 ? That thread refers to an auto option (which doesn't exist in jrvr) and that lower values produce a dim image which is the opposite of what I see in jrvr (lower values = brighter). Put more directly, which libplacebo settings are set by changing the jrvr nits setting?

[Hendrik]

The nits option is the target-peak, and auto is just 203. And lower values don't produce a dim image, but they produce issues with color saturation/hue shift in the image. 203/auto produces a dim image for them.

[jmone]

1) for UHD content with a display in DCI-P3 mode and using a 3dlut generated for dci-p3, is it correct to say both screen gamut and source gamut (in the 3dlut settings) to dci-p3?

Good Question - I too am not clear on what to set where and how the setting under Calibration and HDR menus interact with each other.  Say in my case, I'm targeting 1,000 Nits with HDR to HDR tone mapping limited to P3 in 2020.  Would you:
- HDR Settings: Check "HDR to HDR Tone Mapping" with "Reduce Gamut to DC-P3-D65 (in BT.2020)" and dial in the "HDR to HDR Target Peak Nits" to what you need, and if so,
- Calibration Settings: Screen Gamut (do you set it to 2020, DCI-P3-D65, or DC-P3-D65 in BT.2020?) / Gamma Processing (Disabled) / Calibration Method (Disabled, or load a LUT?)

[Hendrik]

3DLUTs replace the screen gamut or gamma settings. Set them to whatever your screen wants in case the 3DLUT isnt present, but generally they are not used. So the settings you propose would be right, although the screen gamut setting has no immediate impact if the 3DLUT is actually active.
Note that 3DLUTs are not applied for HDR/PQ output at this time.

Also when using HDR pass-through output, or HDR to HDR tonemapping, the settings are also not used, because HDR PQ output is always BT.2020 (either full or limited to DCI-P3), and has no gamma encoding.