Print

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

[mattkhan]

another request on 3D LUTs, can you support more lut formats over and above iridis cube? I can see displaycal supports this format which does make it accessible but comparing to https://www.lightillusion.com/colourspace.html (which is fairly commonly used home theatre calibration software), it only supports that format once you get to a pretty high end licence (>2k) and the home theatre editions only export the eeColor format.

I see that in https://github.com/haasn/libplacebo/issues/37#issuecomment-401597418 there is mention of providing converters though I can't find evidence that these actually exist

[mattkhan]

I was thinking about end user being able to calibrate easily and verify jrvr behaviour so was thinking in terms of madtpg like functionality along with something like the splitscreen (lut/no lut) view. I realise that depends on tool providers engaging but I guess you'd need some form of api for anyone to integrate with anyway, does such a thing exist?

thinking more about this, it does feel like a big gap for the videophile audience (who will tend to have calibration equipment and/or get someone in to calibrate for them). I think there are sufficient alternative ways to profile the display but being able to verify what JRVR actually displays would also be necessary I think for full confidence in what it's doing.

for example displaycal has an untethered mode https://displaycal.net/#untethered which I see exports a large no of png files but I guess you'd need to be able to play these in some way via jrvr in order to get displaycal to measure what JRVR actually renders. I see displaycal is now active on github (https://github.com/eoyilmaz/displaycal-py3) so if JRVR had a pattern generator built in that could be driven by an API then it could be integrated into here at least via a user contribution.

As for calibration, calibrating HDR output is still a bit of a weird topic, and we will mostly rely on the entire ecosystem to figure that out a bit more.
Otherwise, we can do ICC and 3DLUT now. Anything else in that area I missed?

I was thinking about end user being able to calibrate easily and verify jrvr behaviour so was thinking in terms of madtpg like functionality along with something like the splitscreen (lut/no lut) view. I realise that depends on tool providers engaging but I guess you'd need some form of api for anyone to integrate with anyway, does such a thing exist?


in relation to this, I took a look at the displaycal code which drives a pattern generator and think it would be not so hard to integrate an MC api for this if such a thing existed. It basically just sends a couple of tuples of values for the colour to display and the bg colour (if any) so something like MCWS/v1/Calibration/Display?r=123&g=234&b=0 and so on would seem to be minimal interface required to integrate with such software.

In terms of attracting satisfying the serious video crowd, I think this would a(nother) nice feature box tick for MC31 (albeit requires support from such software so isn't an immediate win)

[Hendrik]

Unfortunately DisplayCAL seems to have had no released updates since 2019, and no code changes since 2020. Is the project still alive to bother with even investigating?

Before DisplayCAL even become popular, I have measured software manually with HCFR and the AVSHD Calibration files

IMHO calibrating through the video renderer is not required, and you can just do it through the integrated patterns in the calibration software. All you need to do if you want to be sure all is working properly is to validate the renderer reproduces the colors properly, which you can easily do with spot checks using test pattern video files. Yes, it might not be automated, but ideally you only need to do this once, and you can henceforth measure with the calibration software without involving the video renderer.

I have no big hope in external tools engaging with some kind of API, fwiw.

[mattkhan]

There's an active fork on GitHub - https://github.com/eoyilmaz/displaycal-py3 - so it appears to be alive to me. If you had the API, I would add that myself to displaycal so you would have at least one app using it.

Doing this manually is unrealistic and you certainly won't be doing it once. A 3dlut patch set is commonly a few thousand patches and then verification is commonly 00s, repeat twice each time (SDR and HDR are done separately) and then repeat periodically as your bulb ages (so that depends on usage really but every 6-9 months is not unrealistic)

Even if you calibrate using an external pattern generator, verification is impossible without the lut in place and imo the best way to do that is to use the actual renderer so you know for sure you measure what you will use for film

[Hendrik]

Doing this manually is unrealistic and you certainly won't be doing it once. A 3dlut patch set is commonly a few thousand patches and then verification is commonly 00s, repeat twice each time (SDR and HDR are done separately) and then repeat periodically as your bulb ages (so that depends on usage really but every 6-9 months is not unrealistic)

Even if you calibrate using an external pattern generator, verification is impossible without the lut in place and imo the best way to do that is to use the actual renderer so you know for sure you measure what you will use for film

You calibrate using the automatic app function, like normal. You load the 3DLUT in your renderer. You then do a small set of spot checks to verify the output is as expected. It doesn't require hundreds of checks to do this.

[mattkhan]

You calibrate using the automatic app function, like normal. You load the 3DLUT in your renderer. You then do a small set of spot checks to verify the output is as expected. It doesn't require hundreds of checks to do this.

Verification uses another patch set which is user selected size/design so can be 00s of patches. This is not a manual effort. Effectively you are telling displaycal users to continue relying on madtpg, seems suboptimal to me.

[Hendrik]

I am not talking about DisplayCal "verification". I'm talking about doing manual spot checks.

Either way, I have no plans for this at this time. Even defining an API with the appropriate information is a long project, and I don't see anyone officially adopting it. Some kind of community fork? Its just not discoverable.

[mattkhan]

I am saying that manual spot checks are not a thing, you just run an automated check and generate a report from that. Even hcfr integrates a pattern generator (madtpg being an option) for this purpose too.

Discoverability is a non issue because it would get added to the wiki and relevant forum thread as soon as it is implemented.

Adoption of at least one app is also a non issue as I would do it

The minimal API is a couple of calls that are already defined, it's a subset of madtpg.h (which you may or may not agree with but from a functional perspective, it's v basic)

Obviously appreciate that it's still work on your end that is probably non trivial but external factors seem like non issues to me.

[mattkhan]

it occurs to me that a simple solution is

1) MC provides an API (MCWS or whatever) that is can generate the specified colour and display it on screen in a user specified jrvr profile
2) some community minded individual implements a madtpg -- MC bridge to provide a compatibility layer to existing calibration tools (i.e. a small app that talks madtpg api on one side and translates to MC api calls on the other

I would think that 1 is v straightforward and 2 should be straightforward (i.e. no doubt will be slightly painful, probably has some limitations but is doable and gets the user where they want to be)

[mattkhan]

fwiw I made some progress on this, I think I can see a way to get this working so one can at least automate verification (even if you measure in madtpg) but I think it is going to end up needing changes to displaycal to make it actually usable.

* I worked out exactly what displaycal does when it measures with an optimised patchset (it's ultimately just a preconditioning profile fed into targen, if anyone wants details then I can post that)
* used this to export a variety of test charts to png
* wrote a script that can convert all these pngs (of which there are 000s) into a single video of appropriate length & with small text overlay to indicate what the pattern is -> https://raw.githubusercontent.com/3ll3d00d/jrmc-utils/master/create_patterns.sh
* ran this on my generated pattern sets (takes a surprisingly long time even on a fast machine, ~300 patches per hour, not sure if normal or some option I'm using is v slow, may revisit this if I get the end to end working) so now I have a bunch of videos that can be used for measurements

I then tried to run displaycal in untethered mode (which is basically just a load of calls to spotread) and I think it's fair to say it's unlikely to work as a completely unsupervised thing

I think making into something I can actually use is going to mean changing displaycal's untethered mode so that it's not trying to autodetect when the patch is read, instead I'll just change my video so that each patch is shown for a defined period of time (like 1s), start playback in paused mode and then tell it to advance playback by 1s each time. I would hope this should be a reliable approach that doesn't take much effort to hack into a displaycal fork but we'll see.

[Hendrik]

I've been thinking about it, and mid-term maybe we can offer some simple pattern generator controllable through some manner. What would it really need? A call to start a session, and a call to tell it what to display - RGB color and the size of the pattern on the screen?
Hopefully it shouldn't be too complicated if we can keep it very simple.

[mattkhan]

yes that's about it

it looks like displaycal has support a few socket or http based pattern generators already (resolve, prisma) and the api is basically a single call (to set the colour) which generally just allows for setting some or all of

* colour (rgb)
* background (rgb)
* window size
* whether to use video levels

[mattkhan]

there's a work in progress branch here - https://github.com/3ll3d00d/displaycal-py3/tree/untethered-mcws

it assumes you have

* a testchart loaded into displaycal
* a corresponding video file containing those patterns with each colour shown for 1s
* media network turned on to allow use of mcws
* manually started (and paused) playback in whatever video setup you want to measure

it will then update the position of the video to correspond to the right patch so, theoretically, it should be pretty reliable

haven't tested it anger yet though

[mattkhan]

if we ignore this oddity (https://yabb.jriver.com/interact/index.php/topic,136226.0.html), approach works well and it scrolls through the test patterns rapidly and accurately.

[mattkhan]

that displaycal fork had a few bugs (around untethered mode and madvr 3dlut creation), pushed a PR upstream to fix those & added integration with mcws to drive measurements in https://github.com/3ll3d00d/displaycal-py3/tree/mcws-untethered

[mattkhan]

rewrote the pattern generator in python, much shorter videos (200ms per patch) to make it faster to generate & also works from csv export from displaycal rather than png which has improved accuracy slightly & also makes it much faster to export from displaycal (no need to export 000s of small png)

https://github.com/3ll3d00d/jrmc-utils/blob/master/gen_pattern.py

[mattkhan]

my fork of displaycal seems fairly reliable now

https://github.com/3ll3d00d/displaycal-py3/tree/mcws-untethered

NB: there were a no of bugs in the py3 rendition of the madtpg code which the above also fixes

I ran a short verification report comparing madtpg (with 3dlut) vs jrvr (with the same 3dlut) and there was general agreement between the two so I'm now moderately confident that everything is working & also that I can now run larger patchsets against jrvr automatically.