PCS Refactor May Require Additional Xform for Correct Output | Commit f464b41

[waacton]

I've been using DemoIccMAX to generate test values for my own implementation of colour conversion using ICC profiles. The last time I generated test data was 25 October 2024, and my results matched to many decimal places.

I've just updated the DemoIccMAX code and half of my tests are now failing.

In particular, profiles using TRC matrix conversions (such as sRGB v2 and D65 XYZ) are half the value they used to be for perceptual and absolute rendering intents.

e.g. sRGB v2: [1, 1, 1] to PCS, after applying XYZ scaling to the PCS values (in IccUtil.cpp), used to equal [0.964279, 0.999969, 0.825089], now equals [0.482147, 0.499992, 0.412551]

Elsewhere, the results of many values using Fogra39, Swop2006, and many others - across all rendering intents and in both directions - are also noticeably different, though not to the above extent, but enough for me to consider my conversion now inaccurate and in need of fixing.

Can you share details on what has changed to the calculations? Should conversion values have changed since October?

In case my process of generating data is wrong, I've been using IccEval.cpp as a reference, roughly...

CIccCmm profileApplier
profileApplier.AddXform(profile, intent, icInterpLinear, nullptr, icXformLutColorimetric, false)
profileApplier.Begin()
profileApplier.Apply(dstPixel, srcPixel)

[xsscx]

Hello @waacton

I too am aware of the input/output delta.

Thank you very much for your insight and the data. I will research these issues and provide full disclosure transparency.

[waacton]

Thanks @xsscx I look forward to having a bit more clarity on the issue, especially since it took me a very long time to implement something I thought was working.

For cases like sRGB v2 [1, 1, 1], it's as though a scaling has been done in the wrong direction, something akin to XyzToPcs(pcs) instead of PcsToXyz(pcs). At the very least, the earlier final result of XYZ [0.964279, 0.999969, 0.825089] made sense as being ~= D50.

No idea about the deltas from all the other cases though!

In case it helps, here's all the test data I gathered using the codebase as of October 2024: https://github.com/waacton/Unicolour/tree/main/Unicolour.Tests/Data/ICC. I could easily upload my latest results to a different branch if it would be of any use.

[xsscx]

It appears that GetPCS() was disabled, m_pPCS removed and that CIccPCS now is CIccPCSUtilon Nov 22, 2024 in commit f464b41. See author comments below.

[waacton]

@xsscx I didn't quite realise that the master branch is the one used for active development. Should I be using version branches like Ver2.2.4 to obtain the latest understanding of what a correct conversion is?

[maxderhak]

Legacy PCS processing was extensively refactored to move PCS operations from the apply functions to be Xforms in the transform chain. This results in the ability to optimize operations that are not needed (IE converting from Lab to XYZ in one profile followed by converting from XYZ to Lab in a successive profile can be replaced with no transform since lab is needed). The desired result is better performance when applying profiles on many pixels.

Testing was done to make sure that things work, but not every possible sequence was tested and now we have a bug.

For this particular situation - What sequence of profiles are being applied and what are the CMM configuration options (i.e rendering intent, etc.) are being appled to each profile?

I'm guessing that only one profile is being applied and the conversion from internal to external encoding is not being performed. (This would result in the values being represented as 1/2 of their value. A check for the situation probably needs to be added with an additional xform added to the chain to get the same behavior.