Print

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

[jmone]

 

[Manni]

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!

[Manni]

Bump. any comment from Hendrick or Haasn on the above?

[haasn]

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?

[FenceMan]

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.


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.

[FenceMan]

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.

[mattkhan]

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]

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).

[Manni]

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.

[Manni]

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.

[FenceMan]

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. 

[Manni]

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.

[FenceMan]

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?

[Manni]

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?

[FenceMan]

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.

[Manni]

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

[Hendrik]

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.

[Manni]

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.

[Hendrik]

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.

[Manni]

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

[kasper93]

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.

[Manni]

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.

[kasper93]

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.

[FenceMan]

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?

[Hendrik]

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.

[FenceMan]

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?

[mattkhan]

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?

[FenceMan]

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.

[mattkhan]

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

[FenceMan]

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.

[Manni]

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!

[kasper93]

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.

[mattkhan]

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

[mattkhan]

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!)

[Manni]

It's been requested, hasn't been added yet

Thanks!

[Hendrik]

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?

[FenceMan]

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?

[Hendrik]

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.

[mattkhan]

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

[FenceMan]

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?

[Hendrik]

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.

[mattkhan]

What does "native SDR" mean exactly in this context?

[Hendrik]

Matching a file that starts out as SDR. Any other target would just add complications for no reason.

[haasn]

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?

[Hendrik]

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.

[jmone]

Plus we can already do HDR --> SDR-P3 or SDR-2020

[mattkhan]

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.

[Hendrik]

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.

[mattkhan]

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?

[Hendrik]

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.