The dE ITP values displayed by ColourSpace (1.0.0.1520) aren't matching my own calculations, and I'd like to understand why, if possible. Using the specific example given in Annex 4 of ITU-R BT.2124-0: Target Gamut/EOTF of ST2084 Rec2020, Patch Scale/Resolution of Full 10 bit, RGB triplet 296,201,582, and measured/actual XYZ of 36.0,15.0,190.0, ColourSpace shows the dE ITP as 2.2773. My own calculation, using doubles throughout, yields 2.2819. Annex 4 shows 2.363, but that value is readily explained by the limited precision imposed at key steps in their calculation. I'd like to understand if the ColourSpace value is also explained by the use of more limited precision in the calculation, or if something else is going on.

Without going through your calculations, and comparing the workflow with the maths used in ColourSpace, that is an impossible questions, to answer.
And unfortunately, the value within the example provided within the ITU-R BT.2124-0 documentation demonstrates likely precision/rounding variations.
With an excessive EOTF, as with PQ, that is not at all unexpected.

Steve

Here are my intermediate calculations and final result. LibreOffice Calc matches these to at least 10 decimal places.

RGB: 296, 201, 582
linear RGB: 8.758182114365178, 2.294156077537514, 181.318064547253950
LMS: 16.409278140338003, 23.564657907655260, 163.641839918836380
L'M'S': 0.340119247638553, 0.371321802469549, 0.558280898594428
ITP: 0.355720525054051, 0.134646687344927, -0.161395069575210

XYZ: 36, 15, 190
linear RGB: 8.324787549324366, 3.242605588197572, 178.993068703904130
LMS: 16.578871332020118, 23.913465998086739, 161.609510857943010
L'M'S': 0.340986826660932, 0.372617052519958, 0.556989183424851
ITP: 0.356801939590445, 0.132090117162939, -0.162924537942205

dE ITP: 2.281932290568818

As you can see from your figures, you have far more decimal places than are viable.
(This is mainly down to probe accuracy, as well as screen and probe stability.)

Feel free to check using more realistic values.

Steve

Your response makes no sense, as there is neither probe nor screen involved here. It's an arbitrary choice of XYZ values, close to the chosen target, to demonstrate the difference between the ColourSpace calculation and my own. I certainly don't expect agreement to 15 decimal places, but a difference at just 2 decimal places qualifies as odd to me. I've compared many target/XYZ pairs, and there is often a difference at 2 decimal places, so this particular example is not unusual, nor is it unrealistic. If ColourSpace is using the same equations that I am, with any reasonable precision, then there should surely be agreement to 4 decimal places. So it seems that either ColourSpace is using different equations, or very different precision. It's certainly possible that my code is incorrect, although naturally I think it's correct. Hence my desire to figure out what's going on. Can you provide the ColourSpace intermediate calculations for this example, for comparison?

It means we do not perform such calculations within the GUI to such decimal place levels, as it is pointless, as the original example you have quoted shows.

As I say, feel free to use more realistic values, and if there is a large disagreement in the results, then it may be worth investigating.

Steve

What precision is being used for the calculation? Please give me an XYZ triplet for RGB 296, 201, 582 that you consider "realistic".

You can see all the values in the ColourSpace GUI, and the pop-up Point Info window.

Steve

The pop-up only tells me the (presumably rounded) precision used to display the results, not the precision at which the calculations were carried out. I hope there's someone who works on the code who actually understands the distinction.

The authors of ITU-R BT.2124-0 surely believed the example I used above is both valid and reasonable, since it's the (only) one they explicitly included in the specification. But here are four more examples, picked at random. The RGB values here are 8-bit Legal. Edit: still ST2084 Rec2020.

RGB 112, 142, 136
XYZ 99.210692416621, 172.066291126228, 176.937055394623
dE ITP 11.0074 vs 10.9591

RGB 92, 90, 134
XYZ 34.709269812207, 22.375444075847, 133.321132175155
dE ITP 5.9629 vs 5.9848

RGB 137, 143, 136
XYZ 158.377457959056, 191.124071889562, 161.553191164284
dE ITP 3.6823 vs 3.6663

RGB 131, 131, 122
XYZ 108.222603040454, 120.122622346255, 88.470887657733
dE ITP 3.0545 vs 3.0640

Sorry, but as the standards doc example basically defines a calculation precision, that is obviously what is deemed to be the expected tolerance.
Unless there is a real issue defined we unfortunately have far more important developments to be devoting our time to.
If we have some free time, we will do some evaluation, but as to when that is likely to be, I have no idea.

As stated, if you want to perform more test, with different decimal values, please do feel free to do so.

Steve

Target Gamut/EOTF: Rec709
Patch Scale/Resolution: Legal 8 bit
RGB: 16, 16, 16
XYZ: 0, 0, 0
displayed dE ITP: 0.3104

Surely you're not going to tell me that's a reasonable result.

Target Gamut/EOTF: Rec709
Patch Scale/Resolution: Legal 8 bit
Virtual Probe: OETF Gamma 2.4, Primaries REC709
Characterisation: Cube Based, Cube size 10

Number of points with displayed non-zero dE ITP: 270 (27%)

Please look at the Target xy and the Actual xy.

Steve

Some of the differences are in Y, so Target and Actual xyY also differ. And since I can only see 4 decimal places, who knows if xyY actually match at higher precision.

As always, all reports of errors/bugs/WIBNIs are added into our ongoing and active 'tickets'.
When there is time available for any reported issue to be looked at in more detail, it will be.
Those bugs that are identified immediately as real bugs are obviously of a higher priority.

All feedback is taken seriously.

Steve