INTERACT FORUM

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

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.

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)

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?

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.

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

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!

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.

I request that the ability to turn pane tagging off all the time be added.
I have never nor will I ever will use it, and I am probably not the only one.
Right now, the only thing you can set it to is "keep it enabled".
Having those boxes pop up whenever you select a track or an album is VERY annoying.

Thank you for your time.

Under DLNA Controller Options for this renderer (right click menu), is "Disable SetNext Support" checked?

If it is uncheck it and try again.

tried both. same.