Print

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

[afss_br]

Hello, I have a JVC projector which allows me to manually chose BT.2020 or BT.709 as source signal colorspace. I noticed when there is a colorspace conversion being done by the media player there color errors (sometimes oversaturated and sometimes washed out).

For instance, if I define JRiver output as BT.2020 and the source file being played is BT.709, there is a forced BT.709 to BT.2020 conversion going on that messes up colors on my display (with the proper BT.2020 selection). Comparing the native BT.709 souce with a matched display BT.709 setup, I get much better results.

Please would you consider creating an option within the JRVR/Output/Calibration/Screen Gamut dropdown menu for NATIVE (the current options are Auto, BT.709, BT.2020 SMPTE, PAL, DCI-P3). In other words, what I am proposing is for the output signal colorspace to just match the source material colorspace. I would still like all HDR Tone Mapping capabilities to take place with BT.2020, but WITHOUT colorspace conversions if the source file is BT.709 (not HDR).

[mattkhan]

What HDR content do you have that is in rec709?

Something is wrong somewhere though as converting rec709 to bt2020 shouldn't look strange (doesn't here, also with a JVC projector)

[Hendrik]

Since JRVR is not capable of communicating which colorspace is being used to your display, this mode would result in bad output unless you manually intervene everytime you start a new file - which is anything but comfortable.

If you really want something like this, thats what profiles are for. You can make one based on the video gamut and then adjust the output gamut accordingly.

[jmone]

Matt is right, 709 should look fine in 2020.  I also have a JVC, but will need to check.  If (for whatever reason) you do want to do the manual swap at the JVC end, Hendrik is also right in that you can setup Profiles for all sorts of combos including Colour Space (which is the name of the field in MC for this).  You can do the same for Interlaced, various resolutions etc etc.  Profiles are very powerful for those that want to dial in settings for various attributes.

[mattkhan]

if you do want to use profiles, the jrvr specific fields are listed in https://yabb.jriver.com/interact/index.php/topic,133480.msg924609.html#msg924609 otherwise make sure you run video analysis and then use the fields that produces

[afss_br]

Thank you all for your replies ! I will try the profile option as it sounds like would do the job for me.

For those who own JVC projetors, please try the following:

1) Play a BT.709 file, while having Media Center set as BT.2020 output, having the projector also set to BT.2020 color profile - play a colorful video with lots of REDs. If possible take a picture of a colorful scene.

2) Change Media Center to output BT.709 (of course, also change the JVC color profile to match BT.709) and repeat the playback of the same file. Watch for the colors, specially RED - if possible take a picture to compare with the previous one. I have a JVC RS540, and I find that colors look more vibrant and natural if the whole chain is BT.709.

[karmat63]

I have a related question;
my Epson 9400 VP has a relevant setting, I use for all video materials:
Digital Cinema; it has a color filter on the light path, and complete coverage for DCI P3 color gamut. Digital Cinema has 2 Color Space: BT.709 or BT.2020

With MadVr, I use BT.709 3DLUT for SDR and DCI P3 3DLUT for HDR (with tone mapping HDR to SDR). MadVR has a setting (report 2020 to display, for NVIDIA GPU), that, if checked, report the correct color space to the projector.
So, for SDR movie the projector engages BT.709 color space and, for HDR, BT.2020. And all works as it should, without any manual input.

I'm trying to do the same with JRVR (that, by the way, is now at least on par with MadVr, in terms of image quality), using profiles.
I've built two 3DLUT profiles for JRVR in .cube format, with DisplayCAL: BT.709 3DLUT for SDR and DCI P3 3DLUT.

Using 3DLUT in JRVR, "screen Gamut" settings are disabled (you can choose any color gamut, but they do nothing), but if you change the "3DLUT Gamut (source color space)" settings, the relevant gamut is passed to the display. So, for HDR movies, if I choose BT.2020 3DLUT Gamut (source color space), BT.2020 setting is engaged by the VP and everything is visually correct (similar to MadVR)
Anyway, I don't know if this is the correct setting, as I built the 3DLUT in DCI.P3. But, if I choose DCI.P3 Gamut, the colors look wrong both in BT2020 or BT.709 projector settings
Any input apprecciated.

[mattkhan]

if your projector expects 2020 then I would expect you to need to set screen gamut = 2020 but it's not clear whether jrvr supports this case (sending dci-p3 in a bt2020 container) so I think Hendrik has to comment on exactly how the source colourspace option is used & how it relates to the screen gamut, i.e. does it convert to screen gamut then apply a 3dlut on that or something else?

[karmat63]

The problem is that, using 3DLUT as calibration method, screen gamut settings are actually disabled: changing screen gamut, does nothing, no change at all. I don't know if it is a bug or if it is how is designed to work; the "correct" color gamut is reported to the display only changing gamut inside 3DLUT settings ("3DLUT Gamut (source colorspace)"). But, as you say, we don't know how it works: does it convert DCI.P3 to 2020 or does it send DCI.P3 inside a 2020 container (the second option would be the proper one, as no display is actually capable of 2020 coverage).
Thanks for your input!

[Hendrik]

When you use a 3DLUT, the 3DLUT controls the output color space, depending on the creation parameters of the 3DLUT itself. 3DLUT calibration tools should usually offer you a choice both for input and output colorspace for the 3DLUT (or output is measured with a meter).

[karmat63]

So, just trying to understand, if I profile a display that has a full DCI.P3 coverage, then I create a 3DLUT in 2020 color gamut.
I'm wrong or this is not optimal as the display is far from 2020 coverage? I've tried, and on verification, there are significant errors in color reproduction (DE > 4 in some patches)...

[mattkhan]

So if a 3DLUT is built in DCI.P3, the correct setting would be DCI.P3?

If this outputs dcip3 but your pj expects 2020 then I would expect it's going to be wrong

[karmat63]

I've corrected my answer, sorry...
I think you'right, but what is the solution?

[mattkhan]

You are correct in that creating such a lut can lead to errors

You need a way to let the lut not define the output colourspace basically or you need a way to transform your lut with another one that essentially fits it into bt2020. I am not aware of displaycal being able to do this. I think colourspace can (but that is ££££), probably Argyll can at the cli but I have no idea how to do that.

[Hendrik]

In general it is assumed that the LUT outputs pixel values that are designed for your monitor to display, so no further color processing is performed on them by JRVR. This allows you to actually create rather complex 3DLUTs, eg. some that not only correct, but also transform.

It would be possible to do further processing after, but I fear that might introduce a lot of complexity for very niche scenarios, when in reality the 3DLUT should probably be designed to just output the expected values.

[karmat63]

This is the answer of Florian Höch, the man behind DisplayCal, on this same matter:

https://hub.displaycal.net/forums/topic/question-about-bt-2020-3d-lut-generation/

Q: "Will generating a 3D LUT for BT.2020 be accurate when my display is limited to displaying DCI-P3? Anything higher than approximately70% saturation, depending on the color, will not be reproducible".

A: Yes. It should be of no real concern though (other than some of the patches being clipped to the same color by the display), as the profiler will figure out the limits of the display from the measurements anyway.

I think I will be ok with BT.2020 3DLUT, until something better will be implemented (P3 in BT.2020 container?). Thanks.

[mattkhan]

I don't think it's that small a niche given that relevant content and displays are all approximately DCI-P3 and not many displays have a DCI-P3 input mode so the audience is pretty much "anyone using a 3DLUT with tonemapped HDR (who isn't using a recent JVC projector)"

commentary from people who have tried this on avs says that it may be prone to posterisation errors but only you can find out whether that happens in your case and whether you notice it if it does

[Hendrik]

I don't think it's that small a niche given that relevant content and displays are all approximately DCI-P3 and not many displays have a DCI-P3 input mode so the audience is pretty much "anyone using a 3DLUT with tonemapped HDR (who isn't using a recent JVC projector)"

The real question then is why the 3DLUT creation tools don't have the ability to just make such files. It should be where this gets solved - make a 3DLUT that matches your output.
You are measuring and creating the 3DLUT in this output mode as well, aren't you? Or how do you measure a DCI-P3 LUT when your display chain is in BT.2020 mode?

[mattkhan]

The real question then is why the 3DLUT creation tools don't have the ability to just make such files. It should be where this gets solved - make a 3DLUT that matches your output.
You are measuring and creating the 3DLUT in this output mode as well, aren't you?

yes I agree but I guess madvr added this feature because the tools aren't generally available, I haven't looked in detail but i know the relevant colourspace licence is ~£2k for example so not really feasible for the home user

my projector has a DCI-P3 mode so the problem doesn't come up for me

[karmat63]

I don't think it's that small a niche given that relevant content and displays are all approximately DCI-P3 and not many displays have a DCI-P3 input mode so the audience is pretty much "anyone using a 3DLUT with tonemapped HDR (who isn't using a recent JVC projector)"

Was thinking the same...

commentary from people who have tried this on avs says that it may be prone to posterisation errors but only you can find out whether that happens in your case and whether you notice it if it does

I hope is a viable solution, otherwise there's always the solid, even if outdated, MadVR 113b...

[Hendrik]

I could add a simple checkbox to enable gamut processing after the 3DLUT ran, which would then obey the Screen Gamut option, and allow you to expand the signal to BT.2020 without changing the colors. This would only work if the 3DLUT has the same input and output gamut, but I assume this is the case for you.

What I still wonder however, how are you calibrating your screen to generate a DCI-P3 LUT if you cannot use a DCI-P3 display mode?

Re-reading parts of the thread, do note that JRVR has no equivalence of the "report 2020 to display, for NVIDIA GPU" option, because I generally feel a single-vendor specific option adds a lot of complexity with only limited use. And the Windows built-in option doing the same is non-functional.

[karmat63]

I simply put the display in BT.2020, run Diplaycal and profile, then choose DCI.P3 3dlut gamut.
Honestly, in last days I've compared MadVR  and JRVR running DCI.P3 3dlut derived from the same display profile, and they look visually the same (with small differences). Checking MadVR "report 2020 to display" automatically triggers the correct setting (2020) on the projector. In JRVR I'm doing it manually (setting "3Dlut gamut (source clorspace)" to DCI.P3).

[karmat63]

Maybe I can even create a BT.709 3dlut from the profile setting in 2020, so I can run everything in BT.2020 color space letting the 3dlut doing the relevant corrections... But I don't know if it works as it should...
I will test in next days

[karmat63]

I could add a simple checkbox to enable gamut processing after the 3DLUT ran, which would then obey the Screen Gamut option, and allow you to expand the signal to BT.2020 without changing the colors. This would only work if the 3DLUT has the same input and output gamut, but I assume this is the case for you.

This would be nice; should it work as P3 in 2020 gamut?

[jmone]

I would have thought the option of "P3 limited in 2020" would be the go.  This is how most (not all) UHD BD's are authored and most displays HDR capable displays will take a 2020 or 709 colour space.

[karmat63]

"P3 limited in 2020", sounds like the perfect solution.
Waiting for it... thanks.

[Hendrik]

I added these for a future build:

NEW: Added "DCI-P3-D65 in BT.2020" as a screen gamut configuration to JRVR.
NEW: JRVR can optionally process the gamut after applying a 3DLUT.
NEW: When performing HDR to HDR tone mapping, the gamut can be reduced to DCI-P3 in BT.2020.

Note that when applying a 3DLUT, I would not actually recommend to use the "DCI-P3-D65 in BT.2020" for your Screen Gamut setting, but rather just stick with plain BT.2020, as the 3DLUT may output colors ever so slightly outside of the DCI-P3 spectrum to match your screens behavior, and you don't want JRVR to change those again.

[jmone]

Fantastic Option!  This now means that for those of us with HDR displays that hit (around) P3, JRVR will map that 10% of HDR UHD BD's mastered above P3 down to P3 prior to hitting the displays (poor) gamut mapping!  The added benefit is that over time as displays continue to expand past P3 (some are now already P3 +15%) we can just change a setting in JRVR to full 2020 (or P3 "enhanced" or whaterer they call the next step up in colour space)!  Love it.

[karmat63]

NEW: Added "DCI-P3-D65 in BT.2020" as a screen gamut configuration to JRVR.
NEW: JRVR can optionally process the gamut after applying a 3DLUT.
NEW: When performing HDR to HDR tone mapping, the gamut can be reduced to DCI-P3 in BT.2020.

Note that when applying a 3DLUT, I would not actually recommend to use the "DCI-P3-D65 in BT.2020" for your Screen Gamut setting, but rather just stick with plain BT.2020, as the 3DLUT may output colors ever so slightly outside of the DCI-P3 spectrum to match your screens behavior, and you don't want JRVR to change those again.

I imagine that the screen gamut configuration won't be disabled anymore, using 3Dlut.
Fantastic option, for me (a maybe for many others) the last bit to leave MadVR behind. The actual implementation of 3Dlut HDR to SDR tonemapping is somewhat bugged in JRVR, as there is no option to report to display to use DCI-P3 inside BT.2020, and so a smaller gamut is inflated inside a much bigger one, with obvious oversaturation, expecially on skin tones (I've seen some have reported this problem, eventually related to color gamut mismatch).
Many many thanks.

[jmone]

OK - Split out the discussion on Inverse Tonemapping for SDR ---> HDR conversion https://yabb.jriver.com/interact/index.php/topic,136136.0.html