INTERACT FORUM
More => Old Versions => JRiver Media Center 31 for Windows => Topic started by: Movieman on June 22, 2023, 01:19:10 pm
-
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, ;D but I do believe this is an important consideration for, at least, some of us.
Thanks again for a great product.
-
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.
-
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.
-
We promoted the build you need: https://yabb.jriver.com/interact/index.php/topic,136381.0.html
-
@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.
-
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
-
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.
-
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.
-
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. :o
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)
-
@ 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!!!).
-
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.
-
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.
-
....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).
-
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
-
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).
-
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?
-
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?
-
Auto is rec709 isn't it? If so, I think it's a compromised setup. A valid case but should be tested separately.
-
Anyway, here they are for the settings above for JRVR, madVR, and Resolve.
-
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!
-
Using different project settings in Resolve gives a different mapping but similar pattern to the output.
-
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.....
-
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
-
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.
-
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)
-
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.
-
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..
-
Hi Niklas!
Welcome! And thanks for your work on libplacebo!
For anyone who's curious about haasn ...
https://code.videolan.org/haasn
-
JRiver just sent haasn a Paypal donation. Anyone else? paypal_at_haasn.xyz
replace _at_ with @
-
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 :)
-
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
-
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).
-
I've sent a PM to Hendrik and Niklas with a link.
-
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.
-
- 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.
-
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
-
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.
-
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.
-
Real world examples since everyone is looking here -
This is Spline, isn't this too red?
(https://i.postimg.cc/t4S61B5m/Spline-181109.png) (https://postimg.cc/21WyMFg4)
MadVR looks like this -
(https://i.postimg.cc/8c4RZNRT/MadVR.png) (https://postimg.cc/N2y2MhCn)
And HDR Toys developer is working on some new code that looks like this -
(https://i.postimg.cc/6qf2Bcqc/HDR-Toys-181109-16-shadow.png) (https://postimg.cc/30WJBgg0)
-
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.
-
Real world examples since everyone is looking here -
Can you throw me a dump of this frame somehow? (e.g. ffmpeg -ss HH:MM:SS -i FILE -vframes 1 -vcodec copy -an dump.mkv)
-
https://www.dropbox.com/s/gf772f16ynsoh58/dump.mkv?dl=0
-
Here is another set of examples:
Title: Mamma Mia
This includes the original frame extracted by ffmpeg (zipped) using the following:
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.
-
Remaining Files:
-
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.
-
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.
-
why is that scope "bang on"?
-
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?
-
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)
-
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.
-
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.
-
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.
-
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. :)
-
@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 :) )
-
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.
-
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.
-
Thanks! that worked. Beer $ sent (also to Hendrik).
-
What about me?
-
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.
-
What about me?
https://www.youtube.com/watch?v=OzQKECQgjW8
Now what was the website that delivers chickens again? :)
-
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?"
-
Ahh what's life without a bit of fun? & Good luck getting those through Customs!
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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).
-
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.
-
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...
-
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:
(https://yabb.jriver.com/interact/index.php?action=dlattach;topic=136378.0;attach=47655;image)
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.
-
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.
-
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
-
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.
-
@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...) :)
-
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.
-
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.
-
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.
-
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.
-
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/
-
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.
-
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.
-
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.
-
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....
-
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?
-
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. :)
-
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 :-).
-
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?
-
@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)
-
Please don't spill discussions into multiple places. Just sign up and answer if you want to engage in a particular thread over there. :)
-
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).
-
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 (https://www.youtube.com/watch?v=b5ie-RTzeFw) side by side. Needs to really be viewed at 50hz. I've got NTSC examples as well.
Anyway, different rant!
-
Also, while on related topics, here is a good read on the differences between using LUTS Vs Transforms for colour space conversions (https://blog.frame.io/2020/04/27/luts-vs-transforms/).
-
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.
-
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 (https://www.dropbox.com/sh/eu6kf0epqtm3o5n/AADNMMK-AMeWY2V6Ct4qciFua?dl=0) 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.
-
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?
-
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.
-
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?)
-
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.
-
Thanks - that is what I was doing then started 2nd guessing. Is it worth greying out such options that don't apply at some point for clarity?
-
There is no way to really know if your screen is actually going to be in HDR mode and HDR output is active, which is why the SDR options don't vanish.
Or you might just be playing a SDR video.
-
seems sensible to disable the screen gamut option in the case when a 3dlut is present if that is unused
in my case then it converts BT2020 input to DCI-P3 (which should have minimal impact given there is not that much content outside P3) and then feeds that through the LUT, right?
-
Thanks, final question then (I hope). Is if you are in SDR mode (on the HDR Tab), what is the difference between DCI-P3-D65 and DCI-P3-D65 (in 2020) in the Screen Gamut (Calibration Tab). I get the latter, just not the former as I would have thought most displays are expecting either 709 or 2020, so limiting to P3 in 2020 makes sense, but are there displays that actually accept native P3?
-
JVC projectors have such a mode
-
Okay, I've been cooking up a series of improvements to the gamut/tone mapping algorithm:
- Linearly desaturate colors when greatly reducing brightness
- Remove the "chroma margin" as a result, leading to much more accurate gamut mapping for images with high dynamic range
- Nuke the LMS hybrid mixing completely (though I may re-introduce it with a low strength like 0.05)
- Make the perceptual hue shifting much stronger (starting at 70% of the color space's saturation range) to reduce the prevalence of weird hue discontinuities
Latest sample attached, this is with default settings (targetting BT.709 SDR). I think it's a massive improvement, just eyeballing it. Scope is still a bit funny, but then the scope will always be funny because we're doing perceptual / highly non-linear gamut mapping.
-
Okay, I've been cooking up a series of improvements to the gamut/tone mapping algorithm:
- Linearly desaturate colors when greatly reducing brightness
- Remove the "chroma margin" as a result, leading to much more accurate gamut mapping for images with high dynamic range
- Nuke the LMS hybrid mixing completely (though I may re-introduce it with a low strength like 0.05)
- Make the perceptual hue shifting much stronger (starting at 70% of the color space's saturation range) to reduce the prevalence of weird hue discontinuities
Latest sample attached, this is with default settings (targetting BT.709 SDR). I think it's a massive improvement, just eyeballing it. Scope is still a bit funny, but then the scope will always be funny because we're doing perceptual / highly non-linear gamut mapping.
Throwing this branch at a round of test stills I noticed it regresses the Mad Max lightning sample. Upon further investigation, I found that clipping inside the 3DLUT in IPT space (similar to how relative colorimetric clipping works) before applying the perceptual tone-mapper solves that problem, and also re-introduces some of the subjective "shift towards white" that was always part of the "intended look".
Makes HSV sweep look like this, for better or worse. I think I'm done for now. Will push this round of changes to libplacebo master very soon, then hopefully JRVR can get it soon.
-
Sounds good & thanks for all the work in such a short period of time. FWIW - here are the scopes for "HSV Latest" and "HSV Clipping". They do look cleaner than at the start of this thread, and while still funky on the scope the proof in the pudding will be on real content.
-
Visually, the result looks a lot more pleasing to me, in any case. The perceptual gamut mapping libplacebo does will never produce perfectly shaped vectorscopes, so the goal so far was to remove spikes and other odd shapes with increased precision, and work on the visual result.
I'll be updating MC with a new version of libplacebo this week, and also add a few new options that might help low-brightness/low-contrast cases like projectors, as setting the nits below the reference value is not really recommended. Not sure yet what I should do with that option at all, maybe shrink it and properly explain that it's not the same as madVR's setting.
-
I'll be updating MC with a new version of libplacebo this week, and also add a few new options that might help low-brightness/low-contrast cases like projectors, as setting the nits below the reference value is not really recommended. Not sure yet what I should do with that option at all, maybe shrink it and properly explain that it's not the same as madVR's setting.
FWIW, with latest libplacebo I think setting target-peak low is actually fine, and definitely good for projectors. See https://github.com/haasn/libplacebo/issues/175
-
Ok, I'll leave the option then. Many moving parts this week!
-
... the Mad Max lightning sample.
I do like your single frame dump method BTW:
ffmpeg -ss HH:MM:SS -i FILE -vframes 1 -vcodec copy -an dump.mkv
For consistency of testing, is there a "collection" of a few of these video samples we can download?
-
I do like your single frame dump method BTW:
ffmpeg -ss HH:MM:SS -i FILE -vframes 1 -vcodec copy -an dump.mkv
For consistency of testing, is there a "collection" of a few of these video samples we can download?
I have some here:
- random single frame samples that I personally use (https://snow.haasn.dev/~nand/hdr.txz)
- madVR test set (https://snow.haasn.dev/~nand/madvr.txz)
-
The next MC build incorporates all the recent libplacebo changes into JRVR.
I've also added some new options:
Output -> Contrast Recovery Strength, lets you tune the strength of contrast recovery. Higher values will have a bigger effect, but can lead to ringing.
Output -> Advanced HDR Settings -> Spline Contrast, lets you define the contrast of the spline tone mapping curve, which allows tuning the image for low contrast/brightness setups in particular, eg. projectors (need to specifically select Spline as the tone mapping curve for this to be available)
Advanced -> Use Tricubic Interpolation for gamut mapping, improved quality, but quite a bit slower.
-
Thanks Gents!
-
haasn, thanks for that test set. Used them with the latest (still in beta) JRVR. I do like the HFR Gemini Man movie, and with the clip, the results look terrific. Good Skin Tones, nice saturation and nothing clipping!
-
The Max Mad Fury Road sample however is not so good (lots of clipping). Hendrik tells me that this is weirdly mastered with lots of out of Gamut colours, but it really does look poor. I've also attached how Resolve handles it as a comparison.
-
It doesn't look quite that red to me. Since MC can't open single frame HEVC files, maybe something went wrong when you modified it?
-
Nope - just played it and hit pause straight away. Works with all of haasn's clips. To double check, just played my full copy and looks equally weird which is why I'm wondering if it is a setup issue??
-
Did a test by also turning off my 709 ICM profile in case that was it, and playing from the original UHD. Nope - same thing
-
Thanks Hendrik and all the others for the hard work. Gets better every new release. I love it. I don’t use madvr any more.
-
Im also very pleased, I just dont want to go back to madvr PC!
-
The Max Mad Fury Road sample however is not so good (lots of clipping). Hendrik tells me that this is weirdly mastered with lots of out of Gamut colours, but it really does look poor. I've also attached how Resolve handles it as a comparison.
The Resolve sample looks very undersaturated, are you sure it was correctly tagged as BT.2020? It almost looks like the clip was either bypassing color management or mistagged. That aside, where do you see clipping?
Concerning flames, it's an endless back-and-forth and question of tradeoffs regarding the question of whether or not turning red flames into orange is a desirable property, because the necessary mechanisms to accomplish that inevitably also shift hues of other things. The problem here is that the explosion is, in the HDR source, originally red. It's only through hollywood that we've become accustomed to seeing explosions as orange.
-
Yup, the resolve one looks undersaturated in general, but if we look at the main body of the explosion, Resolve has a range of hues from red to yellow while the JRVR is Red to pink in the main part of the explosion. I think the issue is that on the JRVR example the Red in the main part of the explosion has been hard clipped at around 81% (see the Waveform), whereas the Resolve one does not hard clip the red at all so we get different hues. As a comparison both samples look very similar in their hue for the fire trail that goes to the right, and neither is clipping. I've never seen a pink fire.
-
As a counter point. I know that many find this shot hard but it is great in JRVR. It's very saturated, uses all the dynamic range, does not have the hard clipping and just looks terrific to me!
EDIT: I had to scale this one down a bit as it exceeded the post size limit.
-
Double checked with a colour picker. All the "pink" areas correspond to where the red is clipped.
Here is a screen capture as I move the picker around --> https://1drv.ms/v/s!AkiTPpgNxBQVg4hb8jHZ6miUa8NJCA?e=wxVl2E
EDIT: and there is plenty of range above 81%
-
Hello,
For my Sony projector , SDR->60 nits measured with my Xrite Display Pro ( laser at 60% ) , it's better to use HDR-SDR tonemapping ou HDR-HDR Tonemapping ?
Thanks
-
Hello,
For my Sony projector , SDR->60 nits measured with my Xrite Display Pro ( laser at 60% ) , it's better to use HDR-SDR tonemapping ou HDR-HDR Tonemapping ?
Thanks
Try both and see which one is more pleasing to your eyes. I would say MC31 does a better job of tonemapping than the Sony.
-
No Sony projector has dynamic tone mapping so use SDR output
-
Any recommendations for a low light pj with the new features available?
I’m using an laser epson Ls10000 which is calibrated to dci-p95. At the moment I use 70 as target nit.
I’m talking especially about these features.
8. NEW: Added new options to JRVR for controlling tone mapping. Output -> Contrast Recovery Strength, Output -> Spline Contrast (advanced HDR settings), Advanced -> Use Tricubic interpolation for gamut mapping.
What are the best settings for my setup?
-
I'd add:
is conceptually correct to use the real target nits, as in MadVR? Visually is OK...
The renderer now looks very good, with better contrast and saturation vs MadVR, but, have to say, a bit of red push (clipping), is still there (IMHO)...
-
Everyone's environment is going to be unique. Projector NITS, Screen Size, Screen Gain, Room Treatment, Ambiant Light etc. So we all will need to dial it in for what looks good. Also I'd suggest just dialing in a quick setup at present as there is a heap of refinement of the code going on at present.... so expect continual improvement! Good times!
-
What about presets for some display devices? Eg: Projectors (Low 50-80 nits/ Medium 80-110 nits / High 110-150 nits / Custom)?
-
With as many variables in play, a preset would largely be quite similar to you just changing the brightness slider to match your setup.
-
I don't understand this answer. Increasing brightness also elevates the black floor. Tuning to accommodate your display's nits would not.
-
haasn asked me to post a test version using some brand new changes in gamut mapping. For faster turn-around, you just get the replacement libplacebo DLLs, for windows 64-bit
https://files.jriver-cdn.com/mediacenter/test/jrvr/libplacebo-290-linear_perceptual.zip
On top of MC 31.0.27 or newer, make sure to play a video first so everything is working, then navigate to "%appdata%\J River\Media Center 31\Plugins\libplacebo64" (you can paste that into explorer, without the quotes), and unzip the plugin in that directory, replacing the files in there (with the same names).
These are the changes from MR 490 on the libplacebo project website:
https://code.videolan.org/videolan/libplacebo/-/merge_requests/490
The changes simplify perceptual gamut mapping, and help solve issues with distorted hue.
Any feedback and testing is appreciated! As always we're looking for feedback on improvements, but also regressions, in comparison to 31.0.27/29.
-
Nice! The pink in MM is gone :) Using all the dynamic range without the hard clip, very saturated. Looks good.
-
Samsung Wonderland Rock gets a step up as well. The Pink Tint on the white house walls is even further reduced and I don't see any clipping. As before, very saturated using all the range. Looks great to my eyes (note: this one is 203nits, and the rest on "Default" settings" - The MM one was at 160nits and Spline as I forgot to reset to defaults for testing). I also had to scale this one down a bit as it was above the post limit size.
-
Gemini Man is still looking good!
-
Wow - handles this scene really really well. No loss of details in the highlights or the tones on the horses. Nice!
-
Also not seeing and "red push" on skin tones.
-
What's your output/screen config?
-
Another skin tone.
-
What's your output/screen config?
For this testing all the screen shots (bar the MadMax one) is set to what I think are the defaults of:
- Target Peak Nits : 203
- Enable Contrast Recovery when tone mapping @ 0.4
- Tone Mapping Alog : Auto-select
- Screen Gamut : Auto
- Gamma Processing : Disabled
- Calibration Method : Disabled
Are these the settings you are after? I've also not tried to find the "best" settings at this stage, just looking for stuff that looks "wrong". So far nothing as popped up to complain about!
-
I think the 2 main variables are nits (say 75 for a pj) and gamut (either DCI-P3 or bt2020 Vs rec709)
-
So my summary on the test clips, is a big "Thanks for a job well done" over the weekend on this. It is a big improvement on extreme clips without breaking anthing more "normal". In particular I think it addresses:
- Red Push (on faces)
- Pink Hues in Explosions (though my personal preference is still for a bit more to the yellow for higher nits tone - but that is just an observation)
- Pink Hues when next to red on the walls of those houses (there is still some but you really have to zoom in and it's only on certain walls).
- Good Skin tones (if anything may be a bit cool but again, no big issue)
- Great jobs on saturation and dynamic range without hard clipping highlights or shadows (horses in the snow, red rock)
Very pleased. I'll need to move off testing at a generic 203nits/709 and look at what settings works well for my:
- High Nit Flatscreens (OLED, and HDR1000 screens): maybe HDR to HDR tonemapping @ 700/1,000nits and P3in2020, as well as
- My JVC x7500: maybe HDR to SDR tonemapping @ 100 nits and P3in2020
.... but out of the box it is a great image.
Thanks again for all your work,
Nathan
-
I think the 2 main variables are nits (say 75 for a pj) and gamut (either DCI-P3 or bt2020 Vs rec709)
FWIW - had a quick look at the MM clip set still set to HDR to SDR tonemapping @ 80Nits then with various Screen Gamut Settings. The Screen Gamut choices of 709 / 2020 / P3-D65 / PD-D65 in 2020 all make a sigfificant difference. This shot is P3-D65 in 2020. I can see in the scopes that the Reds are clipping, but I actually prefer this look as it is more yellow in the high nits part of the explosion (but each to their own). Anyway, it will take some time to run through all of this on various setups.
I wish there was a way of taking HDR Screen Shots reliably!
EDIT - Did a test and staight P3-D65 is the closest to the original HDR for me. My ICC Profile is closer again however.
-
I wish there was a way of taking HDR Screen Shots reliably!
Well there is (at least on Win11). Win+Alt+PrtScn will save a PNG and an JXR (JPEG Extended Range) into your C:\Users\[username]\Videos\Captures folder. The PNG looks to be an SDR tonemapped version, and the JXR is a full HDR screenshot. Both are way to big too post on this forum, but for those interested here is a link to a screenshot of the Red Rock, with JRVR and Gamut Mapping - https://1drv.ms/u/s!AkiTPpgNxBQVg4hdUfynB_vH9jDN9g?e=OykdCA
No support for JXR in Resolve so I can not peak at scopes.
-
Concerning flames, it's an endless back-and-forth and question of tradeoffs regarding the question of whether or not turning red flames into orange is a desirable property, because the necessary mechanisms to accomplish that inevitably also shift hues of other things. The problem here is that the explosion is, in the HDR source, originally red. It's only through hollywood that we've become accustomed to seeing explosions as orange.
You are right. I've just started testing the HDR to HDR Tone and Gamut Mapping, and the MM Clip is absolutely all red hues. Not Pink. Not Yellow. I take back my comments about preferring the Yellow!
-
Here is another (final) test build which fixed some hue shifts around very bright elements, eg. sunlit clouds, etc, by re-introducing some stronger desaturation again.
It might have a small impact on other scenes, so any re-tests are appreciated. But as of right now this is a very significant improvement over the version currently shipping in 31.0.29
New version:
https://files.jriver-cdn.com/mediacenter/test/jrvr/libplacebo-290-gamut2.zip
Refer to the previous post for instructions and additional details:
https://yabb.jriver.com/interact/index.php/topic,136378.msg945282.html#msg945282
-
I just finished looking at a bunch of stuff with the (final) test build. Unfortunately, I still see the same issues.
The latest set of libplacebo dlls (-290) are installed in the JRiver31plugins directory.
The red push remains..... The main issue I see is that as the Target Peak Nits is decreased, the relationship between the colors are not being maintained. This is shown as the dark patches in red start disappearing sooner than the patches in the other colors. I'm not really sure what this actually signifies, all I see is that red is the most severely affected of the three primary colors as the TPN decreases..
I am attaching 6 files showing the results from using a value of 2000, 1000, 500, 250, 100, and 50 nits. Realistically, only the range 0f 150 nit's or lower would be usable on a projector and very bad things are happening to red, getting progressively worse as the TPM is lowered. Really, only 1000 or above show a reasonable balance between colors at higher luminance levels.
For this test I am using HDR to SDR mapping, with the projector set to Rec.709. I have also tried HDR to HDR with the projector set to BT.2020 and the results are an even more pronounced red push.
Using patterns from S&M V3 also show the same issue.
The capures were take taken with windows print screen to PNG files which were converted to jpgs for reasons of size. The jpg conversion had no effect on the images presented here. File names should be self explanatory.
-
The red push remains..... The main issue I see is that as the Target Peak Nits is decreased, the relationship between the colors are not being maintained. This is shown as the dark patches in red start disappearing sooner than the patches in the other colors. I'm not really sure what this actually signifies, all I see is that red is the most severely affected of the three primary colors as the TPN decreases..
I am looking at your screenshots, and I'm not really sure how you are arriving at that conclusion of red disappearing sooner.
If I look at the 50 nits screenshot, then red and blue seem to be pretty equal in progression towards higher source brightness, and both still very clearly defined against the background up until the maximum. If anything, green as the third primary is the one that loses definition faster, as well as the three secondaries.
To be clear, just wanting to make sure we're looking at the same things and not some other factors
-
I've been avoiding posting any test patterns given the comments from Hendrik and Haasn that they can look weird when doing perceptual tonemapping (but will have a look) with v290. In the ones above green is the primary that seems to be out of balance wit the other primaries (but this will impact hues of all colours).
Movieman, do you have a real work clip with the "red push" from v290 you can post so we can see.
-
I've been avoiding posting any test patterns given the comments from Hendrik and Haasn that they can look weird when doing perceptual tonemapping (but will have a look) with v290. In the ones above green is the primary that seems to be out of balance wit the other primaries (but this will impact hues of all colours).
Movieman, do you have a real work clip with the "red push" from v290 you can post so we can see.
I am completely lost on this red push thing, to me JRiver with the latest posted patch completely eliminates it vs the current MPV build -
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=410672fa-19e7-11ee-b5bd-6595d9b17862
-
OK - here is the HSV Sweep & Scopes for HDR to SDR 203nit FWIW (given I don't know how perceptual tone mapping should look on these patterns!). The sweep itself looks the best it ever has for Magenta-->Red-->Yellow-->Green-->Cyan. If I was to point at something, it would be that of the primaries, Blue is off axis. It looks to have similar relative strength (both peak and the reduced gamut) but is heading toward Cyan rather than blue.
Edit - Updated the screen shot as the Gamut was not 709 (now is).
-
I am completely lost on this red push thing, to me JRiver with the latest posted patch completely eliminates it vs the current MPV build -
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=410672fa-19e7-11ee-b5bd-6595d9b17862
That is what I pretty much see. I'll need to recheck on v290 but for skin tone I don't see a red push and if anything, it may be a touch cool (but not worth fiddling with).
-
I've been avoiding posting any test patterns given the comments from Hendrik and Haasn that they can look weird when doing perceptual tonemapping (but will have a look) with v290. In the ones above green is the primary that seems to be out of balance wit the other primaries (but this will impact hues of all colours).
Movieman, do you have a real work clip with the "red push" from v290 you can post so we can see.
Here is the ffmpeg capture. I've got a lot more stuff that I am about to post.
-
Here are a series of screen caps taken at differing TPN's
-
Here is the S&M 9 Box Skin Tone Clip. Original is HDR1000, tonemapped to SDR203. Checked the Skin Tones in the Original as well. All looks fine.
-
Here is the S&M 9 Box Skin Tone Clip. Original is HDR1000, tonemapped to SDR203. Checked the Skin Tones in the Original as well. All looks fine.
What is your TPN set to?
-
Here are the first three DaVinci results for the Mama Mia clip
-
The second three
-
What is your TPN set to?
TPN?
-
TPN?
Target Peak Nits.
-
Here is my clip of the MM shot @ SDR 203 (with scopes). Note that the Skin tones in the original are pushed heaps red as we;;. As usual the JRVR is more saturated overall compared to the resolve Tone Mapped version.
-
As posted - all testing has been to SDR 203nits
-
FWIW These are all the relevant JRVR settings I've been test with prior to then tweaking for my HDR and SDR screens.
For this testing all the screen shots (bar the MadMax one) is set to what I think are the defaults of:
- Target Peak Nits : 203
- Enable Contrast Recovery when tone mapping @ 0.4
- Tone Mapping Alog : Auto-select
- Screen Gamut : Auto
- Gamma Processing : Disabled
- Calibration Method : Disabled
Are these the settings you are after? I've also not tried to find the "best" settings at this stage, just looking for stuff that looks "wrong". So far nothing as popped up to complain about!
-
As posted - all testing has been to SDR 203nits
Which doesn't work for projectors.....
Everything I have posted so far is demonstrating what happens when you try to use a projector.
One more screen shot, look at the hard clipping. It's worst on the red but it's there on the green and blue as well. If you look at all the Davinci shots I posted, that red clipping is there at everyTPN.
-
Once more, looking at it with a different approach: Scopes to follow:
-
First set, check out the vectorscope
-
the rest......
That's it I'm done ;D
-
FWIW - here is the SDR 80Nits for me.
-
So on this 80nit version to me I see on the scope with the picker tool:
- Histogram: Only red clipping is in the darkest part of the Shot (The brunette's darkest hair) and you really can't see the impact of this
- Waveform: Nothing is clipping at the top end, but you can see a bit of black crush (same hair). There are no "weird" lines
- Vectorscope: Mine look pretty different to yours. You may want to try my "default" settings (posted above) but with 80nits to see how that looks?
-
So on this 80nit version to me I see on the scope with the picker tool:
- Histogram: Only red clipping is in the darkest part of the Shot (The brunette's darkest hair) and you really can't see the impact of this
- Waveform: Nothing is clipping at the top end, but you can see a bit of black crush (same hair). There are no "weird" lines
- Vectorscope: Mine look pretty different to yours. You may want to try my "default" settings (posted above) but with 80nits to see how that looks?
I was very close to your settings It does look different. Contrast recovery was .5. The blacks are slightly clipped and the gain is higher on my scopes. Hard to tell with different monitors, PJ's etc. Anyhow, I think we've had enough fun for the day.
-
I was very close to your settings It does look different. Contrast recovery was .5. The blacks are slightly clipped and the gain is higher on my scopes. Hard to tell with different monitors, PJ's etc. Anyhow, I think we've had enough fun for the day.
Yup fair enough! Visual fatigue gets me running in circles!
Also, while using scopes helps expose issues, the real measure is how pleasing movies look in real life and we all have different equipment, screens, room conditions, lighting etc etc in addition to the renderer and it's settings. I'm personally not trying to get JRVR to look like madVR (or vice versa). I'm after a pleasing image in MC that will work with my JVC x7500, OLEDs, and HDR1000 LCDs on HTPC's that range from the diminutive NUC to a 4090. So far JRVR really hits the mark for me in testing, but now I need to spend time on each of my HTPC setups in "real life".
-
I had an "aha" moment while eating dinner and I decided to try to replicate the success I have had with MPV on my RS3100 with JRiver.
So, if you have a newer JVC try this:
Set your JVC Content Type to "SDR"
Set your JVC Color Profile to BT.2020 (Normal)
Set your JVC Gamma to 2.4
Set your JRiver options and calibration settings per the attached screen shots.
Put on your favorite movie. Let me know what you think. Feel free to experiment......
(If the saturation still seems a little high, adjust the "Digital Vibrance" on the NVidia desk top settings to taste.)
-
I had an "aha" moment while eating dinner and I decided to try to replicate the success I have had with MPV on my RS3100 with JRiver.
So, if you have a newer JVC try this:
Set your JVC Content Type to "SDR"
Set your JVC Color Profile to BT.2020 (Normal)
Set your JVC Gamma to 2.4
Set your JRiver options and calibration settings per the attached screen shots.
Put on your favorite movie. Let me know what you think. Feel free to experiment......
(If the saturation still seems a little high, adjust the "Digital Vibrance" on the NVidia desk top settings to taste.)
After doing a little bit of sampling, I think I prefer setting the JRiver gamma to 2.4.....
@jmones' DCI-P3 is another valid choice. Set both JRiver and the PJ to DCI.
-
Just had a play with the build on:
HTPC1: NUC12Pro to a Sony OLED. The NUC does not have the grunt to Tone Map without dropping frames. So this one stays on basic HDR Passthrough.
MainPC: 4090 to 1000HDR LCDs. I'm HDR to HDR Tonemapping at 1,000nits and Reduce Gamut to DCI-P3-D65 (in BT.2020). The P3 in 2020 seems to be doing it's job. I've attached a link to the HDR Screenshots (both straight 2020 and also P3 in 2020) including the original Flower clip. With straight 2020, I'm clipping the Reds, and with P3 in 2020 I'm not. https://1drv.ms/u/s!AkiTPpgNxBQVg4hpOKZ9OsxRVRzZbw?e=oYve1s The good thing about this mode is on most clips, you don't see a difference as most will be P3 mastered anyway. Only a few of the test clips have colours outside of P3. I'll be leaving this one on.
TheaterHTPC: 3060 to a JVC x7500: TBA (will have a look tonight).
-
@movieman. Good to hear. There are so many places that the image settings can be tweaked, JRVR, nvidia, JVC! It's about finding what combo works best :) I'll play with the JVC tonight, but I'm pretty happy with the settings above for my flat screens (well I wish my NUC could do HDR tonemapping). FWIW, on the JVC x7500 I have to do HDR to SDR tonemapping else I get the "Magenta Bug" with HDR signals that JVC never fixed on this series.
-
Spent a couple of hours with the JVC x7500 and JRVR. Good news is the nvidia 3060 is powerful enough to run any combination of settings on material up to and including UHD 59.94 without dropping frames.
The first thing I did was to find what combination of JRVR and JVC processing works well together and correctly displays the HDR Clipping Test Pattern (after which I dialed in the Target Peak Nits). If you get the combination wrong between JRVR and the JVC, you can end up with situation where a print screen of the HDR Clipping Test Pattern will show all the detail of say the Red flashing boxs but the image displayed will show most of them are clipped out (like I think Movieman had with his earlier post). This is because the signal being sent from JRVR is not what the JVC is set for, hence showing a weird result.
To cut a long story short (and after watching the test clips and movies I'm familiar with) it turns out (on my setup) the following combination of settings looks great!
JRVR
- HDR to SDR Tonemapping
- Target Peak Nits = 110
- Screen Gamut = DCI-P3-D65 in 2020
JVC x7500
- Picture Mode = Cinema
- Colour Profile = Cinema 2
- Color Temp = 6500K
- Gamma = Normal
- Lamp Mode = High
Anyway, done for tonight!
-
@movieman. Good to hear. There are so many places that the image settings can be tweaked, JRVR, nvidia, JVC! It's about finding what combo works best :) I'll play with the JVC tonight, but I'm pretty happy with the settings above for my flat screens (well I wish my NUC could do HDR tonemapping). FWIW, on the JVC x7500 I have to do HDR to SDR tonemapping else I get the "Magenta Bug" with HDR signals that JVC never fixed on this series.
This is not quite the same. Not sending HDR to the PJ. Sending SDR with a BT2020 color space. Win 10 PC is set to SDR 10 bit yc limited range. PJ sees SDR 10 bit.
-
One for Hendrik - It would be great if we could get directly to the JRVR Config Window (as we can with madVR settings) as currently you end up with two windows open (the Options Window and then from that the JRVR Window). This make it hard on single screen setups to see the impact of changes you are making (plus you lose playback control). Thanks Nathan
-
This is not quite the same. Not sending HDR to the PJ. Sending SDR with a BT2020 color space. Win 10 PC is set to SDR 10 bit yc limited range. PJ sees SDR 10 bit.
Ahh that is pretty much what I'm doing on the JVC.
-
Ahh that is pretty much what I'm doing on the JVC.
OK, that's what works best for me. Regarding your earlier comment on the clipping pattern, the print screen exactly matched what I was seeing on the PJ. So, no mismatch on settings between the PC & the PJ.
-
What are the current recommended settings -
Target Peak Nits - should we define the real number here or adjust to taste? Is 203 the de-facto "auto" for libplacebo?
Tone Mapping Algorithm - should this be auto or spline
Contrast Recovery / Spline Contrast - set to taste?
Gamma Processing - disabled is recommended, is that the de-facto "auto" for libplacebo?
Calibration - disabled vs system wide if we do not have an ICC / 3dlut?
Appreciate the efforts to put us on the bleeding edge of libplacebo development.
-
Been using JRVR tone mapping for the first time. Using an lg-oled display to test it on. Once set up, I put on 'Ted lasso - S3 E5' The picture mainly looked great, but every now and then it looked a little dark. Generally when the scene was indoors. A time stamp, roughly 12mins 18seconds' (Rebecca is sat behind her desk) was very obvious. Using JRVR tone mapping the picture is dark. Use either my displays tone map or madVR and the picture is fine. Is this normal being in its infancy stage?
-
- Target Peak Nits = 250 (yup 250 - gives full coverage over the HDR Clipping Test Pattern and the higher nits means less tonemapping compromises)
that's just going to be (and is) really really dark, I can't see how that can possibly be a good compromise given it basically totally sacrifices luminance
-
Been using JRVR tone mapping for the first time. Using an lg-oled display to test it on. Once set up, I put on 'Ted lasso - S3 E5' The picture mainly looked great, but every now and then it looked a little dark. Generally when the scene was indoors. A time stamp, roughly 12mins 18seconds' (Rebecca is sat behind her desk) was very obvious. Using JRVR tone mapping the picture is dark. Use either my displays tone map or madVR and the picture is fine. Is this normal being in its infancy stage?
Make sure you have the latest build.
And read the thread, from about here: https://yabb.jriver.com/interact/index.php/topic,136378.msg944660.html#msg944660
-
Split the NUC12 performance discussion here:
https://yabb.jriver.com/interact/index.php/topic,136463.0.html
-
that's just going to be (and is) really really dark, I can't see how that can possibly be a good compromise given it basically totally sacrifices luminance
That's the (odd) thing with these setting. It's just not how it looks in real life with the latest JRVR.
I have a Seymour 120" diag screen, should be around 4m2 (gain is between 1.0 and 0.8 according to their spec). At best the JVC pumps out 1900lm or about 554nits per sqm. So in the most generous/optimistic max it could hit is a bit under 140nits across the surface (and in reality, will no doubt be a lot less). I used to run MC lower than this with a custom professional calibration that was done (now a few years back).
So in testing, I could find no combination of JRVR that look balanced on the HDR Clipping Test bars / HSV Sweep / Test Clips with my existing Custom JVC Profile (red in particular was clipped early on). So I started cycling through the built in JVC profiles and low and behold the Cinema looked pretty balanced but was clipping highlights till I raised the JRVR nits. Bit of back and forth while looking at not only the test patterns, the test clips (eg Mard Max, Horses in the snow, Samsung Red Rock etc etc) as well as my own content = the settings I posted.
The JVC and JRVR setting I posted is where I landed having the colours balanced while not clipping whites or crushing black. I can only conclude that what I'm seeing on screen is the combined processing of both JRVR and the JVC. I guess the next step would be to set JRVR to (say) 100nits and cycle through all the profiles again and see if there is some other combination that looks better, but I did not find it last night. I'm out tonight so probably will not get a chance for a bit.
-
Realistically you won't get anywhere near 140 but whatever the value, on the one hand it's a totally valid choice to prioritise highlights, on the other it's something like 25% (a guesstimate based on a couple of scenes so could be totally wrong) of the average output gone to make room for them. Absolute brightness is not perceived brightness but that's still a decent chunk of output gone.
-
Just to note that I think I am simply describing the dynamic target feature which, I think, libplacebo lacks hence making room for highlights in 1 scene means make everything in all scenes in all films dimmer (unless you setup a more complex profile / automation system to manipulate the target when playback starts)
-
For dark moody scenes, I was using the early scenes in Matrix. Most of the settings I was trying meant I could basically see nothing, but was fine with the settings I posted. I'll have a look again.... and also need to look at non HDR material (that I did not do). I'm now wondering if I'm tonemapping down to 250nits with JRVR, and the JVC is then simply tonemapping again to suit the profile / HW specs that it has.
-
You can also try experimenting with the spline contrast option. It would allow you to shift the balance between brightness and highlights a bit more.
I'm now wondering if I'm tonemapping down to 250nits with JRVR, and the JVC is then simply tonemapping again to suit the profile / HW specs that it has.
It would not be able to do this if you output SDR to it. SDR has no metadata or any absolute brightness meaning, so it can't make any deductions from it.
-
Just to note that I think I am simply describing the dynamic target feature which, I think, libplacebo lacks hence making room for highlights in 1 scene means make everything in all scenes in all films dimmer (unless you setup a more complex profile / automation system to manipulate the target when playback starts)
libplacebo does have this feature, it's just hidden from the user: https://code.videolan.org/videolan/libplacebo/-/blob/master/src/tone_mapping.c#L214
This code adjusts the target knee based on the source brightness, target brightness, and source scene average, which ends up determining the gain on the overall image. (A higher knee point = less headroom for highlights)
-
libplacebo does have this feature, it's just hidden from the user: https://code.videolan.org/videolan/libplacebo/-/blob/master/src/tone_mapping.c#L214
This code adjusts the target knee based on the source brightness, target brightness, and source scene average, which ends up determining the gain on the overall image. (A higher knee point = less headroom for highlights)
It's worth pointing out that this code was thrown together in half a day, so there's definitely room for improvement. Probably the first step would be to somehow expose these controls.
Maybe on a rainy day I'll add a bunch of user-facing configurable variables to the spline tone-mapper (ditto perceptual gamut-mapper) so we can start playing with the numbers and seeing what happens.
-
libplacebo does have this feature, it's just hidden from the user: https://code.videolan.org/videolan/libplacebo/-/blob/master/src/tone_mapping.c#L214
This code adjusts the target knee based on the source brightness, target brightness, and source scene average, which ends up determining the gain on the overall image. (A higher knee point = less headroom for highlights)
Ok great, is there any way to see that info? Either in the debug osd or by dumping it to a file?
-
You can also try experimenting with the spline contrast option. It would allow you to shift the balance between brightness and highlights a bit more.
It would not be able to do this if you output SDR to it. SDR has no metadata or any absolute brightness meaning, so it can't make any deductions from it.
I'll add it to the list to check. Something must be up (most likely me!).
-
Hello ,
I share my little work/tests last night - 31.0.29 .
JRVR Tonemapping HDR-SDR on my Sony XW5000 Projector ( full calibrated D65 - Gamma 2.2 - 55 nits mesured ) Laser at 60%- Radiance Screen 110' 0.6 Gain.
So Target Peak Nits : 60 Nits.
Contrast Recovery Strength : 0.9
Tone Mapping Algo : BT2390 ( is that correct ? )
Screen Gamut Auto
Scaling Upscaling Jinc - Chroma Bilateral Chroma Scaling
Scale In Sigmoidal Light
Super Res FSRCNNX 16
Downscaling Lanczos
Sharpening 75
Dithering Blue Noise
Use HDR Dynamic Peak Detection ON
Convert HLG ON
Tricubic OFF ( my NUC11PHKi7C is not enough powerful)
Result is absolutely great ! But a little too Red compared with MADVR .
With MadVR, NUC is at a full power , fans at 100 % , crap ..
With JRiver, quiet , quiet , so quiet, so great !
I have test HDR to HDR Tonemapping , too dark for my projector. Need to use laser at 80%/90% and so it become a bit noisy ..
Thank you very much for your work !
-
a few observations, testing on a recently calibrated (i.e. measures pretty accurate) JVC N7 in DCI-P3 mode
* 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
* the spline contrast ratio control is
a) v fiddly to use (doesn't respond to keyboard, v large steps)
b) the steps are probably too coarse (at 0.1), it makes v little difference at low values but at higher values each step is a really large change (so I think the control as is is probably not so useful)
c) high values mixed with relatively low TPN look absolutely crazy so don't go there :)
* going below about 75 on TPN looks really strange, like the vibrance dial has been turned upto 11
* IMV perceived brightness takes a really large hit by setting TPN to 250 on such a display (re @jmone's earlier testing), way too dark
* at almost any TPN, jrvr is obviously more "intense" (saturated) than madvr (alt+tab'ing between the two on the same scene), it's only at low TPN (<75?) that it looks really obviously and blatantly wrong.
Overall the picture just has too much of a shop display image quality to me at times, i.e. when shops put TVs in burn your face off mode to try to impress passers by. Generally this comes across as just a bit cartoon like and/or CGI in some scenes (a certain uncanny valley quality to it if you get what I mean). It's not in every scene but often enough to be noticeably a bit "off".
one or more of the following would make testing *much* easier btw, 1 is obviously more work than 2/3 but remote control (e.g. let MC on one machine control settings on another) would be really great
1) an MCWS call like LoadDSPPreset (to allow for remote updates to the config), even if just to set specific values (like TPN) for test purposes....
2) one click (or keyboard shortcut) access to JRVR settings
3) automatically select the active profile in the JRVR settings
-
* 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?
-
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
-
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.
-
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
-
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?
-
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
-
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.
-
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.
-
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)?
-
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.
-
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 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.
-
@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!
-
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.
-
The new Libplacebo is the version 29 ? Or I need to overwrite the files ?
-
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.
-
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.
-
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.
-
Cont'd
-
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. :D
-
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.
-
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.
-
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)
-
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. :D
When is 31 coming out?
-
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) (https://yabb.jriver.com/interact/index.php/topic,136154.0.html)" 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
-
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
-
Please don't start mpv discussion here. It's complicated enough already.
-
Question in advance of new version - will the new contrast setting affect anything else (existing 3d Lut or other)?
-
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
-
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.
-
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?
-
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
-
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.
-
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)
-
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.
-
"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.
-
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.
-
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)
-
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)
-
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.
-
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?
-
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.
-
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.
-
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:
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 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)!
-
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).
-
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:
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.
-
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.
-
When you say "bidirectional" do you mean SDR --> HDR tonemapping?!?!
-
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.
-
;D
-
First of all, congrats for all the progress on JRVR. I tried it with MC28 and it was very far off the mark, I skipped MC30, and I tried again with the latest MC31, and the improvement is impressive. :)
I still have a few issues that are set-up / calibration related:
Gamma Issues
Where do you specify the gamma response of the display, so that tonemapping can be done properly? PQ is absolute, not relative, JRVR needs to know the display gamma response to tonemap PQ to power gamma. My JVC NZ8 (RS3100) is calibrated to P3 / gamma 2.4 (very precisely, with an internal 1D LUT, so I know that the display gamma tracks 2.4 exactly).
In madVR, I simply specify that the display is already calibrated to P3 and gamma 2.4, and I get the expected results (correct colors, no black or white crush). With JRVR, there are issues with both black crush and highlights compression, especially when DTM is enabled.
If I specify a gamut of P3, the color are mostly correct, as long as I select a contrast of at least 10,000:1 (lower contrast values are way oversaturated, at least on my 100nits peak display, using a 100nits peak brightness value).
However, there is no way to get a correct gamma response. With gamma processing disabled and the actual native on/off contrast specified (custom / 30,000:1), there is sever black crush. If I specify 2.4 gamma processing (which isn't what I want, I only want to indicate the gamma response of the display/PJ), the black crush is still present. Even with gamma processing at 2.8, there is still significant black crush. I get closer if I select a 10,000:1 contrast (instead of the actual contrast), but there is still black crush. You can look the camp fire scene in the Revenant, most of the detail (that is meant to be visible) is lost.
DTM Issues
In order to display a dark scene such as the camp fire scene in The Revenant (strarting around 00:19:57, about 6 nits), you need to enable DTM in the advanced settings. However, as soon as DTM is enabled, it severely crushes highlights, leading to a loss of details that actually matter. For example, if you play Lucy, at the very beginning, just after the opening credits (from around 00:01:40), you'll see that the details on the cliff behind the caveman are crushed. More importantly, in the scene when she walks into the hotel lobby (around 00:05:30), all the details in the sky above the trees is completely lost with DTM. You should be hable to see a building, it's gone. I've selected "spine" which seems to be the best curve (BT2390 is completely off, not sure why it's even there).
So I guess my questions are:
1) How do you specify the gamma response of a calibrated display so that you don't get any black crush with a gamma 2.4 baseline?
2) How do you get JRVR to display dark scenes (such as the campfire scene in The Revenant) without losing brightness / saturation, which basically means enabling DTM as would be expected, but keep detail in bright scenes such as the Lobby entrance scene in Lucy?
These are just two examples, but these issues are present with all content.
I hope it's just me being unable to set JRVR properly, I really like what it does most of the time, and I haven't experienced any obvious oversaturation, but the black crush / wrong gamma and highlights compression when DTM is enabled are two deal breakers here.
I also have some 3D LUT questions but I'll start with the above for now.
Thanks!
-
Bump. any comment from Hendrick or Haasn on the above?
-
Manni, it's pretty hard to understand what's going on without seeing any screenshots or source frames to compare against.
I'm also confused by some of your comments, and it doesn't help that I don't know much about what libplacebo options the corresponding JRVR settings map to. For example, what do you mean by "If I specify 2.4 gamma processing (which isn't what I want, I only want to indicate the gamma response of the display/PJ), the black crush is still present."? Isn't that what the "gamma processing" option is meant for?
-
First of all, congrats for all the progress on JRVR. I tried it with MC28 and it was very far off the mark, I skipped MC30, and I tried again with the latest MC31, and the improvement is impressive. :)
I still have a few issues that are set-up / calibration related:
Gamma Issues
Where do you specify the gamma response of the display, so that tonemapping can be done properly? PQ is absolute, not relative, JRVR needs to know the display gamma response to tonemap PQ to power gamma. My JVC NZ8 (RS3100) is calibrated to P3 / gamma 2.4 (very precisely, with an internal 1D LUT, so I know that the display gamma tracks 2.4 exactly).
In madVR, I simply specify that the display is already calibrated to P3 and gamma 2.4, and I get the expected results (correct colors, no black or white crush). With JRVR, there are issues with both black crush and highlights compression, especially when DTM is enabled.
If I specify a gamut of P3, the color are mostly correct, as long as I select a contrast of at least 10,000:1 (lower contrast values are way oversaturated, at least on my 100nits peak display, using a 100nits peak brightness value).
However, there is no way to get a correct gamma response. With gamma processing disabled and the actual native on/off contrast specified (custom / 30,000:1), there is sever black crush. If I specify 2.4 gamma processing (which isn't what I want, I only want to indicate the gamma response of the display/PJ), the black crush is still present. Even with gamma processing at 2.8, there is still significant black crush. I get closer if I select a 10,000:1 contrast (instead of the actual contrast), but there is still black crush. You can look the camp fire scene in the Revenant, most of the detail (that is meant to be visible) is lost.
DTM Issues
In order to display a dark scene such as the camp fire scene in The Revenant (strarting around 00:19:57, about 6 nits), you need to enable DTM in the advanced settings. However, as soon as DTM is enabled, it severely crushes highlights, leading to a loss of details that actually matter. For example, if you play Lucy, at the very beginning, just after the opening credits (from around 00:01:40), you'll see that the details on the cliff behind the caveman are crushed. More importantly, in the scene when she walks into the hotel lobby (around 00:05:30), all the details in the sky above the trees is completely lost with DTM. You should be hable to see a building, it's gone. I've selected "spine" which seems to be the best curve (BT2390 is completely off, not sure why it's even there).
So I guess my questions are:
1) How do you specify the gamma response of a calibrated display so that you don't get any black crush with a gamma 2.4 baseline?
2) How do you get JRVR to display dark scenes (such as the campfire scene in The Revenant) without losing brightness / saturation, which basically means enabling DTM as would be expected, but keep detail in bright scenes such as the Lobby entrance scene in Lucy?
These are just two examples, but these issues are present with all content.
I hope it's just me being unable to set JRVR properly, I really like what it does most of the time, and I haven't experienced any obvious oversaturation, but the black crush / wrong gamma and highlights compression when DTM is enabled are two deal breakers here.
I also have some 3D LUT questions but I'll start with the above for now.
Thanks!
Do you mean the building right above her head? I can see it with both JRVR and MadVR.
(https://i.postimg.cc/R0CRpbhm/PXL-20230723-184520352-2.jpg) (https://postimg.cc/873Mj4LX)
Edit I can't find a gamma setting in JRVR that makes the building above her head or the one to the left of it disappear on my screen.
-
I checked the mountains above the caveman also and I don't see a difference between MadVR and JRVR. If you setup JRiver properly you can easily switch between JRVR and MadVR rendering to compare.
-
I tend to agree about the highlights problem, noticed some highlights blowing out while watching 2001 last night, various scenes rather than a one off.
-
Manni, it's pretty hard to understand what's going on without seeing any screenshots or source frames to compare against.
I'm also confused by some of your comments, and it doesn't help that I don't know much about what libplacebo options the corresponding JRVR settings map to. For example, what do you mean by "If I specify 2.4 gamma processing (which isn't what I want, I only want to indicate the gamma response of the display/PJ), the black crush is still present."? Isn't that what the "gamma processing" option is meant for?
Hi Haasn,
Thanks for your reply.
I'm sorry I can't help with the libplacebo command match, we'll have to wait for Hendrick for that.
I'm going to try to clarify what I mean.
Re gamma first, in order to tonemap PQ to power gamma, you need to tell the DTM algo what gamma curve the display /PJ is calibrated to. Without knowing that, there is no way to convert PQ to power gamma accurately. The actual gamma value doesn't matter, whether the display is calibrated to gamma 2.2, 2.4 or 2.6, as long as the DTM knows what it is, it should produce exactly the same picture.
In madVR, there is no need to enable any gamma processing. You simply specify that your display is already calibrated, and to which gamut and gamma. In my case, my display is calibrated to P3 / gamma 2.4. So I disable all gamma processing in madVR, and I simply specify that the display is calibrated to P3 / 2.4. madVR DTM then knows what my baseline is, and can gamutmap to P3 and tonemap PQ to gamma 2.4.
I'm assuming that up to that point all is clear?
The first issue I have with JRVR is that as far as I can see there is no option to specify the gamma target the display is calibrated to. So the only options are to play with the gamma processing (not ideal) and contrast otpions. The gamma processing option is not good or correct, because even when specifying the max value (2.8 ) there is still black crush. You can play with the contrast option, but with my actual native contrast (35,000:1) the picture is still way too dark. You have to lower contrast to 10,000:1 to get a still too dark but watchable picture. It's not possible to use any contrast value lower than 10,000:1 because even 10,000:1 creates an oversaturated picture, and the lower you get below that, the more oversaturated it gets.
In case this matters, I'm using video levels, not PC levels, so that might be part of the problem. So I guess my first question is whether there is a way to specify the gamma baseline for a calibrated display / PJ in libbplacebo, because it doesn't look like JRVR is using this at the moment. I have the correct levels specified in madVR (video 16-235), but I didn't see any such option in JRVR.
The second issue I have is that it's not possible to get good tonemapping with both very dark and even moderately bright scenes. If you enable the DTM option in JRVR advanced settings, you get decent tonemapping for very dark scenes, but the highlights are crushed. If you disable DTM, then the highlights are not crushed, but the dark scenes are way too dark and a lot of shadow detail and saturation is lost.
I can see how dificult it must be for you to comment on this without knowing which settings / options in libplacebo it concerns, but we're going to need Hendrik's help for that.
I can try to take screenshots but when I do (with printscreen) I see a mini bar at the top to select if I want a box or fullscreen, then the screenshot is saved, but I have no idea where. If someone tells me how to take screenshots, I'll take some with both madVR and JRVR to show the differences and why JRVR is incorrect both in the low end (due to the lack of a gamma baseline option) and high end (due to the DTM severely crushing highlights details).
-
I tend to agree about the highlights problem, noticed some highlights blowing out while watching 2001 last night, various scenes rather than a one off.
I assume you have DTM enabled in the JRVR advanced options. Try to disable it and select spline, it should resolve most of the highlights crush, but dark scenes will lose shadow detail and saturation.
I can't find a set of option with JRVR that allows to get both shadow details in very dark scnenes and highlights details in medium to bright scenes.
This was also the case in madVR at the very beginning of its DRM (I had long discussions with madshi about it), but it was resolved a long time ago and definitely not an issue anymore, even in old builds like build 113.
Obviously this is a lot more of an issue for projector users with 100nits peak or less. If you have 600nits or more on a flat panel, it's much less of an issue.
In 2001, you were most likely crushing the details on the planets, and also the floodlights when they discover the monolith.
I'm not mentionning any more specific scenes because the highlights crushing happens in ALL titles if DTM is enabled. So the Lucy scene (which isn't even a very bright title as it's a 1,000nits title) is enough for now.
-
Do you mean the building right above her head? I can see it with both JRVR and MadVR.
Edit I can't find a gamma setting in JRVR that makes the building above her head or the one to the left of it disappear on my screen.
Hi Fenceman, thanks for checking, but you're conflating the two issues. There is no gamma option that can cause issues with the highlights.
The Lucy screenshot is correct and shows the building detail I'm talking about. I assume that you haven't enabled the DTM option in the advanced settings, which is why you are not crushing the highlights and can see the building. Try to play the very dark scene I mention in "The Revenant", and - assuming you have around the same peak brightness as myself, around 100nits -- you'll see that shadow details are barely visible due to the lack of dynamic tonemapping. Enable the DTM option in the JRVR advanced settings, you should be able to see the campfire scene almost properly in The Revenant (bar the gamma issue mentioned), but then you'll have lost all the highlights detail in the Lucy scenes if you watch them again with DTM enabled.
-
Hi Haasn,
Thanks for your reply.
I'm sorry I can't help with the libplacebo command match, we'll have to wait for Hendrick for that.
I'm going to try to clarify what I mean.
Re gamma first, in order to tonemap PQ to power gamma, you need to tell the DTM algo what gamma curve the display /PJ is calibrated to. Without knowing that, there is no way to convert PQ to power gamma accurately. The actual gamma value doesn't matter, whether the display is calibrated to gamma 2.2, 2.4 or 2.6, as long as the DTM knows what it is, it should produce exactly the same picture.
...
I've tried changing every single available setting and nothing makes that house disappear on my screen, not calibration, not HDR, nothing? Are you on current version of JRVR?
Others will have to answer your calibration questions but I just follow the directions on the calibration screen, it literally says an ICC profile or 3dlut should be used so I created a bt.1886 709 .cube lut with Calman and JRVR gives me the option to tell it the lut is bt.709 and by.1886 I assume that is how it knows what to do with the conversion??
Even the advanced DTM setting doesn't change the house for me.
-
I've tried changing every single available setting and nothing makes that house disappear on my screen, not calibration, not HDR, nothing? Are you on current version of JRVR?
Others will have to answer your calibration questions but I just follow the directions on the calibration screen, it literally says an ICC profile or 3dlut should be used so I created a bt.1886 709 .cube lut with Calman and JRVR gives me the option to tell it the lut is bt.709 and by.1886 I assume that is how it knows what to do with the conversion??
Even the advanced DTM setting doesn't change the house for me.
I have disabled calibration for now, I'll talk about 3D LUTs when the basic setting options are resolved. My display (JVC NZ8) is already accurately calibrated with an internal 1D LUT for gamma 2.4 and the native gamut tracks P3 very closely. I could also use an autocaled preset that would be similarly accurate. I don't need a 3D LUT or an ICC profile to get very acceptable results with madVR. Once the baseline is set, I'll create a 3D LUT, but currently the baseline is completely wonky.
If the DTM option in advanced settings doesn't crush the highlights for you, then please post all your settings and what your display / projector is calibrated to.
Also please confirm that your peak brightness is 100nits or less, as obviously you won't crush highlights on a 1,000nits title if you have 1,000 peak nits or more (or even 500nits).
Yes I'm using the latest JRiver version (build 36) for JRVR, as mentioned in my first post.
-
I have disabled calibration for now, I'll talk about 3D LUTs when the basic setting options are resolved. My display (JVC NZ8) is already accurately calibrated with an internal 1D LUT for gamma 2.4 and the native gamut tracks P3 very closely. I could also use an autocaled preset that would be similarly accurate. I don't need a 3D LUT or an ICC profile to get very acceptable results with madVR. Once the baseline is set, I'll create a 3D LUT, but currently the baseline is completely wonky.
If the DTM option in advanced settings doesn't crush the highlights for you, then please post all your settings and what your display / projector is calibrated to.
Also please confirm that your peak brightness is 100nits or less, as obviously you won't crush highlights on a 1,000nits title if you have 1,000 peak nits or more (or even 500nits).
Yes I'm using the latest JRiver version (build 36) for JRVR, as mentioned in my first post.
My projector is calibrated to 150 nits 709 / 2.4 (I created a bt.1886 / 709 cube lut with Calman, full range per the instructions). Projector is set to Auto (which is full range PC). Sure you don't have a levels mismatch or something silly like that?
-
My projector is calibrated to 150 nits 709 / 2.4 (I created a bt.1886 / 709 cube lut with Calman, full range per the instructions). Projector is set to Auto (which is full range PC). Sure you don't have a levels mismatch or something silly like that?
As I said in my previous post, I'm set to use video levels. I haven't seen any option in JRVR to set the levels to video, which is also why I said it could be a video levels issue, as it could explain both the low end and high end issues.
The GPU is set to full, madVR is set to 16-235, and the JVC is set to 16-235.
How do you set the levels to 16-235 in JRVR?
-
As I said in my previous post, I'm set to use video levels. I haven't seen any option in JRVR to set the levels to video, which is also why I said it could be a video levels issue, as it could explain both the low end and high end issues.
The GPU is set to full, madVR is set to 16-235, and the JVC is set to 16-235.
How do you set the levels to 16-235 in JRVR?
I am not sure, I have always had my projectors in PC level. Grain of salt cell phone pic but I see nothing wrong with The Renavent either.
-
I am not sure, I have always had my projectors in PC level. Grain of salt cell phone pic but I see nothing wrong with The Renavent either.
Yes, I set the PJ to PC Levels (with gamma processing disabled and DTM enabled) and that resolves both the low end and high end issues.
So the two questions are:
1) How do you specify the gamma your display is already calibrated to?
2) How do you specify the video levels in JRVR?
Thanks for your help, at least we got somewhere :)
-
How do you set the levels to 16-235 in JRVR?
You don't. Thats not a supported setup, because you are essentially lying to the OS and the graphics card, which are always expecting to receive 0-255 values, and this setup has several downsides, since nothing else knows the correct levels.
Instead, set your OS/GPU to 16-235, and it'll all work as expected.
And the gamma is set with the gamma processing option. You are experiencing black crush because of your wrong levels, not because the option doesn't work.
"Display is already calibrated" in madVR of course also has to process the gamma, or its just lying to you. Otherwise SDR with a source gamma thats not 2.4 would just be wrong. For HDR this simply specifies the target gamma, since the original video is not in gamma.
-
You don't. Thats not a supported setup, because you are essentially lying to the OS and the graphics card, which are always expecting to receive 0-255 values, and this setup has several downsides, since nothing else knows the correct levels.
Instead, set your OS/GPU to 16-235, and it'll all work as expected.
And the gamma is set with the gamma processing option. You are experiencing black crush because of your wrong levels, not because the option doesn't work.
"Display is already calibrated" in madVR of course also has to process the gamma, or its just lying to you. Otherwise SDR with a source gamma thats not 2.4 would just be wrong. For HDR this simply specifies the target gamma, since the original video is not in gamma.
Thanks, makes sense. I’ll try to see if setting the PJ to auto and the HTPC to full (both GPU and madVR) works. In the past I had to set the PJ to limited as some sources would not be detected properly.
I’d rather have a full / full / full chain than a limited / limited / limited one as I don’t only do video playback with the HTPC, I also use it for gaming and video editing. At least with madVR there are some drawbacks to using RGB limited.
Good to know that the gamma processing option is the way to specify the gamma of the display, it didn’t seem to work but you are correct, that was because of the wrong levels.
Please could you confirm if the 3D LUT option works with any gamma target, of if it has to use a gamma 2.2 target for HDR tonemapping to work as with older madVR versions? I’ll try this next now that the baseline / setup issues are resolved.
-
The only thing I could determine for certain is that madVR passes SDR content entirely untouched into the 3DLUT.
What that means for applying a 3DLUT after tone mapping in madVR, I couldn't tell you.
To get parity between SDR content and tone mapped HDR content in JRVR, you should just leave the input tone curve of the 3DLUT on the default - a setting I should probably just remove.
The output of the 3DLUT in turn can then be whatever you like, as the 3DLUT fully controls it.
Note that using a 3DLUT entirely overrides the gamma option, as the 3DLUT is assumed to adjust the image to your display, if any adjustments are needed.
-
The only thing I could determine for certain is that madVR passes SDR content entirely untouched into the 3DLUT.
What that means for applying a 3DLUT after tone mapping in madVR, I couldn't tell you.
To get parity between SDR content and tone mapped HDR content in JRVR, you should just leave the input tone curve of the 3DLUT on the default - a setting I should probably just remove.
The output of the 3DLUT in turn can then be whatever you like, as the 3DLUT fully controls it.
Note that using a 3DLUT entirely overrides the gamma option, as the 3DLUT is assumed to adjust the image to your display, if any adjustments are needed.
Great, I’ll give the 3D LUT à try and I’ll report back if I notice anything unusual. Is the default BT1886? Yes you should remove it if it has to remain unchanged and if the LUT itself accepts any target and not just 2.2.
Looking forward to do some proper testing now that my JRVR set up issues are resolved and the picture looks as expected (with a gamma 2.4 for now).
Thanks again for your help, much appreciated, and congrats again on the improvements in JRVR with MC31, as you can imagine with the correct levels now it’s even more impressive :)
-
The only thing I could determine for certain is that madVR passes SDR content entirely untouched into the 3DLUT.
What that means for applying a 3DLUT after tone mapping in madVR, I couldn't tell you.
SDR content is feed as is into 3DLUT. Of course assuming there is 3DLUT loaded for given colorspace. Else madVR converts to most suitable colorspace and then apply 3DLUT.
HDR tone mapping in madVR always outputs with 2.2 gamma applied. And then apply 3DLUT on said output.
So 3DLUT has to be generated for 2.2 gamma input. For SDR content bt.1886 input would be better, but then it is not compatible with HDR tone mapping output. Maybe there is a way to load different 3dluts with profile system, but I never set it up like that.
if the LUT itself accepts any target and not just 2.2.
3DLUT itself is just a mapping between some input and your display. So it has to have specific input defined. Of course it can be transparent to user if 3dlut file have metadata specifying the input and data can be converted to correct representation before applying LUT. Important part is on the output anyway which defines your display characteristic. I don't know how it works in JRVR.
-
SDR content is feed as is into 3DLUT. Of course assuming there is 3DLUT loaded for given colorspace. Else madVR converts to most suitable colorspace and then apply 3DLUT.
HDR tone mapping in madVR, always outputs with 2.2 gamma applied. And then apply 3DLUT on said output.
So 3DLUT has to be generated for 2.2 gamma input. For SDR content bt.1886 input would be better, but then it is not compatible with HDR tone mapping output. Maybe there is a way to load different 3dluts with profile system, but I never set it up like that.
3DLUT itself is just a mapping between some input and your display. So it has to have specific input defined. Of course it can be transparent to user if 3dlut file have metadata specifying the input and data can be converted to correct representation before applying LUT. Important part is on the output anyway which defines your display characteristic. I don't know how it works in JRVR.
The statement in bold is not true anymore.
The gamma 2.2 requirements for a 3D LUT used to tonemap HDR content to SDR using pixel shader isn't necessary with the recent madVR builds and calibration software that use the new madVR calibration API, hence my question about having a 2.2 gamma target for the LUT or not. Recent versions of madVR (or Envy) can definitely deal with a non 2.2 gamma target for the 3D LUT, as long as the calibration software supports the new calibration API, which isn't the case for DisplayCAL AFAIK.
However both Calman and Colorspace can generate 3D LUTs for madVR/Envy used during HDR tonemapping that use a gamma target that isn't 2.2 (for example a gamma 2.4 target works fine and can be specified in the software).
My question was whether JRVR would handle these LUTs, or if it still had the gamma 2.2 target limitation when tonemapping HDR content to SDR. Hendrik doesn't seem to think it is the case.
-
The statement in bold is not true anymore.
The gamma 2.2 requirements for a 3D LUT used to tonemap HDR content to SDR using pixel shader isn't necessary with the recent madVR builds and calibration software that use the new madVR calibration API, hence my question about having a 2.2 gamma target for the LUT or not. Recent versions of madVR (or Envy) can definitely deal with a non 2.2 gamma target for the 3D LUT, as long as the calibration software supports the new calibrationAPI, which isn't the case for DisplayCAL AFAIK.
However both Calman and Colorspace can generate 3D LUTs for madVR/Envy that use a gamma target that isn't 2.2 (for example a gamma 2.4 target works fine and can be specified in the software).
Well, I don't know then. I don't see how "new calibration API" affects how the lut is applied, but maybe it does or maybe it just generates correct 3dlut, without telling you the details. madVR Envy is good at obfuscating how actually things work.
Nowadays I use my display ICC profile and let libplacebo generate LUT by itself. Good enough for my needs.
-
Can one of you please explain to me input vs output gamma with a 3dlut?
Which is the 3DLut Gamma on the JRVR calibrations options referring to?
I was assuming that I should put whatever I used to create the lut in that box. So when I create the lut with Calman I do bt.1886 and 709 so 1886 is what I put in that box, is this correct?
So in my case when watching UHD JRVR converts 2020 to 709 and then feeds it to the lut?
-
The setting in the JRVR settings refers to the input to the 3DLUT, the output is essentially unknowable and you can do whatever processing you like in it. Its also the last step in the display chain, so it doesn't really matter what the output is - thats going to your display regardless.
If you are trying to emulate settings from madVR, for SDR it should be set to BT.1886 (as thats essentially "untouched" in JRVR/libplacebo), and for HDR tone mapped to SDR, apparently 2.2? But 1886 might be better, as that then lets you use the same 3DLUT for both SDR and tone mapped HDR content.
-
The setting in the JRVR settings refers to the input to the 3DLUT, the output is essentially unknowable and you can do whatever processing you like in it. Its also the last step in the display chain, so it doesn't really matter what the output is - thats going to your display regardless.
If you are trying to emulate settings from madVR, for SDR it should be set to BT.1886 (as thats essentially "untouched" in JRVR/libplacebo), and for HDR tone mapped to SDR, apparently 2.2? But 1886 might be better, as that then lets you use the same 3DLUT for both SDR and tone mapped HDR content.
So by putting BT.1886 in that box I am telling JRVR to convert anything that is not BT.1886 to BT.1886?
-
If you are trying to emulate settings from madVR, for SDR it should be set to BT.1886 (as thats essentially "untouched" in JRVR/libplacebo), and for HDR tone mapped to SDR, apparently 2.2? But 1886 might be better, as that then lets you use the same 3DLUT for both SDR and tone mapped HDR content.
I don't see how madvr is relevant to the tone mapped case, doesn't it depend on libplacebo and how it converts from pq?
-
I don't see how madvr is relevant to the tone mapped case, doesn't it depend on libplacebo and how it converts from pq?
I think this is just assuming the influx of MadVR users want to do things that way. I am not trying to emulate MadVR just want to make sure I am understanding the proper setup for JRVR.
-
My point is it depends on how libplacebo works not how madvr works
If I compare to MPV, it sounds like it is --target-trv which describes auto as
auto
Disable any adaptation, except for atypical transfers. Specifically, HDR or linear light source material gets automatically converted to gamma 2.2, while SDR content is not touched. (default)
The presence of this option suggests that libplacebo can convert to different gamma but it's not clear how this equates to the multiple options in jrvr
-
My point is it depends on how libplacebo works not how madvr works
If I compare to MPV, it sounds like it is --target-trv which describes auto as
auto
Disable any adaptation, except for atypical transfers. Specifically, HDR or linear light source material gets automatically converted to gamma 2.2, while SDR content is not touched. (default)
The presence of this option suggests that libplacebo can convert to different gamma but it's not clear how this equates to the multiple options in jrvr
If that is the case then is BT.1886 in that box then incorrect for UHD's??
Also auto is not an option in the JRVR menu, you have to pick something.
-
The setting in the JRVR settings refers to the input to the 3DLUT, the output is essentially unknowable and you can do whatever processing you like in it. Its also the last step in the display chain, so it doesn't really matter what the output is - thats going to your display regardless.
If you are trying to emulate settings from madVR, for SDR it should be set to BT.1886 (as thats essentially "untouched" in JRVR/libplacebo), and for HDR tone mapped to SDR, apparently 2.2? But 1886 might be better, as that then lets you use the same 3DLUT for both SDR and tone mapped HDR content.
Looking at the JRiver keyboard hot-keys (https://wiki.jriver.com/index.php/Keyboard_Hot-keys), I can't see one to change profiles or to enable/disable the 3D LUT with JRVR. Unless I've missed them, have they been added, and if not would it be possible to add these as a feature request? Thanks!
-
I don't see how madvr is relevant to the tone mapped case, doesn't it depend on libplacebo and how it converts from pq?
As we are comparing tone mapping with madVR most of the time, also the settings and how to translate madVR config to libplacebo or JRVR is a valid discussion, as things are confusing sometimes.
So by putting BT.1886 in that box I am telling JRVR to convert anything that is not BT.1886 to BT.1886?
Yes, before applying 3DLUT. Then 3DLUT is applied to translate it to whatever is encoded in 3DLUT. In our usecase, it will be your measured display response.
-
Looking at the JRiver keyboard hot-keys (https://wiki.jriver.com/index.php/Keyboard_Hot-keys), I can't see one to change profiles or to enable/disable the 3D LUT with JRVR. Unless I've missed them, have they been added, and if not would it be possible to add these as a feature request? Thanks!
It's been requested, hasn't been added yet
-
Yes I know it's a valid discussion but it's also irrelevant in the specifics, the only thing that matters for getting a correct result is exactly how libplacebo is configured and what it can do.
This is still unclear at this point, again using mpv as a guide it says a target-lut is applied after conversion to target-trc. Is jrvr 3dlut source gamma setting the same thing in libplacebo as target-trc does in mpv? If so, it implies libplacebo can target different gammas for HDR and the correct setting is driven by your 3dlut. Ultimately just clarifying, and documenting, this point about jrvr would clear up some confusion (as I think this is at least the 3rd or 4th conversation on the same topic!)
-
It's been requested, hasn't been added yet
Thanks!
-
If so, it implies libplacebo can target different gammas for HDR and the correct setting is driven by your 3dlut.
The 3DLUT does not convey any information how it was created. And the two input dropdowns are there to inform JRVR how it was created and what data should be send into it. Accordingly to those, the image will be converted beforehand. For SDR, BT.1886 is basically "untouched", as that is assumed to be the BT.709 transform, unless a file indicates otherwise. For tone mapped HDR, you can pick whatever you like, but to stay similar to originally SDR content, just using the same would be smart, as in theory a SDR calibration should not apply differently to tone mapped content, no?
-
The 3DLUT does not convey any information how it was created. And the two input dropdowns are there to inform JRVR how it was created and what data should be send into it. Accordingly to those, the image will be converted beforehand. For SDR, BT.1886 is basically "untouched", as that is assumed to be the BT.709 transform, unless a file indicates otherwise. For tone mapped HDR, you can pick whatever you like, but to stay similar to originally SDR content, just using the same would be smart, as in theory a SDR calibration should not apply differently to tone mapped content, no?
I am still confused? The drop down boxes on JRVR are for what we want inputed into the 3dlut and whatever we want the 3dlut to output is dependent on how it was setup?
So if I were to setup a P3-D65 / BT.1886 lut, put that in the drop down boxes then play a Blu Ray rip JRVR would convert 709 to P3-D65 then feed it to the lut?
-
So if I were to setup a P3-D65 / BT.1886 lut, put that in the drop down boxes then play a Blu Ray rip JRVR would convert 709 to P3-D65 then feed it to the lut?
Yes.
-
Ok then it does sound like it is equivalent to --target-trc and should be set based on however you created your lut. Given this, it doesn't sound like this is a setting you should hide, for HDR at least whereas for SDR it sounds like it would be fairly unusual to change it
-
Ok then it does sound like it is equivalent to --target-trc and should be set based on however you created your lut. Given this, it doesn't sound like this is a setting you should hide, for HDR at least whereas for SDR it sounds like it would be fairly unusual to change it
If I want BT.1886 sent to my projector then the lut would have to be setup for BT.1886 (output) and we would also have to send BT.1886 into the lut correct? The lut is not going to convert gamma or colorspace is it? So the drop down boxes should always match what the lut is setup for which is what is ultimately going to be sent to the display?
-
Ok then it does sound like it is equivalent to --target-trc and should be set based on however you created your lut. Given this, it doesn't sound like this is a setting you should hide, for HDR at least whereas for SDR it sounds like it would be fairly unusual to change it
Why would you want to use a different target then native SDR however? It would just mean you need different LUTs. When using a LUT, the setting here is not directly related to your output, so it could be anything.
-
What does "native SDR" mean exactly in this context?
-
Matching a file that starts out as SDR. Any other target would just add complications for no reason.
-
Matching a file that starts out as SDR. Any other target would just add complications for no reason.
What if your display is wider than BT.709 gamut?
-
I would assume most people are not likely to change gamut mode of their display between files - although i'm sure some are.
In the simplest case, you would have one 3DLUT thats designed for whichever gamut you run your display in, and if the input is SDR, or tone mapped HDR, should not really matter, as at that point both are SDR.
If you want to do more per-content fine tuning, there is always profiles to setup.
-
Plus we can already do HDR --> SDR-P3 or SDR-2020
-
Matching a file that starts out as SDR. Any other target would just add complications for no reason.
Practically speaking, Say I want a 2.4 output, why go PQ -> SDR gamma (bt1886) -> 2.4 ? ie why bother with the intermediate step?
Typically more stages introduces potential for artifacts but I have no idea whether that is the case here or not (I guess there is no problem assuming sufficient numeric precision is used)
The other thought is why does libplacebo appear to default to converting HDR to 2.2 rather than a rec709 gamma? Presumably there's a reason for that choice?
I do use profiles and separate luts btw for SDR and HDR. I spent a bit of time wading through displaycal code last night and I suspect it agrees with you, ie expects a rec709 gamma to be the input gamma for any SDR lut irrespective of colourspace. Code is not the easiest to follow so could be wrong but certainly seems that way to me.
-
The other thought is why does libplacebo appear to default to converting HDR to 2.2 rather than a rec709 gamma? Presumably there's a reason for that choice?
libplacebo default is also Rec.1886. Probably a mix up between mpv docs and libplacebo defaults, or mpv overrides the default.
-
libplacebo default is also Rec.1886. Probably a mix up between mpv docs and libplacebo defaults, or mpv overrides the default.
are you sure?
from what I could see
auto in MPV becomes PL_COLOR_TRC_UNKNOWN (https://github.com/mpv-player/mpv/blob/master/video/out/placebo/utils.c#L135C44-L135C64)
PL_COLOR_TRC_UNKNOWN is treated as meaning gamma 2.2 (https://code.videolan.org/videolan/libplacebo/-/blame/master/src/shaders/colorspace.c#L665)
I don't know what precision such a processing pipeline operates in so no clue if the extra conversion has any impact, a quick google suggests single precision float so probably sufficient to be a non issue?
-
More relevantly (as well as infer_both_ref below that):
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/colorspace.c#L610-611
In the actual image processing, it should never be unknown, as it gets inferred to a proper value earlier.
You can easily test this by swapping between disabled/unknown and specifically selecting 1886 or 2.2 in gamma processing, disabled does in fact set it to unknown.
-
Ah ok, thanks for clarifying
As for correct use of displaycal for this case, I would really like to be able to measure this to be sure but measuring a tone mapped image looks tricky as the tone mapping itself distorts the image. I wonder is there a way to construct an image that goes through the same processing but essentially passes through the tone mapping untouched?
-
I wonder is there a way to construct an image that goes through the same processing but essentially passes through the tone mapping untouched?
Well, you have to convert at some point if the data is not representable in your target format. `clip` mode is the closes to untouched as it will clip out of range values, leaving the rest as is.
Practically speaking, Say I want a 2.4 output, why go PQ -> SDR gamma (bt1886) -> 2.4 ? ie why bother with the intermediate step?
It is only your choice, how advance and complex your setup is. You can have multiple 3DLUTs for each colorspace that converts to target display and even can change manually display settings for different content. (and you will not see any difference in the end...)
One thing to remember if you use 3DLUT to change gamut (i.e. bt.2020 to bt.709) you will skip libplacebo's fancy gamut mapping code. And rely on the algorithm of the software that was used to generate 3DLUT.
Also it is little bit incorrect to say "convert with 3DLUT to bt.709", because in practice if we are talking about measured display characteristics, it can be "close to" bt.709, bigger or smaller. Point being we are converting to display response, not really any defined colorspace. Of course depending on the settings/calibration it may be very close to reference, but still...
-
Not sure if we're talking about the same thing, I am just talking about the gamma not the colourspace. In this example it's taking HDR in, libplacebo converts to dci-p3 d65 with rec709/bt1886 gamma and then the lut is tweaking colours within that same colourspace while also adjusting the gamma to 2.4. My question is whether there is any advantage to having libplacebo convert to dci-p3 d65 with 2.4 gamma and then the lut just tweaks colours.
The only difference I can think of is if the extra conversion step introduced precision issues but I am not an expert in this field so that's just a guess
-
Not sure if we're talking about the same thing, I am just talking about the gamma not the colourspace. In this example it's taking HDR in, libplacebo converts to dci-p3 d65 with rec709/bt1886 gamma and then the lut is tweaking colours within that same colourspace while also adjusting the gamma to 2.4. My question is whether there is any advantage to having libplacebo convert to dci-p3 d65 with 2.4 gamma and then the lut just tweaks colours.
I would argue there is no difference in practice. Using bt1886 for SDR is better, because it can apply directly to SDR content and converts it to your target 2.4. And for HDR "extra step" wouldn't be noticeable. Not really an extra step, because you wouldn't do conversion from PQ directly anyway, it is just a question how many 3DLUTs you want to generate :). Using 3DLUT close to display is probably more universal as it doesn't assume any input content, just tweak the colors in the last step as you said.
I think we are splitting the hair here, there is not much difference in practice.
-
I would argue there is no difference in practice. Using bt1886 for SDR is better, because it can apply directly to SDR content and converts it to your target 2.4. And for HDR "extra step" wouldn't be noticeable. Not really an extra step, because you wouldn't do conversion from PQ directly anyway, it is just a question how many 3DLUTs you want to generate :). Using 3DLUT close to display is probably more universal as it doesn't assume any input content, just tweak the colors in the last step as you said.
I think we are splitting the hair here, there is not much difference in practice.
If I have 88% of P3 on my projector would it be better to create a P3-D65 lut or Rec 709?
-
If I have 88% of P3 on my projector would it be better to create a P3-D65 lut or Rec 709?
Honestly you would likely just want to compare the visuals and see what you prefer. You could also get a ICC profile for your exact projectors capability and JRVR would be able to adapt the gamut to that space perfectly.
-
I'm now even more confused as to what the right option is having reviewed exactly what displaycal does when generating a lut :)
specifically, if I generate a SDR LUT in displaycal with a DCI-P3 D65 colourspace then, as far I can tell, it is configuring the input side of the LUT generation to expect a 2.6 gamma with a BT1886 adjustment but with a blackpoint of 0,0,0 which seems to mean it just expects a pure power 2.6 gamma.
it's slightly surprising to me and I could be wrong but it's also quite logical given what I can see in the code
how to translate this to JRVR though? specifically, how does the contrast setting interact with the 3dlut source gamma? I think BT1886 with a 0 blackpoint is basically equivalent to a 2.4 gamma isn't it? if so it means the right option, for my tonemapped HDR use case, would appear to be a 2.6 input.
-
I'm now even more confused as to what the right option is having reviewed exactly what displaycal does when generating a lut :)
specifically, if I generate a SDR LUT in displaycal with a DCI-P3 D65 colourspace then, as far I can tell, it is configuring the input side of the LUT generation to expect a 2.6 gamma with a BT1886 adjustment but with a blackpoint of 0,0,0 which seems to mean it just expects a pure power 2.6 gamma.
it's slightly surprising to me and I could be wrong but it's also quite logical given what I can see in the code
how to translate this to JRVR though? specifically, how does the contrast setting interact with the 3dlut source gamma? I think BT1886 with a 0 blackpoint is basically equivalent to a 2.4 gamma isn't it? if so it means the right option, for my tonemapped HDR use case, would appear to be a 2.6 input.
This might be because DC is targetting Cinema DCI, not consumer P3 (which doesn't really mean anything, as only rec709 and BT2020 are used in consumer content). Did you check the white point as well to see if it was D65?
I don't use DC, but there are no such issues with Calman or Colorspace, you can target any gamut/gamma/white point. I'll make an attempt to create a P3 BT1886 D65 3D LUT when I find the time and I'll report back.
To answer your question, BT1886 with 0 black is 2.4 power indeed. The gamma target only change (especially in the lower end) of the BT1886 curve when black is non-zero. The higher the black floor, the lower the gamma targets in the low end, to get out of black faster.
-
This might be because DC is targetting Cinema DCI, not consumer P3 (which doesn't really mean anything, as only rec709 and BT2020 are used in consumer content). Did you check the white point as well to see if it was D65?
actually that 2.6 is a user setting which displaycal defaults to when you select DCI-P3 D65 (seems like a bug), the whitepoint is D65 though. This gamma gets put on the input profile that goes into collink. It's curious because that would seem to suggest the source gamma in JRVR should match that set in displaycal yet previous testing said this produced v wrong output. I'll have to retest that to check.
-
Instead, set your OS/GPU to 16-235, and it'll all work as expected.
I'm surprised by this. I thought you should never use Limited for the GPU as that causes the GPU to compress the Full range input into Limited, and the GPU doesn't do a particularly great job at this.
Video is of course Limited (Black=16 White=235), and so your media player can also be set to not touch it, then setting the GPU to Full is in essence passthrough of the Full 0-255 signal. Then you set your display to Limited, thus telling the display to interpret 16 as black and 235 as white which is where they are located within the Full range signal coming from the GPU.
If you set your GPU to Limited, then when the Limited video comes in (within its Full container), the GPU will compress Full -> Limited and then that will make 16 go to 32, and 235 go to 219.
Correct:
https://kodi.wiki/images/3/30/Qngr5Fh.png
Wrong:
https://kodi.wiki/images/8/8b/MEltJKj.png
-
I'm surprised by this. I thought you should never use Limited for the GPU as that causes the GPU to compress the Full range input into Limited, and the GPU doesn't do a particularly great job at this.
Video is of course Limited (Black=16 White=235), and so your media player can also be set to not touch it, then setting the GPU to Full is in essence passthrough of the Full 0-255 signal. Then you set your display to Limited, thus telling the display to interpret 16 as black and 235 as white which is where they are located within the Full range signal coming from the GPU.
If you set your GPU to Limited, then when the Limited video comes in, the GPU will compress 16 to 32, and 235 to 219.
Correct:
https://kodi.wiki/images/3/30/Qngr5Fh.png
Wrong:
https://kodi.wiki/images/8/8b/MEltJKj.png
Agreed in principle, that why I decided to go for GPU full / madVR full / JVC full (with the JVC set to auto). Seems to work fine for now, as this resolves the levels issues in JRVR, which follows the GPU settings re full or limited. I haven’t tested all my sources, but it looks like a better solution than limited / limited / limited.
-
Video is of course Limited (Black=16 White=235), and so your media player can also be set to not touch it,
"not touching" it is a misconception, though, because the YCbCr-> RGB conversion already touches everything about it, all you do is change the coefficients of that conversion math a bit. Its not less precise to do that, and its not a separate step. If anything its slightly more precise to use the full range of values, although that difference is marginal.
The thing is that PCs are inherently full range, and they only deal with full range images. If you present anything else to the OS, you lie to it about what kind of image you send. And the end result is that anything thats not video gets clipped. So any overlays get clipped. Any other content on the PC gets clipped.
This is a terrible solution for a rumor of a bad quality conversion.
Its easy to test. Can you tell the difference?
Ideally you would use full-range everywhere, as that has none of the disadvantages.
The "Wrong" situation you described will also never happen, unless you misconfigure the system by using limited twice. Its the video renderer's responsibility to render all content to full range. There will never be "limited video within its full container" at that point.
-
"not touching" it is a misconception, though, because the YCbCr-> RGB conversion already touches everything about it, all you do is change the coefficients of that conversion math a bit. Its not less precise to do that, and its not a separate step. If anything its slightly more precise to use the full range of values, although that difference is marginal.
The thing is that PCs are inherently full range, and they only deal with full range images. If you present anything else to the OS, you lie to it about what kind of image you send. And the end result is that anything thats not video gets clipped. So any overlays get clipped. Any other content on the PC gets clipped.
This is a terrible solution for a rumor of a bad quality conversion.
Its easy to test. Can you tell the difference?
Ideally you would use full-range everywhere, as that has none of the disadvantages.
The "Wrong" situation you described will also never happen, unless you misconfigure the system by using limited twice. Its the video renderer's responsibility to render all content to full range. There will never be "limited video within its full container" at that point.
Correct, it was an over-simplification. I meant simply not touching the levels.
The 3 workable ways to set a video chain up are full-full-full, limited-full-limited, and finally full-limited-limited.
So it seems you suggest the last, but that has 2 conversions, and in my prior testing I have seen it introduce banding where the other methods did not. I blame the GPU conversion to limited as what caused the banding, because it's not present when doing full-full-full or limited-full-limited, so I don't think it's the media player or display end.
But perhaps that is only in certain cases and things change from gpu generation to generation and between gpu driver versions too.
-
SDR content is feed as is into 3DLUT. Of course assuming there is 3DLUT loaded for given colorspace. Else madVR converts to most suitable colorspace and then apply 3DLUT.
HDR tone mapping in madVR always outputs with 2.2 gamma applied. And then apply 3DLUT on said output.
So 3DLUT has to be generated for 2.2 gamma input. For SDR content bt.1886 input would be better, but then it is not compatible with HDR tone mapping output. Maybe there is a way to load different 3dluts with profile system, but I never set it up like that.
3DLUT itself is just a mapping between some input and your display. So it has to have specific input defined. Of course it can be transparent to user if 3dlut file have metadata specifying the input and data can be converted to correct representation before applying LUT. Important part is on the output anyway which defines your display characteristic. I don't know how it works in JRVR.
The statement in bold is not true anymore.
The gamma 2.2 requirements for a 3D LUT used to tonemap HDR content to SDR using pixel shader isn't necessary with the recent madVR builds and calibration software that use the new madVR calibration API, hence my question about having a 2.2 gamma target for the LUT or not. Recent versions of madVR (or Envy) can definitely deal with a non 2.2 gamma target for the 3D LUT, as long as the calibration software supports the new calibration API, which isn't the case for DisplayCAL AFAIK.
However both Calman and Colorspace can generate 3D LUTs for madVR/Envy used during HDR tonemapping that use a gamma target that isn't 2.2 (for example a gamma 2.4 target works fine and can be specified in the software).
My question was whether JRVR would handle these LUTs, or if it still had the gamma 2.2 target limitation when tonemapping HDR content to SDR. Hendrik doesn't seem to think it is the case.
Apologies to Kasper93 and anyone I might have unintentionally misled, he was correct and I wasn't (I haven't done much calibration with madVR over the last two years, and when I did I guess it was with a 2.2 gamma target when HDR content was involved).
I tested this yesterday with both Calman and Colourspace (latest versions) and madVR build 169.
Using a gamma target different from 2.2 for a 3D LUT used to tonemap HDR to SDR is only available/possible in Colorspace and Calman with Envy. It's not available for madVR, even with the most recent builds.
So if you're using madVR (even the most recent experimental versions), the old advice of only using a 2.2 gamma target for the 3D LUT used during tonemapping with pixel shader still stands. The gamut of the baseline (selected in the display / projector) doesn't matter, though the closer you are to 2.2, the less work the LUT has to do. And the fact that you have to select 2.2 doesn't matter either from a picture point of view: PQ is absolute, not relative, so you'll get the same picture irrespective of the 3D LUT target (2.2, 2.4, 2.6 etc), as long as madVR/Envy knows what it is (hence why it has to be 2.2, as that's the fixed value madVR expects for accurate HDR to SDR tonemapping when a 3D LUT is present).
With Envy, if you don't use a 2.2 target, you need to specify it in the HDR options in Colourspace. It's automatic in Calman as it uses the gamma target set for the calibration. You can select only select a different gamma target in this situation with sofware that supports Envy new calibration API (so only recent Colorspace and Calman AFAIK, as I don't think DisplayCAL has been updated to support that new Envy API).
Again, this is only for a 3D LUT used for HDR to SDR tonemapping with pixel shader.
For SDR content, you can still use any target for the 3D LUT (including BT 1886).
If you don't use a 3D LUT, you can calibrate your display / PJ to any gamma target as long as you tell madVR to which gamma value the display is calibrated for, even when tonemapping HDR content to SDR with pixel shader. This 2.2 gamma target limitation is only when using a 3D LUT.
Apologies again for the misinformation. I hope I didn't add more.
-
@manni it's not obvious why the API matters here, you create a lut for a target input gamma and then tell the processing engine what that gamma is. Isn't that just a configuration option in the envy that isn't in madvr? Or can you only load a lut via that API and there is no way to do it manually?
Speaking specifically of displaycal, I think the issue is that there is just one gamma (tone curve) control so no way to vary the input and output side independently.
From a jrvr point of view, it seems that this is configurable so no problem supporting that. However it's not obvious to me yet how to verify this objectively, i.e. via measurements. Any suggestions on how to do this?
-
@manni it's not obvious why the API matters here, you create a lut for a target input gamma and then tell the processing engine what that gamma is. Isn't that just a configuration option in the envy that isn't in madvr? Or can you only load a lut via that API and there is no way to do it manually?
Speaking specifically of displaycal, I think the issue is that there is just one gamma (tone curve) control so no way to vary the input and output side independently.
From a jrvr point of view, it seems that this is configurable so no problem supporting that. However it's not obvious to me yet how to verify this objectively, i.e. via measurements. Any suggestions on how to do this?
Yes of course, there is nothing that would prevent madVR to handle this, but for obvious reason I guess this is an Envy exclusive, like many other things (1D LUT, AI Motion interpolation, etc) that don't drip down into madVR, even if technically it could.
The API simply allows the software to tell Envy which gamma target is used for the LUT. madVR is fixed to 2.2. Envy can accept any target, as long as the software tells it what it is.
Frankly, it doesn't make any difference in practice as PQ is absolute. So you get the same results in Envy irrespective of the gamma target used. That's why the gamma 2.2 limitation in madVR isn't really one, it's an inconvenience only. Some people don't understand that you get the same picture with gamma 2.2 and 2.4 when tonemapping HDR to SDR, so it's easier to give them the option, even if they get exactly the same picture in the end.
-
Well, for maximizing numerical precision of any LUT you technically want the input and output to be as linearly related as possible. So if your display is 2.4 gamma native, using 2.4 gamma as the input would make the 3DLUT slightly more accurate in theory. So if you have a choice, it makes more sense to pick something resembling your display curve than something resembling the input, since the conversion from e.g. BT.1886 to 2.4 in the shader is going to be more numerically precise than the conversion from BT.1886 to 2.4 in the 3DLUT.
Note: tricubic interpolation is possible in libplacebo but much slower and currently only exposed as an option for gamut mapping.
Note 2: It probably doesn't matter in practice, especially at larger sizes. But there's a reason it's called libplacebo 8)
-
Well, for maximizing numerical precision of any LUT you technically want the input and output to be as linearly related as possible. So if your display is 2.4 gamma native, using 2.4 gamma as the input would make the 3DLUT slightly more accurate in theory. So if you have a choice, it makes more sense to pick something resembling your display curve than something resembling the input, since the conversion from e.g. BT.1886 to 2.4 in the shader is going to be more numerically precise than the conversion from BT.1886 to 2.4 in the 3DLUT.
Note: tricubic interpolation is possible in libplacebo but much slower and currently only exposed as an option for gamut mapping.
Note 2: It probably doesn't matter in practice, especially at larger sizes. But there's a reason it's called libplacebo 8)
You are absolutely correct of course. I was having large LUTs in mind. What I meant was that some people with a dark room freak out when they see 2.2 gamma because they think that their tonemapped picture will look washed out (as SDR content does when using 2.2 instead of 2.4 or higher), when in reality, assuming the calibration is perfect, a target of 2.2 or 2.4 or 2.6 for the 3D LUT won't make any difference as long as the renderer knows what it is. In the real world, it's usually better if you can to select a baseline in the display closer to your target, especially with smaller LUTs. I use a 3.7K custom patch set with Colourspace that produces results similar to a 21^3 LUT in a fraction of the time, and it really doesn't care about the baseline. Well, within reason, but we're talking about 2.2 vs 2.4, not 1.8 vs 2.6 :)
I also create an internal 1D LUT in the JVC to my 3D LUT target, so it's 2.4 with Envy and 2.2 with madVR. That way the 3D LUT has less work to do, as gamma in the baseline is near perfect already.
-
Source - https://www.dropbox.com/scl/fi/6mpfiaoy1hdzsg4u5lim9/S-M.mkv?rlkey=3rzxerjrxhsych5ysnrg65zlo&dl=0
MadVR looks blueish and JRVR looks yellowish, which is correct?
-
That "yellowish" image is almost perfectly neutral (white) according to my color picker, with about +1 to red here and there - most likely as a result of the perceptual gamut mapping tending to make very bright colors more white-ish. The madVR image has +10 to blue almost across the board.
Side note, here is the "official" SDR master. It looks like somewhere in between the JRVR and madVR versions to me.
-
That "yellowish" image is almost perfectly neutral (white) according to my color picker, with about +1 to red here and there - most likely as a result of the perceptual gamut mapping tending to make very bright colors more white-ish. The madVR image has +10 to blue almost across the board.
Side note, here is the "official" SDR master. It looks like somewhere in between the JRVR and madVR versions to me.
That's exactly what I thought and saw with color picker - MadVR seems to be pushing blue.
[AVSForum]
-
Lots of people are preconditioned to the madVR look. Best to compare to the original but that advice does not always go down well.
-
Lots of people are preconditioned to the madVR look. Best to compare to the original but that advice does not always go down well.
I will say here what I said there, I don't understand how to have a conversation if we can't even agree on objectively measurable colors. MadVR is more blue when compared to JRVR, I can measure that. Its like bizarro world with everyone telling me blue is white and white is yellow. It is ok to prefer one over the other but I don't understand the complete difference in perception of what these look like.
@haasn do you have any idea why these are so different?
-
That's exactly what I thought and saw with color picker - MadVR seems to be pushing blue. Everyone at AVS seems to think I'm nuts / blind....
You posted screenshots at AVSForum and we told you what we saw. On my LG 4K monitor here set to rec-709, as well as on the 4K display of my Dell XPS 17, I see the JRVR picture yellow/brown, and the snow in madVR white. I have 15 years of experience calibrating, and I can usually spot a wrong white balance on a calibrated display.
I posted to defend JRVR on a few occasions in the AVS thread when I thought it was being misrepresented or unfairly evaluated. I would do the same for madVR.
I don't see any white balance issue with madVR set up properly on a calibrated NZ8 (P3, D65, gamma 2.4, using a C6 profiled to an i1pro2). I'll check that specific shot with JRVR when I find the time, but there is no need to make it sound like it's "us against them".
You're also using non-optional madVR settings and your display is uncalibrated.
Comparing tonemapping with random settings on an uncalibrated display is only saying what looks nicer to you.
I only stepped in briefly to defend JRVR again and explain that settings in JRVR (especially curve selection, gamut mapping and contrast) can have a significant impact on the final picture as well (just like with madVR). Some of the minor clipping / loss of detail in your JRVR shots could be due to poor settings in JRVR, especially re contrast enhancement or the spline contrast settings if you select spline manually.
haasn would need to look at the colors in the original HDR stream as well. It's snow. What tells you that snow/ice couldn't have some blue in the original content? I think you used the 1,000nits version. Please confirm so that Haasn can check in the same stream.
haasn, please could you look in the latest S&M UHD bluray disk (2nd edition from, 2023, there were some issues in the first edition) and see if there is blue in the original content as well?
In this case madVR would be correct and JRVR would be wrong.
I haven't evaluated JRVR properly yet, only selected the most appropriate settings in my case, and I reported that it looked very promising and that the progress in MC31 was impressive.
-
I was coming back here to post that the SDR shot Haasn posted looks more like MadVR to me.
I don't understand what the calibration of my monitor has to do with anything (my projector is perfectly calibrated). I just posted color picker shots that show that MadVR has a bluer look to it - I cannot say enough times that I do not know if one is right or one is wrong I am just trying to point out that there is a difference. One of the pictures is measurably bluer than the other. I am trying to figure out why they are so different.
-
The screenshots have to be compared to the original content. Please confirm which version of the clip you're looking at, so that Haasn can check what the colorpicker says when looking at the original frames in the S&M UHD disc (preferably the latest 2023 edition as there were issues in the first one, according to Stacey himself).
-
I showed some friends of mine who described it just as you do - the blue one looks white and the white one looks yellowish. I am just trying to understand why that is happening because I am very curious why there is such a stark difference in the two softwares. I posted a dropbox link to the source earlier - I don't know which version this is as its part of an overall test suite that someone else posted (folder is labeled madvr and has a bunch of test scenes in it).
-
Look at both with the correct settings on a calibrated display, and let us know if there are still differences. If there are, compare to the original content on the disk. A renderer isn't supposed to correct anything. It's supposed to render what's on the disk as faithfully as possible.
On a calibrated JVC NZ8 (P3, D65, gamma 2.4) I don't see any issue with white balance using madVR with the correct settings. I haven't looked at JRVR in detail yet, but I didn't see anything obviously wrong either once the levels issue was resolved and once I manually selected optimal settings for my situation (100nits peak).
-
I just spent ten minutes removing some personal remarks above. I tried not to remove any substance.
Best just to avoid such remarks.
-
I gathered the following clips in my testing. For the purposes of evaluation, I'm sampling the average of a big (200x200) box near the bottom left corner. For the "HDR" source, I took the 1000 nits clip and linearly scaled it down to SDR range using the "linearlight" tone-mapping function.
SDR horses, BT.709 gamut: 218/218/226 = 3.669% blue boost
SDR horses, BT.2020 gamut: 237/237/242 (*using the BT.2020 SDR source) = 2.1097% blue boost
HDR horses, BT.2020 gamut: 222/222/229 = 3.1531% blue boost
HDR horses, BT.709 gamut (perceptual): 229/229/232 = 1.31% blue boost
HDR horses, BT.709 gamut (softsaturation): 229/229/237 = 3.4935% blue boost
So my findings confirm that the current "perceptual" mode reduces blue saturation, which is not surprising given the design of perceptual is *intended* to reduce saturation of highlights. However, it's still significantly more blue than white on my end, and definitely not yellow. I'm not sure how you produced the screenshot above, my methodology was to load the S&M 1000 nits source frame and show it in plplay, with the target black level override set to 0 and the tone-mapping forced to "linearlight" to try and minimize the effects of tone mapping on the output.
Note that I also included in my above test the "softsaturation" mode, which I'm currently in the progress of working on (and which will become the new "perceptual" default when it's done, hence the confusing filenames / settings in the screenshot)
-
I gathered the following clips in my testing. For the purposes of evaluation, I'm sampling the average of a big (200x200) box near the bottom left corner. For the "HDR" source, I took the 1000 nits clip and linearly scaled it down to SDR range using the "linearlight" tone-mapping function.
SDR horses, BT.709 gamut: 218/218/226 = 3.669% blue boost
SDR horses, BT.2020 gamut: 237/237/242 (*using the BT.2020 SDR source) = 2.1097% blue boost
HDR horses, BT.2020 gamut: 222/222/229 = 3.1531% blue boost
HDR horses, BT.709 gamut (perceptual): 229/229/232 = 1.31% blue boost
HDR horses, BT.709 gamut (softsaturation): 229/229/237 = 3.4935% blue boost
So my findings confirm that the current "perceptual" mode reduces blue saturation, which is not surprising given the design of perceptual is *intended* to reduce saturation of highlights. However, it's still significantly more blue than white on my end, and definitely not yellow. I'm not sure how you produced the screenshot above, my methodology was to load the S&M 1000 nits source frame and show it in plplay, with the target black level override set to 0 and the tone-mapping forced to "linearlight" to try and minimize the effects of tone mapping on the output.
Note that I also included in my above test the "softsaturation" mode, which I'm currently in the progress of working on (and which will become the new "perceptual" default when it's done, hence the confusing filenames / settings in the screenshot)
Awesome thank you. Obviously your methodology is going to be correct all I was wondering is why the difference. So you are saying that the snow started blueish and JRVR is desaturating too much and you are working on improving? This is very appreciated thank you.
-
On a side note, from a glance at these screenshots (and measuring pixel values) it's quite obvious that the left half of the scene is significantly more blue than the right half. So by putting your JRVR comparison on the right half it exaggerates the effect.
-
On a side note, from a glance at these screenshots (and measuring pixel values) it's quite obvious that the left half of the scene is significantly more blue than the right half. So by putting your JRVR comparison on the right half it exaggerates the effect.
Yeah the difference is not very noticeable until they are side by side then all of a sudden it looks drastic.
-
By the way, here is HSV sweep under the new "perceptual" mapping mode. I think your scopes will like this one :D
-
Nice!
-
for me, comparing jrvr & madvr (latest, 169) both converting to p3 and both using the same lut, jrvr looks a bit blown out
-
These were just quick tests I put up JRVR side by side on my screen with MadVR using more of those S&M test clips.
I thought these were a little lacking in blue also so good bet these will improve also.
-
I gathered the following clips in my testing. For the purposes of evaluation, I'm sampling the average of a big (200x200) box near the bottom left corner. For the "HDR" source, I took the 1000 nits clip and linearly scaled it down to SDR range using the "linearlight" tone-mapping function.
SDR horses, BT.709 gamut: 218/218/226 = 3.669% blue boost
SDR horses, BT.2020 gamut: 237/237/242 (*using the BT.2020 SDR source) = 2.1097% blue boost
HDR horses, BT.2020 gamut: 222/222/229 = 3.1531% blue boost
HDR horses, BT.709 gamut (perceptual): 229/229/232 = 1.31% blue boost
HDR horses, BT.709 gamut (softsaturation): 229/229/237 = 3.4935% blue boost
So my findings confirm that the current "perceptual" mode reduces blue saturation, which is not surprising given the design of perceptual is *intended* to reduce saturation of highlights. However, it's still significantly more blue than white on my end, and definitely not yellow. I'm not sure how you produced the screenshot above, my methodology was to load the S&M 1000 nits source frame and show it in plplay, with the target black level override set to 0 and the tone-mapping forced to "linearlight" to try and minimize the effects of tone mapping on the output.
Note that I also included in my above test the "softsaturation" mode, which I'm currently in the progress of working on (and which will become the new "perceptual" default when it's done, hence the confusing filenames / settings in the screenshot)
Thanks for taking the time to look into the content. It's the only way to figure out which renderer is closer to the "truth". Glad to hear that softsaturation is expected to improve things. I'll wait for it to be implemented in JRVR before doing a deep dive.
-
Pushed a new version of libplacebo (v6.292.1) with the new gamut mapping implemented; should hopefully hit a JRVR build soon
-
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.
Would there be a benefit then, to somehow being able to scan the video to determine if there are any out-of-gamut values? Any video without out-of-gamut issues could then be processed without the resulting headroom issues.
-
Would there be a benefit then, to somehow being able to scan the video to determine if there are any out-of-gamut values? Any video without out-of-gamut issues could then be processed without the resulting headroom issues.
The quote you replied to is out of date. The tone-mapping was fixed to never produce out-of-gamut values. That said, dynamic scene analysis would definitely be interesting. But, 3DLUT generation is slow. Very slow. So updating the 3DLUT in realtime will be too slow even if we can measure a gamut estimate.
-
The quote you replied to is out of date. The tone-mapping was fixed to never produce out-of-gamut values.
I was thinking more of potential bad mastering errors I guess, and was hinting at scanning (and tagging/whatever) the files in advance, to determine whether or not 'headroom' is needed, thus negating the need to map (0, 0, 1) input to (0, 0, 0.8 ) output. Color science makes my head hurt.
-
Here is an interesting compare, I guess this is JRVR desaturating too much again? The opening behind Sidious seems to have more color in the MadVR one. Let me state clearly I do not know if one is right or wrong just saying they are different (not even allowed to discuss at AVS apparently). I will test this shot with new gamut mapping once available.
-
If you can dump me a raw hevc frame (+ whatever settings are relevant for your display configuration) I can show you what it looks like with the new gamut mapping
-
If you can dump me a raw hevc frame (+ whatever settings are relevant for your display configuration) I can show you what it looks like with the new gamut mapping
Those are both with same 3dlut specific to my display so probably wouldn't be a good comparison. I will capture same frame once JRVR is updated.
-
Here is another screen that seems to show different colors, this time I extracted from source file if you want to see what the new gamut mapping does. Is this same too much desaturation issue?
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=353186f0-36b5-11ee-b5bd-6595d9b17862
Source - https://www.dropbox.com/scl/fi/09isqkg0vr3bulpvahf2p/output.mkv?rlkey=heg5os0kuopl6307q3wncdcpo&dl=0
-
Build 43 is available here now, which includes the new libplacebo gamut mapping:
https://yabb.jriver.com/interact/index.php/topic,136749.0.html
-
Well it "fixed" the Lord Sidious shot there is now some blue in the opening behind him. The horses snow also has a bit of blue tinge to it now. The First Purge shot I did doesn't seem to have changed which is welcome because that is an example of why I think JRVR looks more alive than MadVR. I will watch some films this weekend but at first glance looks like a welcome improvment.
-
I was trying, and failing, to find a test pattern that shows this
Overall the main negative thing I notice about jrvr now (tone mapping to 100nits dci-p3) is that brighter areas look blown out (lack fine detail or are notably brighter than other areas).
-
I was trying, and failing, to find a test pattern that shows this
Overall the main negative thing I notice about jrvr now (tone mapping to 100nits dci-p3) is that brighter areas look blown out (lack fine detail or are notably brighter than other areas).
This is interesting and I agree with what you are saying so I did a couple of comparisions.
Source is this HDR Grayscale - https://www.dropbox.com/scl/fi/83p7sl4rwsxk2d8sx8oe3/greyscale.mkv?rlkey=oxl2ka2sr3b6y6hew8o51ir96&dl=0
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=91104c98-3ddd-11ee-b5bd-6595d9b17862
I then checked the standard AVS709 black level pattern just to verify I don't have a mismatch or something -
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=8e591a5c-3ddd-11ee-b5bd-6595d9b17862
Not sure what to make of this, do I have a setting wrong somewhere?
They are vastly different at every single step, at least on my system. JRVR looks like a brighter shade of gray at every step except pure white where MadVR looks brighter.
-
Not sure what to make of this, do I have a setting wrong somewhere?
certainly a big difference there
the madvr one is really dark and comes out of black extremely slowly
jrvr is faster to come out of black, shows more even spacing but is squashed at the top and doesn't quite get as bright
they surely don't have the same gamma targets do they?
-
Your AVS709 pattern with madVR doesn't even have a black background, its just grey. That doesn't seem right.
-
certainly a big difference there
the madvr one is really dark and comes out of black extremely slowly
jrvr is faster to come out of black, shows more even spacing but is squashed at the top and doesn't quite get as bright
they surely don't have the same gamma targets do they?
I am using the same 3dlut profile but JRVR is set to bt.1886 and MadVR is set to 2.2 (think it has to be).
Thats why I provided the source so others can try.
-
mine (using my current HDR settings in madvr and jrvr) comes out like https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=edc50f14-3e69-11ee-b5bd-6595d9b17862
I wrote a quick little script to pull out the RGB values from each bar and diff them which gives the following
(step is the change in the avg rgb level from one bar to the next for each renderer, delta is the difference between the avg for each renderer on the same bar)
$ ~/bin/get_colours.sh /media/home-media/greyscale_madvr.png /media/home-media/greyscale_jrvr.png
patch | madvr | avg | step | jrvr | avg | step | delta
1 | 0,0,0 | 0 | 0 | 1,1,1 | 1 | 1 | -1
2 | 4,4,4 | 4 | 4 | 9,9,9 | 9 | 8 | -5
3 | 14,14,14 | 14 | 10 | 23,23,22 | 22 | 13 | -8
4 | 27,27,26 | 26 | 12 | 40,41,40 | 40 | 18 | -14
5 | 45,46,45 | 45 | 19 | 68,67,66 | 67 | 27 | -22
6 | 73,74,72 | 73 | 28 | 103,105,101 | 103 | 36 | -30
7 | 114,115,114 | 114 | 41 | 147,148,144 | 146 | 43 | -32
8 | 158,160,158 | 158 | 44 | 185,184,182 | 183 | 37 | -25
9 | 199,201,198 | 199 | 41 | 209,215,210 | 211 | 28 | -12
10 | 230,233,229 | 230 | 31 | 231,237,232 | 233 | 22 | -3
11 | 250,254,249 | 251 | 21 | 249,250,245 | 248 | 15 | 3
which makes it easy to see that madvr is generally darker until the top end, that jrvr doesn't get so bright and that the steps are much closer together at the top
#!/bin/bash
MID=175
y=540
printf "%-6s | %-11s | %-3s | %-4s | %-11s | %-3s | %-4s | %-3s\n" "patch" "madvr" "avg" "step" "jrvr" "avg" "step" "delta"
for v in {0..10}
do
x=$((MID + $((349 * v))))
crop="1x1+${x}+${y}"
madvr_rgb=$(convert $1 -crop "1x1+${x}+${y}" -format '%[fx:int(255*r+.5)],%[fx:int(255*g+.5)],%[fx:int(255*b+.5)]' info:-)
jrvr_rgb=$(convert $2 -crop "1x1+${x}+${y}" -format '%[fx:int(255*r+.5)],%[fx:int(255*g+.5)],%[fx:int(255*b+.5)]' info:-)
IFS=',' read -r -a madvr_vals <<< "${madvr_rgb}"
IFS=',' read -r -a jrvr_vals <<< "${jrvr_rgb}"
madvr_step=
jrvr_step=
prev_m=
prev_j=
if [[ ${v} -gt 0 ]]
then
prev_m=${madvr_avg}
prev_j=${jrvr_avg}
fi
madvr_avg=$(((madvr_vals[0] + madvr_vals[1] + madvr_vals[2]) / 3))
jrvr_avg=$(((jrvr_vals[0] + jrvr_vals[1] + jrvr_vals[2]) / 3))
delta=$((madvr_avg - jrvr_avg))
madvr_step=$((madvr_avg - prev_m))
jrvr_step=$((jrvr_avg - prev_j))
printf "%-6s | %-11s | %-3s | %-4s | %-11s | %-3s | %-4s | %-3s" $((v+1)) ${madvr_rgb} ${madvr_avg} ${madvr_step} ${jrvr_rgb} ${jrvr_avg} ${jrvr_step} ${delta}
echo ${out}
done
-
same output for your files
~/bin/get_colours.sh MadVRGrey.png JRVRGrey.png
patch | madvr | avg | step | jrvr | avg | step | delta
1 | 6,5,3 | 4 | 4 | 1,2,0 | 1 | 1 | 3
2 | 11,10,9 | 10 | 6 | 20,20,17 | 19 | 18 | -9
3 | 18,18,17 | 17 | 7 | 34,35,34 | 34 | 15 | -17
4 | 29,28,28 | 28 | 11 | 56,54,53 | 54 | 20 | -26
5 | 44,44,43 | 43 | 15 | 80,78,78 | 78 | 24 | -35
6 | 68,65,65 | 66 | 23 | 110,113,112 | 111 | 33 | -45
7 | 97,97,97 | 97 | 31 | 150,150,148 | 149 | 38 | -52
8 | 141,140,141 | 140 | 43 | 186,182,182 | 183 | 34 | -43
9 | 196,195,196 | 195 | 55 | 215,210,210 | 211 | 28 | -16
10 | 235,235,235 | 235 | 40 | 236,231,232 | 233 | 22 | 2
11 | 255,255,255 | 255 | 20 | 248,250,250 | 249 | 16 | 6
yours shows a much bigger difference between the two
-
posting the numbers just to quantify the comparison between them, not exactly sure (certainly at this time of morning!) how to relate that to what the correct values should be for a given gamma
-
in visual form, straight line is the input (equally spaced bars), blue is madvr, red is jrvr, green is just straight line with a 2.2 gamma (was seeing if it approximated that)
-
As far as I know, madVR tonemaps to 2.2 gamma, while we by default use BT.1886. You can swap to 2.2 by setting that on the calibration page, if you want a comparison. This would get it closer, I believe.
As for bright sections being blown out, this pattern doesn't really demonstrate that.
What I would recommend to try with tonemapping to a low target like 100 nits, set the tone mapping algorithm to Spline and try different ranges of Spline Contrast, to tune the behavior of bright and dark sections to your preference.
If you can post a sample that demonstrates that problem it might be helpful. Real content is fine too, test samples only go so far.
-
If you can post a sample that demonstrates that problem it might be helpful. Real content is fine too, test samples only go so far.
already posted here - https://yabb.jriver.com/interact/index.php/topic,136378.msg947320.html#msg947320
As far as I know, madVR tonemaps to 2.2 gamma, while we by default use BT.1886. You can swap to 2.2 by setting that on the calibration page, if you want a comparison. This would get it closer, I believe.
personally I'm not trying to get closer to madvr as such, I'm just using it as something to compare to
As for bright sections being blown out, this pattern doesn't really demonstrate that.
it's an attempt to quantify what is seen in the above, the steps are probably a bit too far apart to really examine this aspect (probably need to do the top x 10% in 1% steps or something like that) it but it does hint at the problem in that the steps are closer together at the top end in jrvr and there is an S shaped curve. That certainly seems like white crush like behaviour to me.
What I would recommend to try with tonemapping to a low target like 100 nits, set the tone mapping algorithm to Spline and try different ranges of Spline Contrast, to tune the behavior of bright and dark sections to your preference.
mine is set to 100nit target already, spline contrast is not making an obvious difference to the top end for me. If I get time, I could measure that pattern with different spline contrast values to see what difference it makes though I guess that curve is in the code somewhere so could be seen somehow?
-
in visual form, straight line is the input (equally spaced bars), blue is madvr, red is jrvr, green is just straight line with a 2.2 gamma (was seeing if it approximated that)
Amazing work thanks. So you are seeing the difference but for whatever reason mine is more drastic? This might finally quantify what I keep saying - MadVR looks dull to me compared to JRVR so maybe it is but also I am doing something to make it worse than it actually is?
-
Here is what I get if I take my 3dlut out of the equation and set both JRVR and MadVR to 2.2 gamma -
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=eceeb59e-3e7e-11ee-b5bd-6595d9b17862
-
Amazing work thanks. So you are seeing the difference but for whatever reason mine is more drastic? This might finally quantify what I keep saying - MadVR looks dull to me compared to JRVR so maybe it is but also I am doing something to make it worse than it actually is?
what are your settings in each?
-
What I would recommend to try with tonemapping to a low target like 100 nits, set the tone mapping algorithm to Spline and try different ranges of Spline Contrast, to tune the behavior of bright and dark sections to your preference.
I don't think this is a solution as spline is described as a "Perceptually linear single-pivot polynomial" which you can see in this chart, in this case I made a new test pattern with 1% steps and then plotted the average rgb value at each point for a number of different spline values. I gather the knee point is configurable in PQ space but don't know how that translates here directly except that we can clearly see the pivot is at the 50% grey point. No smoothing in this so the curves are a little wobbly but I don't think that changes the point being made.
It means changing this value affects both top and low end in exactly the same way which, I would guess, is not going to be a good trade.
in addition, spline 1.5 looks like it's too high a value to be safely allowed given how hard it clips.
it might be interesting to look at the average level of that horse shot later to see where it falls on the curve.
-
what value does jrvr set for that knee point? can it be made user configurable?
-
for comparison, sdr added
-
what value does jrvr set for that knee point? can it be made user configurable?
I was planning on making it more user-tunable, yes. The value is chosen by complicated algorithm taking into account both the input and output brightness range and scene average luminance. I can explain it in more detail tomorrow, I threw it together in half a day. Improvements definitely are possible.
-
Btw, for tuning tone-mapping curves I definitely recommend looking at libplacebo's own LUT visualization graph. I don't know if JRVR exposes it anywhere (though iirc it should be on the overlay somewhere, or something?)
It will show you the tone mapping step exclusively (in PQ-PQ space)
-
there's the attached but I have no idea how to read it, is that what you mean?
-
Yeah, that's the one. What this graph is showing is that it's (on this scene) just doing a perceptually linear (PQ space) stretch, to from the source luminance to the (slightly lower) target luminance.
Regions in deep blue in the graph are where the output image is darker than the input image. (The slice of the gamut mapping 3DLUT in the background can be ignored). (The big blue bar at the top shows the portion of PQ space that the input image is not using, and hence does not need to be tone-mapped; the red bar below it shows the portion of PQ space that the source uses but which is unavailable for output)
-
This is not scientific at all but I have watched probably 10 full length films since build 43 was posted and everything looks amazing.
I am sure there are more improvements to be made but this is really in a good place right now.
-
Yeah, that's the one. What this graph is showing is that it's (on this scene) just doing a perceptually linear (PQ space) stretch, to from the source luminance to the (slightly lower) target luminance.
does the rectangular block show the 0-10000 nits range in absolute terms? the red block seems to be it seems to be ~13% of the total height so that equates to 13% of 10k or some other value? given the target nits in this example is 100 then that's basically invisible on such a view but if I had a higher target then I might be able to distinguish it?
is the perceptually linear stretch show by the straight diagonal line or something else?
-
does the rectangular block show the 0-10000 nits range in absolute terms? the red block seems to be it seems to be ~13% of the total height so that equates to 13% of 10k or some other value? given the target nits in this example is 100 then that's basically invisible on such a view but if I had a higher target then I might be able to distinguish it?
is the perceptually linear stretch show by the straight diagonal line or something else?
The graph is in PQ space. So it shows all PQ codepoints (from 0 to 1023), not nits levels. It's perceptually linear because the diagonal line is straight, yeah. (The gray line is the neutral axis, i.e. what you get from "clip" tone mapping)
-
The graph is in PQ, not in nits. Its a non-linear distribution, on a 0-1 scale, RGB 100% White is at around 0.58 (203 nits), from a quick test 100 nits is at around 0.51. PQ in on the X axis (horizontal), PQ out on the Y axis (vertical).
Decoding guide (including what haasn said):
- The blue area on top is unused brightness, as the source was not that bright
- The red area on top is brightness the source used, but the target does not have (what needs to be tone mapped)
- The main diagonal line goes from the origin to the top right corner of the used source brightness (from bottom left to the right border, where the red and blue areas meet)
- The second curve is from the origin to the bottom of the red area - the tone mapping curve. The area between the main diagonal and the tone mapping curve is colored to indicate the change to the image in that area, blue when it gets darker, green when it gets brighter.
- The vertical white line is the average brightness of the image right now.
The leaf in the background is a visualization of the gamut mapping and can be ignored for this purpose.
-
The graph is in PQ space. So it shows all PQ codepoints (from 0 to 1023), not nits levels. It's perceptually linear because the diagonal line is straight, yeah. (The gray line is the neutral axis, i.e. what you get from "clip" tone mapping)
right ok thanks for explaining (and +1 to Hendrik for further clarification)
does the existing option (that isn't accessible in jrvr but is in mpv) for moving the knee basically move the inflection point up/down the (what appears to be a sigmoid) curve or is it doing something more complex/dynamic than that?
-
Which parameter is that? As far as I can see there is only one parameter for tone mapping functions, and for spline thats the one I exposed in the settings.
-
Mpv docs describe it as
Specifies the knee point (in PQ space). Defaults to 0.30.
Is that what you call spline contrast? The effect didn't really look like moving a knee to me hence I supposed it was something else
-
That is the option JRVR exposes. The description is probably just incorrect/outdated, it happens when stuff needs to be adapted in so many spots. The default is 0.50 even in the code, and it controls the slope more.
-
That is the option JRVR exposes. The description is probably just incorrect/outdated, it happens when stuff needs to be adapted in so many spots. The default is 0.50 even in the code, and it controls the slope more.
The Spline contrast adjustment seems to be disabled if auto-select tone mapping is chosen, is that intentional? So we cannot adjust the knee point and have it set to auto-select?
-
That is correct. The parameter can only be changed with a specific algorithm selected.
-
So, the way the algorithm currently works, at a high level, is this:
Let SrcAvgPQ be the source average level (in PQ), SrcMinPQ and SrcMaxPQ (resp DstMinPQ and DstMaxPQ) be the source minimum and maximum PQ level.
Then,
SrcRange := SrcMaxPQ - SrcMinPQ
DstRange := DstMaxPQ - DstMinPQ
SrcKneeMinimum := Mix( SrcMinPQ, SrcMaxPQ, 0.1 )
SrcKneeMaximum := Mix( SrcMinPQ, SrcMaxPQ, 0.8 )
DstKneeMinimum := Mix( DstMinPQ, DstMaxPQ, 0.1 )
DstKneeMaximum := Mix( DstMinPQ, DstMaxPQ, 0.8 )
SrcKnee := Clamp( SrcAvgPQ, SrcKneeMinimum, SrcKneeMaximum )
KneeRescaled := (SrcKnee - SrcMinPQ) * DstRange / SrcRange + DstMinPQ
KneeAdapted := Mix( SrcKnee, KneeRescaled, AdaptionStrength )
DstKnee := Clamp( KneeAdapted, DstKneeMinimum, DstKneeMaximum )
The resulting SrcKnee and DstKnee values give the knee point - meaning an input value of SrcKnee will get mapped exactly onto DstKnee, with every value in between being smoothly interpolated. The spline slope contrast effectively determines the steepness of the curve at this knee point.
The adaptation strength (for KneeAdapted) is currently hard-coded as 0.7, alongside the knee minimum/maximum at 0.1 and 0.8 of the respective range. The spline function slope tuning is even more ad-hoc and involves two more magic parameters that I don't have time to get into atm. It's all pretty hacky and thrown together in the span of a few hours of testing.
I'd be very welcome to improvements for how to pick a better knee point / scene average brightness target.
-
The Spline contrast adjustment seems to be disabled if auto-select tone mapping is chosen, is that intentional? So we cannot adjust the knee point and have it set to auto-select?
This will be fixed by https://code.videolan.org/videolan/libplacebo/-/merge_requests/546 which will also make all of the other magic constants tunable. (such as the adaptation strength)
-
I'd be very welcome to improvements for how to pick a better knee point / scene average brightness target.
I know I'm not competent to be able to advise on that :) I can only suggest that given that, in terms of what is in the output image, the current parameter appears to affect the low and top end symmetrically then I'd look at ways to tune those independently and/or move the inflection point.
is there some reason that it needs to be symmetrical in the way it is atm?
-
is there some reason that it needs to be symmetrical in the way it is atm?
Not really, it's just a consequence of how the curve was formulated. For 'spline' we fit a 2nd order polynomial below the knee point and a 3rd order polynomial above the knee point. The only other constraint is that the slope at the knee point should be continuous. But apart from that, the value we pick for that slope is arbitrary (hence why you can tune it).
This gives you the sort of 'sigmoid' style shape we observe, where increasing slope increases the curvature at both the top and bottom end. If you increase curvature of only one, you make the function first order discontinuous at the knee point.
-
I created a simulation of the tone mapping code on desmos for those of you who are curious to play around with it:
https://www.desmos.com/calculator/fiydys777e
The parameters are all at the top, SMin/SAvg/SMax and DMin/DMax are PQ luminance levels (not nits!), the defaults are set to 0-1000 nit source range and SDR output (with 1000:1 contrast). KAdaptation is the knee point adaptation strength, KMin and KMax are the knee point clamps, SContrast is the spline contrast and TStrength/TOffset are the slope tuning strength/offsets.
The dotted black line is the 1:1 (neutral) axis, the dotted orange line is the pre-tuning knee point slope, and the dotted red line is the post-tuning knee point slope (the one that is actually used). You can see here quite clearly the effect of raising slope contrast has - since it changes the slope *at* the knee point, it affects the curve both below and above it.
Hopefully this graph should make more intuitive sense than previous algorithm. I'm still looking for ways to improve it.
-
Thanks, that's really useful, will play with it a bit.
Smin/avg/max is driven, in reality, by the measured contents of the current scene?
-
changing s_contrast produces a visually subtle effect in the curve in the pq space and yet my measurements of the actual output showed a v pronounced impact on an obviously sigmoid curve hence it's a bit difficult to relate the sim with reality.
to try to address this, I tried to convert this to nits via the ST2084 eotf thinking it might resemble my measured output but it's not remotely the same so obviously I got that wrong. What transformation is required to then render this in the output space? I guess it could be what i put on the x axis (which is my chart is essentially the input level from 0-100% in 1% steps) but I guess that's what your x axis is also?
I put the corresponding code in a notebook to illustrate -> https://colab.research.google.com/drive/1ewuJB0reuRdJ1ziYkmQRsSULwpS7XkCk?usp=sharing
pic attached of my output
-
I redid my previous test with a pattern that has 100 steps from 0 to ~1000nits (the previous one was full range so 10k nits) & then revisited that Spears&Munsil horse pic to check what the debug OSD and can see that it sees that scene as ~850 nits
my analysis for this case shows no real difference in a greyscale curve between the two renderers. I don't know what, if anything, that tells us but thought I'd share it anyway.
-
This is not scientific at all but I have watched probably 10 full length films since build 43 was posted and everything looks amazing.
I am sure there are more improvements to be made but this is really in a good place right now.
+1
Fascinating thread and well beyond my understanding of these things at this point. I notice a marked improvement with JRVR in recent releases and my family, who generally cares little for the finer details in their video, has pointed out that recently, everything we watch (we use Mediacenter every day, multiple devices/TVs) looks better than it ever has.
The Dune 4K now sits "unused". no point any longer.
Keep going...
-
Smin/avg/max is driven, in reality, by the measured contents of the current scene?
Yes, exactly.
changing s_contrast produces a visually subtle effect in the curve in the pq space and yet my measurements of the actual output showed a v pronounced impact on an obviously sigmoid curve hence it's a bit difficult to relate the sim with reality.
Could this sigmoid curve come from your display device calibration, or a difference in the configuration? e.g. if you configure libplacebo to use BT.1886 gamma handling while your display is actually calibrated to gamma 2.2..
to try to address this, I tried to convert this to nits via the ST2084 eotf thinking it might resemble my measured output but it's not remotely the same so obviously I got that wrong. What transformation is required to then render this in the output space? I guess it could be what i put on the x axis (which is my chart is essentially the input level from 0-100% in 1% steps) but I guess that's what your x axis is also?
There should be no further transformation needed, out nits (from the tone-mapper) is out nits (on the display). Well, the gamut mapper may also mess things up further but on a grayscale pattern this shouldn't matter. The only additional source if discrepancy could be if your calibration is not ideal or if JRVR is misconfigured.
I put the corresponding code in a notebook to illustrate -> https://colab.research.google.com/drive/1ewuJB0reuRdJ1ziYkmQRsSULwpS7XkCk?usp=sharing
I put also the corresponding PQ transformation into the desmos graph: https://www.desmos.com/calculator/gp1ocbnjgm
-
Could this sigmoid curve come from your display device calibration, or a difference in the configuration? e.g. if you configure libplacebo to use BT.1886 gamma handling while your display is actually calibrated to gamma 2.2..
to the best of my knowledge of how madvr + jrvr work, they are configured in the same way. In this case, for HDR, it's a 2.2 gamma to be sent to the display & it's a dci-p3 d65 gamut.
-
I put also the corresponding PQ transformation into the desmos graph: https://www.desmos.com/calculator/gp1ocbnjgm
thanks so this is the same as what I had in https://colab.research.google.com/drive/1ewuJB0reuRdJ1ziYkmQRsSULwpS7XkCk#scrollTo=t8mO_zGdOWnx&line=6&uniqifier=1
my attempt to measure exactly what the rendering was doing was quite simple
1) generate a greyscale ramp as a series of vertical columns (of a given width in pixels) going from 0-100% in 1% steps where 100% scaled so that 100% is inverse eotf(target max nits). This is written as a 16bit png and then encoded using ffmpeg/x265 with the relevant params to make it hdr.
2) play this in JRVR
3) take a full screen screenshot, save as png
4) use imagemagick to grab a single pixel from each column and output as -format '%[fx:r],%[fx:g],%[fx:b]' (i.e. the rgb values of that pixel in the range 0-1)
it means I have both input and values in the range 0-1 in 0.01 steps which I then want to use to correlate
to turn this into nits...
I'd think the input is just multiply by the peak nits of the scene
for the output, it needs to be scaled to the output peak nits (100 in my case) but what else? presumably there's a transformation based on the specified gamma so should I apply the inverse gamma? if I do that, the shape does look correct but not sure if that is some coincidence
-
for the output, it needs to be scaled to the output peak nits (100 in my case) but what else? presumably there's a transformation based on the specified gamma so should I apply the inverse gamma? if I do that, the shape does look correct but not sure if that is some coincidence
Yes, exactly. If the output is set to gamma 2.2, then libplacebo applies an inverse gamma 2.2 function before outputting to the display. So to recover raw nits from the output you should apply a gamma 2.2 function to the measured pixel values. (Or set output gamma to linear, if you're capturing in 16-bit precision)
Though I personally think it makes more sense to look at PQ-PQ graphs rather than nits-nits graphs, since the former is effectively perceptually linear, i.e. it maps how we actually perceive the scene. (Or look at the nits-nits graph on a log-log scale)
-
Yes, exactly. If the output is set to gamma 2.2, then libplacebo applies an inverse gamma 2.2 function before outputting to the display. So to recover raw nits from the output you should apply a gamma 2.2 function to the measured pixel values. (Or set output gamma to linear, if you're capturing in 16-bit precision)
Though I personally think it makes more sense to look at PQ-PQ graphs rather than nits-nits graphs, since the former is effectively perceptually linear, i.e. it maps how we actually perceive the scene. (Or look at the nits-nits graph on a log-log scale)
thanks, I think I have a working comparison now
I ran the model for various different peak nits & spline contrast values. It seems to show 2 things:
1) spline contrast has a really minimal impact until you get to really bright scenes which I would think implies it's not really that useful a parameter to be able to tune?
2) there's a blatantly obvious discontinuity (curve abruptly changes direction) at low peak nits (visible at 50, really blatant at 20 and 10)
looking more closely at your desmos sim, I think the upper knee section of the curve is broken for the case where Smax < Dmax
given it's dynamically calculating this curve based on scene brightness, isn't that a potentially significant bug for dark scenes on a projector? wouldn't it significantly elevate the level of slightly brighter parts of a dark scene? and given that loads of movie content is at low ADL then I'd guess that is a material bug? unless there's something else in the actual code which clamps something to avoid this?
-
looking more closely at your desmos sim, I think the upper knee section of the curve is broken for the case where Smax < Dmax
Note that normally Dmax is clamped to Smax (unless you enabled inverse tone mapping). That said, it definitely seems like we calculate the knee here poorly.
Edit: On second thought, I'm not actually sure if this is unintended. Keep in mind that for inverse tone mapping we want to mostly keep the content the same but strongly boost upper highlights. So an unnatural-looking curve here isn't too far off the mark. You can 'fix' it by raising the knee point adaptation strength.
-
Note that normally Dmax is clamped to Smax (unless you enabled inverse tone mapping). That said, it definitely seems like we calculate the knee here poorly.
Edit: On second thought, I'm not actually sure if this is unintended. Keep in mind that for inverse tone mapping we want to mostly keep the content the same but strongly boost upper highlights. So an unnatural-looking curve here isn't too far off the mark. You can 'fix' it by raising the knee point adaptation strength.
why is it desirable to strongly boost highlights in a dark scene? I appreciate you can't leave it all untouched as then you'll get some discontinuities when the content goes above that limit but wouldn't you want to leave content that fits within some portion of the specified target output level untouched?
or is that what you mean by saying Dmax is clamped to Smax?
what is Smax in practice btw? equivalent of MaxFALL or MaxCLL or something else?
-
Smax is typically the 99.95% percentile value of PQ(Y). Savg is the mean of PQ(Y).
why is it desirable to strongly boost highlights in a dark scene?
Well, it's the point of having the option, I guess. Inverse tone mapping is off by default, mind. To be honest I never really tested inverse tone mapping all that much as I only have OLED screens that can barely go above normal SDR brightness levels.
-
Smax is typically the 99.95% percentile value of PQ(Y). Savg is the mean of PQ(Y).
the behaviour of this curve is significantly driven by (Smax - Savg) but the JRVR only shows one number so it's really hard to relate what we see in a given scene to what the curve is doing at that point
is that displayed value Smax or Savg?
can the missing numbers be added to the OSD pls?
-
I think Kadaptation is the variable that would be most useful to expose (in JRVR) given it basically controls how much you reduce output at the low end in order to make room for a smoother transition to the upper end.
Clearly it would need testing and I could be a million miles off until I am able to do that but, intuitively, I'm not really too sure why it's a good thing for that value to be much beyond 0 and for Scontrast to be similarly close to 0
Some other observations
* increasing contrast ratio (i.e. reducing Dmin) has the side effect of moving the knee down (in output terms), Kadaptation has to be reduced in order to put that back to the same position (so that's another reason to expose Kadaptation albeit perhaps that offset should be adjusted automatically?)
* as the distance between the black level (Dmin) and the knee level reduces, the impact of Scontrast increases as long as Dmin is above zero
* high Scontrast values can produce a really badly behaved curve if the scene values are sufficiently extreme (high peak, low avg) => I think it's another argument in favour of Scontrast being limited to 1 as opposed to the current 1.5
I wonder whether it's feasible to drive Kadaptation from Smax-Savg? it seems like if Savg were low then you might like a reduced Kadaptation as it implies there are relatively few pixels with highlights so letting them blow out might be visually not so harmful (hence preserving more output for low levels) whereas when Savg is high then you may want Kadaptation to reduce as that means many more pixels are brighter and so giving relatively more space for mid level output would help preserve detail.
-
going back to my greyscale ramp, I guess it's an unusually high ADL scene but perhaps it makes a good example of the curve behaves in this case on a projector
with spline 0.5 + low black floor + 100 target peak nits = spline05_greyscale.png
* pretty much a straight line to the knee then pretty much crush the top end
in this sort of scene, seems like you'd want to push the knee down to a lower level (reduced kmax to 0.5) and bring the knee closer to the no compression curve (reduced kadaptation to 0.3) = spline_adapted_greyscale.png
* arguably gives better progress out of black while giving a bit more chance for highlight detail to be retained
the horse scene from Spears & Munsil is actually even higher ADL than this (~55-60% with average signal level ~75%) so I am inclined to think the behaviour of the current spline curve does explain the perception of crushed highlight detail
I think it comes back to the idea that you need vary those, currently static, variables based on the scene content and then work out how to smoothly transition between them on scene cuts to avoid artifacts.
-
Intuitively, it seems that for well-behaved input scenes (Savg <= Kmax*Dmax) we want to make Dknee=Sknee=Savg with M=1, while for sufficiently bright input scenes (Savg >= Kmax*Dmax) we want to cap Dknee at Kmax*Dmax. And combine this with a sufficiently low value of Kmax. This would allow well-behaved input scenes to mostly pass untouched while scenes that are unreasonably bright get their brightness dropped. However, I am a bit worried about making a hard `max()` here, so maybe a powermean with sufficiently high power would be better.
I'll try implementing something like this and see what happens, maybe.
-
https://www.desmos.com/calculator/lovtdrf7xv
Playing around with the above idea made me settle on something like this, the basic idea is to try and always present a sigmoid-like shape with contrast close to 1, but to slowly approximate a pqlinear function as the knee point moves outside the 'valid' knee point range. (The spline contrast parameter can still be used to control how strongly we should adapt the slope towards the linear slope)
I'll try implementing it in libplacebo next and throw it at some scenes.
-
Well, theory is theory and practice is practice. I don't like it - the attempt to make it try and preserve brightness even for seemingly well-behaved scenes basically always backfires - it blows out scenes that we handled much better before.
I think it's better to always adapt the brightness range, and maybe just change the way we tune the slope.
-
Well, theory is theory and practice is practice. I don't like it - the attempt to make it try and preserve brightness even for seemingly well-behaved scenes basically always backfires - it blows out scenes that we handled much better before.
I think it's better to always adapt the brightness range, and maybe just change the way we tune the slope.
what are the capabilities of the display you are testing on? it would be interesting to know that to be able to try to guess what you're seeing from the curve alone.
for example, if I use my display capabilities and compare your nu curve vs existing then I'd guess the new one would be darker overall but you might get increased contrast in bright areas. Might be interesting to see a pic comparing a scene or two run through each.
do you have a standard set of scenes you use as a test pack?
-
the behaviour of this curve is significantly driven by (Smax - Savg) but the JRVR only shows one number so it's really hard to relate what we see in a given scene to what the curve is doing at that point
is that displayed value Smax or Savg?
can the missing numbers be added to the OSD pls?
@haasn hendrik mentions this comes from libplacebo, can you add this pls?
-
what are the capabilities of the display you are testing on? it would be interesting to know that to be able to try to guess what you're seeing from the curve alone.
for example, if I use my display capabilities and compare your nu curve vs existing then I'd guess the new one would be darker overall but you might get increased contrast in bright areas. Might be interesting to see a pic comparing a scene or two run through each.
I'm just testing the out-of-the-box default tone-mapping to 1000:1 SDR display.
do you have a standard set of scenes you use as a test pack?
Yeah, I'll try and publish it online actually as I'm finding it hard to synchronize across machines.
Anyway, I gave the dynamic adaptation strength a few more thoughts and came up with something like this: https://www.desmos.com/calculator/tyv2elsdao
After implementing it, it does significantly improve visual appearance in my books. (See attached before/after images)
-
I tuned it a bit more and pushed my changes here: https://code.videolan.org/videolan/libplacebo/-/merge_requests/551
This significantly improves a number of problematic scenes in S&M, and also increases consistency between different versions of it (1k nits and 10k nits)
On a side note, I noticed that for some reason, the S&M 4000 nits sample seems to be mastered very differently from the 1k and 10k nits samples. The snow horses scene, for example, is a lot brighter - brighter even than the 10k nits sample. This seems to be present in the source, not introduced by tone-mapping, since it's visible even when doing a linear pq stretch.
-
This looks like another pretty significant improvement, can't wait to see the end result. Based on that comparison it looks really good.
-
do you have a standard set of scenes you use as a test pack?
Pushed my test pack to https://github.com/haasn/hdr-tests
-
@haasn hendrik mentions this comes from libplacebo, can you add this pls?
Sure. Pushed to https://code.videolan.org/videolan/libplacebo/-/merge_requests/553
-
New spline tone mapping (right) even seems to outperform HDR10+ OOTF (ST2094-40, left) on some scenes, but worse on others..
-
Yes, exactly. If the output is set to gamma 2.2, then libplacebo applies an inverse gamma 2.2 function before outputting to the display. So to recover raw nits from the output you should apply a gamma 2.2 function to the measured pixel values. (Or set output gamma to linear, if you're capturing in 16-bit precision)
going back to this problem, I still can't get the measured output to look much like the tone mapping function
to recap my process
* create a png encoding in 1% steps from 0-100% where 100% is rescaled based on the max nits (so multiply by ~0.7518 for 1000 nits)
* encode that as an mkv using ffmpeg / x265
* play the mkv in JRVR
* take a screenshot, save to png
* extract the rgb value of each column in the png (using imagemagick output as a %age)
* calculate the luminence of that, apply the appropriate gamma function, convert to nits based on my specified max output (100 nits) then convert that to pq
* plot this vs the theoretical pq input values (aka 0 to ~0.7518 in equal steps)
I removed my 3dlut to take that out of the equation and plotted it against the reference as per your desmos link, it gives me the attached (ref is the tone mapping curve, none is my measured output)
I think my parsing of my png is accurate as I don't see that flat top (clipping) in it which you'd expect if the tone mapping curve were applied
I think it means either the measured average is not what I expect or I'm missing something else
in this case, it says it's tonemapping 1020->100 which must be the peak, it's a even grey scale should average should be 510? measured behaviour is more like the curve you get from an average ~120 (not exactly the same but pretty close)
-
Can you post your file?
-
Can you post your file?
which one?
speaking of missing something made me remember you posted this previously
Smax is typically the 99.95% percentile value of PQ(Y). Savg is the mean of PQ(Y).
so actually the mean is invariably going to be invariably really low isn't it?
for example, the mean of a 0-1000 nits pattern should be 500 nits but converted to PQ and back again, it's ~24.8 nits
i.e.
eotf_ST2084(eotf_inverse_ST2084(1000) / 2)
(I use https://colour.readthedocs.io/en/develop/generated/colour.eotf.html for the conversions)
and actually this does have much the same shape with my measurement (not a perfect fit but the slopes are v similar)
-
It sounds like you are thinking of the median, not the mean. The mean would be higher, because on a linear brightness plot of 0-1000 nits, the vast majority of the area has high PQ values.
eg.
import colour
accum = 0
for nit in range(1,1000):
accum += colour.models.eotf_inverse_ST2084(nit)
print(colour.models.eotf_ST2084(accum / 1000))
==> 375.1
Its not quite 500, but far from 24.8
I'll be adding the output from the peak detect to the OSD in a future update, need to roll new libplacebo binaries again.
-
that is where I started from, i.e.
compute the ADL of the scene
observe that the resulting tone mapping curve behaves much like clipping
assume that might be the reason for apparent clipping in bright scene (S&M horse)
try to measure that directly using a gamma ramp
and that's the point at which measured reality does not appear to match expectation as I don't see or measure a curve that looks like that
so then next steps where
and the only reason I have thought of that is because it appears to fit what I measure, i.e.
find the value for Savg that produces the actual shape
look for a rationale for libplacebo using that value
and that bought me to a linear PQ ramp
z = eotf_inverse_ST2084(1000)
v = np.arange(0, z+0.0001, z / 100)
v_avg = np.mean(v)
f'mean: {v_avg:.6g} nits: {eotf_ST2084(v_avg):.3g}'
==> mean: 0.375914 nits: 24.8
which is what you get if you were to measure the input pixel values themselves, take the mean of those and then convert the resulting value to PQ
-
you may recall that, for a 1000nits peak, I found madvr and jrvr to measure v similarly so I added the ShowHdrMode folder to madvr to get more OSD info and that prints the frame FALL for us
madvr computes it as 50.252 nits with a fall stdev of 31.98
50 is actually a closer match at the top end vs my previous eyeballed value of 25
-
decided to look at libplacebo code for this and I think it measures luminance via this shader
// Measure luminance as N-bit PQ
GLSL("float luma = dot("$", color.rgb); \n"
"luma *= %f; \n"
"luma = pow(clamp(luma, 0.0, 1.0), %f); \n"
"luma = (%f + %f * luma) / (1.0 + %f * luma); \n"
"luma = pow(luma, %f); \n"
"uint y_pq = uint(%d.0 * luma); \n",
sh_luma_coeffs(sh, &csp.hdr.prim),
PL_COLOR_SDR_WHITE / 10000.0,
PQ_M1, PQ_C1, PQ_C2, PQ_C3, PQ_M2,
PQ_MAX);
I found a few sources online for a pq2linear function (referenced via some madvr thread on avs & github) - https://github.com/HDRWCG/HDRStaticMetadata/blob/master/hdrgenerator.cpp#L56 - which calculates the luminance of a pixel and then raises to the power of 1.0/78.84375 , can't find any explanation of where that value comes from though.
-
You can lookup the official PQ formula in the BT.2100 spec, which is where these magic numbers are documented: (well, not quite their origin, but at least their authority)
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-201807-I!!PDF-E.pdf (Table 4)
The peak detect shader implements the inverse PQ EOTF, eg. linear light to PQ, the code you linked does PQ to linear light.
The image gets decoded from PQ to linear light before any further processing is done on it, so these shaders don't run on a PQ input.
-
Ah somehow I missed that m2 was 78.84375
Moderately sure my code is doing the same operations then, will add a fall calc to check what comes out
-
decided to look at libplacebo code for this and I think it measures luminance via this shader
// Measure luminance as N-bit PQ
GLSL("float luma = dot("$", color.rgb); \n"
"luma *= %f; \n"
"luma = pow(clamp(luma, 0.0, 1.0), %f); \n"
"luma = (%f + %f * luma) / (1.0 + %f * luma); \n"
"luma = pow(luma, %f); \n"
"uint y_pq = uint(%d.0 * luma); \n",
sh_luma_coeffs(sh, &csp.hdr.prim),
PL_COLOR_SDR_WHITE / 10000.0,
PQ_M1, PQ_C1, PQ_C2, PQ_C3, PQ_M2,
PQ_MAX);
I found a few sources online for a pq2linear function (referenced via some madvr thread on avs & github) - https://github.com/HDRWCG/HDRStaticMetadata/blob/master/hdrgenerator.cpp#L56 - which calculates the luminance of a pixel and then raises to the power of 1.0/78.84375 , can't find any explanation of where that value comes from though.
Looking at this code again makes me suddenly question whether the luma coefficients we use are wrong. Shouldn't we use the encoding space coefficients, rather than the mastering display coefficients? I think this is a bug, and may result in slightly wrong values of calculated luminance.
-
Looking at this code again makes me suddenly question whether the luma coefficients we use are wrong. Shouldn't we use the encoding space coefficients, rather than the mastering display coefficients? I think this is a bug, and may result in slightly wrong values of calculated luminance.
Yeah, I'm pretty sure it was a bug. Fortunately, the fixed values are barely different in most scenes.
-
which one?
This one:
* create a png encoding in 1% steps from 0-100% where 100% is rescaled based on the max nits (so multiply by ~0.7518 for 1000 nits)
* encode that as an mkv using ffmpeg / x265
* play the mkv in JRVR
-
This one:
generated using https://github.com/3ll3d00d/jrmc-utils/blob/master/greyscale/greyscale.py
encoded using ffmpeg as per the params listed here https://github.com/3ll3d00d/jrmc-utils/blob/4ecbf85003e4c20161299c10ed98f2118d148234/greyscale/greyscale.py#L68
-
based on those links, it seems the MaxFALL of my greyscale ramp is ~144
given each column is a solid block then it is equivalent to a single row containing 1 pixel of each level
np.mean(eotf_ST2084(np.arange(0, n1000 + n1000 / 100, n1000 / 100)))
==> 144.22975018386427
the tone mapping curve definitely does not match my measurements when Savg = 144 though (the slope at the top end has already started to flatten)
-
so actually the mean is invariably going to be invariably really low isn't it?
for example, the mean of a 0-1000 nits pattern should be 500 nits but converted to PQ and back again, it's ~24.8 nits
i.e.
eotf_ST2084(eotf_inverse_ST2084(1000) / 2)
(I use https://colour.readthedocs.io/en/develop/generated/colour.eotf.html for the conversions)
and actually this does have much the same shape with my measurement (not a perfect fit but the slopes are v similar)
I built plplay and ran it on that file, libplacebo does indeed produce a number that looks much like the calculation I performed above (see attached).
it seems unusual to me at least (doesn't mean it's bad/wrong of course), well below that produced by either a FALL calc or an ADL like calculation for this pattern. I will have to try some different scenes to see if that is representative.
-
wrote a little script to calculate fall/max in a few different ways
https://github.com/3ll3d00d/jrmc-utils/blob/master/maxfall/calc.ipynb
APL seems correct
FALL I'm less certain of how to turn into nits, e.g. if I know it says it's a maxcll=1000 file then how to account for that given a screenshot is going to contain full range (0-255) rgb values?
Generally can't reproduce the libplacebo avg at all but can see, from plplay, it's consistently below anything that seems to be generally used (APL or FALL based calcs) or seen in madvr.
One question, I think black bars are included in the calculation. Are bars removed before it reaches the renderer (i.e. the cropped image is sent for rendering) or after? it seems relevant as that means the detected avg/peak will change and hence the tone mapping curve applied will also change.
-
Your plplay screenshot shows 37.83% APL, 25.51 nits. Your ipynb calculates 37.558% APL, 24.7286 nits. Isn't that basically a near-exact match?
One thing to consider is that plplay, at least as of current git master, will exclude solid black pixels from consideration. This avoids black bars messing things up too much (though pixels that are not perfectly 0 will still be counted, e.g. odd pixels with a value of 1 or 2, in practice this accounts for maybe a few percent of a typical black bar). It also means that in your grayscale ramp, the '0' column is not included in the max.
Indeed, if you bias the measured value up by a factor of 100/99 you get pq_eotf(n1000 / 2 * 100/99) = 25.906252786101845 nits, almost exactly what libplacebo measures. (The discrepancy can be explained by encoding noise)
-
Your plplay screenshot shows 37.83% APL, 25.51 nits. Your ipynb calculates 37.558% APL, 24.7286 nits. Isn't that basically a near-exact match?
it's a close match for the greyscale ramp yes
I can't get what seems a good match for real content though, I can add a filter to remove the bottom end to see if it improves that
ultimately if your curve is tuned to your numbers then i doubt it really matters what the absolute numbers are, it just means that the curve shape is different to what was expected when I started delving into this. Nevertheless I think it should be possible to independently verify this and it's mildly frustrating that I'm unable to do so hence why I keep scratching away at that itch :)
-
Something else to keep in mind for the peak estimation is that our "99.995%" is only an approximation value. We group the histogram into a small (64) number of buckets. So likely, all of the values from the top 99% and upwards fall into the same bucket - we don't have the histogram resolution to discriminate between them exactly. So we estimate, by assuming those values are evenly spread inside that bucket and then chopping off where the 99.995% percentile value would be under that assumption.
Also, it's very possible that the peak detection value is off by a small margin of error because of oversampling at the edge of the video. Peak detection runs on a 16x16 block size so we need to pad the image to be a multiple of 16x16. As far as I can tell, this is currently done by hard-clamping to the video, resulting in the same row of pixels basically getting duplicated. There might be a way for me to fix this, but I'm not sure. (Maybe we should at least switch to using mirroring instead of clamping, to avoid a single bright highlight becoming disproportionately dominant?)
P.s., made some more improvements to peak detection, in particular with regards to scene changes: https://code.videolan.org/videolan/libplacebo/-/merge_requests/559
-
am I right in thinking your Savg is calculated via the same 64 bin histogram based mechanism?
how do you pick the bin edges in this case? is it a linear stride from min to max?
one problem with reproducing this is knowing how to correctly scale RGB values of screenshot back into PQ (i.e. if I take a screenshot then max value is always 255 which then implies 10k nits but what's the correct max value in this case? rescale down to the stated MaxCLL or leave it as is?). How does this actually work in the real content stream? e.g. if maxcll is 1000 then the decoded values can still imply a 10000 peak? i.e. if it actually keeps to 1000 then the peak value is ~0.75 (relatively speaking)?
regardless, I applied this technique and see v minor differences on the 99.95% value, slightly bigger but still relatively small differences on the avg value (vs an accurate percentile/mean) but these values are still way off what plplay reports (albeit see above point about how to scale a png of a tonemapped image to get back to a sane pq value, perhaps that's an intractable problem with a hdr rendering? )
-
The Average PQ brightness is calculated with a straight forward artihmetic mean (add them all up, divide by count), the histogram bins are not used here. Although it does use the same 16x16 blocks the compute shader runs on.
PQ is an absolute scale, it always goes from 0 to 10000, metadata is just a hint to help the software/screen, it does not impact the coding of the values. So any given PQ value is always the same brightness. So yes, a 1000 nits image would have a peak of ~0.75 in PQ, and you can certainly have pixel that exceed MaxCLL.
-
Incidentally, I noticed some other inconsistencies in the peak detection the other day, where a static frame was showing changing peak detect values over time (which should be impossible). I was planning to look into some potential bugs here.
-
Also, it's very possible that the peak detection value is off by a small margin of error because of oversampling at the edge of the video. Peak detection runs on a 16x16 block size so we need to pad the image to be a multiple of 16x16.
how do you analyse a 16x16 block? is it the average luminance of the pixels within the block?
for example, if I look at your orientexpress.hevc file, there are 2 {255,255,255} pixels (see attached for location). Your peak detect definitely doesn't see these so I would think that means they are either not in the source (see my last comment about how to get a passthrough) or averaged away by the use of a 16x16 block.
As far as I can tell, this is currently done by hard-clamping to the video, resulting in the same row of pixels basically getting duplicated. There might be a way for me to fix this, but I'm not sure. (Maybe we should at least switch to using mirroring instead of clamping, to avoid a single bright highlight becoming disproportionately dominant?)
given we're talking about a few pixels at the border (and for standard resolutions, I think it means we're talking about the top/bottom only), would cropping make more sense?
PQ is an absolute scale, it always goes from 0 to 10000, metadata is just a hint to help the software/screen, it does not impact the coding of the values. So any given PQ value is always the same brightness. So yes, a 1000 nits image would have a peak of ~0.75 in PQ, and you can certainly have pixel that exceed MaxCLL.
if I take a UHD source, disable tonemapping and make it output as BT2020, is this equivalent to a passthrough of the source content?
-
if I take a UHD source, disable tonemapping and make it output as BT2020, is this equivalent to a passthrough of the source content?
You also want to output in PQ - without windows knowing its PQ and converting to SDR for you. Assuming you want to screenshot it for analysis. Or maybe using ffmpeg with vf_libplacebo might be the way to go here to make straight up images in the specification you want.
Any SDR output will clip the content thats above the SDR brightness (unless tone mapping has reduced it below already). I suppose you could set the SDR brightness at 10000 nits, but the gamma encoding is terrible for such a huge brightness range and you would lose a lot of detail.
-
You also want to output in PQ - without windows knowing its PQ and converting to SDR for you.
thanks, I hadn't thought of that. It removes that scaling problem completely & using vf_libplacebo would also make a lot of sense as it get a bit tedious pulling out screenshots manually :)
-
so I wonder what turns those pixels in my previous pic into 100% white? in PQ, those same pixels are ~60% grey which is similar to neighbouring pixels but when rendered to either bt2020 or 709, just those 2 pixels turn in 100%
-
Incidentally, I noticed some other inconsistencies in the peak detection the other day, where a static frame was showing changing peak detect values over time (which should be impossible). I was planning to look into some potential bugs here.
Okay, I figured out what was causing this - debanding being enabled. If I disable debanding, I always measure the exact values. But with debanding adding some amounts of noise and grain, the values fluctuate from frame to frame. This is expected, I guess, so no cause for alarm here.
-
So, here is the result of my experimentation on orientexpress.hevc. In all cases, I am testing with plplay defaults and HDR peak detection enabled. I kept the peak percentile at 100.0%, to make sure we get only exact (not approximated) values.
Measured values:
- Max: 291.00 cd/m² (61.86% PQ)
- Avg: 4.34 cd/m² (23.80% PQ)
- (99.995% estimate: 263.55 cd/m² (60.81% PQ))
I then took the image and passed it through a grayscale operator using ImageMagick for analysis. For lack of anything better, I used the Rec709Luminance option, even though this is not entirely accurate (wrong gamma, wrong matrix coefficients on the BT.2020 image). So it should be taken only with a grain of salt. They are also only accurate to 8 bits (I disabled dithering to get consistent values), so there is about ~10 nits of rounding error towards the top end. Regardless, here are the measured values:
BT.2020 PQ input file:
Channel statistics:
Pixels: 2674210
Gray:
min: 11 (0.0431373)
max: 158 (0.619608)
mean: 60.9368 (0.238968)
median: 45 (0.176471)
standard deviation: 39.9296 (0.156587)
kurtosis: -0.991433
skewness: 0.709792
entropy: 0.93231
So the true maximum as measured by this method is 61.96% PQ. Slightly higher than what libplacebo was measuring, but given the inaccuracies inherent in the IM method, alongside the 8 bit rounding, the libplacebo result is more likely to be accurate. The mean as estimated by this process is 23.89% PQ, again matching (if slightly too high) what libplacebo measures.
Gamut mapped BT.709, output in PQ:
Channel statistics:
Pixels: 2674210
Gray:
min: 10 (0.0392157)
max: 158 (0.619608)
mean: 60.8102 (0.238471)
median: 45 (0.176471)
standard deviation: 39.9282 (0.156581)
kurtosis: -0.986014
skewness: 0.71678
entropy: 0.930441
After gamut mapping from BT.2020 to BT.709 we see that the max is still 61.96% and the mean is 23.84%. This is now a bit closer to the libplacebo measured values, probably because now we're using the correct matrix coefficients for the grayscale operator (BT.709) - even if the gamma is still wrong.
Tone mapped to SDR BT.2020, output in PQ:
Channel statistics:
Pixels: 2674210
Gray:
min: 10 (0.0392157)
max: 148 (0.580392)
mean: 58.6171 (0.229871)
median: 44 (0.172549)
standard deviation: 38.0244 (0.149115)
kurtosis: -1.04137
skewness: 0.679
entropy: 0.933258
The max has been reduced to 58.0392% PQ, or about 202.42 nits. This tracks well onto the 203 nits target. The new frame average brightness is 22.9871%, or 3.85 nits (down from 4.34 nits). This steps seems to be working as intended.
Gamut mapped SDR BT.709, output in PQ:
Channel statistics:
Pixels: 2674210
Gray:
min: 10 (0.0392157)
max: 146 (0.572549)
mean: 58.5102 (0.229452)
median: 44 (0.172549)
standard deviation: 38.0216 (0.149104)
kurtosis: -1.03707
skewness: 0.684922
entropy: 0.935584
After gamut mapping to BT.709 it appears the maximum has dropped down to 57.25% PQ, or 187.76 nits. This is substantially lower than 203 nits, but was evidently introduced as part of the headroom needed for perceptual gamut mapping. (In terms of 8 bit PQ values it is only lower by 2, so it's probably also distorted by rounding error) The frame average remains almost unchanged at around 22.94% PQ, or 3.83 nits.
Final SDR output:
Channel statistics:
Pixels: 2674210
Gray:
min: 4 (0.0156863)
max: 248 (0.972549)
mean: 59.4856 (0.233277)
median: 28 (0.109804)
standard deviation: 60.3931 (0.236836)
kurtosis: -0.468588
skewness: 1.03268
entropy: 0.868375
And in full color RGB:
Channel statistics:
Pixels: 2674210
Red:
min: 6 (0.0235294)
max: 255 (1)
mean: 67.0188 (0.262819)
median: 37 (0.145098)
standard deviation: 59.135 (0.231902)
kurtosis: -0.525254
skewness: 0.924761
entropy: 0.884698
Green:
min: 3 (0.0117647)
max: 255 (1)
mean: 56.4452 (0.221354)
median: 22 (0.0862745)
standard deviation: 61.4242 (0.240879)
kurtosis: -0.463476
skewness: 1.0606
entropy: 0.849128
Blue:
min: 0 (0)
max: 240 (0.941176)
mean: 55.7532 (0.21864)
median: 21 (0.0823529)
standard deviation: 62.118 (0.2436)
kurtosis: -0.118993
skewness: 1.2104
entropy: 0.819895
Image statistics:
Overall:
min: 0 (0)
max: 255 (1)
mean: 59.739 (0.234271)
median: 26.6667 (0.104575)
standard deviation: 60.8924 (0.238794)
kurtosis: -0.404202
skewness: 1.05152
entropy: 0.85124
So the final SDR output perfectly spans the pixel range 0-255, with the average pixel being 59.739 (or about 23.42% of the available value range, which is exactly what we'd expect given the input scene distribution).
-
how do you analyse a 16x16 block? is it the average luminance of the pixels within the block?
for example, if I look at your orientexpress.hevc file, there are 2 {255,255,255} pixels (see attached for location). Your peak detect definitely doesn't see these so I would think that means they are either not in the source (see my last comment about how to get a passthrough) or averaged away by the use of a 16x16 block.
given we're talking about a few pixels at the border (and for standard resolutions, I think it means we're talking about the top/bottom only), would cropping make more sense?
if I take a UHD source, disable tonemapping and make it output as BT2020, is this equivalent to a passthrough of the source content?
I cannot reproduce this with my methodology, and I see no (255,255,255) pixels anywhere either in the source nor in the tone-mapped result. As for your question, we measure maximum and average separately:
PQ_Y = Input luminance in 14-bit PQ
Block_Avg := Sum(PQ_Y) / Block_Size
Block_Max := Max(PQ_Y)
Global_Avg := Sum(Block_Avg) / Num_Blocks
Global_Max = Max(Block_Max)
-
All I did was play it with plplay with default settings and then took a screen capture of the active window, results in 2 white pixels here.
-
The changes to libplacebo talked about here over the last page and a half will be available to JRVR in 31.0.60. And the average and peak brightness levels will now be shown on the OSD.
-
sounds good, any plans to expose further tunable parameters to influence the tone mapping?
-
There will be an advanced option to let you tweak every libplacebo option by referring to it by name (not in yet, need to restructure how we set all the libplacebo settings). If one option proves to be particularly meaningful, it might get a UI option later.
-
Great, will test later on
-
Build 61 should have the advanced options interface, which is essentially just a textbox on our end.
Multiple options are delimited with commas, (semi)colons or whitespace.
There is a documentation page for libplacebo here which documents these:
https://libplacebo.org/options/
You are likely going to be interested in Tone-mapping constants:
https://libplacebo.org/options/#tone-mapping-constants
These settings are applied after all ours, so it should allow overriding almost everything, with only a few tiny exceptions that are re-set based on each input frame.
-
Build 61 should have the advanced options interface, which is essentially just a textbox on our end.
There is a documentation page for libplacebo here which documents these:
https://libplacebo.org/options/
You are likely going to be interested in Tone-mapping constants:
https://libplacebo.org/options/#tone-mapping-constants
These settings are applied after all ours, so it should allow overriding almost everything, with only a few tiny exceptions that are re-set based on each input frame.
How does the new Hermite downscaling option compare to using SSIM external shader?
-
Hermite is a high-performance option with decent quality, its not a top quality option, but it's fast, and better then bilinear in quality.
But this is not a tone mapping question, please use the other thread for generic inquiries. :)
-
Most everything in this thread is beyond my pay grade... but I do have a problem that if I activate the HDR and HDR tone mapping options for many of my 4k videos they basically go black... too dark to watch. I've tried adjusting the Windows HDR calibration and playing with settings in JRVR.
My question is... for those of us that don't really follow what's going on in this thread, where should we be setting our HDR options to avoid this ultra dark? Thanks, in advance, for your help.
-
I think there is a bug in here as there is some extremely obvious/distracting brightness flickering in at least one scene from the S&M disk (the one shown in the attached pic)
as it rotates, the petals visibly flickering in brightness
-
see attached
NB: this is a video using simplescreenrecorder of my windows HTPC playing this back viewed via KRDC so no clue what that does to the colours, I'm just trying to demonstrate the flickering here
-
When quoting a sample from the S&M disc, can you let us know which file on the disc it is, or something to help finding it? :D
-
Same track the snowy horse comes from, disc 2 4th option down on the left then the bt2020 1000 nits version
-
track shown in the attached menu, scene starts at ~3:09
-
the visibility of the effect scales with the contrast ratio option, it's more obvious as contrast ratio goes up but remains visible even at the lowest 1000:1 setting
the effect appears to completely disappear only once you get to ~400 nits tone mapping target (peak for this scene is ~600 nits)
the reported avg appears to flicker between ~3 and ~6 nits
this might suggest the problem is centred on scene detection? i.e. it shouldn't be changing the target curve during this scene but is hence the brightness flickering
-
Peak Detection seems like the likely culprit. Possibly the more responsive settings are a bit too aggressive, especially with it ignoring black pixels. I'm reading in the second disc now and will confirm in a bit.
-
I can definitely see it here. Curious that it doesn't happen on the similar scenes before and after that point.
-
Build 61 should have the advanced options interface, which is essentially just a textbox on our end.
Multiple options are delimited with commas, (semi)colons or whitespace.
There is a documentation page for libplacebo here which documents these:
https://libplacebo.org/options/
You are likely going to be interested in Tone-mapping constants:
https://libplacebo.org/options/#tone-mapping-constants
These settings are applied after all ours, so it should allow overriding almost everything, with only a few tiny exceptions that are re-set based on each input frame.
Holymoly!
Thanks Hendrik!!!!
Really glad you guys have put so much time into JRVR. It's quickly replacing MadVR for me. I pushed myself into using it for the last ~ 2 weeks for my more critical viewing in the theater and I gotta say, it aint bad. It's getting *really* close.
-
So, the problem in this scene boils down to to strange encoding noise, causing the result to flicker between 0 and 1, rather than being a constant 0. Since we ignore all-black pixels when computing the frame average brightness, this results in the average brightness flickering wildly. (See pic, orange pixels here are all-black)
I suspect the solution will be to use some sort of soft roll-off rather than a hard cutoff.
-
fwiw that's the only time I've noticed such instability so far (not had time to test extensively though)
does that affect the avg only? or how does this interact with https://libplacebo.org/options/#hdr-peak-detection which seems to be where the scene detection parameters are? If it's constantly updating the avg/peak within a scene then isn't that going to (theoretically) lead to further instability?
-
One of the main posters on the madvr tonemapping thread provided a load of shots from some aces test patterns which might be useful
https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector-no-support-questions.2954506/page-849#post-62865517
It's noticeable how the two have flipped around since a few months ago, madvr is now the more saturated one while jrvr can look a little anaemic at times (colours that you might expect to pop aren't doing so in some scenes but are in others)
I will post pics at the weekend to illustrate
-
a few comparisons
sometimes jrvr is just a bit dark
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=02edd15c-64a6-11ee-b5be-6595d9b17862
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=6e1afdec-64a6-11ee-b5be-6595d9b17862
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=a9fe2582-64a6-11ee-b5be-6595d9b17862
yet other times it's markedly brighter
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=ecd76bfc-64a6-11ee-b5be-6595d9b17862
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=9e8716f6-64a5-11ee-b5be-6595d9b17862
or red is a bit too desaturated (though red is a bit excessive in the comparison in this example for me)
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=d2a98fcc-64a5-11ee-b5be-6595d9b17862
subjective impression atm... jrvr is a bit dark, madvr (I am using the most version before the very latest batch of more experimental changes) a bit red
-
Overall madvr is certainly looking much better than JRVR.
-
In the first example, one looks like a night scene. The other doesn't.
In the last example, take a look at the text on the vertical sign at the left. One is nearly readable. The other is muddy.
-
I redid the madvr shots using these settings to try to tone down the (imo excessive) red saturation - https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector-no-support-questions.2954506/page-831#post-62830597
I didn't realise those links would update automatically so the old version is gone, same links (if you force a reload) should now compare those settings with jrvr both set to tm to 100nits
Overall madvr is certainly looking much better than JRVR.
I can watch either quite happily tbh. I have watched some films and did not notice any misbehaviour from jrvr and it looked fine. In comparison, for me, the red saturation in madvr is a bit much at times atm. When you flip them back to back then the differences do become quite apparent and they do seem to tone map quite differently right now. I would say that jrvr is flatter (it's darker in dark scenes but lighter in some other scenes) and it seems that red is generally desaturating quite a bit more than you might expect so I think there is room for improvement there (and/or room for some accessible options to tweak the behaviour)
In the last example, take a look at the text on the vertical sign at the left. One is nearly readable. The other is muddy.
see attached, the traffic light makes it clear what is going on because we have a reasonable expectation of what a traffic light looks like. In JRVR, on a RGB colour picker, red and green are basically maxed out & blue is at ~170 so it seems like it has shifted well beyond orange. In madvr, it's at ~230 red/green and ~130 blue. Perhaps this is actually just a reflection of how jrvr is pushing towards clipping? i.e. the same excess of brightening that we seem in some other images. While madvr does tend to get a bit red for me, I do think it's giving a more realistic image overall.
NB: haven't looked at a non tone mapped version of this so these are purely subjective comments atm
-
Anyway, I gave the dynamic adaptation strength a few more thoughts and came up with something like this: https://www.desmos.com/calculator/tyv2elsdao
I thought of trying to tweak some parameters but wanted to do it in a vaguely educated way rather than guessing so is the above reflective of the current build?
if so, is
Kadaption_pre = knee_adaptation (https://libplacebo.org/options/#tone-mapping-constants)
-
I thought of trying to tweak some parameters but wanted to do it in a vaguely educated way rather than guessing so is the above reflective of the current build?
if so, is
Kadaption_pre = knee_adaptation (https://libplacebo.org/options/#tone-mapping-constants)
You can compare to the code if in doubt, but that is the same variable (the code has a bit of a different flow, but the math is the same)
https://github.com/haasn/libplacebo/blob/master/src/tone_mapping.c#L226
-
I wonder if the difference in saturation is solely due to this desaturation mechanism:
diff --git a/src/shaders/colorspace.c b/src/shaders/colorspace.c
index f044b543..429e4491 100644
--- a/src/shaders/colorspace.c
+++ b/src/shaders/colorspace.c
@@ -1965,7 +1965,7 @@ void pl_shader_color_map_ex(pl_shader sh, const struct pl_color_map_params *para
}
// Avoid raising saturation excessively when changing brightness
- GLSL("ipt.yz *= min(i_orig / ipt.x, ipt.x / i_orig); \n");
+ //GLSL("ipt.yz *= min(i_orig / ipt.x, ipt.x / i_orig); \n");
}
if (need_gamut_map) {
Some random pictures: https://slow.pics/c/VBgsCfbs
Simply removing this line is probably not the correct fix but it does illustrate the downside of this logic (which was originally a solution for the exact opposite problem, excessive saturation in very dark/bright scenes).
-
The difference is even more pronounced at 100 nits target: https://slow.pics/c/iuZ7ktw6
-
I recall reporting that some months ago (people looking too red in certain scenes), certainly there's a line to tread between giving everyone sunburn and bleaching the red out
some sort of more complex rolloff is required I guess?
-
I recall reporting that some months ago (people looking too red in certain scenes), certainly there's a line to tread between giving everyone sunburn and bleaching the red out
some sort of more complex rolloff is required I guess?
Yeah, possibly we want to reduce the saturation along the curve of the actual gamut hull, rather than linearly. It is some sort of convex function that is non-trivial to compute. Maybe we can approximate it with some sort of polynomial?
-
I was fiddling with different values for those tm parameters and noticed that you can inadvertently break it when simulating dark scenes, at least in the desmos link anyway
it occurs when this becomes undefined
K_{CoefLow}=f_{smoothstep}\left(K_{Min},K_{Def},T_{knee}\right)
because Kmin = Kdef = Tknee
example in https://www.desmos.com/calculator/1roma3igms
it's common for Savg to be quite low when expressed in nits and it only takes some small highlight areas to bump up the peak which is what this simulates, I was then trying to up the avg level without producing odd discontinuities in the curve as Savg increases so reduced Kdef then was playing with Kmin (which then clamps Kdef to Kmin). At this point you fairly quickly notice the curve disappearing because of the above condition being met.
not sure if this affects the real implementation or is it just an artifact of the simulation?
-
not sure if this affects the real implementation or is it just an artifact of the simulation?
It is an artifact of the simulation, the real code handles this edge case:
static inline float pl_smoothstep(float edge0, float edge1, float x)
{
if (edge0 == edge1)
return x >= edge0;
x = (x - edge0) / (edge1 - edge0);
x = PL_CLAMP(x, 0.0f, 1.0f);
return x * x * (3.0f - 2.0f * x);
}
Though we could also work it around by enforcing a small epsilon between Kdef and Kmin. Note that this is a degenerate case any way, since normally Kmin < Kdef < Kmax.
-
knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25
I'm going to try and live with this for a while as a set of options that, for a projector like a jvc, gives a bit of pop back in dark scenes without appearing to compromise brighter scenes.
MC default => https://www.desmos.com/calculator/xmq9mspdb7
"Pop" preset => https://www.desmos.com/calculator/o2yre5gyyb
click play on Savg to compare the curve across different scene avgs (for a given peak)
At first glance, it seems to do the job but need to spend more time on real content to know whether it actually works. It might be pushing it just a bit far at times, e.g. lack of detail on the boy on left
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=ea50a89a-65c7-11ee-b5be-6595d9b17862
but in other cases it brings the highlights to life
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=110cec8c-65c8-11ee-b5be-6595d9b17862
or toning down some of the brightness
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=3ba1e3e4-65c8-11ee-b5be-6595d9b17862
-
Yeah, possibly we want to reduce the saturation along the curve of the actual gamut hull, rather than linearly. It is some sort of convex function that is non-trivial to compute. Maybe we can approximate it with some sort of polynomial?
I computed a third-order polynomial approximation. Using this instead of a linear desaturation recovers a bit more of the source.
https://code.videolan.org/videolan/libplacebo/-/merge_requests/609
-
Hello,
This is exactly my feeling every time I watch a film or series with JRVR DTM on my Sony XW5000 with JRiver. The image is very beautiful, dynamic but sometimes too dark and sometimes lacks "pop"..
How do we implement this modification Haasn? Because it seems to solve this problem no ?
THANKS !
-
MC default => https://www.desmos.com/calculator/xmq9mspdb7
"Pop" preset => https://www.desmos.com/calculator/o2yre5gyyb
Looking at your "Pop" preset, it almost seems like you want the lower section of the TM curve to be a linear function instead of a 2nd order polynomial?
-
This is exactly my feeling every time I watch a film or series with JRVR DTM on my Sony XW5000 with JRiver. The image is very beautiful, dynamic but sometimes too dark and sometimes lacks "pop"..
How do we implement this modification Haasn? Because it seems to solve this problem no ?
The changes to libplacebo discussed here will be available in JRVR in a future update, but don't have an exact ETA right now.
-
Looking at your "Pop" preset, it almost seems like you want the lower section of the TM curve to be a linear function instead of a 2nd order polynomial?
It wasn't a design target as such, just a side effect of a) trying to minimise loss in dark scenes, and b) avoiding unusual variations in the curve behaviour as Savg increases while working with the parameters available. The latter was definitely a problem with some values, especially when s contrast is higher.
-
I added a curve that does something like what you want w.r.t spline slope being mostly linear, but I think it has some undesirable loss of contrast and brightness in dark scenes e.g. frame 44 of the test set above (contrary to your intentions): https://code.videolan.org/videolan/libplacebo/-/merge_requests/610
Not sure I'm happy with it. It seems like we need some logic to prevent the slope from getting too low.
-
Something has broken in my libplacebo build setup since I last tried to built plplay so I can't currently try it out, do you have some page somewhere describing a build environment?
A desmos sim could be handy if you have a moment to do that also
-
fixed my libplacebo build, are those options accessible in plplay?
-
fixed my libplacebo build, are those options accessible in plplay?
Yeah, inside the "Tone mapping" section, under "Fine-tune constants"
-
Overall madvr is certainly looking much better than JRVR.
IMO, they are different, but TBH none is objectively wrong or overall better-looking – whatever that means, because as always with TM what we find "better-looking" might not even be what the colourist saw when grading this scene. That's one of the reasons the AVSforum madvr DTM thread is 5 years old and 850+ pages long with thousands of infinite variations of the same 10 screenshots :D
-
IMO, they are different, but TBH none is objectively wrong or overall better-looking – whatever that means, because as always with TM what we find "better-looking" might not even be what the colourist saw when grading this scene. That's one of the reasons the AVSforum madvr DTM thread is 5 years old and 850+ pages long with thousands of infinite variations of the samey 10 screenshots :D
I agree, if you read that thread recently they are basically guessing at what to do right now. I am not saying this is right or wrong just that their TM is just as much a work in progress as anyone elses. Also lets not forget that the TM in the Envy is months / years behind the PC version and everyone raves about it.
I watch a film almost every night using JRVR and have yet to see anything I find unacceptable. Improvements are always welcome but everything works really well ATM.
-
After comparing a lot between madVR, MPV and JRiver MC I found out that dark scenes suffer from desaturation in libplacebo when target-contrast is not "inf". I created an issue (https://github.com/mpv-player/mpv/issues/12707) for that. Both MPV and JRiver MC are affected.
Beside that the tone mapping looks pretty good now. Very bright and high saturated scenes are a bit worse in regards of details comparing do madVR. But I would say >90 % of the time it looks very close and has no problems with very bright scenes/movies.
One little thing: using the internal color conversion (without 3D LUT) the orange tints are less saturated in comparison to madVR. Using relative conversion for gamut mapping mode can change that (tested with MPV). Most of the time it is not visible. I only noticed it in "Elemental" which is very special, because the main character is a flame. :)
-
Nice to see you here again Nils. Nils is a known as a genius in the German community regarding MadVr and HDR Tonemapping. I think he could help here a lot with testing and reporting about quality and improvements.
-
I posted this in the JRVR tonemapping thread (https://yabb.jriver.com/interact/index.php/topic,135621.msg952578.html#msg952578) but will repost a shorter version here as it might be more appropriate.
I find using the knee_adaptation parameter very useful (for example changing it to 0.8 from the 0.4 default) resolves the highlights crushing in the cloud details at the beginning of chapter 3 of Pacific Rim, though it might have downsides elsewhere, I haven't checked for this yet), so it might be a good idea to expose this parameter in the GUI.
I also find a huge brightness instability issue with high nits content. For example, chapter 3 in Mad Max Fury Road is unwatchable with a peak of 100nits (all advanced options enabled, enabling slow peak detection doesn't seem to help).
There is no stability issue with madVR as long as you select the correct settings in the latest experimental build (see details in the link above).
Any chance to get this brightness instability in JRVR resolved? Can other users confirm that they experience this too with around 100nits peak and mad max FR chapter 3?
-
I find using the knee_adaptation parameter very useful (for example changing it to 0.8 from the 0.4 default resolves the highlights crusing in the cloud details at the beginning of chapter 3 of Pacific Rim, though it might have downsides elewhere, I haven't checked for this yet), so it might be a good idea to expose this parameter in the GUI.
what are you using for spline contrast?
-
what are you using for spline contrast?
0, and contrast enhance is disabled too (not sure it does anything when spline is selected).
I find that spline contrast crushes highlights too much, so I leave it to zero.
-
0, and contrast enhance is disabled too (not sure it does anything when spline is selected).
I find that spline contrast crushes highlights too much, so I leave it to zero.
I have tended in that direction also though I would say it does basically "disable" (for want of a better term) most of the design of that curve, it's largely invariant to the scene avg nits basically - https://www.desmos.com/calculator/xlqsj2qjhk
fwiw the one I was trying is like https://www.desmos.com/calculator/o2yre5gyyb which trades increased brightness/consistency at low end for possibly a flatter response (aka possibly less detail) at the top end, this is just the following option
knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25
I only spent limited time testing it though so can't say I can recommend it, seemed preferable to me in most scenes to the built in defaults though.
-
I have tended in that direction also though I would say it does basically "disable" (for want of a better term) most of the design of that curve, it's largely invariant to the scene avg nits basically - https://www.desmos.com/calculator/xlqsj2qjhk
fwiw the one I was trying is like https://www.desmos.com/calculator/o2yre5gyyb which trades increased brightness/consistency at low end for possibly a flatter response (aka possibly less detail) at the top end, this is just the following option
knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25
I only spent limited time testing it though so can't say I can recommend it, seemed preferable to me in most scenes to the built in defaults though.
Thanks, I'll give these a try and will report back.
Can you (or anyone else) reproduce the brightness stability issues I reported around 100nits peak? They make JRVR unusable to me. Please try to watch Mad Max Fury Road chapter 3 with 100nits peak and let us know.
-
Can you (or anyone else) reproduce the brightness stability issues I reported around 100nits peak? They make JRVR unusable to me. Please try to watch Mad Max Fury Road chapter 3 with 100nits peak and let us know.
I can confirm that there are visible brightness adjustments in your example.
-
I can confirm that there are visible brightness adjustments in your example.
Thanks for confirming!
Hopefully, this can be fixed.
-
After comparing a lot between madVR, MPV and JRiver MC I found out that dark scenes suffer from desaturation in libplacebo when target-contrast is not "inf". I created an issue (https://github.com/mpv-player/mpv/issues/12707) for that. Both MPV and JRiver MC are affected.
Beside that the tone mapping looks pretty good now. Very bright and high saturated scenes are a bit worse in regards of details comparing do madVR. But I would say >90 % of the time it looks very close and has no problems with very bright scenes/movies.
One little thing: using the internal color conversion (without 3D LUT) the orange tints are less saturated in comparison to madVR. Using relative conversion for gamut mapping mode can change that (tested with MPV). Most of the time it is not visible. I only noticed it in "Elemental" which is very special, because the main character is a flame. :)
I also noticed that very dark scenes become kind of grey if target-contrast is not set to inf (especially if left at default 1000). A good example is House of the Dragon episode 3, where there are dark scenes in the forest. target-contrast set to "inf" made it look very close to MadVR.
-
I have tended in that direction also though I would say it does basically "disable" (for want of a better term) most of the design of that curve, it's largely invariant to the scene avg nits basically - https://www.desmos.com/calculator/xlqsj2qjhk
fwiw the one I was trying is like https://www.desmos.com/calculator/o2yre5gyyb which trades increased brightness/consistency at low end for possibly a flatter response (aka possibly less detail) at the top end, this is just the following option
knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25
I only spent limited time testing it though so can't say I can recommend it, seemed preferable to me in most scenes to the built in defaults though.
Thanks again for these. They don't reclaim as much picture depth/contrast/detail in the Pacific Rim example at the beginning of chapter 3, but they produce a much better picture overall tha the default settings (to flat / crushed highlights) or my 0.8 knee_adaptation (great for the Pacific Rim example but too dim in most other situations). Like you I've only done limited testing so can't recommend them, but at first sight they seem like a significant improvement over the default.
Unfortunatey, they don't help with the brightness instability issue, so I won't investigate further until that issue is solved. Looking forward to a solution!
-
Thanks again for these. They don't reclaim as much picture depth/contrast/detail in the Pacific Rim example at the beginning of chapter 3, but they produce a much better picture overall tha the default settings (to flat / crushed highlights) or my 0.8 knee_adaptation (great for the Pacific Rim example but too dim in most other situations). Like you I've only done limited testing so can't recommend them, but at first sight they seem like a significant improvement over the default.
Unfortunatey, they don't help with the brightness instability issue, so I won't investigate further until that issue is solved. Looking forward to a solution!
thanks for testing, comparing to latest madvr beta (which I only just upgraded to and which brings it own blackscreen problems with some discs for me) and using your settings from avs for that, madvr is retains rather more saturation these days. I haven't noticed brightness instability that I can recall though, any other scenes noticed that on? I don't have max max so can't compare that one.
-
thanks for testing, comparing to latest madvr beta (which I only just upgraded to and which brings it own blackscreen problems with some discs for me) and using your settings from avs for that, madvr is retains rather more saturation these days. I haven't noticed brightness instability that I can recall though, any other scenes noticed that on? I don't have max max so can't compare that one.
The black screen with some discs with madVR might be because you have the measurements files enabled in madVR settings (configuration / files and folders) and have old measurements files for these titles. Recent test versions don't support measurements files, which causes these black screens when some are present. Delete the measurement files if present, or to be sure check "ignore all measurement files" in madVR configuration settings.
Re brightness jumps with JRVR, try any high nits films (mastered to 4,000nits or more) with fast scene changes. Maybe Pacific Rim, The Meg... The bathroom scene in chapter 4 of MI6: Fallout can be a good test for that too. So are the conference room scenes with Morgan Freeman in Lucy. I've stopped using JRVR since I noticed this, as it's a dealbreaker for me, so I don't have other example. But when madVR has some brightness stability issues, the above are the clips I use to test and eradicate.
There are no stability issues with the settings I posted recently on AVS for madVR (it definitely needs details threshold at one and either Mars or Mercury, as well as doubling the default brightness speed adjustment settings, and conservative contrast settings (up to log low or log very low max). Indeed, there is a lot more saturation and picture depth than JRVR, and no brightness stability issue.
-
which brings it own blackscreen problems with some discs for me
I noticed that it does sometimes hang on a black screen when closing a movie and has to be task killed. I'll check on the measurement files though, and see if that helps.
-
I noticed that it does sometimes hang on a black screen when closing a movie and has to be task killed. I'll check on the measurement files though, and see if that helps.
The measurements file issue is only when playback starts, not when it stops.
-
The bathroom scene in chapter 4 of MI6: Fallout can be a good test for that too.
ok yes I see what you mean, there's an example at approx 28:49 when they first walk in the bathroom. If you pause at that point and wait a little while then the peak nits stabilises to approx 1000nits, if you do this a few times (i.e. 1s jump forward then wait) then you see the following avg/peak nits pattern
8.1,957.9
7.4,99.8
11.1,99.8
15.2,471.1
15.4,489.5
17.4,513.5
24.7,522.5
this dip and rebound drives the brightness change and it occurs about 3-4s after the dip in peak nits and lasts for a second or so before it pops back up so I assume this is some sort of decaying average being applied over some seconds to judge the brightness? I guess it needs some additional logic to guard against short lived outliers which aren't scene changes to fix it which seem like it should be doable.
the nearly 1k nits peak scene is the attached and you can see the peak comes from the light that is outside the room but still just visible, in the next second the door has closed so it's no longer there hence the major reduction in peak nits
I'd agree this definitely would be a good thing to fix, you can make various choices on how to tune it but those give a generally consistent appearance but flickering is in the distracting category which you can't really get away from (once you see it).
-
ok yes I see what you mean, there's an example at approx 28:49 when they first walk in the bathroom. If you pause at that point and wait a little while then the peak nits stabilises to approx 1000nits, if you do this a few times (i.e. 1s jump forward then wait) then you see the following avg/peak nits pattern
8.1,957.9
7.4,99.8
11.1,99.8
15.2,471.1
15.4,489.5
17.4,513.5
24.7,522.5
this dip and rebound drives the brightness change and it occurs about 3-4s after the dip in peak nits and lasts for a second or so before it pops back up so I assume this is some sort of decaying average being applied over some seconds to judge the brightness? I guess it needs some additional logic to guard against short lived outliers which aren't scene changes to fix it which seem like it should be doable.
the nearly 1k nits peak scene is the attached and you can see the peak comes from the light that is outside the room but still just visible, in the next second the door has closed so it's no longer there hence the major reduction in peak nits
I'd agree this definitely would be a good thing to fix, you can make various choices on how to tune it but those give a generally consistent appearance but flickering is in the distracting category which you can't really get away from (once you see it).
Thanks for confirming and looking into this. I'm super sensitive to frame drops and brightness fluctuations, so yes, that's not something I can live with, but many people have more tolerance. That's the first thing I adressed with madVR when I recommissioned my HTPC, and hopefully both can be solved in JRVR as well.
Glad one of the examples I provided showed the issue with JRVR. Now we have at least two clips that cause brightness instability with JRVR, hopefully this will help the devs to fix.
-
ok yes I see what you mean, there's an example at approx 28:49 when they first walk in the bathroom.
Could you cut a short sample of that scene? Preferably as short as can be to reproduce, and long enough to see it of course.
-
Could you cut a short sample of that scene? Preferably as short as can be to reproduce, and long enough to see it of course.
I sent a link via email
-
Got it, thanks. Will look at it soon-ish, after I finish some other work.
-
I can also confirm this problem...I reported it back on September 10, 2023 with a much earlier build. Here is the quote:
The below observations have held true with builds 42 and 50, the only 2 versions I have tried:
I have a similar (or maybe the same...I haven't done enough testing yet) issue. I noticed very frequent and sudden brightness fluctuations in Love In Taipai, a few hundred over the course of the movie, and when I checked with MPC-HC's Info tool it was listed as "SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible". Since I am not technically educated enough to know whether or not it is the fault of the DTM, I have narrowed down the problem only to JRVR in general, as when I switch to Red October madVR the problem goes away. I planned on doing more testing before reporting this problem, but since this thread was already started I thought I would at least confirm that I have noticed the behavior, though I have not examined enough other content to reach any conclusions.
While I am here, I might as well report another problem I have noticed with JRVR:
When the APL is low AND has no bright elements in it, the graininess of the film increases and actually shimmers at times. Once there is a bright element in the frame, then the graininess and shimmering disappear and the picture once again looks solid. This is very noticeable on a 158" scope screen (167" 16:9), where people with smaller screens might not notice the effect. The "shimmering" can also give the appearance of movement or "crawl". This happens on any video, not just HDR10+ or even with HDR (1080p does the same thing), so I suspect the issue is with the VR in general, not the tone mapping. Again, more testing is necessary. And again, switching to MC's stock version of madVR fixes this problem as well.
I mistakenly thought it was an HDR10+ issue at that time. @Manni, thanks for bringing this issue to the surface and assuring me that I wasn't crazy... ;)
-
You can make the HDR peak detection settings much less aggressive if you're sensitive to this sort of thing. Possibly, the recent changes (aimed at combating the exact opposite problem) were too aggressive.
That being said, one thing I was wondering about was whether we should be using the N% histogram value instead of the average brightness.
-
You can make the HDR peak detection settings much less aggressive if you're sensitive to this sort of thing. Possibly, the recent changes (aimed at combating the exact opposite problem) were too aggressive.
That being said, one thing I was wondering about was whether we should be using the N% histogram value instead of the average brightness.
Hi Haasn,
Thanks for this suggestion. Which parameter are you suggesting to change in libplacebo, and in which way? As reported, changing the "Allowed delayed HDR Peak detection" in JRVR Advanced settings doesn't help, and obviously we don't want to lose HDR dynamic peak detection, which enables dynamic tonemapping. These are the only related options I can see in the JRVR interface.
I know this isn't your area, but it might be good to expose this parameter in the GUI so we can find the best compromise or adjust to taste if you've already made changes in the opposite direction. Brightness stability is a top priority for PQ, along with no frame drops, at least for me, because they are the most noticeable and distracting artifacts. Everything else (within reason!) comes second.
In the meantime, we can change the libplacebo parameters in JRVR of course, so please advise which change you have in mind.
-
I think it will be these ones
https://libplacebo.org/options/#hdr-peak-detection
Probably
scene_threshold_low and high in particular
I'll give it a try though I am slightly sceptical this will work for this sort of case and/or seems like something that would be easier to tune if one could record the levels seen by jrvr and then test different filter values offline (rather than via playback which is a slightly slow & laborious process)
-
I couldn't find any difference using those parameters on this scene so I still think it would need a change in the algorithm itself
-
I did some more testing of Jrvr Vs madvr and I would say jrvr is now noticeably flatter than latest madvr, not sure how else to put it, just greater depth/contrast in madvr I think
-
I did some more testing of Jrvr Vs madvr and I would say jrvr is now noticeably flatter than latest madvr, not sure how else to put it, just greater depth/contrast in madvr I think
Plus a lot more saturation with the latest improvements with StimHK lum method, gamut roll-off and ACES settings.
Personally, I'll need two things to start looking at JRVR again and try to help bridge that gap:
- brightness instability issue resolved (hopefully that won't take too long as Hendrick has confirmed he will be looking into this soon-ish).
- implementation of vertical shift according to black bars / A/R. I can't use a player/renderer that doesn't support this, preferably in real-time as madVR does, so that I can mask a single black bar at the bottom of my 16/9 projector screen. This has been on the MC to do list for a while now, but it looks like most of the work is happening on the audio side of JRiver at the moment, based on the changelog from the last builds, so I hope the video side will get some love again soon (I fully understand that users on the audio side need some attention too). I've worked with the developer of CMC to implement an automatic selection of a picture mode in the JVCs according to the A/R saved in the MyMovies database, it's fully functionmal and will be implemented in the next build early next year. This will allow support for titles not handled by JRVR black bar detection, such as DVDs. But it's a pain to do this for all titles, so really vertical lens shift is needed to be implemented in JRVR. Ideally, JRVR would provide the option to detect black bars in real-time. Yes, it's costly but it's no problem for a recent GPU and so much better than relying on metadata and a lengthy scanning process, especially when you have 3600+ titles and are not using the MC library at all (I only use MC as a player, the metadata is provided by MyMovies and the front-end by CMC on the HTPC and by the MyMovies app on iOS for my Oppo 203 clone and Dune Pro Vision 4K Solo player).
Until then, unfortunately JRVR isn't useable for me, so my motivation to spend time helping to improve it is minimal. It's made great progress in MC31 compared to what I tested a while ago in previous versions, but it still lags behind madVR, both from a tonemapping/PQ point of view at 100-150nits of peak brightness or less and from a functionality point of view (no vertical picture shift, no shortkeys to manually select profiles, no command line exec on profile selection) all things I use for automation with madVR in my projector setup. I can survive without some of these, but not without the two items listed above.
I'm sure JRVR is great for high nits displays, especially if you can use it in HDR passthrough, but it's not there (yet) for a projector setup.
This being said and to be fair, JRVR has less bugs (with an old driver in my case, as HDR passthrough support is broken in recent drivers with my 3090) and is better maintained than madVR, which is a big plus, but only if it's on a par re functionality and PQ.
Once the above two items are fixed/implemented, I'll come back and will be happy to try to help bridge the PQ gap by providing examples where JRVR is still lacking vs madVR.
-
no shortkeys to manually select profiles
Fwiw there are mcws commands to do this now so should be possible to handle this situation if using a programmable remote
-
Fwiw there are mcws commands to do this now so should be possible to handle this situation if using a programmable remote
Thanks, I've seen this and might dig into it when/if I find the time but it's still a lot more complicated than simply assigning a shortcut key and a commande line to each profile in the GUI, as is possible with madVR. That's in the WIBNI list though, not in the "can't live without" list :)
-
manni,
You've been a lot of help, but sometimes your posts come across as pushy -- more demands than requests. If you want to live in madVR land, please do it, and without giving us one last ultimatum.
I appreciate your technical expertise and eagerness for progress, but in the list above, Hendrik already gave you a work-around, and mattkahn just gave you another. That you don't get precisely what you expect is just life. Live with it.
Niklas and Hendrik have done something amazing and incredibly useful.
As we say, you're either on the bus, or you're not.
Jim
-
I don't think it's either/or in general, whichever is best overall is the one to use. Currently there are pros and cons to each but, just for HDR on a projector, madvr has definitely taken a marked step forward relative to jrvr in last month or two. It's normal thing really, one lib gets a burst of activity to push things forward and that raises the bar, hopefully jrvr responds in kind in the coming months :)
-
manni,
You've been a lot of help, but sometimes your posts come across as pushy -- more demands than requests. If you want to live in madVR land, please do it, and without giving us one last ultimatum.
I appreciate your technical expertise and eagerness for progress, but in the list above, Hendrik already gave you a work-around, and mattkahn just gave you another. That you don't get precisely what you expect is just life. Live with it.
Niklas and Hendrik have done something amazing and incredibly useful.
As we say, you're either on the bus, or you're not.
Jim
Jim, I didn't put any ultimatum, and I apologise if my post came accross as demands.
Please take all the time you need, or don't do anything, I'm not making any demands. I'm 100% on board with MC, and yes Hendrik and Niklas have done something amazing with JRVR, but this is a comparison thread, so I posted where I believe JRVR is still lacking compared to madVR and why I've (temporarily) paused using it.
I've accepted the old driver workaround as I have no choice, and as I said the solution offered by Mattkhan is about something that's not a big deal for me (shortkeys and command line for profiles). The two biggies are brightness stability and vertical picture shift. Without these, I can't use JRVR. It's as simple as that. Hendrik has already confirmed that he'll be looking into the brightness stability issue soonish (not sure which workaround you're talking about, I haven't seen any from him, Haasn didn't reply when I asked more details on which parameters to use in JRVR in order to fix the issue). Re the vertical shift, I understand that there is no ETA for scheduled features, but it's been a few months now and I have no guarantee that it will ever be implemented. So without an ETA, I'm off JRVR for now.
It's a purely personal position, and obviously not something relevant for anyone without a projector (and most likely a 16/9 screen). Given that it's likely a niche part of your audience, I could completely understand if it was to take years or even was never implemented, but then why should I invest time in a feature (JRVR) that I can't use, when one (madVR) already provides what's missing, and currently with significantly better PQ? It doesn't make sense for me and I hope you can understand this.
For me, brightness stability and vertical picture shift (preferably in real-time) are big deals.
You find me pushy, I find support often dismissive. Often, my feedback is dismissed until/unless one of the "regulars" confirms the issue. It's not very pleasant, even if I can understand. I guess we both have to live with this. :)
It takes a lot of time to contribute and look into a rendering solution in order to help improve it. I'm happy to do this if it's a renderer I can use. If it's not, I just can't afford the time. My hobby is not to spend time on renderers, my hobby (and my work, I work in film & TV) is to watch content in the best possible way. I hope you'll understand.
I explained why I can't use JRVR at the moment. I'm not demanding anything and I can definitely live without JRVR.
This being said, I'd love it if JRVR could fit my needs better, and I'll be happy to help and contribute if it does.
I don't think one has to choose the land they live in. Competition is always a good thing. I did push for madVR to improve it's saturation, and I did say at the time (publicly) that JRVR was superior in that aspect, so competition is always in the interest of the user. I strongly believe that there is room for both madVR and JRVR, they both have their pros and cons, and I refuse to be in one land or the other, even if I've paused using JRVR for now.
I still use JRiver MC with madVR, and I love MC (it's the only player I use, even if I do so with a different front end). I regularly recommend it, and if it's supported in CMC it's because I suggested it many years ago. Hopefully it's not because I'm (temporarily) off the JRVR wagon that you're going to throw me out of the MC train. :)
-
Don't worry, I'll definitely try to judge if something is a symptom of a general problem or a singular weird video.
-
Don't worry, I'll definitely try to judge if something is a symptom of a general problem or a singular weird video.
It's not a singular weird video, it's been confirmed with both Mad Max Fury Road (unless you're discarding my report) and MI6-Fallout (Mattkhan). I'll provide other clips if needed (I've given a list in my previous post, such as Lucy, The Meg, etc), but it's definitely not a one-off, even though it only happens in specific situations. These are the same clips I use to detect (and fix) brightness instability in madVR when present, so I know where to look to make it obvious, it doesn't mean it can't happen in any title.
-
You literally just said it's an unreasonable expectation (to look at individual scenes)
I wasn't explicit enough for you, apparently. We don't look at every scene reported. We don't have the movies. We don't have the equipment.
Of course we look at scenes.
Matt, it's probably a language problem.
-
Ok fair comment, I misunderstood
-
manni,
You've been a lot of help, but sometimes your posts come across as pushy -- more demands than requests. If you want to live in madVR land, please do it, and without giving us one last ultimatum.
I appreciate your technical expertise and eagerness for progress, but in the list above, Hendrik already gave you a work-around, and mattkahn just gave you another. That you don't get precisely what you expect is just life. Live with it.
Niklas and Hendrik have done something amazing and incredibly useful.
As we say, you're either on the bus, or you're not.
Jim
One observation and a suggestion.
Yes MadVR has made progress in the last month but if you guys think that is going to ever result in an HTPC version that isn't time limited and capture card blocked once they are done moving things to the Envy than you are incredibly naive. Everyone is being used as free testers for Envy development and gets to use the HTPC version temporarily while doing so but that will not last forever so those with the knowledge to help JRVR development should do that happily because there is a useable means to an end with JRVR.
There is a potential giant market out there if you guys are able to get JRVR working with the VideoProcessor program. Everything past MadVR 113 has either timed out or specifically blocks the VP program so dozens / hundreds of users are "stuck" at 113 and would probably jump onboard a program that has active development and is very arguably already better than MadVR 113. This might be better use of everyone's time right now rather than chasing edge case issues that few even notice at this point.
-
chasing edge case issues that few even notice at this point.
The difference between madvr and jrvr right now on a projector are not edge case issues. It's an obviously better picture overall (on top of some edge case issues to which people have varying sensitivity).
-
The difference between madvr and jrvr right now on a projector are not edge case issues. It's an obviously better picture overall (on top of some edge case issues to which people have varying sensitivity).
I have not tested the newest versions (way too many options) so I will trust what you say.
My point stands though, there is an untapped market out there for a high quality renderer that works with VP.
-
It doesn't need to work with VP, MC itself can use a capture card already, it just needs improvements to handle HDR. There was already mentioned on some other thread btw.
-
It doesn't need to work with VP, MC itself can use a capture card already, it just needs improvements to handle HDR. There was already mentioned on some other thread btw.
Great point. I did read the other thread but have not tried yet. Seems like a little tweaking can make it pretty seamless. How cool would it be to be able to browse our stored libraries and then seamlessly switch to capture card if we want to watch streaming or physical media.....
-
Going OT a bit but I think MC needs a known compatibility list of capture cards and/or improvements to how it interacts with them. I still use mpc-be rather than MC for this purpose because MC has had problems with cards I have used whereas mpc-be just worked.
-
I have completed the tests over at AVS Forums regarding brightness stability tests comparing madVR, JRVR and as a control renderer MPC-VR, which I believe is static and fixed at 125nits.
In the last run, I've tested both renderers against the JVC DTM (fw 3.0, HDR frame adapt, frame by frame DTM) because I suspect MPC-VR to be static and not dynamic, so it didn't feel like a fair comparison. I got the same results: the JVC DTM passes all the brightness stability tests that are failed by madVR, JRVR or both renderers.
As you'll see, I've used two different sets of settings:
In post #1 https://www.avsforum.com/threads/brightness-stability-issue-with-projectors-or-low-nits-displays-when-using-dtm-with-jrvr-and-madvr-no-support-questions.3290169/#post-63007530, optimised settings at 108nits DPL and test results. As you'll see, with these settings, madVR passes most of the brightness stability test. When it fails, it can be resolved if it's unstability by disabling DTN (Jumanji) or by raising detail threshold to 10 (Dune), but that's not a fix, it only resolves the clipping, any detail above 1 will cause brightness instability in other clips. JRVR is the worst performing and I couldn't find any fix. The JVC DTM passes all the tests.
In post #2 https://www.avsforum.com/threads/brightness-stability-issue-with-projectors-or-low-nits-displays-when-using-dtm-with-jrvr-and-madvr-no-support-questions.3290169/#post-63007547, worst-case settings at 50nits DPL and test results. With these, many new clips fail with madVR, and the fix is simply to use better settings (optimised ones). With JRVR, the results are the same re number of passes or fails. The JVC DTM passes all the tests.
I attach the results for both sets of settings, please read the linked posts for more information.
If any users or the devs would like to reproduce these issues, you can download all the clips causing brightness stability issues with JRVR in the first post. I would suggest you focus first on the first clips, which are the most offensive/obvious ones from a brightness stability point of view: Mad Max Fury Road (all of Chapter 3), MI6 - Fallout (the whole of the bathroom scene), Jumanji 2019 (two visible issues in one clip, depending on settings).
Madshi has got all the information and is likely to get working on this in the next couple of weeks, so hopefully many if not most of the issues will be fixed in madVR soon.
I hope that you guys can reproduce and improve these results with JRVR as well.
As soon as a developer has made progress with either renderer, I'll re-test with the improved build and will produce updated test results.
-
Which renderer JRVR or MADVR provides better HW efficiency? I mean which provides acceptable HDR to SDR tonemapping ( and color conversion ), downscaling 4K to FHD, but with lower GPU requirements.
- 4k HDR source ( some with single layer DV), mostly 23/24p
- 1080p SDR REC.709 target display
- Notebook level of CPU with integrated GPU ( in my case its Intel HD620 and dedicated Nvidia MX150 )
- rather low quality settings
Tried MPC-HC with madvr and even with the option trade Q for perf option "compromises to tone mapping", the upload and rendering queues dropped to 1-2 frames, which resulted in occasional video stutter. Not mentioning the NB went really hot. Will try JRiver with JRVR later on. What are your experiences in terms of renderer efficiency for such very "basic" scenario?
Thanks
-
acceptable is too subjective to be able to comment imv
madvr can use significantly more GPU than jrvr but, when both are configured reasonably, I find they produce a comparable load on the GPU. Other posters have said they can achieve better results with jrvr with lower powered hardware than they have been able to achieve with madvr though so my guess is jrvr will work for you.
-
Note that JRVR (and probably also madVR) mainly targets discrete GPUs, and a lot of the shaders may not be particularly optimized for integrated or mobile GPUs. While there is a bunch of low-hanging fruit that we could pursue to try and optimize JRVR more for this use case, it's never been a priority since most users of heavy shaders will be on some sort of discrete graphics PC.
Generally, though, JRVR receives more optimization than madVR (just my personal impression from others' comments in the past), in particular scaling and DTM.
-
I have setup a new thread for MC32 to continue the discussion over here: https://yabb.jriver.com/interact/index.php/topic,138341.0.html
and I'm in the process of analyzing the brightness samples above to see how to improve the peak detection.
-
I have setup a new thread for MC32 to continue the discussion over here: https://yabb.jriver.com/interact/index.php/topic,138341.0.html
and I'm in the processing of analyzing the brightness samples above to see how to improve the peak detection.
That's great, thanks, lookking forward to discussing in new thread.