madVR - high quality video renderer (GPU assisted)

[SirMaster]

Originally Posted by shaolin95

All reviews/test I have seen of the JVC RS520 puts it at about 97% of DCI-P3.
For example: "After calibration this RS520 was covering 97% of the DCI-P3 color gamut. With some extra calibration work, this RS520 could potentially get more coverage but it would be at the expense of color accuracy."

It has some special filter that helps with that.
I will try that first and see how it looks.
Thanks

Yes DCI-P3 coverage is good, not BT.2020 which is what you said originally.

If you make a DCI-P3 3DLUT you should get good results. But a BT.2020 3DLUT will not yield good results as the coverage of that color gamut on the display is way too low.

[tp4tissue]

Originally Posted by SirMaster

Yes DCI-P3 coverage is good, not BT.2020 which is what you said originally.

If you make a DCI-P3 3DLUT you should get good results. But a BT.2020 3DLUT will not yield good results as the coverage of that color gamut on the display is way too low.

If you take a gamut map to HDR content, you will see that it pushes some coordinates outside the DCI-p3 spectrum.

It's not the file that's causing problems, it's how argyll cms compresses the gamuts into whatever gamut the tv has. It does a different operation between P3 / Rec2020 as the source colorspace.

Depending on the movie, this may or may not work well. It's at the whim of Argyll, and its algorithm's interplay with the primaries of the TV.

You need both.

[shaolin95]

Originally Posted by tp4tissue

If you take a gamut map to HDR content, you will see that it pushes some coordinates outside the DCI-p3 spectrum.

It's not the file that's causing problems, it's how argyll cms compresses the gamuts into whatever gamut the tv has. It does a different operation between P3 / Rec2020 as the source colorspace.

Depending on the movie, this may or may not work well. It's at the whim of Argyll, and its algorithm's interplay with the primaries of the TV.

You need both.

So now I am confused if I should do 3Dlut for dcp , rec709 or just use my projector with the 2020 color space as it looks darn good to me eyes already 😁

[tp4tissue]

Originally Posted by shaolin95

So now I am confused if I should do 3Dlut for dcp , rec709 or just use my projector with the 2020 color space as it looks darn good to me eyes already 😁

All 3, and under each 3 you would also create ones with other rendering intent such as colorimeteric, preserve saturation, saturation.

So, in total, probably 12-15 different luts that you play with depending on the movie.

This is all created from the same set of measurements, so you only need to measure once. < assuming you set these settings correctly >

None of them will look-bad, but for example one lut might push red into an orange/pink area (depending on the primary of the device). and you'd need a different lut which doesn't do that.

This is a long chain of color-interplay between file, cms, lut intent, madvr.

There's no one size fits all. It might work on someone else's tv, but not yours.

[shaolin95]

Originally Posted by THU22

This is what you need to do in CRU, it is very simple. Make sure you export the original EDID first, in case you mess something up.

You can basically delete everything in "Detailed resolutions" and add the ones you need. You should only have two or three in there (but even the third one might not work sometimes). Most of common resolutions are stored in the extension blocks, so you will not lose anything by doing this. Resolutions you add here will appear as PC resolutions in the nvidia control panel.
23.975 works best in my case, it could be different in yours. Experiment.

12-bit works with this method, unlike custom resolution in the nvidia control panel.

Looks like my projector is picky about the settings but finally found settings that worked and now playing star Wars was showing between 1.80 and 2 hours for repeated frames and 23.975... etc so I am very happy already. ��


Now on some possible less exciting news I also found this piece of intriguing information from a poster on avsforum:
"Quick notes for nVidia HTPC/MadVR users [others please skip]: the magenta bug present on the rs500 at 4K60 8bits in 385.28 and for all 8bits resolutions in all recent drivers including the latest is gone, which is great news. This means 8bits becomes usable, and leaving MadVR dither to 8bits might be a better option than forcing 12bits out because levels are still borked in 12bits with recent drivers. [EDIT 01/03/19: I found the reason for this: there is a bug in the new models that force YCC422 behind madVR's back when RGB 12bits is selected in the nVidia CP. The driver sends RGB 12bits, the JVC reports RGB 12bits, but in reality it's forcing YCC422. JVC knows about the bug, so hopefully they will fix it in an upcoming f/w update]."

It is a post from last year...guess I need to figure out a way to test if this affects my projector. I hope not as he said new models and his post is from 2019 so maybe mine is not affected. Any suggestions where to see this issue more easily?

[SirMaster]

Originally Posted by tp4tissue

If you take a gamut map to HDR content, you will see that it pushes some coordinates outside the DCI-p3 spectrum.

It's not the file that's causing problems, it's how argyll cms compresses the gamuts into whatever gamut the tv has. It does a different operation between P3 / Rec2020 as the source colorspace.

Depending on the movie, this may or may not work well. It's at the whim of Argyll, and its algorithm's interplay with the primaries of the TV.

You need both.

Honestly I don't think anyone should be making a 3DLUT where the source color space is BT.2020 since no display comes close to reaching BT.2020.

I have tried making dozens of 3DLUTS for BT.2020 and every single one ends up with posterization near the gamut limits.

And for rendering intent, if you are trying to make a 3DLUT for a gamut that is wider than your display, the only ones that yield good results are the default "Absolute colorimetric with white point scaling" or maybe "Luminance matched appearance"

All the others are bad and lead to shrinking the native gamut even more and colors being much farther off.

Here is a measurement I took of what the 3DLUT does with 6 of the rendering intents for a display that cannot reach P3. Clearly the "Absolute colorimetric with white point scaling" is the best.

https://slow.pics/c/mldFlPW3

But unless your display can come within 10% of the native gamut you are targeting I would't target that gamut and would drop down to the lower one. Like if you are above 90% P3 then with enough patches you can get a result that's largely posterization free, otherwise if you are less than 90% then I wouldn't bother with P3 and would just stick to rec709.

And again I don't think anyone should be trying to target BT.2020 as that always leads to a lot of posterization no matter which rendering intent I used and for which display I tried making the 3DLUT for.

[tp4tissue]

Originally Posted by SirMaster

I have tried making dozens of 3DLUTS for BT.2020 and every single one ends up with posterization near the gamut limits.

The posterization is SPECIFIC to each display, resultant of argyll's algorithm's interplay with the gamut.

It has NOTHING to do with specific underpinnings of rec2020 or dci p3.

It's not resultant of the size of the gamut.

On one of my displays, I get posterization on Red while setting dcip3 as source, while rec2020 doesn't have this problem.


You can fix this to some degree just by moving your primaries in the tv's cms a little left or right. But overcorrection might cause issues of its own. So In general, steer clear of tv / monitor CMS except for the tone curve.

You're also wrong about rendering intent.

Colorimetric w/ white point scaling actually shrinks the gamut the most. because it cuts off earlier along the primaries to preserve accuracy over saturation. But again, this depends on where the primaries are. it may not behave this way for all situations.

Preserve saturation, and saturation, gives you the widest use of the gamut, but can be oversaturated.

[omarank]

Originally Posted by SirMaster

I don't think anyone should be trying to target BT.2020 as that always leads to a lot of posterization no matter which rendering intent I used and for which display I tried making the 3DLUT for.

Argyll or some color engines may cause LUT issues when directly targeting BT.2020, especially when the display's gamut is close to or smaller than DCI-P3. But technically, it is possible to create a BT.2020 LUT for such displays that is free of artifacts or has least amount of artifacts. I don't agree with the general advice to not create BT.2020 LUTs for BT.2020 HDR content.

@SirMaster: Can you share your display characterization data (the display profile), for which you were not able to get a good BT.2020 HDR to SDR LUT?

[omarank]

Originally Posted by tp4tissue

You're also wrong about rendering intent.

Colorimetric w/ white point scaling actually shrinks the gamut the most. because it cuts off earlier along the primaries to preserve accuracy over saturation. But again, this depends on where the primaries are. it may not behave this way for all situations.

Preserve saturation, and saturation, gives you the widest use of the gamut, but can be oversaturated.

Saturation intent (and also Perceptual intent) should not be used for Display Calibration 3DLUTs. Absolute Colorimetric with white point scaling (-iaw) and Relative Colorimetric (-ir) are the only recommended rendering intents here. The latter is normally used when the display contrast is already low and you don't want to reduce it further in correcting the white point. In most other cases, the former should be used.

[SirMaster]

Originally Posted by tp4tissue

You're also wrong about rendering intent.

Colorimetric w/ white point scaling actually shrinks the gamut the most. because it cuts off earlier along the primaries to preserve accuracy over saturation. But again, this depends on where the primaries are. it may not behave this way for all situations.

I'm not sure how you can say this is wrong. I attached my actual measurements of this and "Absolute colorimetric with white point scaling" is the widest gamut result.

I have done this on my computer monitors, TVs, and projectors all with the same result.

Sure I cannot say it will be this way for every monitor because I cannot test every monitor. But every display I have generated 3DLUTs for and where I have tried multiple rendering intents have ended up this way.

"Absolute colorimetric with white point scaling" has simply always led me to the best results that I see after verifying the LUT no matter what displays I have calibrated so far. Unless I am doing something very wrong.

I am definitely open for learning. I just write about what I have found based on my own experiences with the software and the process.

[SirMaster]

Originally Posted by omarank

Argyll or some color engines may cause LUT issues when directly targeting BT.2020, especially when the display's gamut is close to or smaller than DCI-P3. But technically, it is possible to create a BT.2020 LUT for such displays that is free of artifacts or has least amount of artifacts. I don't agree with the general advice to not create BT.2020 LUTs for BT.2020 HDR content.

@SirMaster: Can you share your display characterization data (the display profile), for which you were not able to get a good BT.2020 HDR to SDR LUT?

I only happen to have files from one display handy.

https://nicko88.com/misc/NX5_gamut/

The DCI-P3 LUT causes a very, very tiny amount of posterization, small enough to not really notice normally.

The BT.2020 one causes pretty massive posterization that can't be ignored IMO.

But I saw this same phenomenon making a DCI-P3 3DLUT on one of my computer monitors which has just slightly more than rec709 and not near full P3 gamut (it's the display that was shown in my 6 screenshot measurements earlier).

Same thing on my Samsung TV that has near full P3 coverage when I tried a BT.2020 LUT.

If there is a way to make a 3DLUT with ArgyIICMS targeting a gamut that is substantially wider than the display's native gamut and there to be no noticeable posterization then I guess I just don't know how to achieve such results. It's the only result I have ever seen on a multitude of displays that I have generated LUTs for. And I have tried all the rendering intents. I am not sure what else I can adjust.

But when I target a gamut that is smaller than the display's native or only slightly larger then the results have always been fine.

[shaolin95]

All this conversation and different opinions on what is wrong or right for 3D Lut, its making me think I am just going to switch to 2020 as it is in my projector and enjoy my movies

[tp4tissue]

Originally Posted by shaolin95

All this conversation and different opinions on what is wrong or right for 3D Lut, its making me think I am just going to switch to 2020 as it is in my projector and enjoy my movies

Your projector is not rec 2020. it has its own way of mapping a rec2020 Container (from file) onto whatever gamut it does have, which is something closer to DCI-P3.

The reason we get posterization from argyll cms is when its gamut compression engine fails. This failure can be the result of many things in the chain not necessarily always the same.

This compression failure is also not simply the result of how big or small the gamut is.

I have SDR displays using a p3 and rec2020 lut, It's only 76% dci p3 and yet NO Posterization.

Smaster's observation of getting posterization tuning for rec2020 is TRUE for HIS DISPLAY. It is NOT_TRUE for all displays. Again, it's not due to how big the gamut is, it's how closely aligned the primaries are to the source color space, and the various interplays of the display chain. We have multiple devices with multiple maps.

[shaolin95]

Originally Posted by tp4tissue

Your projector is not rec 2020. it has its own way of mapping a rec2020 Container (from file) onto whatever gamut it does have, which is something closer to DCI-P3.

The reason we get posterization from argyll cms is when its gamut compression engine fails. This failure can be the result of many things in the chain not necessarily always the same.

This compression failure is also not simply the result of how big or small the gamut is.

I have SDR displays using a p3 and rec2020 lut, It's only 76% dci p3 and yet NO Posterization.

Smaster's observation of getting posterization tuning for rec2020 is TRUE for HIS DISPLAY. It is NOT_TRUE for all displays. Again, it's not due to how big the gamut is, it's how closely aligned the primaries are to the source color space, and the various interplays of the display chain. We have multiple devices with multiple maps.

Yeah I read that it may do like 80% of 2020 vs almost 100% for DCI P3.
So if if it was you, how would you calibrate it for 4k movies?

[brazen1]

Originally Posted by huhn

queues are not supposed to cost performance just Vram and as long as there is enough Vram this is free.

if you think RCA is ot free as it should be please make a a screen of the OSD with it and without it.

Sure. Here's with and without denoising activated and the setting for 'activate only if it comes for free (as part of NGU sharp' is also ticked.
Clearly you see denoise in the stats chewing up 17.02ms and pushing me way over the edge.
Fwiw, turning off supersampling doesn't improve anything. This is SDR. HDR is even worse. What am I doing wrong? Thanks.

https://i.imgur.com/smDH8yK.png



https://i.imgur.com/3X9N5BW.png

[tp4tissue]

Originally Posted by shaolin95

Yeah I read that it may do like 80% of 2020 vs almost 100% for DCI P3.
So if if it was you, how would you calibrate it for 4k movies?

Do BOTH, and look for anomalies in saturated areas. Try various rendering intents as well, you may like preserve saturation and saturation for certain movies.

[SirMaster]

Originally Posted by tp4tissue

Smaster's observation of getting posterization tuning for rec2020 is TRUE for HIS DISPLAY. It is NOT_TRUE for all displays.

Well for what it's worth in this case, shaolin95 is using a JVC as am I which use the same bulb and similar LCoS panels.

So I think there is good chance he runs into a similar issue. Something to look out for at least.

Many of us over on AV Science forum JVC calibration thread are noting the posterization with 3DLUT for BT.2020 on all our JVC projectors, but it'd fine when targeting DCI-P3.

I have seen it on other displays, but seems particularly bad on JVCs in general.

[shaolin95]

Originally Posted by tp4tissue

Do BOTH, and look for anomalies in saturated areas. Try various rendering intents as well, you may like preserve saturation and saturation for certain movies.

Ok I am planning to work on that tonight with DisplayCAl as I suppose it my best option.

Silly question, when interpreting stats in terms of rendering and max, what is a "safe" number to see there? I am leaving a movie running now to see in 2 hours what kind of drops if any I get. It is showing like 5 hours for repeated frames, so I don't expect any issues but just in case

UPDATE:
Finished the 2.5 hour movie with one frame repeated. It was showing 5 hours but still repeated 1..guess it not a big deal much better than my starting point of repeating a frame every 30s

[shaolin95]

Originally Posted by SirMaster

Well for what it's worth in this case, shaolin95 is using a JVC as am I which use the same bulb and similar LCoS panels.

So I think there is good chance he runs into a similar issue. Something to look out for at least.

Many of us over on AV Science forum JVC calibration thread are noting the posterization with 3DLUT for BT.2020 on all our JVC projectors, but it'd fine when targeting DCI-P3.

I have seen it on other displays, but seems particularly bad on JVCs in general.

Good to know. I didn't realize you have a JVC. Thanks

[THU22]

Originally Posted by shaolin95

Finished the 2.5 hour movie with one frame repeated. It was showing 5 hours but still repeated 1..guess it not a big deal much better than my starting point of repeating a frame every 30s

So what did you set exactly to achieve this result?