More > JRiver Media Center 32 for Windows

3D LUT Calibration with JRiver

(1/3) > >>

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:

--- Quote from: Manni on May 24, 2024, 05:25:43 am ---and there will be a way to assign a different LUT (or no LUT) according to content.

--- End quote ---

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

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

Navigation

[0] Message Index

[#] Next page