Print

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

[Paul Coddington]

Just started playing with JRVR since installing 29.

BACKGROUND:

Currently, with madVR, I have it scripted to automatically assume full range BT.709 or tone mapped HDR BT.2020 for 300 nits peak (monitor max level) to simplify mode selection hassles (under this arrangement, I only have to manually flick the monitor between BT.709 and BT.2020 modes from the taskbar, and I have the BT.2020 mode set brighter at 300 nits for this purpose).

This gives me better, more consistent results than HDR passthrough, as movie average and peak brightness levels are all over the place in practice and the 300 nit HDR mode native to the monitor displays precise levels clipped, not rolled off (while the 500 nit and higher emulation modes are rolled off, they do not preserve the levels of dark scenes and do not work well for content that averages 300 nits).

The main frustration with madVR is that is a bit glitchy with film grain: it tends to exaggerate film grain really badly to the point of being almost unwatchable when downscaling 4K to 1440p unless some combination of unwanted pre- and post-filters are applied (in a way that is not immediately obvious, but recently discovered by accident). It's like the downscaling stacks the grain up together to increase its contrast rather than averages it out and scales it down with the rest of the picture. This happens with all selectable downscaling modes, oddly enough.

OBSERVATIONS:

1. JRVR is a remarkably pleasing picture. When downscaling 4K to 1440p it is a little softer focus than madVR but quite watchable with no grain issues.

2. The main problem with JRVR for me is catering for mode switching between SDR and HDR content. Although the options dialog says it is better to use an ICC profile than set the gamma, in the current version JRVR seems to ignore the monitor ICC profile altogether.

So, when the monitor mode is changed, JRVR options have to be changed as well. When viewing SDR content, JRVR must be manually set to BT.709 G2.4, and when viewing HDR content it must be manually set to BT.2020 G2.4. There is no possibility of mapping SDR and HDR to the same monitor profile due to the 200nit difference in brightness.

It would be much more convenient if it used the current monitor ICC profile to do this automatically, because switching the monitor mode from the taskbar app already changes the ICC profile for Windows automatically.

3. A mystery I have not yet solved is a significant difference in colour between madVR and JRVR.

When watching HDR content, with both madVR and JRVR set to identical settings (tone map to BT.2020 G2.4 at 300 nits peak using BT.2390 and measured peak compensation) JRVR output is more saturated (or perhaps wider).

It is not clear which is correct or why they are different. Odd scenes in JRVR look a little off and unnatural (slightly over saturated on some objects in some scenes but not all), yet grass and trees look much better than with madVR (although this would still be true if it were incorrect: I can make trees and grass look more lush and true to life by wrongly displaying an sRGB photo in BT.2020 mode).

The amount of difference in the colour might be equivalent to sending unmapped DCI to a BT.2020 display with a native gamut that is slightly wider than DCI+AdobeRGB, or perhaps pushing 16–235 without conversion to 0–255. So, I'll be playing about with settings to see if tweaking these will trick the renderers into matching each other so I can figure out what the problem might be.

Or it might be that madVR is desaturating gamut rather than clipping, although with BT.2020 content on a BT.2020 monitor this should have no effect at all as there will be no colours outside BT.2020 to clip or remap.

Or could it be DolbyVision enhancements coming into play, with perhaps JRVR supporting them and madVR not(?).

In all this, have not had time to play with SDR HD and SD videos, so I am not sure how JRVR is doing with those. HDR tone mapping has occupied my time.

[mike0zero]

Just started playing with JRVR since installing 29.

BACKGROUND:

Currently, with madVR, I have it scripted to automatically assume full range BT.709 or tone mapped HDR BT.2020 for 300 nits peak (monitor max level) to simplify mode selection hassles (under this arrangement, I only have to manually flick the monitor between BT.709 and BT.2020 modes from the taskbar, and I have the BT.2020 mode set brighter at 300 nits for this purpose).

This gives me better, more consistent results than HDR passthrough, as movie average and peak brightness levels are all over the place in practice and the 300 nit HDR mode native to the monitor displays precise levels clipped, not rolled off (while the 500 nit and higher emulation modes are rolled off, they do not preserve the levels of dark scenes and do not work well for content that averages 300 nits).

The main frustration with madVR is that is a bit glitchy with film grain: it tends to exaggerate film grain really badly to the point of being almost unwatchable when downscaling 4K to 1440p unless some combination of unwanted pre- and post-filters are applied (in a way that is not immediately obvious, but recently discovered by accident). It's like the downscaling stacks the grain up together to increase its contrast rather than averages it out and scales it down with the rest of the picture. This happens with all selectable downscaling modes, oddly enough.

OBSERVATIONS:

1. JRVR is a remarkably pleasing picture. When downscaling 4K to 1440p it is a little softer focus than madVR but quite watchable with no grain issues.

2. The main problem with JRVR for me is catering for mode switching between SDR and HDR content. Although the options dialog says it is better to use an ICC profile than set the gamma, in the current version JRVR seems to ignore the monitor ICC profile altogether.

So, when the monitor mode is changed, JRVR options have to be changed as well. When viewing SDR content, JRVR must be manually set to BT.709 G2.4, and when viewing HDR content it must be manually set to BT.2020 G2.4. There is no possibility of mapping SDR and HDR to the same monitor profile due to the 200nit difference in brightness.

It would be much more convenient if it used the current monitor ICC profile to do this automatically, because switching the monitor mode from the taskbar app already changes the ICC profile for Windows automatically.

3. A mystery I have not yet solved is a significant difference in colour between madVR and JRVR.

When watching HDR content, with both madVR and JRVR set to identical settings (tone map to BT.2020 G2.4 at 300 nits peak using BT.2390 and measured peak compensation) JRVR output is more saturated (or perhaps wider).

It is not clear which is correct or why they are different. Odd scenes in JRVR look a little off and unnatural (slightly over saturated on some objects in some scenes but not all), yet grass and trees look much better than with madVR (although this would still be true if it were incorrect: I can make trees and grass look more lush and true to life by wrongly displaying an sRGB photo in BT.2020 mode).

The amount of difference in the colour might be equivalent to sending unmapped DCI to a BT.2020 display with a native gamut that is slightly wider than DCI+AdobeRGB, or perhaps pushing 16–235 without conversion to 0–255. So, I'll be playing about with settings to see if tweaking these will trick the renderers into matching each other so I can figure out what the problem might be.

Or it might be that madVR is desaturating gamut rather than clipping, although with BT.2020 content on a BT.2020 monitor this should have no effect at all as there will be no colours outside BT.2020 to clip or remap.

Or could it be DolbyVision enhancements coming into play, with perhaps JRVR supporting them and madVR not(?).

In all this, have not had time to play with SDR HD and SD videos, so I am not sure how JRVR is doing with those. HDR tone mapping has occupied my time.

I have found the same issue with colour saturation.

Two images, left is MadVR tone mapped, right is JRVR tone mapped, as you can see the colours are very different with the JRVR version looking more saturated.

Not quite the same frame but you get the idea.

[mike0zero]

I have found the same issue with colour saturation.

Two images, BR2049 left is MadVR tone mapped, right is JRVR tone mapped, as you can see the colours are very different with the JRVR version looking more saturated, same goes for Ford vs Ferrari.

Not quite the same frames but you get the idea.

[SamuriHL]

Those screenshots look like what's being output is in the wrong color space.  I.E. what you'd get if you try to take a rec.709 video and play it in bt.2020.

[mike0zero]

Those screenshots look like what's being output is in the wrong color space.  I.E. what you'd get if you try to take a rec.709 video and play it in bt.2020.

Thanks for feedback I will take a look at your suggestion and report back.

[SamuriHL]

To be clear I'm not suggesting that's necessarily what's actually happening simply stating that's what it looks like from the screenshots.  When you try to force rec.709 content into a bt.2020 signal the display will oversaturate the reds which is what those look like.

[Hendrik]

When viewing SDR content, JRVR must be manually set to BT.709 G2.4, and when viewing HDR content it must be manually set to BT.2020 G2.4.

The above observations in combination with this statement has me rather suspicious that they are right. If you change the settings in JRVR without also changing the settings in your screen, of course one of those is going to look wrong.
Your screen can only be setup to expect either BT.709 or BT.2020, if its for example BT.709 and you then set JRVR to output BT.2020 its going to be wrong.

The Target Gamut in JRVR should be set to one setting independent of content - only dependent on what your screen is setup to actually receive. The entire Output section relates to your screen, not the content you are playing.
Of course if you are actually changing a setting in your screen to receive different signals for every video, this wouldn't apply, but noone would have the patience to do that, because screen configuration menus are usually extremely tedious to control. (PS: There was something about a tray icon, that sounds like more changing the ICC profile, not the actual screen settings)

One potential explanation would be if you used the setting in madVR to set your screen to BT.2020 mode, this is not an option available in JRVR currently because there is no vendor-independent way to do that, and we're not quite there yet to bother with eg. an NVIDIA-only option, etc.

[arcspin]

I too have seen this.
I have my projector, JVC X5500, pro-calibarated to REC.709 and need advice how to set JRVR HDR tonemapping to?
BT-2446a, BT2390, Hable?

None of the suggestions seems to render a balanced picture without overstaurated colors and crushed blacks.


In madVR I can setup the display calibration to REC.709.

[Hendrik]

Out of interest, I also dug up Blade Runner 2049 and found one of the scenes in question, and under identical properties, the images look pretty similar. The tonemapping is not identical, naturally, JRVR is slightly brighter, but the colors seem quite the same shade otherwise.

This is tonemapping to SDR BT.709, with otherwise pretty much default settings (not tuned tonemapping at all, was only interested in the colors).

I can only conclude that some kind of setting difference results in your over-saturation. As SamuriHL pointed out, expecting eg. BT.2020 and actually delivering BT.709 would result in oversaturation, for example.
Also note that JRVR does not currently allow limited range RGB output. If your screen does not properly support full range, you need to set your graphics card to limited range, as JRVR will always produce full range (as thats what D3D is designed to receive, by definition)

Just to confirm, I also did a second test, tonemapping to SDR BT.2020 - which this display I'm on does not support, since its a PC monitor, but regardless the image of madVR and JRVR looked to have the same (wrong) colors, with no major differences (not uploaded pictures of that)

[mike0zero]

Out of interest, I also dug up Blade Runner 2049 and found one of the scenes in question, and under identical properties, the images look pretty similar. The tonemapping is not identical, naturally, JRVR is slightly brighter, but the colors seem quite the same shade otherwise.

This is tonemapping to SDR BT.709, with otherwise pretty much default settings (not tuned tonemapping at all, was only interested in the colors).

I can only conclude that some kind of setting difference results in your over-saturation. As SamuriHL pointed out, expecting eg. BT.2020 and actually delivering BT.709 would result in oversaturation, for example.
Also note that JRVR does not currently allow limited range RGB output. If your screen does not properly support full range, you need to set your graphics card to limited range, as JRVR will always produce full range (as thats what D3D is designed to receive, by definition)
Just to confirm, I also did a second test, tonemapping to SDR BT.2020 - which this display I'm on does not support, since its a PC monitor, but regardless the image of madVR and JRVR looked to have the same (wrong) colors, with no major differences (not uploaded pictures of that)

Hendrik

Thanks for your feedback, I also think that my iPhone camera makes my images look much brighter than they actually are, plus it emphasises the brighter highlights.

I think I have it set up incorrectly, I will re test according to your settings, thanks for providing these.

[Paul Coddington]

The above observations in combination with this statement has me rather suspicious that they are right. If you change the settings in JRVR without also changing the settings in your screen, of course one of those is going to look wrong.

Your screen can only be setup to expect either BT.709 or BT.2020, if its for example BT.709 and you then set JRVR to output BT.2020 its going to be wrong.

The Target Gamut in JRVR should be set to one setting independent of content - only dependent on what your screen is setup to actually receive. The entire Output section relates to your screen, not the content you are playing.

Of course if you are actually changing a setting in your screen to receive different signals for every video, this wouldn't apply, but noone would have the patience to do that, because screen configuration menus are usually extremely tedious to control. (PS: There was something about a tray icon, that sounds like more changing the ICC profile, not the actual screen settings)

One potential explanation would be if you used the setting in madVR to set your screen to BT.2020 mode, this is not an option available in JRVR currently because there is no vendor-independent way to do that, and we're not quite there yet to bother with eg. an NVIDIA-only option, etc.

This is not what is happening, as far as I can tell.

But I have come down unwell shortly after posting, I'm tired and may have been mistaken and got a setting wrong while testing, so I'll recheck in a day or so after I have rested a bit.

To clarify my earlier post, I usually use the monitor in BT.709 mode at 100 nits for SDR BT.709 content and in BT.2020 mode at 300nits for HDR content. madVR can automatically select output profile according to content metadata, and I can easily switch the active monitor mode from the monitor's taskbar menu app with the mouse and expect the correct ICC profile to be swapped into place. It is the most seamless option that I have found so far.

The reason for doing it this way is to not shorten the lifespan of the monitor by running it at 300nits unnecessarily and improve black levels a notch for SDR content by running at 100 nits, offload as much colour management to the monitor itself (the internal LUTs it generates when calibrated are high quality).

It is not uncommon for some users to switch modes on demand: sRGB is needed for web and everyday office work and programming, but if I am working with or watching video I will need the monitor to be either BT.709, BT.2020 or HDR passthrough depending on content and context (casual viewing vs. editing/grading). Likewise, if I am editing photos, other modes come into play depending on context (website, printer, or archival restoration). So, mode switching for me is frequent and typical, so may as well do it for SDR vs. HDR content for best possible quality.

Monitors designed for photographers, graphic designers, video editing and grading professionals, movie studio special effects artists, etc, have software-based menus in the taskbar to select a range of calibrated modes for different tasks and contexts at the click of a mouse.

But, the JRVR options dialog has two problems: it does not seem to use the active monitor ICC profile registered with Windows, as set by the monitor, and manual settings are not designed for easy access for monitors that change calibration modes for different tasks.

JRiver Media Center is a PC app with a focus on home theatre, but there are those of us who live bedsitter style using our PCs as a "home theatre" after hours with headphones, because there is no budget or space for a TV (screen size is relative to seating distance for an audience of one in a dark room). Plus, I use JRiver with madVR as sanity check when I need to edit video.

That was a bit of a ramble, but I think it is important to keep a broad range of use cases in mind. PCs are used for much more than dedicated home theatre devices hooked up to domestic TV sets.

But, I am seeing exactly the problem that others have demonstrated in the screenshots above, when JRVR and madVR are both set to output tone mapped HDR as BT.2020 G2.4 to a colorimeter calibrated BT.2020 G2.4 monitor.

As an aside, it just occurred to me I should also check whether JRVR is failing to pickup the monitor ICC profile because it is ICC v4 and not all applications have caught up to that yet.

[Paul Coddington]

To be clear I'm not suggesting that's necessarily what's actually happening simply stating that's what it looks like from the screenshots.  When you try to force rec.709 content into a bt.2020 signal the display will oversaturate the reds which is what those look like.

Yes. I read somewhere ages ago that some Blu ray titles are DCI internally, and I was wondering aloud if that might be the problem in the original post (that remapping did not take that into account, presuming it is true in the first place).

But this would also happen if JRVR was outputting BT.709 when setup to output BT.2020 due to a bug or incomplete feature (which might not manifest in all use cases).

[Paul Coddington]

I have found the same issue with colour saturation.

Two images, left is MadVR tone mapped, right is JRVR tone mapped, as you can see the colours are very different with the JRVR version looking more saturated.

Not quite the same frame but you get the idea.

Yep, that's what I am seeing when both madVR and JRVR are setup to output tone mapped HDR as SDR BT.2020 on a BT.2020 monitor. My test Blu-ray was Wonder Woman 1984.

[Paul Coddington]

Out of interest, I also dug up Blade Runner 2049 and found one of the scenes in question, and under identical properties, the images look pretty similar. The tonemapping is not identical, naturally, JRVR is slightly brighter, but the colors seem quite the same shade otherwise.

This is tonemapping to SDR BT.709, with otherwise pretty much default settings (not tuned tonemapping at all, was only interested in the colors).

I can only conclude that some kind of setting difference results in your over-saturation. As SamuriHL pointed out, expecting eg. BT.2020 and actually delivering BT.709 would result in oversaturation, for example.
Also note that JRVR does not currently allow limited range RGB output. If your screen does not properly support full range, you need to set your graphics card to limited range, as JRVR will always produce full range (as thats what D3D is designed to receive, by definition)

Just to confirm, I also did a second test, tonemapping to SDR BT.2020 - which this display I'm on does not support, since its a PC monitor, but regardless the image of madVR and JRVR looked to have the same (wrong) colors, with no major differences (not uploaded pictures of that)

I encountered the problem tone mapping to BT.2020, and my PC monitor has a BT.2020 mode (which will clip to native gamut in practice, which is the superset of Adobe RGB plus DCI-P3 in effect, significantly wider than BT.709).

I might check later to see if the difference would be easily visible on a narrow gamut monitor when I go back to re-check my settings and re-test.

[jmone]

Yes. I read somewhere ages ago that some Blu ray titles are DCI internally....

HDR UHD Blu Ray typically uses BT.2020 colour space, and most (though not all) limit the Gamut within this colour space to P3-D65 (DCI-P3 with a D65 white point).

SD Blu Ray typically uses BT.709

[jmone]

...and it seems to be evenly split between mastering to either 1,000 and 4,000 cd/m2 for HDR UHD BD (though a few discs also have some "clips" that seem to be mastered to 10,000).

[Hendrik]

As an aside, it just occurred to me I should also check whether JRVR is failing to pickup the monitor ICC profile because it is ICC v4 and not all applications have caught up to that yet.

JRVR does not use ICC profiles at all yet (its going to be added as one of the next features). If you do big corrections that would result in such differences, then that might be it. Although I don't think madVR supports ICC profiles either (unless thats a new addition in the beta versions), but I guess you made a 3DLUT of them to feed to madVR?

I'm not seeing any fundamental color differences here no matter what target I tonemap to, without involving an ICC.

[lello]

JRVR does not use ICC profiles at all yet (its going to be added as one of the next features).

Will it be possible to add an ICC profile, or even create it with JRVR?

[Paul Coddington]

JRVR does not use ICC profiles at all yet (its going to be added as one of the next features). If you do big corrections that would result in such differences, then that might be it. Although I don't think madVR supports ICC profiles either (unless thats a new addition in the beta versions), but I guess you made a 3DLUT of them to feed to madVR?

I'm not seeing any fundamental color differences here no matter what target I tonemap to, without involving an ICC.

Sorry I'm late back, but I finally have some extra observations. I'll number the paragraphs for easy reference.

1. My monitor is hardware calibrated, the ICC profiles it creates appear to be equal to generic standards (effectively passthrough to the monitor internal LUT), except for Native mode, so I can just script madVR to output generic built-in standards for BT.2020, BT.2100, BT.709 according to content and flick the monitor mode to match. I had to create a LUT for madVR to display correctly when the monitor is in sRGB, as there is no built-in option for that.

2. Now that JRiver has an ICC option, it appears that the current ICC profile is indeed being used. No matter which monitor mode I choose the output looks about the same within expected differences in brightness and gamut, provided I restart JRiver after switching modes. This is ideal behaviour, an advantage over madVR.

3. However, it still looks oddly over saturated compared to madVR, regardless of gamut clipping options. So, a glowing red light in JRiver is a much deeper red than in madVR. Which looks attractive until you realise Tom Hanks sitting in a lawn chair at night in Apollo 13 has a red shirt that is not dull deep red like a shirt in the dark would be as portrayed in madVR but almost glowing deep red brighter than other objects in the scene almost like a dull light source. I am not seeing any anomalies with general photo editor usage using the same ICC profiles, so I don't think they are broken.

4. A potential problem is that JRiver engine Ctrl-J always reports that tone mapped HDR is being output as BT.709 regardless of content, output and gamut mapping selections. So, even when the monitor is BT.2020, as prescribed by the ICC profile in use, JRiver reports it is outputting tone mapped SDR as BT.709. I am not sure if this is a conversion error (wide-gamut SDR is a desirable option that at least preserves one of the major benefits of HDR encoding) or a logging error (eg: variable in logging not being updated and containing the wrong value). It might imply that an unnecessary conversion from BT.2020 to BT.709 is in the pipeline even though the selected output is BT.2020 which may well clip and oversaturate some colours.

5. In all cases, madVR tone mapping HDR to SDR looks closer in appearance to direct HDR passthrough in PQ mode, provided you disable the brightness tweak (by placing a named empty file in the madVR) to aim for pure BT.2390, especially if you disable dynamic peak measurement. So, if HDR tone mapping in JRiver is more saturated than HDR passthrough to a PQ monitor, something feels a bit off. JRiver BT.2390 is also higher contrast and more "pop" than madVR, where BT.2466 is slightly lower shadow contrast than madVR (I can't find any information on which standard is considered better or for what context, so this setting is hard to choose objectively, but I can see the third option is popular with gamers though).

6. There appears to be another tone-mapping problem with HDR in that the JRiver engine peak nits setting is not behaving as expected. If someone is tone mapping to view in the dark at lower brightness (say, because their IPS monitor has poor black levels and they want to sacrifice some "pop" for deeper blacks), they may want to set peak nits to match their SDR monitor running at 100-200 nits backlight. madVR allows you to do this and the HDR highlights roll off smoothly, even with no options enabled to recover explosions and highlights. With JRiver engine, any setting below 203nits clips highlights badly. So in Star Wars III, the opening battle scene pans down from the scrolling text looking directly into the sun: madVR reproduces the sun as a bright natural featureless glow at all peak nit settings, but JRiver depicts the sun as a jiggling cluster of pure white overlapping rectangles at peak nit settings below 203 nits.

7. Part of the problem faced is when two products potentially use potentially different methods to achieve the same goal with limited information available, it is hard to know which one is more accurate. Perhaps one clips gamut and the other does a perceptual shift, but how to tell? Even so, as mentioned before, madVR tone mapping seems perceptually closer to PQ HDR passthrough and JRiver is not just higher contrast and more saturated, but there are sometimes also scenes where it feels like the colours don't quite match with each other into a coherent whole (usually darker scenes). Yet, the extra apparent contrast is quite pleasing and sometimes madVR looks a bit weak in contrast for darker scenes.

8. On the list of suggestions, it would be cool if one day JRiver engine could have an option to set the monitor to match the frame rate of the source. It seems to currently convert everything to the current desktop refresh rate. That option seems to improve clarity in madVR (ability to see very fine detail like pores in skin, individual hairs, etc). Also it is really handy that madVR can pass HDR directly through to the monitor without the Windows HDR desktop being turned on (HDR Desktop causes unacceptable problems, such as SDR content not being displayed correctly with proper colour management, more stress on monitor back light for extra brightness never used for the bulk of normal desktop tasks, less deep blacks). Early days yet, more will come I'm sure.

[Hendrik]

I'm skipping the tonemapping quality points for now, as its a complex topic, and its mostly not my math, but part of the rendering library we use. I'll gather more information on that.

3. However, it still looks oddly over saturated compared to madVR, regardless of gamut clipping options. So, a glowing red light in JRiver is a much deeper red than in madVR. Which looks attractive until you realise Tom Hanks sitting in a lawn chair at night in Apollo 13 has a red shirt that is not dull deep red like a shirt in the dark would be as portrayed in madVR but almost glowing deep red brighter than other objects in the scene almost like a dull light source. I am not seeing any anomalies with general photo editor usage using the same ICC profiles, so I don't think they are broken.

4. A potential problem is that JRiver engine Ctrl-J always reports that tone mapped HDR is being output as BT.709 regardless of content, output and gamut mapping selections. So, even when the monitor is BT.2020, as prescribed by the ICC profile in use, JRiver reports it is outputting tone mapped SDR as BT.709. I am not sure if this is a conversion error (wide-gamut SDR is a desirable option that at least preserves one of the major benefits of HDR encoding) or a logging error (eg: variable in logging not being updated and containing the wrong value). It might imply that an unnecessary conversion from BT.2020 to BT.709 is in the pipeline even though the selected output is BT.2020 which may well clip and oversaturate some colours.

The OSD is probably just wrong. The ICC profile should override any target color decisions, it just doesn't communicate it back for the OSD to properly reflect it. I'm not sure why you are seeing some oversaturation though.
You could maybe compare using your ICC profile vs. setting the desired plain target color gamut (in JRVR Settings -> Output, disable ICC profiles there as well) like you did with madVR? If those look the same, then at least we know its not ICC causing any issues, but maybe to look somewhere else (or we know it is ICC, useful information either way)

It might be useful to also test with wide-gamut SDR content as the source if you have any, to take the tonemapping out of the process.

Just to be clear, even on a monitor that expects BT.2020 colors, you are seeing oversaturation? Ideally it should not touch the colors at all in such a situation, but just tonemap the brightness - of course that can impact colors to a degree.

8. On the list of suggestions, it would be cool if one day JRiver engine could have an option to set the monitor to match the frame rate of the source. It seems to currently convert everything to the current desktop refresh rate. That option seems to improve clarity in madVR (ability to see very fine detail like pores in skin, individual hairs, etc). Also it is really handy that madVR can pass HDR directly through to the monitor without the Windows HDR desktop being turned on (HDR Desktop causes unacceptable problems, such as SDR content not being displayed correctly with proper colour management, more stress on monitor back light for extra brightness never used for the bulk of normal desktop tasks, less deep blacks). Early days yet, more will come I'm sure.

Both of these are actually possible already.
For frame rate, go to MC Settings -> Video -> Display Settings, and set "Display Setting automatic change mode", "On" will automatically try to detect right modes, and Custom lets you manually specify which modes to use.

For HDR, JRVR can turn Desktop HDR on and off again as you play HDR content. Just leave it off, and in JRVR Settings, Output, enable "Automatically switch to HDR mode when starting playback"
Yes, this turns on the standard desktop HDR, but only while you are playing a HDR movie, and turns it back off after.


PS:
There have been some changes to how ICC profiles are handled just in 29.0.62, and I wonder if this can impact both 3&4 as well as interactions with tone-mapping. Which version did you test on?

6. There appears to be another tone-mapping problem with HDR in that the JRiver engine peak nits setting is not behaving as expected. If someone is tone mapping to view in the dark at lower brightness (say, because their IPS monitor has poor black levels and they want to sacrifice some "pop" for deeper blacks), they may want to set peak nits to match their SDR monitor running at 100-200 nits backlight. madVR allows you to do this and the HDR highlights roll off smoothly, even with no options enabled to recover explosions and highlights. With JRiver engine, any setting below 203nits clips highlights badly. So in Star Wars III, the opening battle scene pans down from the scrolling text looking directly into the sun: madVR reproduces the sun as a bright natural featureless glow at all peak nit settings, but JRiver depicts the sun as a jiggling cluster of pure white overlapping rectangles at peak nit settings below 203 nits.

Are you using an ICC profile in this scenario? I think using an ICC profile can actually override the target nits right now, as it gets the display brightness from the ICC profile (if present). Although that would mean you would not see a difference, so I assume you are not - or are using a version before .62, as that behaved differently.

I think I have that particular disc though so I'll give it a look. In my testing most things looked pretty decent - of course you lose detail in bright highlights, but it should not degrade badly.

[Hendrik]

I think I have that particular disc though so I'll give it a look. In my testing most things looked pretty decent - of course you lose detail in bright highlights, but it should not degrade badly.

I tried to reproduce this, but it seems fine over here.

Due to the size of the images I've only attached them as an album here:
https://imgur.com/a/08KBB8a

Down to 100 nits everything looks pretty normal to me, below 100 nits you start compressing the "SDR" image data, which greatly impacts the image.

The image looks pretty grainy to me, i'm not sure if thats the source or my copy of it - which should be a direct disc rip, as thats how i store all my discs.

This is with everything in standard mode, tone map mode: auto, and gamut: clip