INTERACT FORUM

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.

Good call - I updated and am still experiencing this issue in 32.0.45 however.

So this is a simple question.

For a laptop that's not on a network, what remote can I use to control JR MC32?

And an unrelated followup if I may.... same Mc32 recently installed and I notice that Play Doctor is not available. How to enable in this feature?

TIA

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.

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

If it is uncheck it and try again.

Changed: Reverse Geocoding will use "municipality" for [City] field, if other elements ("city", "town", or "village") are not found.

Sounds good. I hadn't realised they had such granular breakdown. In my 'Boyland' example, the Scenic Rim regional information would have been very useful, so agree with this.

Propose: [City] amalgamates municipality, city, town, village in the form Municipality\City\Town\Village ?
If any empty, they are ignored. If any identical, they are not duplicated? Would this be doable?
This ensures all useful permutations of the info is available, and also nested with the highest 'region' information (below state/province) captured, and ability to expand to smaller areas.

How are you handling sublocation? I can see various fields of 'Street', 'suburb', 'amenity' etc

Could we agree on the hierarchical structure of these? With some fields consolidated in a [City] hierarchy (like above) and others in a[Sublocation] hierarchy.
The broader [Places] could either be a non-hierachical ; delimited list (ie no nesting or groupings)
....or a full [Country]\[State]\[City - Municipality\City\City district\Town\Village]\[Sublocation - Suburb\Road\Amenity\]

Any thoughts from others?

Sorry Marko, this won't line up with your nested keywords approach, but the with magic of MC expressions I'm sure you can migrate (in either direction) as you desire