Print

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

[mattkhan]

Ah ok, thanks for clarifying

As for correct use of displaycal for this case, I would really like to be able to measure this to be sure but measuring a tone mapped image looks tricky as the tone mapping itself distorts the image. I wonder is there a way to construct an image that goes through the same processing but essentially passes through the tone mapping untouched?

[kasper93]

I wonder is there a way to construct an image that goes through the same processing but essentially passes through the tone mapping untouched?

Well, you have to convert at some point if the data is not representable in your target format. `clip` mode is the closes to untouched as it will clip out of range values, leaving the rest as is.

Practically speaking, Say I want a 2.4 output, why go PQ -> SDR gamma (bt1886) -> 2.4 ? ie why bother with the intermediate step?

It is only your choice, how advance and complex your setup is. You can have multiple 3DLUTs for each colorspace that converts to target display and even can change manually display settings for different content. (and you will not see any difference in the end...)

One thing to remember if you use 3DLUT to change gamut (i.e. bt.2020 to bt.709) you will skip libplacebo's fancy gamut mapping code. And rely on the algorithm of the software that was used to generate 3DLUT.

Also it is little bit incorrect to say "convert with 3DLUT to bt.709", because in practice if we are talking about measured display characteristics, it can be "close to" bt.709, bigger or smaller. Point being we are converting to display response, not really any defined colorspace. Of course depending on the settings/calibration it may be very close to reference, but still...

[mattkhan]

Not sure if we're talking about the same thing, I am just talking about the gamma not the colourspace. In this example it's taking HDR in, libplacebo converts to dci-p3 d65 with rec709/bt1886 gamma and then the lut is tweaking colours within that same colourspace while also adjusting the gamma to 2.4. My question is whether there is any advantage to having libplacebo convert to dci-p3 d65 with 2.4 gamma and then the lut just tweaks colours.

The only difference I can think of is if the extra conversion step introduced precision issues but I am not an expert in this field so that's just a guess

[kasper93]

Not sure if we're talking about the same thing, I am just talking about the gamma not the colourspace. In this example it's taking HDR in, libplacebo converts to dci-p3 d65 with rec709/bt1886 gamma and then the lut is tweaking colours within that same colourspace while also adjusting the gamma to 2.4. My question is whether there is any advantage to having libplacebo convert to dci-p3 d65 with 2.4 gamma and then the lut just tweaks colours.

I would argue there is no difference in practice. Using bt1886 for SDR is better, because it can apply directly to SDR content and converts it to your target 2.4. And for HDR "extra step" wouldn't be noticeable. Not really an extra step, because you wouldn't do conversion from PQ directly anyway, it is just a question how many 3DLUTs you want to generate . Using 3DLUT close to display is probably more universal as it doesn't assume any input content, just tweak the colors in the last step as you said.

I think we are splitting the hair here, there is not much difference in practice.

[FenceMan]

I would argue there is no difference in practice. Using bt1886 for SDR is better, because it can apply directly to SDR content and converts it to your target 2.4. And for HDR "extra step" wouldn't be noticeable. Not really an extra step, because you wouldn't do conversion from PQ directly anyway, it is just a question how many 3DLUTs you want to generate . Using 3DLUT close to display is probably more universal as it doesn't assume any input content, just tweak the colors in the last step as you said.

I think we are splitting the hair here, there is not much difference in practice.

If I have 88% of P3 on my projector would it be better to create a P3-D65 lut or Rec 709?

[Hendrik]

If I have 88% of P3 on my projector would it be better to create a P3-D65 lut or Rec 709?

Honestly you would likely just want to compare the visuals and see what you prefer. You could also get a ICC profile for your exact projectors capability and JRVR would be able to adapt the gamut to that space perfectly.

[mattkhan]

I'm now even more confused as to what the right option is having reviewed exactly what displaycal does when generating a lut

specifically, if I generate a SDR LUT in displaycal with a DCI-P3 D65 colourspace then, as far I can tell, it is configuring the input side of the LUT generation to expect a 2.6 gamma with a BT1886 adjustment but with a blackpoint of 0,0,0 which seems to mean it just expects a pure power 2.6 gamma.

it's slightly surprising to me and I could be wrong but it's also quite logical given what I can see in the code

how to translate this to JRVR though? specifically, how does the contrast setting interact with the 3dlut source gamma? I think BT1886 with a 0 blackpoint is basically equivalent to a 2.4 gamma isn't it? if so it means the right option, for my tonemapped HDR use case, would appear to be a 2.6 input.

[Manni]

I'm now even more confused as to what the right option is having reviewed exactly what displaycal does when generating a lut

specifically, if I generate a SDR LUT in displaycal with a DCI-P3 D65 colourspace then, as far I can tell, it is configuring the input side of the LUT generation to expect a 2.6 gamma with a BT1886 adjustment but with a blackpoint of 0,0,0 which seems to mean it just expects a pure power 2.6 gamma.

it's slightly surprising to me and I could be wrong but it's also quite logical given what I can see in the code

how to translate this to JRVR though? specifically, how does the contrast setting interact with the 3dlut source gamma? I think BT1886 with a 0 blackpoint is basically equivalent to a 2.4 gamma isn't it? if so it means the right option, for my tonemapped HDR use case, would appear to be a 2.6 input.

This might be because DC is targetting Cinema DCI, not consumer P3 (which doesn't really mean anything, as only rec709 and BT2020 are used in consumer content). Did you check the white point as well to see if it was D65?

I don't use DC, but there are no such issues with Calman or Colorspace, you can target any gamut/gamma/white point. I'll make an attempt to create a P3 BT1886 D65 3D LUT when I find the time and I'll report back.

To answer your question, BT1886 with 0 black is 2.4 power indeed. The gamma target only change (especially in the lower end) of the BT1886 curve when black is non-zero. The higher the black floor, the lower the gamma targets in the low end, to get out of black faster.

[mattkhan]

This might be because DC is targetting Cinema DCI, not consumer P3 (which doesn't really mean anything, as only rec709 and BT2020 are used in consumer content). Did you check the white point as well to see if it was D65?

actually that 2.6 is a user setting which displaycal defaults to when you select DCI-P3 D65 (seems like a bug), the whitepoint is D65 though. This gamma gets put on the input profile that goes into collink. It's curious because that would seem to suggest the source gamma in JRVR should match that set in displaycal yet previous testing said this produced v wrong output. I'll have to retest that to check.

[SirMaster]

Instead, set your OS/GPU to 16-235, and it'll all work as expected.

I'm surprised by this.  I thought you should never use Limited for the GPU as that causes the GPU to compress the Full range input into Limited, and the GPU doesn't do a particularly great job at this.

Video is of course Limited (Black=16 White=235), and so your media player can also be set to not touch it, then setting the GPU to Full is in essence passthrough of the Full 0-255 signal.  Then you set your display to Limited, thus telling the display to interpret 16 as black and 235 as white which is where they are located within the Full range signal coming from the GPU.

If you set your GPU to Limited, then when the Limited video comes in (within its Full container), the GPU will compress Full -> Limited and then that will make 16 go to 32, and 235 go to 219.

Correct:
https://kodi.wiki/images/3/30/Qngr5Fh.png

Wrong:
https://kodi.wiki/images/8/8b/MEltJKj.png

[Manni]

I'm surprised by this.  I thought you should never use Limited for the GPU as that causes the GPU to compress the Full range input into Limited, and the GPU doesn't do a particularly great job at this.

Video is of course Limited (Black=16 White=235), and so your media player can also be set to not touch it, then setting the GPU to Full is in essence passthrough of the Full 0-255 signal.  Then you set your display to Limited, thus telling the display to interpret 16 as black and 235 as white which is where they are located within the Full range signal coming from the GPU.

If you set your GPU to Limited, then when the Limited video comes in, the GPU will compress 16 to 32, and 235 to 219.

Correct:
https://kodi.wiki/images/3/30/Qngr5Fh.png

Wrong:
https://kodi.wiki/images/8/8b/MEltJKj.png

Agreed in principle, that why I decided to go for GPU full / madVR full / JVC full (with the JVC set to auto). Seems to work fine for now, as this resolves the levels issues in JRVR, which follows the GPU settings re full or limited. I haven’t tested all my sources, but it looks like a better solution than limited / limited / limited.

[Hendrik]

Video is of course Limited (Black=16 White=235), and so your media player can also be set to not touch it,

"not touching" it is a misconception, though, because the YCbCr-> RGB conversion already touches everything about it, all you do is change the coefficients of that conversion math a bit. Its not less precise to do that, and its not a separate step. If anything its slightly more precise to use the full range of values, although that difference is marginal.

The thing is that PCs are inherently full range, and they only deal with full range images. If you present anything else to the OS, you lie to it about what kind of image you send. And the end result is that anything thats not video gets clipped. So any overlays get clipped. Any other content on the PC gets clipped.
This is a terrible solution for a rumor of a bad quality conversion.

Its easy to test. Can you tell the difference?

Ideally you would use full-range everywhere, as that has none of the disadvantages.
The "Wrong" situation you described will also never happen, unless you misconfigure the system by using limited twice. Its the video renderer's responsibility to render all content to full range. There will never be "limited video within its full container" at that point.

[SirMaster]

"not touching" it is a misconception, though, because the YCbCr-> RGB conversion already touches everything about it, all you do is change the coefficients of that conversion math a bit. Its not less precise to do that, and its not a separate step. If anything its slightly more precise to use the full range of values, although that difference is marginal.

The thing is that PCs are inherently full range, and they only deal with full range images. If you present anything else to the OS, you lie to it about what kind of image you send. And the end result is that anything thats not video gets clipped. So any overlays get clipped. Any other content on the PC gets clipped.
This is a terrible solution for a rumor of a bad quality conversion.

Its easy to test. Can you tell the difference?

Ideally you would use full-range everywhere, as that has none of the disadvantages.
The "Wrong" situation you described will also never happen, unless you misconfigure the system by using limited twice. Its the video renderer's responsibility to render all content to full range. There will never be "limited video within its full container" at that point.

Correct, it was an over-simplification. I meant simply not touching the levels.

The 3 workable ways to set a video chain up are full-full-full, limited-full-limited, and finally full-limited-limited.

So it seems you suggest the last, but that has 2 conversions, and in my prior testing I have seen it introduce banding where the other methods did not.  I blame the GPU conversion to limited as what caused the banding, because it's not present when doing full-full-full or limited-full-limited, so I don't think it's the media player or display end.

But perhaps that is only in certain cases and things change from gpu generation to generation and between gpu driver versions too.

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

Apologies to Kasper93 and anyone I might have unintentionally misled, he was correct and I wasn't (I haven't done much calibration with madVR over the last two years, and when I did I guess it was with a 2.2 gamma target when HDR content was involved).

I tested this yesterday with both Calman and Colourspace (latest versions) and madVR build 169.

Using a gamma target different from 2.2 for a 3D LUT used to tonemap HDR to SDR is only available/possible in Colorspace and Calman with Envy. It's not available for madVR, even with the most recent builds.

So if you're using madVR (even the most recent experimental versions), the old advice of only using a 2.2 gamma target for the 3D LUT used during tonemapping with pixel shader still stands. The gamut of the baseline (selected in the display / projector) doesn't matter, though the closer you are to 2.2, the less work the LUT has to do. And the fact that you have to select 2.2 doesn't matter either from a picture point of view: PQ is absolute, not relative, so you'll get the same picture irrespective of the 3D LUT target (2.2, 2.4, 2.6 etc), as long as madVR/Envy knows what it is (hence why it has to be 2.2, as that's the fixed value madVR expects for accurate HDR to SDR tonemapping when a 3D LUT is present).

With Envy, if you don't use a 2.2 target, you need to specify it in the HDR options in Colourspace. It's automatic in Calman as it uses the gamma target set for the calibration. You can select only select a different gamma target in this situation with sofware that supports Envy new calibration API (so only recent Colorspace and Calman AFAIK, as I don't think DisplayCAL has been updated to support that new Envy API).

Again, this is only for a 3D LUT used for HDR to SDR tonemapping with pixel shader.

For SDR content, you can still use any target for the 3D LUT (including BT 1886).

If you don't use a 3D LUT, you can calibrate your display / PJ  to any gamma target as long as you tell madVR to which gamma value the display is calibrated for, even when tonemapping HDR content to SDR with pixel shader. This 2.2 gamma target limitation is only when using a 3D LUT.

Apologies again for the misinformation. I hope I didn't add more.

[mattkhan]

@manni it's not obvious why the API matters here, you create a lut for a target input gamma and then tell the processing engine what that gamma is. Isn't that just a configuration option in the envy that isn't in madvr? Or can you only load a lut via that API and there is no way to do it manually?

Speaking specifically of displaycal, I think the issue is that there is just one gamma (tone curve) control so no way to vary the input and output side independently.

From a jrvr point of view, it seems that this is configurable so no problem supporting that. However it's not obvious to me yet how to verify this objectively, i.e. via measurements. Any suggestions on how to do this?

[Manni]

@manni it's not obvious why the API matters here, you create a lut for a target input gamma and then tell the processing engine what that gamma is. Isn't that just a configuration option in the envy that isn't in madvr? Or can you only load a lut via that API and there is no way to do it manually?

Speaking specifically of displaycal, I think the issue is that there is just one gamma (tone curve) control so no way to vary the input and output side independently.

From a jrvr point of view, it seems that this is configurable so no problem supporting that. However it's not obvious to me yet how to verify this objectively, i.e. via measurements. Any suggestions on how to do this?

Yes of course, there is nothing that would prevent madVR to handle this, but for obvious reason I guess this is an Envy exclusive, like many other things (1D LUT, AI Motion interpolation, etc) that don't drip down into madVR, even if technically it could.

The API simply allows the software to tell Envy which gamma target is used for the LUT. madVR is fixed to 2.2. Envy can accept any target, as long as the software tells it what it is.

Frankly, it doesn't make any difference in practice as PQ is absolute. So you get the same results in Envy irrespective of the gamma target used. That's why the gamma 2.2 limitation in madVR isn't really one, it's an inconvenience only. Some people don't understand that you get the same picture with gamma 2.2 and 2.4 when tonemapping HDR to SDR, so it's easier to give them the option, even if they get exactly the same picture in the end.

[haasn]

Well, for maximizing numerical precision of any LUT you technically want the input and output to be as linearly related as possible. So if your display is 2.4 gamma native, using 2.4 gamma as the input would make the 3DLUT slightly more accurate in theory. So if you have a choice, it makes more sense to pick something resembling your display curve than something resembling the input, since the conversion from e.g. BT.1886 to 2.4 in the shader is going to be more numerically precise than the conversion from BT.1886 to 2.4 in the 3DLUT.

Note: tricubic interpolation is possible in libplacebo but much slower and currently only exposed as an option for gamut mapping.

Note 2: It probably doesn't matter in practice, especially at larger sizes. But there's a reason it's called libplacebo

[Manni]

Well, for maximizing numerical precision of any LUT you technically want the input and output to be as linearly related as possible. So if your display is 2.4 gamma native, using 2.4 gamma as the input would make the 3DLUT slightly more accurate in theory. So if you have a choice, it makes more sense to pick something resembling your display curve than something resembling the input, since the conversion from e.g. BT.1886 to 2.4 in the shader is going to be more numerically precise than the conversion from BT.1886 to 2.4 in the 3DLUT.

Note: tricubic interpolation is possible in libplacebo but much slower and currently only exposed as an option for gamut mapping.

Note 2: It probably doesn't matter in practice, especially at larger sizes. But there's a reason it's called libplacebo

You are absolutely correct of course. I was having large LUTs in mind. What I meant was that some people with a dark room freak out when they see 2.2 gamma because they think that their tonemapped picture will look washed out (as SDR content does when using 2.2 instead of 2.4 or higher), when in reality, assuming the calibration is perfect, a target of 2.2 or 2.4 or 2.6 for the 3D LUT won't make any difference as long as the renderer knows what it is. In the real world, it's usually better if you can to select a baseline in the display closer to your target, especially with smaller LUTs. I use a 3.7K custom patch set with Colourspace that produces results similar to a 21^3 LUT in a fraction of the time, and it really doesn't care about the baseline. Well, within reason, but we're talking about 2.2 vs 2.4, not 1.8 vs 2.6

I also create an internal 1D LUT in the JVC to my 3D LUT target, so it's 2.4 with Envy and 2.2 with madVR. That way the 3D LUT has less work to do, as gamma in the baseline is near perfect already.

[FenceMan]

Source - https://www.dropbox.com/scl/fi/6mpfiaoy1hdzsg4u5lim9/S-M.mkv?rlkey=3rzxerjrxhsych5ysnrg65zlo&dl=0

MadVR looks blueish and JRVR looks yellowish, which is correct?

[haasn]

That "yellowish" image is almost perfectly neutral (white) according to my color picker, with about +1 to red here and there - most likely as a result of the perceptual gamut mapping tending to make very bright colors more white-ish. The madVR image has +10 to blue almost across the board.

Side note, here is the "official" SDR master. It looks like somewhere in between the JRVR and madVR versions to me.

[FenceMan]

That "yellowish" image is almost perfectly neutral (white) according to my color picker, with about +1 to red here and there - most likely as a result of the perceptual gamut mapping tending to make very bright colors more white-ish. The madVR image has +10 to blue almost across the board.

Side note, here is the "official" SDR master. It looks like somewhere in between the JRVR and madVR versions to me.

That's exactly what I thought and saw with color picker - MadVR seems to be pushing blue. 

[AVSForum]

[jmone]

Lots of people are preconditioned to the madVR look.  Best to compare to the original but that advice does not always go down well.

[FenceMan]

Lots of people are preconditioned to the madVR look.  Best to compare to the original but that advice does not always go down well.

I will say here what I said there, I don't understand how to have a conversation if we can't even agree on objectively measurable colors.  MadVR is more blue when compared to JRVR, I can measure that.  Its like bizarro world with everyone telling me blue is white and white is yellow.  It is ok to prefer one over the other but I don't understand the complete difference in perception of what these look like.

@haasn do you have any idea why these are so different?

[Manni]

That's exactly what I thought and saw with color picker - MadVR seems to be pushing blue.  Everyone at AVS seems to think I'm nuts / blind....

You posted screenshots at AVSForum and we told you what we saw. On my LG 4K monitor here set to rec-709, as well as on the 4K display of my Dell XPS 17, I see the JRVR picture yellow/brown, and the snow in madVR white. I have 15 years of experience calibrating, and I can usually spot a wrong white balance on a calibrated display.

I posted to defend JRVR on a few occasions in the AVS thread when I thought it was being misrepresented or unfairly evaluated. I would do the same for madVR.

I don't see any white balance issue with madVR set up properly on a calibrated NZ8 (P3, D65, gamma 2.4, using a C6 profiled to an i1pro2). I'll check that specific shot with JRVR when I find the time, but there is no need to make it sound like it's "us against them".

You're also using non-optional madVR settings and your display is uncalibrated.

Comparing tonemapping with random settings on an uncalibrated display is only saying what looks nicer to you.

I only stepped in briefly to defend JRVR again and explain that settings in JRVR (especially curve selection, gamut mapping and contrast) can have a significant impact on the final picture as well (just like with madVR). Some of the minor clipping / loss of detail in your JRVR shots could be due to poor settings in JRVR, especially re contrast enhancement or the spline contrast settings if you select spline manually.

haasn would need to look at the colors in the original HDR stream as well. It's snow. What tells you that snow/ice couldn't have some blue in the original content? I think you used the 1,000nits version. Please confirm so that Haasn can check in the same stream.

haasn, please could you look in the latest S&M UHD bluray disk (2nd edition from, 2023, there were some issues in the first edition) and see if there is blue in the original content as well?

In this case madVR would be correct and JRVR would be wrong.

I haven't evaluated JRVR properly yet, only selected the most appropriate settings in my case, and I reported that it looked very promising and that the progress in MC31 was impressive.

[FenceMan]

I was coming back here to post that the SDR shot Haasn posted looks more like MadVR to me.

I don't understand what the calibration of my monitor has to do with anything (my projector is perfectly calibrated).  I just posted color picker shots that show that MadVR has a bluer look to it - I cannot say enough times that I do not know if one is right or one is wrong I am just trying to point out that there is a difference.  One of the pictures is measurably bluer than the other.  I am trying to figure out why they are so different.

[Manni]

The screenshots have to be compared to the original content. Please confirm which version of the clip you're looking at, so that Haasn can check what the colorpicker says when looking at the original frames in the S&M UHD disc (preferably the latest 2023 edition as there were issues in the first one, according to Stacey himself).

[FenceMan]

I showed some friends of mine who described it just as you do - the blue one looks white and the white one looks yellowish.  I am just trying to understand why that is happening because I am very curious why there is such a stark difference in the two softwares.  I posted a dropbox link to the source earlier - I don't know which version this is as its part of an overall test suite that someone else posted (folder is labeled madvr and has a bunch of test scenes in it).

[Manni]

Look at both with the correct settings on a calibrated display, and let us know if there are still differences. If there are, compare to the original content on the disk. A renderer isn't supposed to correct anything. It's supposed to render what's on the disk as faithfully as possible.

On a calibrated JVC NZ8 (P3, D65, gamma 2.4) I don't see any issue with white balance using madVR with the correct settings. I haven't looked at JRVR in detail yet, but I didn't see anything obviously wrong either once the levels issue was resolved and once I manually selected optimal settings for my situation (100nits peak).

[JimH]

I just spent ten minutes removing some personal remarks above.  I tried not to remove any substance.

Best just to avoid such remarks.

[haasn]

I gathered the following clips in my testing. For the purposes of evaluation, I'm sampling the average of a big (200x200) box near the bottom left corner. For the "HDR" source, I took the 1000 nits clip and linearly scaled it down to SDR range using the "linearlight" tone-mapping function.

SDR horses, BT.709 gamut: 218/218/226 = 3.669% blue boost
SDR horses, BT.2020 gamut: 237/237/242 (*using the BT.2020 SDR source) = 2.1097% blue boost
HDR horses, BT.2020 gamut: 222/222/229 = 3.1531% blue boost
HDR horses, BT.709 gamut (perceptual): 229/229/232 = 1.31% blue boost
HDR horses, BT.709 gamut (softsaturation): 229/229/237 = 3.4935% blue boost

So my findings confirm that the current "perceptual" mode reduces blue saturation, which is not surprising given the design of perceptual is *intended* to reduce saturation of highlights. However, it's still significantly more blue than white on my end, and definitely not yellow. I'm not sure how you produced the screenshot above, my methodology was to load the S&M 1000 nits source frame and show it in plplay, with the target black level override set to 0 and the tone-mapping forced to "linearlight" to try and minimize the effects of tone mapping on the output.

Note that I also included in my above test the "softsaturation" mode, which I'm currently in the progress of working on (and which will become the new "perceptual" default when it's done, hence the confusing filenames / settings in the screenshot)

[FenceMan]

I gathered the following clips in my testing. For the purposes of evaluation, I'm sampling the average of a big (200x200) box near the bottom left corner. For the "HDR" source, I took the 1000 nits clip and linearly scaled it down to SDR range using the "linearlight" tone-mapping function.

SDR horses, BT.709 gamut: 218/218/226 = 3.669% blue boost
SDR horses, BT.2020 gamut: 237/237/242 (*using the BT.2020 SDR source) = 2.1097% blue boost
HDR horses, BT.2020 gamut: 222/222/229 = 3.1531% blue boost
HDR horses, BT.709 gamut (perceptual): 229/229/232 = 1.31% blue boost
HDR horses, BT.709 gamut (softsaturation): 229/229/237 = 3.4935% blue boost

So my findings confirm that the current "perceptual" mode reduces blue saturation, which is not surprising given the design of perceptual is *intended* to reduce saturation of highlights. However, it's still significantly more blue than white on my end, and definitely not yellow. I'm not sure how you produced the screenshot above, my methodology was to load the S&M 1000 nits source frame and show it in plplay, with the target black level override set to 0 and the tone-mapping forced to "linearlight" to try and minimize the effects of tone mapping on the output.

Note that I also included in my above test the "softsaturation" mode, which I'm currently in the progress of working on (and which will become the new "perceptual" default when it's done, hence the confusing filenames / settings in the screenshot)

Awesome thank you.  Obviously your methodology is going to be correct all I was wondering is why the difference.  So you are saying that the snow started blueish and JRVR is desaturating too much and you are working on improving?  This is very appreciated thank you.

[haasn]

On a side note, from a glance at these screenshots (and measuring pixel values) it's quite obvious that the left half of the scene is significantly more blue than the right half. So by putting your JRVR comparison on the right half it exaggerates the effect.

[FenceMan]

On a side note, from a glance at these screenshots (and measuring pixel values) it's quite obvious that the left half of the scene is significantly more blue than the right half. So by putting your JRVR comparison on the right half it exaggerates the effect.

Yeah the difference is not very noticeable until they are side by side then all of a sudden it looks drastic.

[haasn]

By the way, here is HSV sweep under the new "perceptual" mapping mode. I think your scopes will like this one

[jmone]

Nice!

[mattkhan]

for me, comparing jrvr & madvr (latest, 169) both converting to p3 and both using the same lut, jrvr looks a bit blown out

[FenceMan]

These were just quick tests I put up JRVR side by side on my screen with MadVR using more of those S&M test clips.

I thought these were a little lacking in blue also so good bet these will improve also.

[Manni]

I gathered the following clips in my testing. For the purposes of evaluation, I'm sampling the average of a big (200x200) box near the bottom left corner. For the "HDR" source, I took the 1000 nits clip and linearly scaled it down to SDR range using the "linearlight" tone-mapping function.

SDR horses, BT.709 gamut: 218/218/226 = 3.669% blue boost
SDR horses, BT.2020 gamut: 237/237/242 (*using the BT.2020 SDR source) = 2.1097% blue boost
HDR horses, BT.2020 gamut: 222/222/229 = 3.1531% blue boost
HDR horses, BT.709 gamut (perceptual): 229/229/232 = 1.31% blue boost
HDR horses, BT.709 gamut (softsaturation): 229/229/237 = 3.4935% blue boost

So my findings confirm that the current "perceptual" mode reduces blue saturation, which is not surprising given the design of perceptual is *intended* to reduce saturation of highlights. However, it's still significantly more blue than white on my end, and definitely not yellow. I'm not sure how you produced the screenshot above, my methodology was to load the S&M 1000 nits source frame and show it in plplay, with the target black level override set to 0 and the tone-mapping forced to "linearlight" to try and minimize the effects of tone mapping on the output.

Note that I also included in my above test the "softsaturation" mode, which I'm currently in the progress of working on (and which will become the new "perceptual" default when it's done, hence the confusing filenames / settings in the screenshot)

Thanks for taking the time to look into the content. It's the only way to figure out which renderer is closer to the "truth". Glad to hear that softsaturation is expected to improve things. I'll wait for it to be implemented in JRVR before doing a deep dive.

[haasn]

Pushed a new version of libplacebo (v6.292.1) with the new gamut mapping implemented; should hopefully hit a JRVR build soon

[Audionut11]

That is exactly what the perceptual mode is designed to do. It's just not that easy because you may have out-of-gamut values either as a result of bad mastering or (more likely) as a result of tone mapping, so you need some additional headroom.

Would there be a benefit then, to somehow being able to scan the video to determine if there are any out-of-gamut values? Any video without out-of-gamut issues could then be processed without the resulting headroom issues.

[haasn]

Would there be a benefit then, to somehow being able to scan the video to determine if there are any out-of-gamut values? Any video without out-of-gamut issues could then be processed without the resulting headroom issues.

The quote you replied to is out of date. The tone-mapping was fixed to never produce out-of-gamut values. That said, dynamic scene analysis would definitely be interesting. But, 3DLUT generation is slow. Very slow. So updating the 3DLUT in realtime will be too slow even if we can measure a gamut estimate.

[Audionut11]

The quote you replied to is out of date. The tone-mapping was fixed to never produce out-of-gamut values.

I was thinking more of potential bad mastering errors I guess, and was hinting at scanning (and tagging/whatever) the files in advance, to determine whether or not 'headroom' is needed, thus negating the need to map (0, 0, 1) input to (0, 0, 0.8 ) output. Color science makes my head hurt.

[FenceMan]

Here is an interesting compare, I guess this is JRVR desaturating too much again?  The opening behind Sidious seems to have more color in the MadVR one.  Let me state clearly I do not know if one is right or wrong just saying they are different (not even allowed to discuss at AVS apparently).  I will test this shot with new gamut mapping once available.

[haasn]

If you can dump me a raw hevc frame (+ whatever settings are relevant for your display configuration) I can show you what it looks like with the new gamut mapping

[FenceMan]

If you can dump me a raw hevc frame (+ whatever settings are relevant for your display configuration) I can show you what it looks like with the new gamut mapping

Those are both with same 3dlut specific to my display so probably wouldn't be a good comparison.  I will capture same frame once JRVR is updated.

[FenceMan]

Here is another screen that seems to show different colors, this time I extracted from source file if you want to see what the new gamut mapping does.  Is this same too much desaturation issue?

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=353186f0-36b5-11ee-b5bd-6595d9b17862

Source - https://www.dropbox.com/scl/fi/09isqkg0vr3bulpvahf2p/output.mkv?rlkey=heg5os0kuopl6307q3wncdcpo&dl=0

[Hendrik]

Build 43 is available here now, which includes the new libplacebo gamut mapping:
https://yabb.jriver.com/interact/index.php/topic,136749.0.html

[FenceMan]

Well it "fixed" the Lord Sidious shot there is now some blue in the opening behind him.  The horses snow also has a bit of blue tinge to it now.  The First Purge shot I did doesn't seem to have changed which is welcome because that is an example of why I think JRVR looks more alive than MadVR.  I will watch some films this weekend but at first glance looks like a welcome improvment.

[mattkhan]

I was trying, and failing, to find a test pattern that shows this

Overall the main negative thing I notice about jrvr now (tone mapping to 100nits dci-p3) is that brighter areas look blown out (lack fine detail or are notably brighter than other areas).

[FenceMan]

I was trying, and failing, to find a test pattern that shows this

Overall the main negative thing I notice about jrvr now (tone mapping to 100nits dci-p3) is that brighter areas look blown out (lack fine detail or are notably brighter than other areas).

This is interesting and I agree with what you are saying so I did a couple of comparisions.

Source is this HDR Grayscale - https://www.dropbox.com/scl/fi/83p7sl4rwsxk2d8sx8oe3/greyscale.mkv?rlkey=oxl2ka2sr3b6y6hew8o51ir96&dl=0

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=91104c98-3ddd-11ee-b5bd-6595d9b17862

I then checked the standard AVS709 black level pattern just to verify I don't have a mismatch or something -

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=8e591a5c-3ddd-11ee-b5bd-6595d9b17862

Not sure what to make of this, do I have a setting wrong somewhere?

They are vastly different at every single step, at least on my system.  JRVR looks like a brighter shade of gray at every step except pure white where MadVR looks brighter.