With the most recent release of LightSpace we have added a 'Stabilisation' capability, for use during display measurement/profiling/calibration.

This addition has come about due to some in-depth evaluations we have been performing on different display technologies, where the displays would just not profile and calibrate as expected.

Some time back we added 'Drift' to help compensated for both display and probe drift over the profiling duration, and that makes some sense, as display profiling is a stressful process for any display/probe combination, especially for the cheaper probes.

But, in performing recent display technology evaluations it became apparent that some displays suffer 'drift', or more correctly 'stability' issues that are far more aggressive than the expected 'drift' issues.

The issues appear to be heat related thermal instability.

To overcome this during measurement/profiling/calibration we have added the ability to insert a 'stabilisation' frame after every probe read.
This is nominally a black frame, but can be user defined for colour, as well as duration.
The patch is not 'read', it is just displayed for the set period to prevent thermal instability.
The stability patch is set after every real profiling patch to even-out the stabilising effect, preventing cyclical issues caused by a slow heat build-up, followed by a cooling down period, as would happen with the insertion of longer duration stability patches after xxx seconds of profiling.

This 'Stabilisation' process seems to work well for measuring/profiling/calibration.

However, when in real use, such displays will not have regular 'cooling' periods, and will immediately suffer thermal instability, especially if the display is being used in a colour critical environment, such as for grading, as the same image/scene will be held on the display for extended periods, causing thermal instability as the display screen heats up.

The display will therefore NOT be calibrated as expected when in real use.

This means displays that require the use of Stabilisation Patches for calibration should be treated with caution if attempted to be used in colour critical environments, such as for grading work.

See: https://www.lightillusion.com/error.html

Steve

Really interesting way of visualising the display behaviour.
If (not sure from the description) you're only comparing to the measured gamut boundaries and gamma, and extrapolating the rest of the expected values, how do you know how much of this shape is due to drift / stabilisation issues and how much due to just the way the display tracks across the cube?
It would be really interesting to see the same cubes profiled in different orders, or with the stabilisation turned on / off.

Any chance of getting some more interesting visualisations like these into LS?

This was just part of our initial display assessment.
(It was these results that defined the need for Stabilisation...)
So far the results with Stabilisation active prove all the above.
Just not had time to documentate the results - but so far they follow exactly as you would expect.

But, while the addition of the 'Stabilisation' patches assist with the thermal issues, the underlying calibration issues remain, as shown by profiling the display to itself.
Even with the 'Stabilisation' active, the display still profiles very poorly to itself, meaning a very large profile and 3D LUT would be required for any chance of accurate calibration, ignoring the thermal instability issues.

As for making the tools available beyond in-house, we would have a lot more work to do.
They are not what we would call 'user friendly, as is.
But, they are rather useful

Steve

A Drift graph shows the higher-frequency drift, combined with a low-frequency drift/shift that WRGB OLEDs suffer.
(This profile was with a non-contact CR-100, so there is no probe drift.)



And if you look at the different RGB tracks you can also see the way the colour temp of the display changes over time.
It starts warm (red/yellow) and ends cold (blue/cyan).
(This was a display that had been left to warm/stabilise over an extended period before profiling.)

Steve

Edited to add: Using the standard Sequential Patch Set within LightSpace will cause the above Drift result, due to the thermal instability issues within the display. The previous Anisometric patch set also caused similar issues, but the patch set has since been updated to provide consistent power demands, so limiting thermal variations during profiling. See below for background information.

jfinnie
To better answer your question, here is a direct comparison with Stabilisation on/off.
The left-hand graphs are 'Stabilisation Off', and the right 'Stabilisation On'.

Again, each profile has been 'mapped' to itself, using the peak gamut, white point, and gamma values from each profile.
A 'good' display would generate a near perfect result.



If you look at the normal CIE graphs above you can see the 'With Stabilisation' (right hand graph) has a perceivably higher number of 'Orange' dE points, so in general terms the display when profiled with the black stabilise patches is better. But, there are still issues...
(The Drift graph below backs this up.)



The 3D CIE graphs better show the difference, with the general level of error as shown with the dE vectors being visibly less in the 'Stabilised' graph.





The Cube graphs are normalised versions of the 3D CIE graphs, and assist in really seeing both the underlying issues, and the greater issues caused by the thermal instability of the display when Stabilisation is not used.
Note that the graphs without stabilisation show how the displays will respond in 'normal' use.
You can easily see the 'scallop' out of the cube on the left hand side on both with and without Stabilise graphs.
But on the 'no Stabilise' you can see a step change in the data along the bottom edge, and the more random alignment of the dE vectors, especially to the right of the step change.



Both graphs verify the above, with the 'Stabilised' results showing the underlying instability of the display over time, with a Sequential patch set.

Steve

Edited to add: Adopting the new LightSpace Anisometric patch set, the regular saw-tooth instability can be reduced, but there remains a visible thermal instability. See below.

Very interesting Steve. So is the sawtooth in the drift graph down to the particular patch sequence? It makes me wonder if there would be benefit to doing the patch sequence in an order which avoided the sawtooth, as at each big change of direction there will be a few patches that the drift algorithm would struggle to help (may even hinder) because it won't be clear which way they should be adjusted.
Of course the accurate profiling is only one part...The drift swing in real use looks pretty scary!

jfinnie
No, it would appear to be down to the way the displays work, and has nothing to do with the patch sequence, size, or anything like that.
Easy to verify as changing the 'patch sequence' produces the same basic results.
And as the Anisometric patch sequence used is basically 'random', you would expect a random saw-tooth, if that was an influencing factor.

Steve

Edited to add: James was right, and the use of a Sequential patch set will cause the saw-tooth Drift result.

Interesting, so I guess it is some kind of crude temperature compensation which has discrete adjustment steps once a threshold has been crossed. Be interesting to know if the sawtooth can be affected by environment (desk fan, aircon, etc).

But I guess there is no point in trying to keep the panel cool for the profile if the end result will not match how the display behaves in actual use.

After some very interesting discussions with James (jfinnie), it has become very obvious he is right!

The way the Anisometric patch sequence works causes a sub-harmonic frequency thermal drift in the WOLED display, half the frequency of the Anisometric patch set.
(Sometimes being so close to the program we can miss the obvious!)



The above shows how using a different CSV patch set, defined to maintain a better overall patch level, can remove the saw-tooth thermal instability response.

However, it does nothing for the volumetric issues.



We will be updating the Anisometric Patch set sequence based on this.

Thanks to James Finnie for spotting this association with the patch sequence, and also DeWayne Davis at A/V Fidelity for running a lot of different tests for us.

Note: the drift graph is 'flatter' just because during profiling with the new patch set the average power of the patches is maintained to a consistent level. That will NOT happen in real use, where the thermal instability will be a real issue.

Steve

It should also be said that the initial ramp on the right-hand Drift profile, with the CSV patch set, is down to the displays slowly responding to the patch sequence average power value.

We will be adding a 'Pre-Roll' function to LightSpace to better manage this too.
(For now, run the calibration sequence for 5 to 10 mins, and then abort and re-start.)

Steve

Glad it was a useful discussion. Being able to have sensible conversations with the people who can "make it happen" is one of the reasons I love this package. Lightspace just keeps getting better and better .

As a continuation of WOLED assessment, the following shows a volumetric comparison of a WOLED and LCD display when used for HDR, with a peak Luma of around 700 to 800 nits, again with both displays profiled to themselves to provide relative data that is easy to compare.

As can very easily be seen the WOLED has major volumetric issues when used for HDR, as the colour gamut luma cannot match the grey scale luma, causing a clipping of RGB Separation.

The LCD display has relatively consistent volumetric accuracy throughout.











Again, looking at the above, a good display would profile to itself near perfectly.
And would have an RGB Separation graph where the RGB plots follow perfectly the target line (all overlapping).
As can be seen, the LCD is 'ok', while not perfect, but the WOLED has major issues that are easily apparent, due to the inclusion of the 'white' pixel, as this distorts the standard RGB colour channel relationship - excessively at HDR brightness levels.

In very simple terms, what this means is the WOLED can never be calibrated for HDR...

Really interesting pics; though having trouble getting my head around it a little bit.

So what does the WOLED graph mean in terms of a graph that might be considered more "standard"?

The WOLED I believe would follow PQ EOTF up to about 70% stimulus level for white. Up to what stimulus level would the colours follow the PQ EOTF?

When calibrating any HDR display you MUST set it to a standard Power Law gamma, and then profile it.
You can then calibrate to any EOTF you want.
You cannot profile an HDR display with an EOTF active (especially one with roll-off/tine mapping) and then use that profile to calibrate it.

So, all the above graphs for both displays are with a standard Power law gamma, with Peak Luma set to HDR levels (700 to 800 nits in this case).

As there is no PQ EOTF active the displays should profile to themselves near perfectly, just as for the SDR tests that started this thread.

That is why the WOLED display data is so appalling - there is no PQ EOTF active, so the results should be near perfect.

Steve

Hi Steve,
Thanks for that great thread. So also thanks James for giving some ideas for improvement in patch Sequenz.

Funnily enough User d-nice was mentioned my thinking already with screen uniformity. So brightness is no big matter but color accuracy due to the white sub Pixel and heat. There must be a screen uniformity test before calibration and then the patch Sequenz must switch only between the fields which passed the uniformity test.
So a patch squenz in my idea have the uniformity test first all passed fields will be kept in the field lottery. Then you measure several patches with screen stability and well optimized patch Sequenz and switch/rotate between passed field spots to finish measurement. Didn't know if this could be programmed. But this will overcome the cool down time with in use of contact meters. Instead of just calibrate only 5 to 10 minutes and then to wait.