- This topic has 17 replies, 2 voices, and was last updated 7 years, 1 month ago by
.
-
Posts
-
Hi Florian
I’ve been working on producing a rec 709 2.4 eecolor LUT for an UP2716D using resolve patches via decklink, and noticed that the default of video levels for the LUT gives a very slight colour cast to the greys. I noticed this too a few weeks back when first producing an eecolor LUT via windows.
My project settings in Resolve are video levels for monitoring (almost always the correct setting to use), a timeline with colour calibration charts, rec 709 2.4. The dell needs a slight green push, which can’t be done at the monitor without disabling UC, so this is done in the calibration. With the video levels LUT this was evident with slightly off white greys, whereas using a full range LUT the greys look fine, and the same whether the eecolor is on or off. Is this result to be expected, and if so, why is a video level LUT the default and not a full range LUT?
To try and verify the loaded LUT and the green cast issue, I did a curves based calibration with the LUT loaded. With the 16-235 LUT the coverage was less than 100% and the curves indeed pulled back the green, which was also visible on Resolve’s scopes during calibration to produce the curves. With the full range LUT loaded, srgb coverage was 100.0%, with an almost white curves line, and just a slight adjustment to red at the highest levels (possible LUT inaccuracy as it was produced from only 822 patches).
I’ve found how to validate the actual loaded eecolor LUT by turning off device link profile and validating (I think that’s the way at least), and I’m revising my thoughts here as the video level LUT does verify better. In which case, the issue of the green cast is unresolved. I’ve added grey balance verification results below. The first is with the video level LUT in play and the second with the data level LUT. Though the video level LUT is better overall, the grey balance has more points with a green skew, the error values are higher, and therefore the average error is higher. Though small, this is most definitely visible.
So, data level LUT has purer greys but is a more inaccurate LUT due to range mismatch I suppose. Video level LUT is fundamentally more accurate but has dirty greys due to a green cast. Any ideas what may be up?
Sorry for the chain of posts, but this is an extended verification with the video level LUT loaded. Relevant, I suspect, are that the colours most in error are also the green/yellow points. I should perhaps say that the LUT was produced with only 822 patches, but the same green cast was noticable from around double the patches. I’ve not gone over 2000 yet as that takes a long time with the artificial delay for Resolve.
Did you adjust the whitepoint to hit the target using the monitor’s controls during interactive adjustment, or are you letting the calibration do the adjustment?
White point is as measured. The only control that can be adjusted without disabling uniformity calibration is brightness, and it’s essential to have UC enabled as it’s so bad without, so I only adjusted brightness to hit around 120cd/m2 and then used as measured for that too, which turns out to be very consistent. I also did a calibration with 3000 patches or so and get the same result. With a video LUT most measured test points are bang on other than the greener ones, and the greys have a cast. With a full range LUT more colours are off, but evenly so there is no perceptible cast.
I’ve been using an available corrections file for the i1 and the monitor, but last night tried without. Without corrections the blue needs to be brought down, and this gave similar results with now a slight reddish cast.
It appears as though the adjustment needed to balance the RGB levels is overly biasing the LUT in some way, and perhaps this wouldn’t be evident if the RGB levels are balanced at the monitor first. It will disable UC, but I’ll do a calibration this evening after bringing the RGB levels in line at the monitor and see what the results are like.
I’m still not sure what you’re trying to do. If you set whitepoint to “as measured”, this usually means you want the 3D LUT to adjust the white for you (according to the selected source colorspace) – if the visual result looks “off” to you, it could mean you’ve run into observer metameric failure, i.e. even though the measurements are spot on, due to the spectral response of the display, what your eyes perceive is visibly different from what the instrument “sees”. In that case, you may need to adjust the white visually (to a known reference, e.g. another display) and re-calibrate/profile (setting 3D LUT rendering intent to “relative colorimetric” so it doesn’t change the white you’ve adjusted).
What doesn’t make sense to me is that both 16..235 and full range LUTs seem to work for you without changing (?) Resolve’s configuration – I would expect only one of the two to produce the correct black and near-black levels (near-black not crushed, black not lifted).
Sorry, wrong terminology. The profile is 709 1886 2.4 D65. The *white level* is as measured, but other settings should be as necessary for dispcal to do a valid correction per the specified profile. I’ve attached a shot of the colour points from an extended validation with video level LUT in the eecolor as the PDF didn’t capture it. As you’ll see, most points validate well, save for the green/yellow points. The question in my mind is why are these off after calibration? The monitor is pretty accurate out of the box already, and doesn’t the green points being off after calibration mean that the LUT is incorrect in some way, or does the calibration needing to push the green slightly to achieve the correct whitepoint make it impossible to get those colours accurate?
As for both LUT’s “working”, the correct LUT in the eecolor does seem to be the video levels one based on other factors, so I’m only testing with those, however that’s the one that looks off for the greys.
After letting the display warm up this evening, I balanced the RGB levels on the monitor and tried a calibration with a low number of patches. Though all the colour points on a validation were slightly off from the few patches, this was now by a similar amount all round. The monitors uniformity compensation has to be on though as otherwise you can see the non-uniformity on the screen and it measures badly, so I cannot adjust the RGB levels at the monitor. With UC enabled, the device measures as pretty even (almost all double ticks).
As you’ll see, most points validate well, save for the green/yellow points. The question in my mind is why are these off after calibration?
The usual reason for this is the monitor gamut not being large enough, so out of gamut colors simply clip. Did you profile the monitor in its wide gamut mode?
Yes, the monitor’s custom settings mode always uses the full gamut. When first producing a LUT to use directly in Resolve the calibration was reporting about 99.5% srgb. With the eecolor LUTs a calibration reports about 97.4% srgb coverage, though the gamut graphic shows that srgb is well within the measured gamut other than the srgb boundary just touching the inside of the measured gamut blue boundary. When I applied the resultant video LUT to the eecolor and then used a curves calibration to profile the result, dispcal reported 100.0% srgb coverage and curves aligned well.
As having to lift the green a little increases the level shift at each step, I wondered if that could be a factor, but as the adjustment is slight it seems unlikely. The monitor also supports 10 bit and that’s how it’s being driven, though this may be 8 bit with dithering.
I’ll add some other screenshots or screen recording of the process in case that highlights something.
Took a few more images. The 3D view seems interesting.
calibration-start is the initial readings. Green actually starts off at a level similar to RB but settles after the recommended 30 mins or so as read there.
after-calibrate are calibration results.
gamut resolve decklink is the gamut view after calibration. Isn’t the rec709 colour space well within gamut? Not sure why gamut coverage therefore reports as 97.3%
profile-3d is the 3D view. Not sure why the mesh pushing outside of the gamut (or colourspace? I’m guessing it’s gamut).
A provider of commercial calibration software here in the UK did claim over the phone that the argyll colour science is poor, which I dismissed at the time as commercial spin and because I’ve had seemingly good results in the past, but I am starting to wonder if the maths is off after all. I also tried 1.8.3 after reading about issues with 1.9, but results were similar.
Do these extra images shed any further light? Happy of course to send any other data that may help.
gamut resolve decklink is the gamut view after calibration. Isn’t the rec709 colour space well within gamut?
[…]
profile-3d is the 3D view. Not sure why the mesh pushing outside of the gamut[…]
That means Rec709 actually is (partly) out of gamut for this display. Interesting, I wouldn’t have expected this. There’s ways around this, but all of them are compromises.
A provider of commercial calibration software here in the UK did claim over the phone that the argyll colour science is poor, which I dismissed at the time as commercial spin and because I’ve had seemingly good results in the past
Sounds like something Steve Shaw of Light Illusion would say 🙂
but I am starting to wonder if the maths is off after all.
I doubt any of this has to do with “off maths” though.
Happy of course to send any other data that may help.
If you could attach the profile and related files please (with profile selected in DisplayCAL, click the “Create compressed archive” button).
Archive attached.
“Sounds like something Steve Shaw of Light Illusion would say” – you might think that, I couldn’t possibly comment 🙂
If you need anything different please let me know. I agree about gamut size on the face of it, however I’m pretty sure that the monitor has a much wider gamut than rec709/srgb and actually exceeding P3 – doesn’t the 2d gamut image after calibration indicate this, with the gamut well beyond the colourspace except possibly at blue? I’m sure this wouldn’t be the issue, but I wondered if this effect would happen if the green adjustment was somehow effectively applied twice. When the monitor is cold it doesn’t need so much green correction, so I’m going to try a calibration from that state too to see what the results are like.
One thought. The calibrations I made have been with Resolve set to use video levels when producing the patches as this is the setting that you should almost always have when grading. If I calibrate with data levels instead then coverage is 99.9% as attached, however no combination of video or data LUT and video or data levels in Resolve then gives a LUT that gets even close to validating correctly. I found this the other day hence generating patches with a project at video levels. I suspect being at video levels for the patches is related somehow.
If I calibrate with data levels instead then coverage is 99.9% as attached
This is what worries me, the gamut with data levels is larger, indicating that the monitor indeed should be driven with data levels, unless it has some faulty internal processing. Please attach the data levels profile as well.
