Print

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

[kasper93]

* I think there is a bug in TPN or values below 50 aren't supported

if you set it to progressively lower values then the image (I think as expected) gets brighter and/or more saturated until you get to 50, if you then go to 49 it gets much darker and doesn't change as you go lower

What version are you testing? This has been changed last week in libplacebo. Current limit is 10 nits, it should be more than enough for any real use-case.

I'm sure this change is available in recent JRVR test builds. This makes me wonder if you are testing some older build?

[mattkhan]

What version are you testing? This has been changed last week in libplacebo. Current limit is 10 nits, it should be more than enough for any real use-case.

I'm sure this change is available in recent JRVR test builds. This makes me wonder if you are testing some older build?

the one posted here which, as far as I can see, is the latest in this thread - https://yabb.jriver.com/interact/index.php/topic,136378.msg945306.html#msg945306

[jmone]

Matt - you were right.  Went back and tested.  Turns out the HDR clipping test pattern I was using only showed a 240-1000nit range (weird... but I should have looked at the scale) to dial in the min/max.  This time I used the new S&M HDR one that goes from 0.1 to 10,000 and used that to dial it in from crushing blacks and clipping whites.  Not only did I use the sample HDR test clips (which are mostly very bright) but also used the "Matrix" opening scenes that are very dark.  In the end I settled on 110nits with the JVC Lamp set to High.  I'm still crushing black in the 0.0-0.2nit range but I prefer that to dropping to say 80nits and raising the overall brightness.  Thanks for persisting! I also edited my earlier settings post.

[jmone]

the one posted here which, as far as I can see, is the latest in this thread - https://yabb.jriver.com/interact/index.php/topic,136378.msg945306.html#msg945306

I think this one is the newest - https://yabb.jriver.com/interact/index.php/topic,136463.msg945409.html#msg945409

[mattkhan]

I think this one is the newest - https://yabb.jriver.com/interact/index.php/topic,136463.msg945409.html#msg945409

Does that one change tone mapping or just the contrast recovery implementation?

[mattkhan]

Matt - you were right.  Went back and tested.  Turns out the HDR clipping test pattern I was using only showed a 240-1000nit range (weird... but I should have looked at the scale) to dial in the min/max.  This time I used the new S&M HDR one that goes from 0.1 to 10,000 and used that to dial it in from crushing blacks and clipping whites.  Not only did I use the sample HDR test clips (which are mostly very bright) but also used the "Matix" opening scenes that are very dark.  In the end I settled on 110nits with the JVC Lamp set to High.  I'm still crushing black in the 0.0-0.2nit range but I prefer that to dropping to say 80nits and raising the overall brightness.  Thanks for persisting! I also edited my earlier settings post.

I didn't do this v scientifically, just by eye on a few different scenes and landed on 100 so pretty similar to you

[jmone]

Does that one change tone mapping or just the contrast recovery implementation?

I think it is all changes made between the two dates in the source tree.

[Hendrik]

An increase in saturation might be because JRVR does black point compensation, which madVR does not do, but in JRVR you can't set the black point/contrast right now, and from what I understand, projectors are usually considered to have a rather high contrast, despite their low brightness?
I might add an option to let you control the contrast, which gives JRVR more room to use that contrast, rather then trying to compress everything, resulting in increased saturation.

This should also be a useful option if you tonemap to SDR for a OLED display, rather then using HDR out.

I think it is all changes made between the two dates in the source tree.

No, its not. I cherry picked pertinent changes, because a fully clean build updated the ABI (the version changed from 290 to 292 by now), and you can't replace the dll with one of a different version.
So the change to allow brightness down to 10 nits was not included there.

[mattkhan]

An increase in saturation might be because JRVR does black point compensation, which madVR does not do, but in JRVR you can't set the black point/contrast right now, and from what I understand, projectors are usually considered to have a rather high contrast, despite their low brightness?
I might add an option to let you control the contrast, which gives JRVR more room to use that contrast, rather then trying to compress everything, resulting in increased saturation.

This should also be a useful option if you tonemap to SDR for a OLED display, rather then using HDR out.

a JVC projector is known for its black level  (vs other brands) so options to exploit that would be good

does that interact with a 3dlut (which may also designed to handle that compensation)?

[FenceMan]

An increase in saturation might be because JRVR does black point compensation, which madVR does not do, but in JRVR you can't set the black point/contrast right now, and from what I understand, projectors are usually considered to have a rather high contrast, despite their low brightness?
I might add an option to let you control the contrast, which gives JRVR more room to use that contrast, rather then trying to compress everything, resulting in increased saturation.

This should also be a useful option if you tonemap to SDR for a OLED display, rather then using HDR out.

No, its not. I cherry picked pertinent changes, because a fully clean build updated the ABI (the version changed from 290 to 292 by now), and you can't replace the dll with one of a different version.
So the change to allow brightness down to 10 nits was not included there.

I just want to throw a completely unscientific opinion in the mix of all of this.

We are all "guilty" of comparing JRVR to MadVR which is great for frame of reference but to me JRiver just looks better for whatever reason.  To me MadVR looks kind of dull in comparison to JRiver.  My theory (but just a wild guess really) is that so much focus has been put on the extreme cases and test patterns that the overall look has been somewhat compromised.  I was watching Captain Marvel last night and the scene where she is hanging upside down with the "lasers" pointed to her head those "lasers" I am sure in the MadVR world would by hyperfocused on and heaven and earth would be moved to get them looking just right with little regard for the rest of the picture.  I guess what I am saying is I hope you guys don't get too focused on what MadVR is doing (or what they did as again it seems like abandonware) and end up with a dull picture to satisfy the extreme cases / test patterns.

Note that my projectors are both 150+ nits so I am not suffering from the same issues that the 50 nit people are.

[mattkhan]

I am comparing to madvr because it's the only other option available so need to decide which one is better. Put simply, I haven't noticed madvr look "wrong" but I have noticed jrvr look "wrong". This is more noticeable to me than the times the increased saturation (of jrvr) looks good.

[JimH]

I guess what I am saying is I hope you guys don't get too focused on what MadVR is doing (or what they did as again it seems like abandonware) and end up with a dull picture to satisfy the extreme cases / test patterns.

I agree.

[jmone]

@FenceMan - I agree.  The "holy grail" is simply a good-looking image on your equipment in your environment that you are happy with for the commercially released titles we get. 

Sure, there are comparisons to be made between madVR, EVR, XYZ, HW Renderers, etc and these are absolutely valid.... but at the end of the day, the only thing that matters is if it looks good to your eyes, with your setup, in your environment.  Who decreed that madVR (or whatever renderer) is the holy grail to aim for anyway? 

I'm for one am glad that JRVR/libplacebo is on the scene.  It's generating a great looking image that runs on a wide range of GPU (from modest iGPU's up).  The other one thrown around that makes my eyes role is "directors' intent".  If you want that then get the same equipment that they graded on and replicate the environment that it was graded in.  Otherwise, it's chasing rainbows.  You have 0 chance of a HDR BD movie perfectly replicating "directors' intent" on a 50 nit (or any home) PJ...but who cares as long as it looks good to you anyway?  The other option if you really want "Directors Intent" then stump up for a DCP copy (digital cinema package) and the 500K PJ that goes with it. 

At some point, you just have to sit back and enjoy the movie.... instead of debating what the exact hue the fabric on the red chair in the background of some shot should be (I've no idea, I was not on the set).  As long as skin tones are correct, you're not crushing black, blowing highlights or some weird tonal banding... I say we are good to go.

Is JRVR/libplacbeo perfect?  Nope.  Will it ever be?  Nope.  The great thing about JRVR/libplacebo is it is both open source and under active development and the devs are taking a keen interest in the feedback we are giving across our varied setups.  We have already seen (and will see more) rapid continual improvement.  Keep the comparisons and suggestions coming I say!

[FenceMan]

I am comparing to madvr because it's the only other option available so need to decide which one is better. Put simply, I haven't noticed madvr look "wrong" but I have noticed jrvr look "wrong". This is more noticeable to me than the times the increased saturation (of jrvr) looks good.

I get it, everything is relative so you have to compare to something but at the end of the day with the newest JRVR build vs MadVR .166 recommended settings (and at my 150 nit setting for both) JRVR just looks more alive and I hope they never lose that chasing the perceived "correct" color for fire, or slightly more detail in a laser that is onscreen for 8 seconds.

[tixi]

The new Libplacebo is the version 29 ? Or I need to overwrite the files ?

[Movieman]

OK, I have some additional information, which it turns out is incomplete.  More to follow as soon as I process the new screen shots.

1.  Screen shots in both JRiver and MPV are not reliable as they seem to not be taken from the final output of the video chain, so it looks like it points to an issue in libplacebo. Win-PrtScn seems to be the only valid method to capture the image.

2.  The red push I previously discussed only appears when doing HDR to HDR tone mapping. There is also some blue push to be seen.  HDR to SDR looks fine.

Some print screens from DaVinci Resolve showing the imbalance

I've tried adjusting my JVC HDR RS3100 settings which can compensate to a degree for the push.  I also tried HLG which looked better, but still 'wrong'.

These patterns are also from S&M V3.

Thanks for taking a look at this.

[JimH]

Terminology

JRiver is our software player. 

JRVR is JRiver Video Renderer, our complete video renderer for Windows, Linux, and MacOS.

libplacebo is the library of video rendering routines used by JRVR to take raw video and display it.

So, when you're talking about what is putting frames on your screen, please use JRVR _or_ libplacebo, and not JRVR / libplacebo, and not JRiver.

I've corrected a few posts above.

[Movieman]

I seem to be going in circles here, but we're back to the red clipping at lower TPN levels.

What we have here is DaVinci Resolve comparison screen shots of the three primary colors at a TPN of 50 and 125.

This time, back to ordinary Rec.709 HDR to SDR mapping. Blue in next post....

Notice that even at 125, red is clipping, while green and blue are OK.  At 50 everything is clipping to various degrees.

[Movieman]

Cont'd 

[Hendrik]

Seems like I can't reproduce this with the latest (upcoming) version, at least not near as dramatically.
Setting a higher contrast also helps.

I cut off the white squares to clean up the graph, so here are two waveforms at 1000:1 contrast (the default), and at 1000000:1 contrast (an OLED setting for my screen).
In both you can see how it flattens out at the top, but not in a clipping manner, it actually curves at the top to create a smooth end. There is only so much you can preserve if the brightness gets really low.

My guess on the difference between red and green is that red may contain out of gamut colors, but I can't easily check that right away. Actually DCI-P3 contains colors in the red spectrum that don't fit BT.2020, its a bit of a mess.

[Movieman]

Seems like I can't reproduce this with the latest (upcoming) version, at least not near as dramatically.
Setting a higher contrast also helps.

I cut off the white squares to clean up the graph, so here are two waveforms at 1000:1 contrast (the default), and at 1000000:1 contrast (an OLED setting for my screen).
In both you can see how it flattens out at the top, but not in a clipping manner, it actually curves at the top to create a smooth end. There is only so much you can preserve if the brightness gets really low.

My guess on the difference between red and green is that red may contain out of gamut colors, but I can't easily check that right away.

Maybe clipping isn't the correct description here. 

If you look at the green pattern on my capture, you'll see that the amplitude of the green pattern is a full 128 + units on the graph from the top flat line to the bottom tips of the pulses. 

Compare that to the amplitude of the your red capture pattern which is, maybe, if I'm being generous, 10 units. The question in my mind is ?what happened to the amplitude of the pulses on the red pattern?  My opinion  is that excessive amplitude has driven the upper baseline of the pattern far beyond the 1023 top line.

Same 128 + units with the blue pattern on my TPN 125 capture, although you can see an obvious decrease in blue amplitude on my TPN 50 capture as well.

There is no way they should look that different.  That tells me the color temperature tracking is also going to be inaccurate across the brightness range from black to white.

Sorry to keep adding my thoughts, but I also find it interesting that green is the only color that has a straight and true line to it's target on the vectorscope.

[Hendrik]

I checked the M&S samples we're looking at here, and they all contain out of gamut colors to various degrees. Red is the worst, almost entirely out of gamut, blue is a bit better, and green is almost good - presumably because green is far wider in BT.2020.

These pattern seem to have been made with absolutely no reference to the BT.2020 gamut, but rather just thrown in the most extreme primaries possible to encode. I think this is the source of the differences between the three primary colors. Green looks good because its almost entirely in-gamut, and red looks bad because its almost entirely out of gamut. And blue is somewhere in the middle.

JRVR does not treat colors separately, in fact the ICh colorspace being used for gamut mapping doesn't really allow that, as colors are broken down to Intensity, Chromaticity (or saturation), and Hue, rather then RGB or anything of that sort.
But colors being out of gamut to varying degrees seems like a very good suspect for why there are observable differences. The gamut map is setup for in-gamut colors, so those map nicely to the target gamut, if they go out of gamut then it has to aggressively reign them in. In this case, soft-clipping, the slight roll-off you see in my latest screenshots on the waveform.

[Movieman]

While I'm certainly not a subject matter expert in tone and gamut mapping, it doesn't seem to be an issue for MadVR.  (Other than blue being a little off target)

[FenceMan]

Seems like I can't reproduce this with the latest (upcoming) version, at least not near as dramatically.
Setting a higher contrast also helps.

I cut off the white squares to clean up the graph, so here are two waveforms at 1000:1 contrast (the default), and at 1000000:1 contrast (an OLED setting for my screen).
In both you can see how it flattens out at the top, but not in a clipping manner, it actually curves at the top to create a smooth end. There is only so much you can preserve if the brightness gets really low.

My guess on the difference between red and green is that red may contain out of gamut colors, but I can't easily check that right away. Actually DCI-P3 contains colors in the red spectrum that don't fit BT.2020, its a bit of a mess.

When is 31 coming out?

[jmone]

Great   Poorly mastered test patterns really don't help!

I hope this one "Test Pattern - ITU-R BT.2111 PQ 10,000 Nits (for testing Tone and Gamut Mapping)" doesn't have out of bound colours (it was generated using Resolve's Pattern Generator).  I've attached the Scopes for this Test Pattern.

Anyway, using this pattern - I tone mapped to SDR at 60 / 100 / 1,000 / 10,000 nits using spline and limiting the gamut to P3 in 2020. 

I'm not really sure how much we can interpret from such patterns.  It is interesting to see (using the Parade and Waveform) how the curve is applied at different nits.  The other thing I see when comparing it to the original is the colour mixing you can see in the Waveform and Parade does not look even (but then again, I have no idea how it should look with Perceptual Tone mapping that JRVR is doing).

All tested on MC 31.0.31

[Movieman]

Thought I'd give MPV a shot at it.......

Here's the pertinent config info

vo=gpu-next
hwdec=auto

fbo-format=rgba16f  #similar to MadVR
gpu-api=d3d11
gpu-context=d3d11
d3d11-output-format=rgb10_a2

############
# Profiles #
############

[bt.2100-pq]
profile-cond=get("video-params/primaries") == "bt.2020" and get("video-params/gamma") == "pq"
profile-restore=copy
target-trc=gamma2.4
target-prim=bt.709
tone-mapping-mode=auto
gamut-mapping-mode=perceptual
hdr-compute-peak=yes

end]
profile-cond=eof_reached
profile-restore=copy-equal

Not too bad, huh?

mpv-x86_64-20230706-git-9ad14e0

[JimH]

Please don't start mpv discussion here.  It's complicated enough already.

[FenceMan]

Question in advance of new version - will the new contrast setting affect anything else (existing 3d Lut or other)?

[karmat63]

I've done a small experiment: played both the SDR and the HDR version of The greatest showman, in particular the singer scene at about 50 min, at 100 nits on my desktop monitor.

- MadVR gives a very similar image both in SDR and HDR
- JRVR gives a noticeable red push in HDR, while it's just the same as MadVR in SDR.
(HDR file tone-mapped to SDR)

My 2 cents

[jmone]

Also posted this over at AVS.

I'm being really cautious posting my test pattern results (aka the HSV which I like as it shows all hues at all intensities). On one of my posts over at JRiver I was posted my HSV comparisons and also noting stuff like the "blue" is well off target as well. Hendrik responded that they are doing "perceptual tone mapping with black point adaptation" and it will make the charts look weird.

I can get nice looking "accurate" HSV charts doing HDR 10,000 2020 --> 709 Gamma 2.4 inside Resolve. The trouble is when I use the exact same settings on say that madMax clip, it looks very desaturated, and JRVR one is far better.

So here are three shots:
JRVR_MM: The MadMax clip tone mapped by JRVR (from a few days ago)
DR_MM: The MadMax lip tone mapped by Resolve
DR_HSV: The HSV chart tone mapped by Resolve (same as above).

When playing with the Resolve tonemapped MadMax clip, to try to make it look more the original (eg say redder explosion) you start mucking with the tone around (which warps the axis off the "true line". Esp Blue which gets warped towards line off axis towards cyan like we see in the JRVR examples.

[Audionut11]

I can get nice looking "accurate" HSV charts doing HDR 10,000 2020 --> 709 Gamma 2.4 inside Resolve. The trouble is when I use the exact same settings on say that madMax clip, it looks very desaturated, and JRVR one is far better.

What's the cause of the increased brightness and reduced contrast?

Also, when comparing skin tones, would it not be preferable to use the patterns that include the colorchecker?

[Movieman]

What's the cause of the increased brightness and reduced contrast?

Also, when comparing skin tones, would it not be preferable to use the patterns that include the colorchecker?

Some here may disagree, but the Resolve shot is actually the more accurate rendering. 

Looking at the JRVR mapping image, pay attention to that large flat line at 100 on the waveform and the parade scales.  You can also see the clipping on the histogram. That's actually showing the clipping of the highlights from the reds.  Since the blue and green are at lower levels, they are not being clipped.  This is artificially changing the color balance and removing details from the explosion.  The fact that everything in the image including the sand has a reddish orange tint indicates that the red signal level has been increased over what is in the source as shown in DaVinci mapped image.

Any time you see a distinct perfectly flat line with no details like that on a video (or audio, for that matter) waveform, it's a sure sign that some of details are being lost because you have exceeded the ability of the HW or SW to accurately process these signal levels.  This can happen at the brightest point (white clipping) in a video signal, or at the darkest point (black crush). In either case, the result is a lack of details in the affected area.

With that said, it's possible that this increased brightness and red push with the resulting clipping could have been a creative choice on the part of the media's creator because they wanted the image to have more punch and/or visceral impact. 

However, in this case the fact that in the DaVinci image the details are visible and the color balance is not skewed to red makes this unlikely. 

For those who are not in the video business, it is important that you are aware of the fact that DaVinci Resolve is the reference standard software used by editors and colorists in film and video worldwide.  That places it as the software that most of the original creators of the video and audio we see on our screens today use to create the original master.

That leaves the tone and gamut mapping of the processor or display responsible for what we see on the screen.

I firmly believe that patterns like the one I've attached here should be the primary basis for determining the accuracy of tone and gamut mapping and the resulting design decisions. 
However, even on this pattern, notice the red is a touch low and the blue tends a little towards cyan.  Ideally, every color should fall squarely in its respective color target.

Only then should the ability to change the image we are viewing on the screen to match one's personal preference, viewing environment, and equipment choice be provided.

The above is just my $.02,  YMMV

[jmone]

Some here may disagree, but the Resolve shot is actually the more accurate rendering. 

Yeah, I'm one that is on the disagreement side.  I've looked at the original HDR version using Resolve --> Blackmagic UltraStudio 4K --> certified HDR1000 (actual measured is 1,600nits) P3 Montior.  Do you have at least a 1,000nit HDR screen you can view this on, otherwise I'm not sure how you can compare how the various tone mapped versions to the HDR original?

While there is no way to take a screen shot off this monitor as the chain completely bypasses all windows processing, the JRVR SDR Tonemapped image is much closer than Resolves version (the sand, cars, sky look about the same, with the main difference is there is very little yellow in the explosion in the original HDR version vs the SDR ones - but something has to give with reducing to SDR).  By comparision, Resolves SDR version just look it needs additional saturation in the Clr Mgt tab to get it to a similar level as the original.  For example, in the original HDR there is almost no yellow in the explosion (except the very very highlight).  I did also post over on AVS, an HDR Screen Shot of JRVR playing this clip in HDR (which you need to download and play in an HDR capable viewer on an HDR 1,000nit screen).  https://1drv.ms/i/s!AkiTPpgNxBQVg4h_Zu9Y62Jhi-icLQ?e=OVNwbd

What I can post is the Scopes of this HDR Shot.  Like with the JRVR SDR Tonemapped version, red is maxed.  Sure there may be a tiny bit clipped in the Waveform on the SDR version, but it really is just flat across that part of the image. 

[Movieman]

If it's not too much trouble, could you please have a look at exposing a few of the gamut-mapping-mode settings, perhaps in an advanced menu?  I did a deep dive into the various gamut mapping choices in libplacebo here:  https://www.avsforum.com/threads/unofficial-mpv-player-support-thread.3274072/page-34#post-62669876 

(I know, XXX is a verboten subject, but it's the only tool I have to be able to compare and examine the libplacebo options that might translate into potential improvements for JRVR.)

While it may be hard (actually it blew my mind) to believe, there is one (and only one) gamut-mapping-mode option in libplacebo that is, like Mary Poppins, “Practically perfect in every way” on a vectorscope.

I've just spent a few hours viewing a number of problematic clips including the one above that started this discussion.  All traces of red push / clipping are gone with this setting called  .............. wait for it ............. "saturation". 

I know it gets a bad rap in some of the docs, but it sure solves all the clipping and saturation issues I'm having with libplacebo that have been bugging me.  Perhaps it could do the same for JRVR, at least for Rec.709 targets.

So, if you would, could you please take a look at this.

Thanks (in advance)

[haasn]

If it's not too much trouble, could you please have a look at exposing a few of the gamut-mapping-mode settings, perhaps in an advanced menu?  I did a deep dive into the various gamut mapping choices in libplacebo here:  https://www.avsforum.com/threads/unofficial-mpv-player-support-thread.3274072/page-34#post-62669876 

(I know, XXX is a verboten subject, but it's the only tool I have to be able to compare and examine the libplacebo options that might translate into potential improvements for JRVR.)

While it may be hard (actually it blew my mind) to believe, there is one (and only one) gamut-mapping-mode option in libplacebo that is, like Mary Poppins, “Practically perfect in every way” on a vectorscope.

I've just spent a few hours viewing a number of problematic clips including the one above that started this discussion.  All traces of red push / clipping are gone with this setting called  .............. wait for it ............. "saturation". 

I know it gets a bad rap in some of the docs, but it sure solves all the clipping and saturation issues I'm having with libplacebo that have been bugging me.  Perhaps it could do the same for JRVR, at least for Rec.709 targets.

So, if you would, could you please take a look at this.

Thanks (in advance)

"Saturation" will produce a perfect vectorscope result (especially on synthetic test patterns) but badly desaturate (and warp) real content. It will happily destroy skin tones if the mastering primaries are not aligned with your display's, for example.

Actually, I was experimenting with providing a "soft saturation" mode which will apply colorimetric mapping for values inside a protection region, and use saturation mapping for everything else. But as always, it's stuck in "parameter tuning" hell. My first experiment was just using hard-coded cutoff point but every attempt I made to make it pick the cutoff point more smartly resulted in some sort of issue.

[Movieman]

"Saturation" will produce a perfect vectorscope result (especially on synthetic test patterns) but badly desaturate (and warp) real content. It will happily destroy skin tones if the mastering primaries are not aligned with your display's, for example.

Actually, I was experimenting with providing a "soft saturation" mode which will apply colorimetric mapping for values inside a protection region, and use saturation mapping for everything else. But as always, it's stuck in "parameter tuning" hell. My first experiment was just using hard-coded cutoff point but every attempt I made to make it pick the cutoff point more smartly resulted in some sort of issue.

First of all, I really appreciate your work to improve the product.

I just spent about 4 hours or so watching "real" content. Probably 5 or 6 different titles and I certainly didn't see any of what you described. All the titles were ones that had issues with excessively red skin tones or red clipping / over saturation and I saw no signs of these issues.  Of all of the libplacebo gamut mapping choices available to me, this one was clearly the best for me. 

I'll check out some other titles later on.  Just sampled another 5 or 6 titles, and have seen no anomalies. 

I get the feeling that I may have to adjust the gamma slightly, but it'll mean tweaking it very slightly. 

It's really nice to see a saturated blue for a change rather the teal or pastel blue that masqueraded as blue in the past.

My results:

#gamut-mapping-mode=auto         0  uses perceptual
#gamut-mapping-mode=clip         -  excessive amplitude on all targets
#gamut-mapping-mode=perceptual   0  blue off target towards cyan, magenta just short
#gamut-mapping-mode=relative       -  Only hits 2 targets
#gamut-mapping-mode=saturation   +  99.8% perfect
#gamut-mapping-mode=absolute     -  Only hits 3 targets
#amut-mapping-mode=desaturate    -  Only hits 1 target
#gamut-mapping-mode=darken       -  Only hits 2 targets - blue and green hues incorrect - red excessive amplitude
#gamut-mapping-mode=linear         -  Only hits 1 target - low amplitude - blue hue incorrect

Blues were actually blue, saturation was excellent, so far it really works for me, mapping to a JVC RS3100 using Rec.709 @ 110 nits.

Not sure how to resolve the differences we do or don't see.  That's why I suggested exposing the options in JRVR through an expert menu.

All I know is that JRVR requires me to dial back the Digital Vibrance on my NVidia card to deliver a pleasing image.

BTW, I was a projectionist in commercial cinemas for 40 years or so (35mm & 70mm), so I'm pretty picky about image and sound quality.

[Audionut11]

Looking at the JRVR mapping image, pay attention to that large flat line at 100 on the waveform and the parade scales.  You can also see the clipping on the histogram. That's actually showing the clipping of the highlights from the reds.  Since the blue and green are at lower levels, they are not being clipped.

On close inspection of the waveforms, you can clearly see that not only is the Red channel clipped in resolve, but also white and green. Since you've referenced an audio signal, consider this, if you increase the volume of a file to induce clipping, render the file, and then open the rendered file and reduce the volume, have you removed the clipping? Perhaps in this instance, clipped signal isn't the exactly correct term, perhaps compressed highlights would suit better.

Any time you see a distinct perfectly flat line with no details like that on a video (or audio, for that matter) waveform, it's a sure sign that some of details are being lost because you have exceeded the ability of the HW or SW to accurately process these signal levels.  This can happen at the brightest point (white clipping) in a video signal, or at the darkest point (black crush). In either case, the result is a lack of details in the affected area.

As I alluded to above, it can also happen at some point in the chain, notwithstanding that the final rendered detail isn't at the peak ends.

With that said, it's possible that this increased brightness and red push with the resulting clipping could have been a creative choice on the part of the media's creator because they wanted the image to have more punch and/or visceral impact. 

However, in this case the fact that in the DaVinci image the details are visible and the color balance is not skewed to red makes this unlikely.

Feels like you might have misunderstood my message regarding brightness and contrast, and perhaps that's my fault.

1. Resolve clearly has an increased black point.
2. Resolve clearly has overall increased brightness.
3. Resolve clearly has a lower white point (lower peak nit level).

In my view, the above indicated a workflow issue.

[haasn]

I wanted to quickly point something out concerning the "cyan shift" of blue:

BT.2020 blue is inherently more cyan than BT.709. I drew on this diagram a line connecting the BT.2020 "blue" primary to the (shared) D65 white point. The intersection with the BT.709 gamut is at the Yxy chromaticity point (0.15763, 0.08748), or color rgb(0%, 25.7980%, 100%) in sRGB, which is quite a bit more cyan than the normal BT.709 blue primary.

Have a look at the attached image to see what I mean. At the bottom left you have the (colorimetrically mapped) blue primary of BT.2020 next to the BT.709 blue primary. (I also drew the connecting lines, for visualization)

[Movieman]

I wanted to quickly point something out concerning the "cyan shift" of blue:

BT.2020 blue is inherently more cyan than BT.709. I drew on this diagram a line connecting the BT.2020 "blue" primary to the (shared) D65 white point. The intersection with the BT.709 gamut is at the Yxy chromaticity point (0.15763, 0.08748), or color rgb(0%, 25.7980%, 100%) in sRGB, which is quite a bit more cyan than the normal BT.709 blue primary.

Have a look at the attached image to see what I mean. At the bottom left you have the (colorimetrically mapped) blue primary of BT.2020 next to the BT.709 blue primary. (I also drew the connecting lines, for visualization)

Yes, I see that in your diagram. Unfortunately I also see it when mapping to BT.709 in almost any scene with sky.  Is there any possible way to correct for that discrepancy in a linear way as the blue amplitude increases?

BTW, In the latest release you have definitely made great progress with the tone mapping wrt hitting the targets more accurately. 

This may be asking for the moon, but I don't suppose there is also a way to improve gamut accuracy for intermediate colors between the color targets? 

Although, it probably would take a super-computer to solve for all the possible permutations, I have a suspicion that this is what is accounting for my skin tone issues, even with the latest beta.  (Attached screen shot has been brightened for more clarity)

[Movieman]

After testing 31.0.32, I'm happy to say that it's a huge step forward from the previous release. 

While there was still a little too much red for my taste, I was easily able to correct it with about 4 or 5 clicks left on the saturation slider.  It's probably a JVC thing.....
 
A little more remediation on the slightly off target blue to fix up the skies and JRiver could easily become my go-to media player. 

Kudos to everyone involved.

[Audionut11]

BT.2020 blue is inherently more cyan than BT.709. I drew on this diagram a line connecting the BT.2020 "blue" primary to the (shared) D65 white point. The intersection with the BT.709 gamut is at the Yxy chromaticity point (0.15763, 0.08748), or color rgb(0%, 25.7980%, 100%) in sRGB, which is quite a bit more cyan than the normal BT.709 blue primary.

Why do the green and red primaries not suffer the same apparent problem?

[haasn]

Why do the green and red primaries not suffer the same apparent problem?

They do, it's just much less noticeable because our eye is more sensitive to slight shifts in blue than slight shifts in red/green, and also because the relative distance to the white point is much higher.

[Audionut11]

They do, it's just much less noticeable because our eye is more sensitive to slight shifts in blue than slight shifts in red/green, and also because the relative distance to the white point is much higher.

Interesting. I always thought we were most sensitive at green, but I guess that's brightness, not color accuracy, judging from your response.

My first thought is to just map fully saturated bt.2020 blue to fully saturated bt.709 blue, and so on for the other primaries, mapping the rest of the spectrum using that fancy maths stuff, but I don't think too hard because it makes my head hurt.

[haasn]

My first thought is to just map fully saturated bt.2020 blue to fully saturated bt.709 blue, and so on for the other primaries, mapping the rest of the spectrum using that fancy maths stuff, but I don't think too hard because it makes my head hurt.

That is exactly what the perceptual mode is designed to do. It's just not that easy because you may have out-of-gamut values either as a result of bad mastering or (more likely) as a result of tone mapping, so you need some additional headroom. That is why (0, 0, 1) in the source colorspace (e.g. BT.2020) does not map exactly onto 0, 0, 1 in the destination colorspace (e.g. BT.709), but more likely something like 0, 0, 0.8.

We have a test in libplacebo to ensure the perceived hue doesn't change much though: https://code.videolan.org/videolan/libplacebo/-/blob/master/src/tests/tone_mapping.c#L129

From the log:

Code: [Select]

Testing primary: RGB {0 0 1}
Before:    ICh {0.389832 0.303854 -2.030579}
After:     ICh {0.390027 0.224699 -1.829562} = RGB {-0.000058 0.026228 0.791465}
Should be: ICh {0.396571 0.251027 -1.832995}

So you can see that it maps BT.2020 blue onto roughly BT.709 {0, 0.02, 0.8}.

Edit: A second contributing factor here is that the BT.2020 primary may have a different subjective intensity (brightness) compared to the BT.709 primary, as a result of the shift in hue. Since the perceptual gamut mapper is designed to leave intensity untouched, that may also also result in a discrepancy here. In fact, you can see this in the log - the source color (BT.2020 blue) has an intensity of 0.389832. The output color we map it to has an intensity of 0.390027. But the actual maximally saturated BT.709 blue has a much higher intensity of 0.396571.

Maybe we should also have the primary saturation code adjust intensity slightly to compensate for the difference.

[jmone]

I have to say, I'm really impressed not only how good it looks, but also how efficient it is.  Both with HDR --> HDR (for flat screens) and HDR --> SDR (for PJ) tone mapping.  I wish I could squeeze some more performance out of the Intel NUC12 but that is a pretty low end iGPU and it does surprisingly well (it would be crushed by madVR as a comparison)!

[danbez]

I have to say, I'm really impressed not only how good it looks, but also how efficient it is.  Both with HDR --> HDR (for flat screens) and HDR --> SDR (for PJ) tone mapping.  I wish I could squeeze some more performance out of the Intel NUC12 but that is a pretty low end iGPU and it does surprisingly well (it would be crushed by madVR as a comparison)!

With the new JRiver "exclusive" options, what are you using for your HDR->SDR PJ focused tone mapping? Real nits or the original recommendation of using 203? Also, are you keeping BT.2020 or changing the gamut to BT.709 as part of the process? (I like to keep it SDR BT.2020 as the JVC allows that).

[Movieman]

That is exactly what the perceptual mode is designed to do. It's just not that easy because you may have out-of-gamut values either as a result of bad mastering or (more likely) as a result of tone mapping, so you need some additional headroom. That is why (0, 0, 1) in the source colorspace (e.g. BT.2020) does not map exactly onto 0, 0, 1 in the destination colorspace (e.g. BT.709), but more likely something like 0, 0, 0.8.

We have a test in libplacebo to ensure the perceived hue doesn't change much though: https://code.videolan.org/videolan/libplacebo/-/blob/master/src/tests/tone_mapping.c#L129

From the log:

Code: [Select]

Testing primary: RGB {0 0 1}
Before:    ICh {0.389832 0.303854 -2.030579}
After:     ICh {0.390027 0.224699 -1.829562} = RGB {-0.000058 0.026228 0.791465}
Should be: ICh {0.396571 0.251027 -1.832995}

So you can see that it maps BT.2020 blue onto roughly BT.709 {0, 0.02, 0.8}.

Edit: A second contributing factor here is that the BT.2020 primary may have a different subjective intensity (brightness) compared to the BT.709 primary, as a result of the shift in hue. Since the perceptual gamut mapper is designed to leave intensity untouched, that may also also result in a discrepancy here. In fact, you can see this in the log - the source color (BT.2020 blue) has an intensity of 0.389832. The output color we map it to has an intensity of 0.390027. But the actual maximally saturated BT.709 blue has a much higher intensity of 0.396571.

Maybe we should also have the primary saturation code adjust intensity slightly to compensate for the difference.

I think that would be an excellent approach.

[haasn]

I think that would be an excellent approach.

This line of thinking ultimately led me to develop an entirely new gamut mapping approach, tonal mapping: https://code.videolan.org/videolan/libplacebo/-/merge_requests/497

The idea is to transform the source ICh values into a relative representation - which dubbed TSh ("tone", "saturation", hue) - which is scaled such that T=0, S=1 represents the maximally saturated color of each hue. Then we do saturation mapping in this colorspace. One really cool thing about this approach is that it works bidirectionally, unlike the existing bespoke perceptual code.

It still needs some work before it's ready but I think it heads into an interesting direction and may replace perceptual one day.

[jmone]

When you say "bidirectional" do you mean SDR --> HDR tonemapping?!?!

[Hendrik]

This is about gamut mapping, not tone mapping. Increasing colorspace, eg. 709 -> 2020, not increasing brightness. Technically its already capable of inverse tonemapping, but its just not a very smart algorithm and might burn out your eyes.