Print

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

[Manni]

Hi there,

I see that this feature is experimental, and I was wondering if devs were still working on the current implementation, or if there is a thread discussing this already (I couldn't find any).

At the moment, I can't really use this because it looks like the software expects a single 3D LUT for all content.

I guess this can work with a projector if you tonemap HDR to SDR and don't mind throwing away contrast, but most people will need at least the following:

- a 3D LUT for SDR content that targets Rec-709 / Power gamma 2.x (or BT1886) with a peak white around 50-200nits depending on PJ/display/personal preference. I target 100nits for SDR with my 77" QD OLED.
- A passthrough mode for HDR that doesn't use any LUT and simply passes HDR content to the display. In that case the 3D LUT is only used for SDR content.
- Ideally, an option for a separate 3D LUT for HDR content that calibrates the HDR mode of the display to a specific gamut/PQ peak with static tonemapping (for example I target Rec-2020 / PQ 1,200nits peak for HDR). In that case, we would have two 3D LUTs, one for SDR content, the other for HDR content, each being selected automatically according to content, as the display will switch automatically between two different modes (SDR/HDR). Not sure how this would work though and if it's even possible with HDR passthrough.

It's great that this feature supports madVR LUTs for compatibility, but what's missing is that we can only verify the calibration with JRiver using manual patterns, as JRiver has no pattern generator (that I know of) supported by calibration software. It's not really possible to assume that a LUT generated by madVR will measure the same when using JRiver. Have others done some tests and has this been established? Is it planned to create a pattern generator working along with this 3D LUT feature in order to facilitate profiling and verification?

Maybe I'm missing something, for example maybe we're supposed to use profiles in order to have different LUTs or calibration settings according to content (or maybe the LUT is only for SDR and is automatically disabled with HDR passthrough).

If this experimental feature is in active development, I'd be happy to do some testing once I understand better how it's supposed to work.

[mattkhan]

Yes you use different profiles to select different luts

As far as I can tell, the response is consistent with madvr and it does appear to work as intended if you use the right settings.

I have previously requested a pattern generator API but that has not been implemented as yet. This is in one of the jrvr threats I think but would have to search to find that

The way I went about it is but exactly straightforward but I will post it anyway

* Wrote scripts that can convert a displaycsl patch set into a video of still frames (each patch is a predefined length) containing those patches in the specified order

* Forked the latest displaycsl (python 3 version,) and extended it's manual mode to integrate with MC via mcws so that it plays that video in full screen and advances the video to the right timestamp to show the specified pattern

With this I can use displaycsl essentially as per madtpg for profiling and verification purposes

Clearly it would be massively more convenient to just have an API to drive, I think I also suggested writing some bridge process that could then advertise this via the madvr network protocol which then make it compatible with anything that can talk to madtpg. For me, this is the best way forward (and the latter bit doesn't need to be built in house even, it just needs the pattern generator API).

I can explain how to get my process up and running if you like. It's not exactly trivial to operate but was only way I could see to use it.

[mattkhan]

One thing to note.... Once I got to the point where I believed I had verified that jrvr was consistent with madvr when using a madvr format 3dlut generated by displaycal then I reverted to using madtpg as the above process is a bit brittle (managing MC window state automatically is not bullet proof and neither is the associated displaycal tool) compared to madtpg. Verification was to the best of my ability/knowledge so take with as small or large a pinch of salt as you deem necessary!

[Manni]

Thanks a lot for the explanations above, much appreciated.

I agree 100% that compatibility with madTPG at API is the best way forward, as there is very little chance to get Portrait Display to support this in Calman now that they have the G1, or to get Steve to add it in Colorspace. It might be done by the community for HCFR or DisplayCAL, but I don't use these.

I won't be using profiles either as I'm not sure how I would trigger them (I use BD Folders for all my content).

I also won't use your method for profiling/verification, it's too involved for me

So hopefully at some point this madTPG API compatibility will be implemented, and there will be a way to assign a different LUT (or no LUT) according to content.

The easiest way to do this would be to disable the LUT when using HDR passthrough, if that isn't done already. That way we could at least use a 3D LUT for SDR and no LUT for HDR.

Thanks also for confirming that a madVR LUT behaves the same in JRiver after verification, I really didn't feel like going back to manual patterns to verify that (though I'll probably will the first time I use this, when I do).

[Hendrik]

and there will be a way to assign a different LUT (or no LUT) according to content.

Profiles are the way designed to do this. Not planning on anything else.

3DLUTs are not currently used with HDR output, though.

[Manni]

Profiles are the way designed to do this. Not planning on anything else.

Hi Hendrik,

Even simply specify two LUTs, one for rec-709 content, one for BT2020 content, as is the case for madVR? That would be enough.

Please could you confirm what the current behaviour is when HDR passthough is selected. Is the 3D LUT disabled in that case?

What about implenting compatibility with the madVR API for profiling / verification?

[mattkhan]

There is a command to activate a profile manually now so it's feasible to automate it using an external remote control (not sure if feasible for you but certainly technically possible)

[Hendrik]

Even simply specify two LUTs, one for rec-709 content, one for BT2020 content, as is the case for madVR? That would be enough.

You can simply create a second profile with the second LUT, the system is designed flexibly to avoid a lot of special "simple" cases (which are different for everyone).

https://yabb.jriver.com/interact/index.php/topic,133480.0.html
Its not super complicated, just copy the default profile, setup a rule for something like [JRVR Video Gamut]=bt2020 - and off you go

Please could you confirm what the current behaviour is when HDR passthough is selected. Is the 3D LUT disabled in that case?

3DLUT is disabled for HDR output currently.

What about implenting compatibility with the madVR API for profiling / verification?

We cannot support a madVR API.
Maybe we can offer our own test-pattern generation through MCWS at some point.

[Manni]

Great thanks for the clarification. If the 3D LUT is disabled for HDR I'll simply use the SDR LUT for now.

[Manni]

I'm now using a rec-709 gamma 2.4 3D LUT in JRiver and all seems fine. My TV (Samsung S90C) is quite accurate after manual calibration so the difference isn't huge.

Questions:

1) Is there a way to see that the 3D LUT is enabled? There doesn't seem to be any info related to the 3D LUT in the OSD. If there is no way to display this info currently, it would be great to add it to the OSD (3D LUT: filename for example).
2) Is there a way to enable / disable the 3D LUT on-the-fly, as in madVR, with a hotkey (I use CTRL-SHIFT-3 in madVR)? A split-screen would be great too, to show the difference between LUT on and LUT off.
3) Assuming the LUT is active in SDR, it doesn't seem to be active in HDR passthrough, so all seems to be working as expected.

Thanks!