Print

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

[lello]

Its not meant to be per zone currently.

Then maybe this is why madvr no longer works for me.
I have created a new zone for JRVR, which I activate manually after disabling the switch so when I switch to the zone with madvr, obviously something remains of the zone with JRVR.

(but maybe, as an ignoramus, I'm talking nonsense)

[Hendrik]

Only the JRVR settings are not per-zone, selecting between madVR and JRVR should not be impacted from that.

I routinely switch between all three options for testing, and have not noticed any issues.

[Manfred]

The new release solved the problem:

In Costa Rica 4k 29,97 FPS in the intro JRVR has some micro stuttering compared to madVR where the camera move in the beginning is super smooth. On my desktop monitor the 29,97 are up scaled to 60 FPS.

I have switched my Workstation & Media Renderer in the Living Room now to JRVR. So far no issues. Quality is on par or even better than madVR. In Alien 1 there is less noise compared to madVR (GTX 1070). In my music concerts movement of artists is great - no latency issues.

If using Jinc for up-scaling 29i ripped blu-ray's JRVR requires also some beefy GPU but much less utilization than madVR.

Great work!

[JimH]

Split terrym's Problem with Bad Files

[tij]

In Alien 1 there is less noise compared to madVR (GTX 1070)

Is it UHD version of Alien? ... Which JRVR you using - Hable or BT? ... By noise - you mean film grain?

[Manfred]

Is it UHD version of Alien? ... Which JRVR you using - Hable or BT? ... By noise - you mean film grain?

It's BD Version. No - In the scene at 58:00 it's really noise in the movie.

[tij]

It's BD Version. No - In the scene at 58:00 it's really noise in the movie.

Is it Director's cut or Theatrical?

I need to dig through my boxes for BD version as I have replaced it with UHD version on NAS.

If its excessive film grain that was present in original disc ... and video renderer removed it without user telling it so ... i would be a bit worried 

PS. MadVR also have noise reduction option ... but from what i recall its quite expensive operation

[lello]

Screenshot comparison would be good ... to know exactly what you mean

In some case "film grain" is part of film "character" ... EDIT: and noise reduction (whether intentional or biproduct of other processing) can "flatten" out the image

I fixed madvr so I was able to take a couple of comparison screenshots.
The movie is Joker in which undoubtedly the director wanted a bit of video grain on purpose. With madvr the image seems more detailed but with more video noise, with jrvr less detailed but with equally less video noise.

[img width= height= alt=madvr" border="0]https://i.ibb.co/G07f2Rv/madvr.png[/img]

[img width= height= alt=jrvr" border="0]https://i.ibb.co/s95PSfG/jrvr.png[/img]

[tij]

I fixed madvr so I was able to take a couple of comparison screenshots.
The movie is Joker in which undoubtedly the director wanted a bit of video grain on purpose. With madvr the image seems more detailed but with more video noise, with jrvr less detailed but with equally less video noise.

[img width= height= alt=madvr" border="0]https://i.ibb.co/G07f2Rv/madvr.png[/img]

[img width= height= alt=jrvr" border="0]https://i.ibb.co/s95PSfG/jrvr.png[/img]

I assume this is HD source too ... upscaling to 4K

I also assume you using NGU fot MadVR. That scaler is sharp. And imho is one step ahead of Jinc (thank god, Hendrick is working on alternative).

JRVR atm uses Jinc ... which by itself is an excelent scaler ... but produces softer results ... film grain gets soften out too ... which kinda looks like DNR producing "cleaner"  but softer/"blurrier" image.

Its possible with MadVR to use NGU then set in postprocessing to reduce noise ... results are excelent (albeit not too my liking ... as i prefer film grain), but needs powerful GPU as i recall noise reduction is quite costly computationally in MadVR

[lello]

Sorry if I haven't provided more details. The file is not an upscaled HD, but a 4K. Also on madvr I use Jinc because for my Rx580 NGU it is too much in case of 4k HDR sources.

[tij]

Sorry if I haven't provided more details. The file is not an upscaled HD, but a 4K. Also on madvr I use Jinc because for my Rx580 NGU it is too much in case of 4k HDR sources.

Hmm ... i cannot see grain reduction in this scene from Joker UHD between MadVR and JRVR (both Hable and BT) ... for UHD scaling wont matter much (only chroma channel gets scaled ... that should not be able to blur out grains)

I am on 28.078 beta version though.

[Hendrik]

With MadVR i set target nits at 480. Doing 480 nits for Hable gives similar results where scenes are very bright, but dark scenes gets crushed.

Doing 100 nits for Hable gives similar to my MadVR, but then very bright scenes get "clipped".

Hable is not great for dark scenes, but in bright scenes it "feels" better. On the other hand, BT.2390 seems to perform better in dark scenes.
I'm going to look into BT.2390 and see if its bright scene behavior needs to be improved, because it should definitely be the favored algorithm.

If you are using a specific movie as an example, a clip or at least a timestamp would be nice though.

Generally would avoid reducing the target peak below the default of 203 though, as that will only amplify any shortcomings.
Instead of focusing only on Hable, maybe give BT.2390 a try and try to achieve an acceptable result with the target peak.

On one note, who is to say how its really supposed to look, though?
If, for example, you compare the SDR Blu-ray of that Harry Potter scene, its also quite overblown in brightness, similar to what you get with BT.2390, and very unlike to what you get from madVR.

[jmone]

It is a good point, we should be evaluating what looks good rather than a comparison to how madVR looks, or perhaps comparing it to HDR Passthrough to see how JRVR tonemapping works against the HW tonemapping that the HDR Displays are doing.

At present (for me), I find the blown highlights / oversaturation on BT.2390 to be more noticeable than the poorer black details on Hable.  I have also found I end up running way higher than 203 nits (500 or even 750 on screens with higher NIT capabilities).

[jmone]

...not wanting to add more complexity options but any thoughts on ACES filmic tone mapping?

[tij]

I am not expert on tone mapping. And its very subjective on what's look good. Most ppl prefer oversaturated images - thats why demo TV in shops run very oversaturated images.

Without having reference monitor ... its hard for me to say whats right. Thats why i am sticking with comparing with MadVR (not beta ones). I recall MadVR forums compared to HD BD for lack of other references.

The Scenes I am using are from Batman v Superman Dawn of Justice (2016) time stamp 2:30:57

and Harry Potter and the Deathly Hallows Part 2 (2011) time stamp 1:31:36

Overall ... if really watching movie - then my choice will be BT as it handles both very bright and very dark scenes better

Though ... I prefer Hable pictures - gives more details (in Harry Potter screen shots - ceiling has more details in Hable and MadVR). But never know if nit settings gonna cause problem in dark or bright scene. Edit3: and hable seems to preserve hue better than BT.

Edit: JRVR seems to give greenish tint to Harry Potter bright areas - not so noticable in Hable ... but very noticable in BT (similar to what my LG E6 is doing)

Edit2: scratch that i dont see tint in Hable anymore ... at least i think so

[mattkhan]

Comparing against current tonemapping implementations that are thought to do a good job seems a sensible way to approach this overall (e.g. a recent lumagen, fairly recent madvr beta, jvc n series projector) given the absence of a reference implementation. It's probably a fair bit quicker than using subjective preference given the experience of that madvr tonemapping thread. From that it is easy to see that people have different preferences (though broadly appear to fall into a few different camps depending on what they prioritise), that looking at loads of content is important (and very time consuming) and that having a well calibrated display with a known peak output (and sharing this info) is important because you need to know how much work the tonemapping is having to do to judge how it performs.

[Hendrik]

Comparing against current tonemapping implementations that are thought to do a good job seems a sensible way to approach this overall (e.g. a recent lumagen, fairly recent madvr beta, jvc n series projector) given the absence of a reference implementation. It's probably a fair bit quicker than using subjective preference given the experience of that madvr tonemapping thread.

The problem with that is of course if people focus too much on comparing to madVR, we might as well miss a goal of a decent version just because it looks different to madVR. Afterall madVR has spent over two years doing nothing but tonemapping, and we just don't have that kind of time to invest, and we're not selling our tonemapping for 5k a pop. If users are looking for the best tonemapping you can get, madVR will continue to be supported, although you'll likely have to put in the work to figure out how to configure all the parameters in madVR.

I don't have the knowledge (or time) to invent a new custom algorithm, so I have to stick to published research in that field, and lean on other solutions, like the two options being presented here.

From what I can tell so far, the peak detection seems to be a bit too aggressive, if the peak is adjusted a bit then BT.2390 seems quite a bit happier with these bright scenes. So I'm talking with the author of the peak detection to see if there is a flaw we can address, or in the intepretation of the peak data in BT.2390, and see what's what.

For the record, the two BT.2390 screenshots posted above look pretty good to me.

Pass-through is also coming, and hopefully we can make that a reliable solution as well. Although some pre-requisite features are still missing, like overlays, otherwise you would get thrown out of HDR when you change the volume or such, which of course wouldn't be great.

[JimH]

The problem with that is of course if people focus too much on comparing to madVR, we might as well miss a goal of a decent version just because it looks different to madVR.

I'm in complete agreement.  We're not trying to duplicate madVR.

[lepa]

Not sure if supposed to report other than picture quality issues but...
previously selected external subtitles are not drawn if playback is stopped and started again. OSD shows subtitles selected but they are not drawn until toggling subtitles to something other and then back.

[JimH]

Not sure if supposed to report other than picture quality issues but...

Functional problems like that are very important.  Thanks.

[tij]

Are BT.2390 and Hable to stay? or one of them will be dropped once the better one is identified?

Really like Hable when it works

[Hendrik]

Not unless something else proves to be superior everywhere. The problem with Hable is that it almost needs per movie config, if not per scene.

[jmone]

Yup Overlays are need to be done, but in my setup (OS HDR always on), I'm not sure that I'd be thrown out of HDR mode when using HDR Passthrought as I "think" Windows will tone map SDR Overlays anyway (just a guess).

[Hendrik]

Overlays also add Blu-ray menus (Windows only), and they avoid disrupting Fullscreen playback, which is the only way to get DWM to leave us alone for proper timing, so definitely coming first

[jmone]

Perfect!  It will also make JRVR feature complete. 

FWIW, I did a bunch of testing on HDR Passthrough (madVR) to my 1,000 Nit screens vs Tone Mapping with the same UHD HDR10 HEVC BT2020/P3 DCI @ 50fps 1,000nit clip encoded at 8 & 10 bit with both 4:2:0 and 4:4:4 colour space.  My general impressions were:
- On high NIT HDR Displays - passthrough looks the best (there is no need to tonemap, or that the tonemapping done by the Display works well).... though I did not try clips encoded at 4,000 nits.
- There is a bunch of stuttering as the 4:4:4 10Bit clips start to play but it then settles down and I was surprised how much better it looked compared to 4:2:0 (I need to try this on a NUC as I noticed that render times seemed to also drop).  I was surprised by this as I had always through we were not that sensitive to chroma (note: the original source is 4:2:2 then encoded in Resolve to either 4:2:0 or 4:2:2)

I feel that ToneMapping is a good / needed solution for those with Low Nit / SDR displays playing HDR Content (and hence why the madVR thread is all about Projectors).  The good news could be that as screen brightness levels are pretty good on some models, tone mapping may not be needed, just passthrough. 

Looking forward to seeing how passthrough goes and what works better on what setups.

[jmone]

Quick (off topic) Q:  I thought modern GPUs supported HW Acceleration decoding for 4:4:4 HEVC, but I noticed my test clips all play using the CPU not GPU?

[Hendrik]

4:4:4 decoding is not exposed through DXVA/D3D11, so you can't use it unless you do vendor-specific things.

[jmone]

Thanks.  Kills that idea off! ... and explains why HW accelerated encode/decode it works in Resolve.  The i9 has enough horse power but the rest all flat line.

[jmone]

Here is an interesting HDR test pattern video for testing tone mapping - Direct Link to File --> https://drive.google.com/file/d/1yeWp53vi90resQMm_E8ir2TRxntF5qUm/view?usp=sharing , thread https://www.avsforum.com/threads/hdr10-test-patterns-set.2943380/

As the video plays, it ramps up the brightness on the dress so you can see where the clipping happens (and the crush of the dark details in the wall / floor).  It also shows undesired tonal changes (like skin tones).

Here are some side by side examples where I had paused the video when the dress is at 1,000nits.  In MC I then compared Hable and BT2390 at two different brightness levels (203 and 750nits).  I also compared side by side with HDR Passthrough to see which ones look the closest to it (can't post a HDR screen shot unfortunately).  Anyway, of the four, Hable @ 203 is the closest in terms of detail and skin tone (though the HDR passthrough version there is a lot more detail in the dress and even down to individual stones in the earrings).  Interestingly, ramping up the brightness from 203 to 750nits helps the most on BT.2390 to get highlight detail back but then skin tones looks weird at these brightness levels for both look off.

[tij]

Here is an interesting HDR test pattern video for testing tone mapping - Direct Link to File --> https://drive.google.com/file/d/1yeWp53vi90resQMm_E8ir2TRxntF5qUm/view?usp=sharing , thread https://www.avsforum.com/threads/hdr10-test-patterns-set.2943380/

As the video plays, it ramps up the brightness on the dress so you can see where the clipping happens (and the crush of the dark details in the wall / floor).  It also shows undesired tonal changes (like skin tones).

Here are some side by side examples where I had paused the video when the dress is at 1,000nits.  In MC I then compared Hable and BT2390 at two different brightness levels (203 and 750nits).  I also compared side by side with HDR Passthrough to see which ones look the closest to it (can't post a HDR screen shot unfortunately).  Anyway, of the four, Hable @ 203 is the closest in terms of detail and skin tone (though the HDR passthrough version there is a lot more detail in the dress and even down to individual stones in the earrings).  Interestingly, ramping up the brightness from 203 to 750nits helps the most on BT.2390 to get highlight detail back but then skin tones looks weird at these brightness levels for both look off.

Interesting, jmone.

I played around with your test clip. Target nits at 600 with peak detection.

Basically took screenshot of clip at 500nit dress and 1000nit dress. Screenshot don't include dress - as its brightness ramp makes everything look darker - but look at the earing with brightness almost as dress.

1. BT - earing gets brighter while everything else stay almost intact - only earing gets brighter (but some details are lost in earings)
2. Hable - earing gets a bit brighter while everything else gets darker (earing details almost stay intact)

It feels like Hable try to preserve details in bright area by not going very bright ... and for viewer to perceive brightness dims everything else

EDIT: feels like BT is only compressing bright area (greater compressin in bright area results in detail lost) while Hable compresses everything (less compression in bright area gives more details there ... but compressing "normal" area results in dimming)

[jmone]

Yeah, there are lots of variations that can be used for testing.  I picked the 1,000 nit dress as that can be a common HDR mastering spec (but so can 500, 2000, 4000 or ER up to 10000 so take your pick from the relative part of the test clip) which than needs to then be compressed down into a presumably smaller brightness range so I chose the default 203 and also a much higher one at 750 to better match what my screen is capable of but still requiring the mapping of 1,000 nit down to a lower value.  I'm not sure that tone mapping of a 500nit scene to a 600nit setting would do anything?  ..or is it expanding the range?  Also as the MC brightness settings get closer to the nits of the scene then the more the two curves look the same, but I was surprised on the tonal shift. 

[tij]

Yeah, there are lots of variations that can be used for testing.  I picked the 1,000 nit dress as that can be a common HDR mastering spec (but so can 500, 2000, 4000 or ER up to 10000 so take your pick from the relative part of the test clip) which than needs to then be compressed down into a presumably smaller brightness range so I chose the default 203 and also a much higher one at 750 to better match what my screen is capable of but still requiring the mapping of 1,000 nit down to a lower value.  I'm not sure that tone mapping of a 500nit scene to a 600nit setting would do anything?  ..or is it expanding the range?  Also as the MC brightness settings get closer to the nits of the scene then the more the two curves look the same, but I was surprised on the tonal shift.

I mapped 500 to 600 exactly so there is no change ... to see what non bright area supposed to look ... then crank up to 1000

... and as mention above - BT doesnt alter non bright area (if it does - its not noticable) ... but Hable darkens it - quite noticably

EDIT: in picture i posted ... see some girl's hair highlight details get lost with Hable ... but remain imtact with BT

[tij]

Guessing - BT use some sort of S curve

When target gamma is out ... might remedy Hable darkness ... can't wait to test

[Hendrik]

Anyway, of the four, Hable @ 203 is the closest in terms of detail and skin tone (though the HDR passthrough version there is a lot more detail in the dress and even down to individual stones in the earrings).

Personally, I feel like the skin is way underexposed on anything but BT 203nits. Yes, it loses detail in the dress, and even overexposes it a bit, but the skin looks like skin and actually lit up like you would a proper photo to be. Of course I'm watching this on screens in SDR mode with no specific setup to try to use extra brightness or anything, just setup for normal SDR viewing.

I think that point should be made clear of the expectations. The goal is to provide a good experience when watching on SDR screens. If your screen is bright enough that a target of 750 nits is even reasonable, you should probably just be using pass through. Not designing an alternative for TV tonemapping on HDR screens, but rather something to watch the content on PC screens or older TVs. If you want to replace HDR tonemapping on a HDR screen on your PC, madVR is likely the option you want to go for.

... and as mention above - BT doesnt alter non bright area (if it does - its not noticable) ... but Hable darkens it - quite noticably

Thats why I think BT.2390 is ultimately better, because you don't want your entire image to darken because some highlight gets brighter.

[jmone]

This might help in the comparison.  I converted the Women in the White dress clip to BT709 using Davinci Resolve to see how they handle it.  https://behome.dyndns.info/index.php/s/ZF5Ajj8B6WqoMHA

The dress does eventually blow out at over 1,000nits , but the rest of the frame looks to stay as it should.  Pretty impressive and at least gives us what it could look like (eg below is the 1,000 nit dress converted to 709)

[jmone]

In looking at them again with the DR version
- The High 750 nit settings just looks poor for both Hable and BT.2390.  Not only the the exposure look wrong, but I see a green? grey? colour cast.
- The BT.2390 @ 203nits does look good overall and the added pop to the skin tone is pleasing but the blown out whites on the dress is really poor (and gets worse as the brightest increase above 1,000 nits and there are plenty of high nit content on HDR discs)
- The Hable @ 203nits has a bunch of problems, with the skin tone underexposed and probably even the shadows details on the bottom half of the dress. 

If possible I'd take BT.2390 if the blown highlights can be addressed, or Hable if the overall brightness could be increased for tone mapping down to 203 nits.  I'm not sure either are fixable at 750nits, but as you say - tone mapping is for low NIT SDR Screens.

It's early days, but I'm thinking / hoping I'll land on JRVR with HDR Passthrough on bright HDR Displays, and JRVR tone mapping on the PJs.

[jmone]

If anyone has other problematic scenes (and I have the disc), I'm happy to convert that part to 709/SDR in Resolve for comparison shots.

[tij]

Thats why I think BT.2390 is ultimately better, because you don't want your entire image to darken because some highlight gets brighter.

Atm it does seems so ... that test clip with white dress ... white dress starts at 200 goes up to 10000 then goes down to 200

Through out clip ... BT2390 keeps background (anything not dress and earrings) consistent at same brightness/contrast (if there are changes ... i cannot see it).

Habble ... starts to darken background as dress pass target brightness ... worst: once dress brightness starts to dim - the background ends up slightly darker than what it started with (hard to see side by side ... so post animated gif)

[tij]

Now that's something i didn't expect. Hable has more low light level details.

Blade Runner 2049 ... timestamp 00:04:57

[Hendrik]

The next build enables the target gamut and gamma options, although both should just match your screen and viewing conditions, and can't really be used to dial in content.
Additionally, specifically for Hable there is a new option to control the boost it uses to recover brightness, which could help to obtain a more universally useful image out of Hable (the default of 1.0 disables the extra brightness boost)

With the dress test clip, these settings worked pretty neatly for me:

- Hable
- Max Boost: 3 to 4
- Desat: 0.75/1.5

Without the Desat change, the skin color would somehow feel washed out, especially compared to BT.2390. I have not tested it much yet with pure dark scenes though, but it does seem to do a decent job to preserve perceived brightness more or less in the dress clip, as well as not mess up the Harry Potter scene from before. The dress clip is a rather contrived example however, usually high brightness highlights wouldn't be quite as prominent and image filling in a scene.

Still also exploring ways to improve BT.2390 peak brightness behavior.

Last but not least, you can enable logging of frame times, to help analyse any issues with frame pacing/stuttering/etc. It'll write a neat CSV with all frame times into the log folder so I can see what might be up.

[tij]

28.0.79

Just had a quick look. Incredible. Hable looks almost identical to MadVR 0.92.17 ... Batman v Superman Dawn of justice - no more crushing dark details ... Bladerunner 2049 - inside the house can see couch details well

BT.2390 also improve in Bladerunner 2049

BT.2390 is still not so good at high brightness scenes - details in highlights got lost ... Meg - the beginning helicopter flight ... details in bright skies gets lost - it just a bright patch in the sky (Hable and MadVR can see bright clouds)

Will do screen shot later.

One request - jump behavior in video currently is 5seconds ... near impossible to take screen shot for comparison ... especially in scenes that each frame changes brightness dramatically (Harry Potter Goblet of Fire - graveyard scene fight) ... can we have frame by frame skipping

Great job Hendrik

... also for target Gamut ... can we have DCI-P3?

EDIT: some shots from Meg ... 00:04:55

[Hendrik]

One request - jump behavior in video currently is 5seconds ... near impossible to take screen shot for comparison ... especially in scenes that each frame changes brightness dramatically (Harry Potter Goblet of Fire - graveyard scene fight) ... can we have frame by frame skipping

I think we support frame stepping (at least forward), but not sure JRVR supports that, as i'm not certain whats required to make that work. I can probably implement that, but it'll be after my vacation.

[tij]

I think we support frame stepping (at least forward), but not sure JRVR supports that, as i'm not certain whats required to make that work. I can probably implement that, but it'll be after my vacation.

[SHIFT]+[Right Arrow] works with MadVR but not JRVR

Not high priority ... as rather see JRVR improvement

Attached is Meg from 3D BluRay (since its 3D ... its brightness might have been boosted during mastering to take into account 3D glasses)

EDIT: colors "details" looks very similar to Hable with low Desat values

[jmone]

- Hable
- Max Boost: 3.5
- Desat: 0.75/1.5
- Target Gamut/Gamma: Auto
- Target Peak Nits: 203

Great work!  White dress clip looks good at all brightness levels without blowing out or weirdness in the background / shadows.  Very pleasing skin tones (even if a bit more saturated).  Did a run through of my 1,000 nit mastered HDR videos and they also looked great.  I'm not sure if there is much more to wring out of Hable but this combination certainly produces a very good default setting that few would complain about.  If you can tame the BT.2390 peak brightness behaviour it would be a good comparison.

I'll now have a look at some dark content with these settings.

Target Gamut:  I did try 2020 and it gave everything an olive cast so went back to Auto (709).  As tij suggested, DCI-P3 is probably the widest colour space that realistically can be supported anyway on consumer devices (as I see that UHD BD are typically mastered in 2020 but limited to DCI-P3 for this reason).

[jmone]

On dark scenes the difference between the two is more subtle (but using the same Hable setting above for both, just switching between Hable and BT.2390).  Hable maybe has a bit more details in the shadow but it does handle the gradients in the highlights better (see Juniors throat).  BT.2390 on the left, Hable on the right.

[jmone]

again, subtle difference.  BT.2390 (on left) has more noise in the clouds and banding around the sun rise over the hills than Hable (right)

[Hendrik]

Target Gamut:  I did try 2020 and it gave everything an olive cast so went back to Auto (709).  As tij suggested, DCI-P3 is probably the widest colour space that realistically can be supported anyway on consumer devices (as I see that UHD BD are typically mastered in 2020 but limited to DCI-P3 for this reason).

The problem here isn't the color space to use, but what the TV expects. On my LG OLED I have an option to swap between BT.709 or BT.2020 for SDR signals (HDR is always BT.2020, I believe). The output of the renderer has to match that, there is no other options. So if I swap it in the TV to BT.2020, then the desktop gets super oversatured - as expected, but I presume JRVR would look just right if its in BT.2020 output mode (I didn't test that yet, but theory holds).

If you are using Windows HDR, DWM probably expects SDR BT.709/sRGB and converts to HDR BT.2020 for output - hence it expects JRVR to output BT.709/sRGB, like any normal desktop application would, but if you send BT.2020 instead then you get the typical under-saturated look with a slightly green hint - just as if your TV was expecting BT.709 and you send BT.2020.

Presumably Windows can be informed of the gamut you are sending, but thats a task for another day.

I don't know if any TVs can be set to expect DCI-P3. Maybe some slightly older models had that before BT.2020 properly established itself?
The only reason not to use BT.2020, if your TV can accept it, would be to avoid banding in 8-bit signals, due to the much wider colorspace and the same amount of bits. JRVR can't output 10-bit yet.

Its important to remember that both the Gamut and Gamma options are not about the source image, or your preference, its entirely only about what the display expects to be receiving (or if you use Windows HDR, what DWM expects) - and displays will expect BT.709 or BT.2020 - even if they can only display DCI-P3. Unless someone is going to tell me that you can also set your display to expect DCI-P3, then I can add it.
(Gamma can be a bit about preference, to be fair.)

[mattkhan]

Unless someone is going to tell me that you can also set your display to expect DCI-P3, then I can add it.

JVC projectors can and it is the recommended target to use when calibrating (and for 3dlut use) if the option is available to you. It would be good to add it here.

[jmone]

@ Hendrik - That makes sense.  In resolve you can set a colour space (709 / 2020 / DCI-P3 etc etc) but you also have the option of setting a colour space like 2020 but then limit the range to DCI-P3, which is what most UHD BD have done (given no display can resolve all of 2020).....  & yes I'm testing on Win11 with OS HDR on all the time going to my high nit HDR Screens..... so I'll be seeing a different looking image that others, but it does fix the dropping in and out of HDR mode all the time.  Then again, everyone will have a different combo of HW, SW etc etc.

Anyway, did some more testing on dark + high contrast dark / bright scenes (space shots, explosions etc).  With the exception of the blown highlights in BT.2390 the rest of the frames look very similar unless I got down to pixel peeping.  So for now I'd call the new Hable setup "good" (or "good enough") with your suggested settings for me for tone mapping.  I'm sure there are endless variations and knob twiddling but I just don't see any glaring issue to report on Hable.  That said, I'll need to test on the PJs next as the low NITs of this setup will be interesting to see. 

@ mattkhan - I don't think I have a DCI-P3 option on my JVC 7500.  I can set it to 2020 (then ST.2084 for Gamma) which worked very well in my last round of testing.  I'll dig further tonight when it is dark.

[Hendrik]

@ Hendrik - That makes sense.  In resolve you can set a colour space (709 / 2020 / DCI-P3 etc etc) but you also have the option of setting a colour space like 2020 but then limit the range to DCI-P3, which is what most UHD BD have done (given no display can resolve all of 2020

We're never going to expand the colorspace, just re-package it, so if it comes off of a UHD BD as DCI-P3 inside BT.2020, then we wouldn't change that when it gets output as BT.2020, still DCI-P3 inside BT.2020. Only if the envelope gets smaller will the colors have to be adjusted.

I just wanted to make sure those options are properly understood. But luckily it'll also look quite wrong if you set it wrong. I suppose there will need to be a proper wiki article at some point.
But if there are devices out there that can actually accept a DCI-P3 signal without the BT.2020 envelope, then I can certainly add it - although it'll be a bit, since thats part of the rendering library, and i need to re-build it for new values.

As for the tonemapping settings, if we don't find anything super bad, I might change the defaults and reset the tonemapping settings for everyone in a new build before I take a break for a week. It sounds like it might be good enough for a while so I can take my vacation and focus on other features. Feel free to also suggest changes to the settings I posted above.