When I try the feature with the above release I get first, after a while of alternate white and quite black patches, that the extra delay cannot be computed. If I retry it computes a delay of 2/3 seconds
I have tried exactly the same with 1.0.0.2096 and it works fine!

I have used Pgen connected directly to the power, Prometheus probe, with its probe settings.
Only for evaluating the sensitiveness of the feature, with the previous release I usually get 0 extra delay (HD with FR = 120 Hz on an LG Oled). if I change the FR to 24 Hz and set probe max integration time to 1 microsec, I get 0.1x of extra delay (with x 0, 3, 1, 0)

Actually, no, the previous ColourSpace versions did not work fine - there was a bug there.
They just failed without a warning message, and reported a zero value.
The failure messagenow shows there is instability in the probe measurement values.
(You can see this by changing the probe settings.)
We will be changing the sensitivity in a future release.

Steve

I have tried the setting is giving me 0.1x with previous release in new release: first time it has given me the warning message, second time 2.008, third the warning, forth 0.508, fifth 2.008 .... For sure each time I reconnect the probe I get first the warning message.
The right extra delay for such a case (I have measured with black stab patch) is 0.175 .... it cannot be 0.5 or 2 seconds ....

As above, instability in the probe/display is the issue
The threshold for acceptance likely needs to be larger, also as said.

And as said, you can see this with different probe settings, such as longer integration time, and larger averaging.

You will also likely get strange results with the Admesy Auto mode.

Steve

You said that previously it failed, but no warning and 0 extra but never gotten 0 with my settings in previous release!
And never gotten with the last release anything that is close to 0.2, that looks the right experimental extra delay (with 24 Hz frame rate).

It would be nice to have the related measurements and overhead in the log file, as for the other d

Have you tried with any Oled? With which probe?

PS: watching the log file, it appears that going from 120 to 24 Hz you need to have an additional overhead of 200 msec (A number that does not make sense to me, I would have expected an additional delay of 1/24 (i.e. 0.042) seconds. Further, I cannot understand why for the measures that fail, the overhead drops. I would have expected a wrong measure, but with the same overhead, unless, for same reasons, Pgen becomes faster.

Attached file: ColourSpaceMeasurementLog.xls

The reading you are getting are invalid, for the reasons stated above.
You will need to find settings for the probe that provided stable and consistent Delay values.
When we change the threshold sensitivity, that may help with your probe/display combination.

The measurement times in the log file are all defined by the probe - not ColourSpace.
We have no control over how long the probe thinks it needs to take.

Steve

Can you see any instability from the log I have attached? All with a black stabilisation for the reason you know and with extra delay = 100.
And it does not work as said. Also tried with a Klein. Any instability and it does not work. Very similar behaviour.

Attached file: ColourSpaceMeasurementLog1.xls

Sorry, you are not understanding the underlying issue.
Your Log only has a 940 patch - no near black.
Please wait until we alter the stability threshold.

Steve

I will will wait, no problem.
Anyhow at the end I have patches with 108 and 90 ...

We have completed our changes to the threshed stability, and the Auto function will likely NOT work with Admesy probes, as well as other Probes/Settings combinations.
Such Probes/Settings internally actively defeat the concept of an Auto Delay function.
This cannot be overcome.

See the Signal Delay section within the Calibration Issues page.

Steve