Print

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

[Movieman]

I have a quick question for you all....  The title says it all.

As you can see in the screen shots I have attached, while MadVR maintains almost perfect saturation and hue values, with limited red clipping, JRVR is all over the place.  Blue is almost cyan, and the reds and magentas are seriously clipped.  The red clipping shows up clearly in Jrvr red clipping.jpg where the floor and the chair cushion on the left side loses all detail.

I realize that you are using libplacebo for the JRVR side of things and that it is open source.

However, my question is: do you think you can get the owners of that software to address these issues and achieve parity with MadVR?
I am sure that on most program material, these deficiencies may not stand up and scream "look at how far this scene differs from the intended result", but I have clearly seen it in almost every scene that includes human skin.

I, and I am sure at least some of your other customers, are waiting with baited breath for any possible improvements.

I don't mean to poke the bear, but I do believe this is an important consideration for, at least, some of us.

Thanks again for a great product.

[Hendrik]

The public version of JRVR is out of date. Gamut mapping has been improved in an upcoming update.

Detail being lost in tone mapping is generally a factor of choosing a too low target luminace. Try increasing it. Its not as simple as reading your projectors spec sheet and plugging that number in, im afraid. Especially low numbers below the default should be used with care.

Tone mapping produces an SDR signal, which inherently is designed to be a relative luminace, unlike HDR which is absolute.

What that means is what you are really controlling with that number is the contrast and detail retention, rather then brightness. Lower numbers favor detail in the dark, higher numbers detail in bright sections.

[Movieman]

I ran a series of tests and the target luminance has to be raised to 600+ to get rid of the red clipping. However the red push still exists. Also that does nothing to the accurate target placement.  See attached. 

If you would like to take this offline, I'd be a willing alpha tester for you.  I am retired and can devote lots of time.  PM me if interested.

Projector is an RS3100 with a peak white of 110 nits on the screen.

[JimH]

We promoted the build you need:  https://yabb.jriver.com/interact/index.php/topic,136381.0.html

[jmone]

@Movieman

The new version that JimH has linked is working better for me on the HSV sweeps (but I'm testing HDR to HDR Tonemapping).  Here is a screen shot of madVR (top) and JRVR (bottom) tone mapping 10,000 nit 2020 down to 1,000nit with the latest version of JRVR.  Still some weirdness in the Blue at high Nits and the transition through magenta (from Blue to Red).  I do think JRVR looks better on the Red to Green (though yellow) and Green to Blu (through Cyan) than madVR on this version. 

This SDR Screen Shot does NOT represent what I see on the HDR screen but does sort of show what is going on with the Blue (no idea how to get a realistic screen shot of HDR - this is the Win+Alt+PrintScn that is better than just PrintScr but it is still way off).  I've posted elsewhere that Blue seems to be harder to tone map than the other primaries as it is not great with madVR either (but it is doing a better job than JRVR at present). 

Looking forward to what you find as well.

PS - Hendrik is one of the devs discussing and submitting code to the libplacebo project.  The changes in Tonemapping in this version was from feedback here that he then worked on. 

[Movieman]

OK, just took a look at it.  Better, but the red over saturation remains a major problem. Have to take target peak nits up to 1000 to not clip red which makes the entire image un-usably dark. target points are better, blue is still wonky. Contrast recovery enabled, hardware decoding on, all other settings default

Screenshots are attached - old beta - new_beta  - new_beta_tpn=600 - new_beta_tpn=800 - new_beta_tpn=1000

[Hendrik]

For any real world content make sure peak detection is on, for dynamic tone mapping. It greatly improves all aspects of it, including reported cases of increased red saturation in eg. skin tones.

Also note that color and brightness are two very distinct topics. Tone mapping deals with brightness. Gamut mapping with reducing the color gamut as needed. Many (higher end) projectors are actually capable of producing wider colorspaces like DCI-P3 or even BT.2020 to a decent coverage, without having the brightness for proper HDR, so you can avoid any processing of the color itself.

[jmone]

Getting in the Davinci Resolve scopes "fun", here are 4 examples:
- HSV Sweep Original (10,000 Nits)
- HSV Sweep DR (Davinci Resolve) Tonemap (1,000 Nits)
- HSV Sweep madVR Tonemap (1,000 Nits)
- HSV Sweep JRVR Tonemap (1,000 Nits)

From a purely technical POV on these test clips, Davinci Resolve's tonemapping wins by a mile.  I'd not be aiming at madVR, I'd be aiming for what Resolve can do.

[Movieman]

Wow!!!!, that's a real eye opener. 

It looks like many things have to happen to JRVR tone mapping, but the biggest single factor that's visible on most program material is the excessive red. 

As a basic starting point, it should be mandatory that the 3 primary colors are processed in a manner where all three clip at the exact same amplitude, regardless of the target nit level.  In the DaVinci Resolve plots I posted, the level of the red primary was always considerably higher than green & blue.  Looking at @jmones results for JRVR, it's amazing that the resulting image even looks fairly acceptable.

Until that criteria is met, I just don't it will be acceptable to the discerning viewer.

Just my $.02, YMMV (and your opinions as well) 

[jmone]

@ Movieman - I'd not jump to any conclusions on my post yet!  This is me testing in HDR 10,000 to HDR 1,000 tone mapping mode for a start... then dragging in those SDR screen shots in resolve to analyse (though I did a quick check in SDR mode and it looked similar).  Thing is in real life viewing JRVR looks great to my eyes.

It would be good if you could repeat the test with your setup and settings to see if it is just me stuffing something up or not (highly likely!!!).

[Hendrik]

How do you even take screenshots to analyze from JRVR? If you can't take untouched HDR screenshots, then measuring a HDR output of 10000 to 1000 nits tone mapping is not really in any way comparable, because you are not comparing the JRVR output, but whatever the screenshot contains.

Also, I could change some settings to make your test patterns and color analysis of them look better. But that says nothing about real world content. The pattern you are using and the analysis you do on them only focus on one aspect. Test pattern are misleading, as they focus on singular aspects, not the whole picture.

[jmone]

Yup, I did point out trying to take HDR screenshots being not faithful (used Win+Alt+PrtScn to get a SDR JPG) and it is very very valid point but:
- you only have to play the HSV Sweep Test pattern in MC to see the difference between the renderers and potential issue
- I redid it today with everything set to SDR and tonemapping to 200Nits and got similar results
- Asked for others to check with a warning I could be the problem (and I'm still 75% on the "I" is the issue)
- Same process for madVR and JRVR so will be equally skewed

I'm also keenly aware that:
- we don't watch test patterns, and
- I think JRVR looks good in real life

But... is it something work looking at?  I think so.  My guess is there is something not quite right (but happy to admit that I am certainly not the expert) and I also had a look at the YRGB histogram comparisons (attached) showing some odd peaks with Green, Blue, and Luminosity for JRVR, and weird Luminosity peaks with madVR.

[jmone]

....I could change some settings to make your test patterns and color analysis of them look better.

Please don't.  This is a discussion trying to both understand and help JRVR for the better.  As you said, the whole Gamut and Tone mapping is an evolving process, and we are trying to get involved.  We all have different setups so can test across a much wider range of scenarios that one person can.  If you have a standardized way for us to better test, then please let us know.  I thought the HSV sweep would be good as it shows every possible hue and luminance possible and is easy to see with the eye any weird banding or uneven graduations (which we currently have).

[mattkhan]

How do you even take screenshots to analyze from JRVR? If you can't take untouched HDR screenshots, then measuring a HDR output of 10000 to 1000 nits tone mapping is not really in any way comparable, because you are not comparing the JRVR output, but whatever the screenshot contains.

Also, I could change some settings to make your test patterns and color analysis of them look better. But that says nothing about real world content. The pattern you are using and the analysis you do on them only focus on one aspect. Test pattern are misleading, as they focus on singular aspects, not the whole picture.

on the one hand, this is obviously true. It's also very much the approach lumagen appeared to take to this subject.
on the other hand, there's a reasonable chunk of evidence to say that when certain posters have looked at the behaviour in scopes (of madvr)and tuning has been done on this basis, the resulting changes have been preferred on real world content (and that same testing has subsequently influenced lumagen to tweak things further).

so basically making scopes well behaved seems like a good goal to have

[Hendrik]

I'm not dismissing test pattern, I'm cautioning against fixating too much on a single data point. Also, to ensure the testing process is actually reasonable. SDR screenshots of HDR content might tell you obvious subjective problems, but for objective analysis in eg. the scopes they are not useful. Either tone map all the way to SDR, or take HDR screenshots (if any such tool exists).

[jmone]

woops - missed the edit of your post.  I'll redo the HSV Sweeps with a full HDR to SDR for the screenshots as I just don't think there is anyway to take an accurate HDR screenshot.  What NIT level?  100? 200?  xxx?

[jmone]

So I'm doing the following:
- Windows : Turn Off HDR
- JRVR
  - Screen Gamut = Auto
  - Gamma Processing = Disabled
  - Calibration = Disabled
  - HDR to SDR Conversion = 100?? Nits
  - Enable Contrast Recovery = ON
  - Enable 10-Bit output for SDR Videos = On
  - Tone Mapping Algo = Auto
  - Use HDR Dynamic Peak Detection = On

Anything else?

[mattkhan]

Auto is rec709 isn't it? If so, I think it's a compromised setup. A valid case but should be tested separately.

[jmone]

Anyway, here they are for the settings above for JRVR, madVR, and Resolve.

[jmone]

Auto is rec709 isn't it? If so, I think it's a compromised setup. A valid case but should be tested separately.

Happy to test with an actual set of agreed params   I'm just making stuff up otherwise!

[jmone]

Using different project settings in Resolve gives a different mapping but similar pattern to the output.

[Movieman]

Just curious, which gamut mapping mode are you running in the latest beta?

The latest MPV drop has all of the new modes in it.....

[jmone]

I just put it on Auto for the latest tests. I think it is Spline when in Auto?  I did run through all the options and they certainly make a difference, but the underlying pattern is the same.  When I was testing on my 1,000nit HDR screen it was Tone Mapping to 1,000nits and Gamut mapping to P3 in 2020 or leaving it in straight 2020

[haasn]

Hi, developer of libplacebo here.

So, there are two things that we do that might lead to these bad vectorscope results:

1. The "perceptual" gamut mapper tries directly shifting primaries onto other primaries. So when mapping BT.2020 to BT.709, for example, the BT.2020 red hue vector will be rotated (in IPTPQc2 space) to map directly onto the BT.709 hue vector. However, this is only done for out of gamut colors, which might explain why the vectorscope lines look funny. This is configured by the gamut mapping setting. The default (auto) is equivalent to "perceptual", but try changing this to "relative" (colorimetric clipping only).

2. To avoid leaking overbright colors in "extreme" samples (mad max et al.), we also run the tone-mapper per-channel in LMS space and mix a portion of that result back into the normal tone-mapped image. This seemed to give good results on the samples I threw it at, but it's a known source of strange color warping when the source contains input colors that badly exceed the legal range, as test patterns often do. This is configured by the "hybrid_mix" libplacebo parameter. (I'm not sure if JRVR exposes this)

I don't know how to reproduce your methodology, so it would be great if you could re-run tests with those two options disabled and then see if that fixes the strange vectorscope plots.

[Hendrik]

I installed DaVinci Resolve to get those graphs up, and made scopes with the requested settings, as they are not exposed.

Tone Mapping to SDR 203 nits, BT.709.

https://imgur.com/a/dkctJnh

The visual output is also included, which has some quite distinct differences. (I really need to setup some self-hosted image gallery)

[jmone]

Nice! - pretty much what I see.    I'm always worried what windows is doing behind the scene, or calibration files, or prtscn etc.  Glad I'm not going mad (or just stuffing something up).  I can't say what it "should" look like but both Resolve and madVR don't have these erratic patterns.  Given Resolve is "the" colour grading suite for professional productions, I'm guessing their tone mapping algos (which you can see in my posts) are the best out there.  I'm clueless on how to do it however.  I also continue to note that JRVR (and the latest libplacebo) produces a great image already.

Thanks for looking at this.  I can redo my comparison at 203nits and share my Resolve settings if that helps (as it does subtly change the shape of the graphs).  Better still, if it is helpful, I can share a Resolve project where this is all setup.

[haasn]

So, looking at this in more detail it's obvious that the problem is a lot trickier than initially suspected. It almost seems to exist on a fundamental level - the design decision in libplacebo was to do tone-mapping in IPT/ICh space, but doing so introduces such artefacts almost no matter what I try. Even with completely disabled gamut mapping, I get a strange output at times.

So far my candidates seem to be:

• Too low 3DLUT precision? (unlikely)
• Wrong 3DLUT interpolation (we use trilinear for ICh), but switching to tetrahedral ended up being worse here
• Too low precision on GLSL IPT<->RGB conversion? (very unlikely)
• Doing 3DLUT in IPT is fundamentally bad, and we should switch to PQ-RGB (though this is much worse for precision)
• Doing any sort of tone-mapping in IPT is fundamentally flawed
• This sample possibly contains values that are very far outside of its own specified source gamut, and we should clip to that gamut _before_ passing any values into our TM pipeline
• Most of the gamut mapping functions are done by bisection search / numerical approximation, rather than exact math... and maybe we need to increase the precision tolerances here?
  

I'm running thin on time at the moment, but I will try experimenting with using PQ-RGB 3DLUTs in the future to see if that helps with the weird artefacts, or if it's just fundamentally a result of limitations in the new gamut mapping modes..

[JimH]

Hi Niklas!

Welcome!  And thanks for your work on libplacebo!

For anyone who's curious about haasn ...
https://code.videolan.org/haasn

[JimH]

JRiver just sent haasn a Paypal donation.  Anyone else?  paypal_at_haasn.xyz

replace _at_ with @

[jmone]

JRiver just sent haasn a Paypal donation.  Anyone else?  paypal_at_haasn.xyz

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

[jmone]

Hi Niklas!

Thanks for looking at this and your work on libplacebo!  It is starting to look great and gives the entire community a high-quality open source video renderer option. 

I don't know how to reproduce your methodology, so it would be great if you could re-run tests with those two options disabled and then see if that fixes the strange vectorscope plots.

I see you have already done a bunch of commits, so I don't know if the following is still relevant or not, but here is the method I've used in Resolve for the HDR to SDR tests (see pics).  I have done comparisions with various JRVR options set ON/OFF but could not find any combination that did not produce the odd looking vectorscopes.  I also added screen shots using EVR and madVR (as well as DR own tone mapping) as a comparision as well.

- Color Managment Page - This sets the Output Colour Space to SDR Rec.2020.  As we also have the full HDR HSV Sweep, keep the Color Processing Mode in HDR
- Added the 10,000nit HDR 2020 HSV Sweep test video (trimmed to 5 sec for ease of use) & the JRVR, madVR, EVR screen shots to the timeline.  On these clips do a "Right Click" --> "Bypass Color Managment"  This will then stop DR doing additional colour mgt and you can see in the scopes what is in each sample is doing.
- Also added a 2nd instance of the 10,000nit HDR 2020 HSV Sweep test video but this time did a "Right Click" --> "Input Colour Space" --> "Same as Timeline" and make sure "Bypass Color Managment" is unchecked.  Now DR will tone map this clip it to SDR Rec.2020 (as that is what we set the timeline as) for a comparison.

I've made a copy of this DR Project and uploaded it to Movieman's FTP site and I "presume" he will share a link with those that want it (else I'll put one up).

Thanks
Nathan

[Movieman]

I just asked Nathan to go ahead and put the files up for all, since my ISP keeps changing my IP address (and I don't always keep my FTP server up).

[jmone]

I've sent a PM to Hendrik and Niklas with a link.

[jmone]

One other important feature reading the Vectorscope is the Skin Tone Line (running from the center at about 11pm).  Here is an example of how it works (using some random photo off the net).  Regardless of the skin tone, it should fall along that line.  It should make it easier to confirm if you are actually seeing a "red push" on skin tones etc.

[haasn]

- Also added a 2nd instance of the 10,000nit HDR 2020 HSV Sweep test video but this time did a "Right Click" --> "Input Colour Space" --> "Same as Timeline" and make sure "Bypass Color Managment" is unchecked.  Now DR will tone map this clip it to SDR Rec.2020 (as that is what we set the timeline as) for a comparison.

Hold on, this step seems strange. I'm no expert in DR (actually, I've never used it) but setting Input Colour Space to "Same as Timeline" sounds like you're overriding the HDR clip's metadata to treat it as SDR instead. This is not the same thing as tone-mapping, and in fact, it will always generate a perfect vectorscope. For an accurate comparison against DR, don't you have to leave the source color space as HDR and uncheck the "Bypass Color Management" option?

By the way, while I think these vectorscopes show some serious flaws in the libplacebo algorithm implementation (and I'm starting to get a better idea of where to look), I think we also need to take them with a grain of salt because they are based on R/G/B/C/M/Y color model axes, which is not perceptually uniform. Libplacebo, after all, does tone-mapping in a perceptually uniform color space (IPT). We used to do tone-mapping in YRGB as well, but doing so actually introduces serious perceptual hue shifts and provides worse results (IMHO) than after the switch to IPT. But YRGB color management models will always look perfectly clean on a RGBCMY vectorscope, whereas IPT color models will always seem to result in weirdly curved lines.

That said, even just looking at it visually, it's obvious that the libplacebo result is seriously wrong (chopped off regions, harsh boundaries, ringing-like artefacts) even in principle (compared to a perfect IPT-space color mapping algorithm). I'll look further into why this is the case.

[jmone]

Hi Niklas,

EDIT:  Turns out the original settings I posted (use Timeline) will produce the same patterns as the default ICT was set to HDR.  It is still better practice to set each clip however such as below however.

To see how DR tone maps the 10,000Nit HDR HSV test pattern to the projects SDR 2020 setting:
- "Bypass Color Managment" should be OFF and the ICT set correctly (PQ ST2084? and NOT Timeline)  eg "Right Click" --> "Input Colour Space" --> "PQ" --> "ST2084".  Other option could be "Input Colour Space" --> "Rec2100" --> "Rec2100-ST2084" but this looks wrong as it clips in the waveform.  Attached is the updated screen shot.

All other clips should still be set to "Bypass Color Mgt" so the scopes will be displayed "as is" for the clips without Resolve doing anything.

Hoping I got it the right way around this time!

Thanks
Nathan

[jmone]

FWIW, in DR you can choose a couple of intermediate colour spaces for grading / editing that are much bigger than 2020 (either their own "DaVinci YRGB Colour Managed" or "ACES" workspace).  The workflow is to do the appropriate ICT on each clip to normalise them into this big colour space where all grading / editing is then done with an OCT at end of the pipeline to the desired colour space for the final rendering (all LUTless).  This way (in theory) is that you keep the same grading in the big colour space then just change the OCT as needed for an HDR, SDR or whatever output you need in a nondestructive way as nothing is baked in during the process.

I can't comment on the Pro's and Con's of IPT vs YRGB color management or what Resolve / ACES is really doing under the hood but Resolve is used for the colour grading of plenty of commercial releases. 

[Movieman]

Two things to be aware of:You need the paid version of DaVinci resolve to be able to import jmones' project

We also need to be aware that apparently there are 2 different versions of each of these patterns out there.  For example at 10,000 nits they are 00428.m2ts and 00429.m2ts.  Using Mediainfo, the only difference I see is:

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

Looking at the actual BT2020 frame (using Vegas Video, as Resolve doesn't seem to be able to import or open m2ts files) I see the same colored "blobs" on the left and right sides of the 429 patterns.
So, please let's make sure we are all using same version (the one without the blobs) for our work.

One additional point: 

I don't believe we should be using the 10,000 MCL patterns for testing as almost no actual UHD's are mastered at that level. I have only seen one clip at that level and that's the LG Cymatic Jazz demo.
I believe it makes more sense to concentrate on the correct mapping of the 4000 MCL and lower patterns.

[FenceMan]

Real world examples since everyone is looking here -

This is Spline, isn't this too red?


MadVR looks like this -


And HDR Toys developer is working on some new code that looks like this -

[Movieman]

Real world examples since everyone is looking here -

Absolutely too red. MadVR is closest to a natural skin tone of the three.  Even his T-Shirt is pink(ish) in the HDRToys clip.

[haasn]

Real world examples since everyone is looking here -

Can you throw me a dump of this frame somehow? (e.g.

Code: [Select]

ffmpeg -ss HH:MM:SS -i FILE -vframes 1 -vcodec copy -an dump.mkv)

[FenceMan]

https://www.dropbox.com/s/gf772f16ynsoh58/dump.mkv?dl=0

[Movieman]

Here is another set of examples:

Title: Mamma Mia

This includes the original frame extracted by ffmpeg (zipped) using the following:

Code: [Select]

D:\Apps\mpv_default\ffmpeg -ss 00:03:50.689 -i "F:\BDMV\STREAM\00016.m2ts" -vframes 1 -vcodec copy -an ffmpeg_capture.mkv
Then there are 3 sets of captures using the players capture and print screen  3 players were used JRiver, Zoom Player with MadVR and MPV.

The files are split between this post and the next.

[Movieman]

Remaining Files:

[jmone]

Two things to be aware of:You need the paid version of DaVinci resolve to be able to import jmones' project

It also may be that I'm running 18.5 Beta 3.  I "think" you can open a project between Studio and Free but the Database changed from 18 to 18.5 and the projects are not compatible.

We also need to be aware that apparently there are 2 different versions of each of these patterns out there.  For example at 10,000 nits they are 00428.m2ts and 00429.m2ts.  Using Mediainfo, the only difference I see is:

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

Looking at the actual BT2020 frame (using Vegas Video, as Resolve doesn't seem to be able to import or open m2ts files) I see the same colored "blobs" on the left and right sides of the 429 patterns.
So, please let's make sure we are all using same version (the one without the blobs) for our work.

Looks like there are 3!  I used 000430.m2ts as that as what Windows Resource Monitor was showing being accessed when I played the S&M disk.  I then remuxed just the main Video to MKV appending itself over and over till I had something that was 2min long (ish).  I'll have a look at 000429.m2ts.

One additional point: 

I don't believe we should be using the 10,000 MCL patterns for testing as almost no actual UHD's are mastered at that level. I have only seen one clip at that level and that's the LG Cymatic Jazz demo.
I believe it makes more sense to concentrate on the correct mapping of the 4000 MCL and lower patterns.

While I get the argument, the maths for the renderer should work for the entire possible 2020 colour space and luminance. 

Anyway, I think the method is good enough to show what each renderer is doing (EVR, madVR, Resolve, libplacebo) for Niklas and Hendrik to now ponder.

[jmone]

Real world examples since everyone is looking here -

This is Spline, isn't this too red?

MadVR looks like this -

And HDR Toys developer is working on some new code that looks like this -

And this is what these clips look like on the scopes for skin tone.  MadVR is too cool, Spine is better, but HDR Toys is bang on.

[mattkhan]

why is that scope "bang on"?

[FenceMan]

And this is what these clips look like on the scopes for skin tone.  MadVR is too cool, Spine is better, but HDR Toys is bang on.

HDR Toys looks really good all around.  Does it look better on the original scopes?

[jmone]

why is that scope "bang on"?

See that thin white line running from the center up at around 11 oclock.  Thats the Skin Tone line that you want your skin tones to fall onto.  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.  The Spline example is not too far off, and with a bit of a Tint correction in Resolve I can make the spline example look very similar to the HDR Toys one.  I have to apply a lot more on the madVR one.  There is also a slight exposure difference between the three complicating this (they are also slightly different frames)

[jmone]

HDR Toys looks really good all around.  Does it look better on the original scopes?

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.