Originally Posted by madshi
madVR's tone mapping works like this: If you actually tell madVR the proper peak Nits value that you measure your display as, all the pixels in the lower Nits range (ideally from 0-100 Nits) are displayed absolutely perfectly, in the same way a true 10,000 Nits display would show them. Tone mapping only starts somewhere above this lower Nits range. However, we can't simply jump abruptly from 0 compression to strong compression, so the tone mapping curve needs to start smoothly, otherwise the image would get a somewhat unnatural clipped look. Practically, if you set madVR's peak luminance value to 200 Nits, the tone mapping curve starts compressing pixels at 23 Nits. If you set madVR's peak luminance value to 400 nits, the tone mapping curve starts compressing at 75 Nits.
Of course projectors are rather dim, compared to flat panel displays. So if you actually tell madVR the proper Nits value you measured, tone mapping will be very heavily handed, and you'll lose a lot of highlight detail. So naturally, you'll want to pretend that your projector has higher peak luminance capability than it really has. If you do that, tone mapping will relax a little, but the overall image (including the low end range!) will be darker than the UHD Blu-Ray disc encoding asks for.
This probably explains why you're not happy with either the 200 Nits nor 400 Nits setting? I suppose what you really want/need is some tricky tone mapping curve which doesn't compress highlights as much as it mathematically should, while at the same time making sure that the lower end is reproduced exactly as the UHD disc asks for? We're approaching the impossible here: Since your projector is so dim, a lot of compression is needed. So where should we compress? If you enter the measured Nits value, the top end if heavily compressed. You don't like that. If you enter a much higher than measured Nits value, the bottom end becomes too dark (= compressed in a sense). You don't like that. So if you don't like compression at the top end and not at the bottom end, where should be compress instead? I suppose we could try making the tone mapping curve flatter, so that it compresses more strongly in the mid range and less strongly in the top range, but doing that would probably take some life out of the picture...
Anyway, here's a quick test suggestion: madVR's "contrast" slider is a linear light S curve gamma modification. So you could try to enable gamma processing, use 400 Nits to get less compression, and then use the contrast slider to "help" the lower end. Maybe that's more to your liking? Doing it this way will move away from the scientific approach of madVR's tone mapping curve, though. But I suppose lying to madVR by entering a higher than measured peak Nits value already gets rid of the science, anyway...
I understand all this, and this is why I'm saying that MadVR isn't as adaptive as it could/should be to get best results depending on the content for each title, at least with our projectors.
My display has 120nits PeakY (actual) in low lamp with 1750 hours on. I quickly saw that using the actual peakY was compressing too much, this is when I started raising the value. But then it seems impossible to find a single value that provides bright enough picture for 1000-1100nits titles (in a way that addresses the issue pointed by Kris Deering in titles such as The Revenant) and still resolve enough highlights that you don't clip visible information in titles with content going significantly above 1100nits.
What I can do with custom curves is use the equivalent of a 200nits value in MadVR for 1000-1100nits titles (titles with no content above 1100nits), and the equivalent of a 400nits+ value in MadVR for 4000nits titles (titles with content above 1100nits). The Vertex switches automatically between these two curves (in fact I'm playing with three curves at the moment, although I think two are probably enough).
My initial assumption was that MadVR would look at the content, and adjust the room left for the highlights according to said content. We don't need as much room for highlights with content under 1100nits, so we can ramp up the brightness of the curve to improve the low end and keep less room for highlights.
I have no interests in "tricks". The custom curves are mostly based on BT2390, they are just not adaptable the way MadVR could/should be if it was looking for MaxCLL and adjusting the value for PeakY accordingly, as it seems the current adaptive way based on the frame analysis isn't able to address the above issue..
I guess you can't do this on a frame by frame basis without causing significant jumps in picture brightness because the content wasn't mastered that way (it's not HDR10+ or DV), but you can get a fairly accurate estimate of the actual MaxCLL, if using MaxBrightness to first identify whether the title has valid metadata or not, then determine whether it could have content above 1100nits or not, then use MaxCLL to test again if the metadata is valid or not, then if it's valid get an indication of the content. If there is any uncertainty on the accuracy of the metadata, I fall back on 4000nits to be on the safe side.
This is the latest automatic algo I've asked HD Fury to implement in the Vertex for the V2.1 of the JVC Macro feature (HDR10-Main is a curve clipping at 4000nits, HDR10-Optional is a curve clipping at 1100nits with a higher diffuse white):
IF HDR10_Max_Brightness EQUALS 0 THEN HDR10-Main ELSE ** invalid metadata so select 4000nits curve
IF HDR10_Max_Brightness BELOW OR EQUALS 1100 THEN HDR10-Optional ELSE ** in that case we know the content can't be above 1100nits, so we select the 1100nits curve even if the maxCLL is invalid (it often is equal to 0)
IF HDR10_Max_CLL EQUALS 0 THEN HDR10-Main ELSE ** (title is a 4000nits curve with invalid MaxCLL, so I select the 4000nits curve to be safe)
IF HDR10_Max_CLL BELOW OR EQUALS 1100 THEN HDR10-Optional ELSE HDR10-Main ** (otherwise I use MaxCLL to select the 1100nits or 4000nits curve).
With the custom tabs, I can use the JVC max of three custom curves and I select (at the moment) a curve according to MaxCLL that clips at 1100nits, 2200nits or 4000nits following the algo above but testing MaxCLL for 2200nits as well. If you prefer, you could do 500nits, 1200nits and 4000nits as the MaxCLL value has little bearing with the MaxBrightness value, but with the Vertex the algo would be less accurate as there are a limited amount of lines and conditions available in the custom mode so I prefer to stick to values used in the mastering metadata info, even if it's not 100% accurate. I think the algo above will be 99% of the time a best case scenario.
This is why I'm suggesting to add ways to test for MaxBrighness and MaxCLL in profiles in MadVR, or preferably ways to specify at least one threshold value (preferably two) so that MadVR can adjust the internal value of PeakY according to the actual MaxCLL of each title (using algo above or similar), or let us specify the PeakY value we want to apply according to content if you can't find an algo to extrapolate this for projectors from the actual peakY (which would be, of course, the ideal way to implement this).
For example, if the algo above (or similar) was implemented in MadVR and we had the possibility to specify a PeakY value for 1100nits and 4000nits content, I would specify for my actual peakY of 120 a value of 200nits for 1100nits content and 450 (possibly more) for titles with content up to 4000nits (or above). This would give a similar result to what I can get at the moment with custom curves, using the Vertex to select automatically the correct calibration according to content. Ideally, we would want to support a few more MaxCLL threshold, such as 500nits and 2200nits.
Again, I've parked my tests in MadVR at the moment due to lack of time. MadVR works great in passthrough mode with 2/3 custom curves and the Vertex to switch automatically between the curves according to the actual content, not only with the HTPC as a source but with any other source and any other calibration (3D, x.v.color, HLG BT2020, HLG REC709, SDR film, SDR TV, many of which are not supported by MadVR/LAV). I want to first establish that the calibration is correct and assess whether some of the issues I'm seeing are calibration related or MadVR related before fine-tuning the peakY value I need according to content and providing you with a detailed report. The earlier you find the time to implement this, the faster I can resume my tests and resume this discussion with you, probably in the doom9 thread rather than here as most of it isn't JVC specific (and probably too technical and boring for most of the readers of this thread).
I have run a full autocal of my PJ a couple of days ago to calibrate my SDR Rec-709, SDR BT2020 and HDR10 baselines and I've created new 3D LUTs (rec-709 profile which I use to also create PAL and NTSC LUT and SDR BT2020 profile which I use to also create a DCI-P3 LUT). I'm only waiting for MadVR to report the active 3D LUT in the OSD to resume my testing.
By the way, for those who were wondering about autocal with the BT-2020NF colour profile, you can use standard instead of reference and the calibration will be accurate. You can't use the BT2020-NF profile without running an autocal without the filter enabled at the iris/lamp mode you will be using. The autocal you have made with reference and BT2020F won't be accurate when you select BT2020-NF and it will cause gamma and color shifts. You will also need to correct the errors from your Spyder in the BT2020NF profile, same as with the BT2020F profile.
Madshi I would appreciate if we don't start a long discussion here and now. As I said, I need to resume testing once I've ruled out any potential issue with calibration in MadVR. Once I'm 100% sure that the correct 3D LUT is applied, I'll provide more feedback and we can move on.