In the following code from the outputTransform() function, the CAT matrix is calculated but not used by the next line which uses D60_2_D65_CAT which is a constant using REC709_PRI as the second parameter of calculate_cat_matrix. Isn’t the next line supposed to be using CAT instead like the following? XYZ = mult_f3_f33( XYZ, CAT);
// Undo CAT from assumed observer adapted white point to ACES white point
if (D60_SIM == false) {
if ((DISPLAY_PRI.white[0] != AP0.white[0]) &
(DISPLAY_PRI.white[1] != AP0.white[1])) {
float CAT[3][3] = calculate_cat_matrix( AP0.white, DISPLAY_PRI.white);
XYZ = mult_f3_f33( XYZ, D60_2_D65_CAT);
}
}
@jimdinunzio sort of…
You are correct that CAT is declared but then is not used. The code snippet you included in your post appears to come from the invOutputTransform() function. If you look in the corresponding block of code from the forward transform, there is a placeholder TODO: comment:
// Apply CAT from ACES white point to assumed observer adapted white point
// TODO: Needs to expand from just supporting D60 sim to allow for any
// observer adapted white point.
if (D60_SIM == false) {
if ((DISPLAY_PRI.white[0] != AP0.white[0]) &
(DISPLAY_PRI.white[1] != AP0.white[1])) {
float CAT[3][3] = calculate_cat_matrix( AP0.white, DISPLAY_PRI.white);
XYZ = mult_f3_f33( XYZ, D60_2_D65_CAT);
}
}
Thanks for reviewing closely. I’ll note this and we could definitely use this type of scrutiny when it comes time to beta test and review the code for ACES 2.0.
The intent is to build in the mechanism to apply a CAT or not, no matter the whites. If I recall correctly, in the default transforms supplied with 1.1, we only needed D65 for the HDR ODTs. But currently if people try to use OutputTransform() to make their own transforms, they could run into issues if their white is not D65.
When the parametric Output Transform model is updated and applied to all the transforms (including SDR), the rest of this block will need to be expanded and tested for all use cases. There are a number of “half-finished” or “skeletal” code fragments such as this one in these Output Transforms because they stemmed from experimental code that I had written which was decided to be released as a testing ground with the HDR ODTs before fully fleshing it out for future applications.
Thanks.
BTW, Is there an approximate time frame for when the parametric solution will be used in SDR transforms and added full support for HDR with dim environments? for ACES 2.0 in general? Also I was wondering why there is not separate Academy transforms for 2.2 gamma in the SDR transforms in addition to BT.1886. In the TV display world we still are expecting 2.2 on certain screens supported in the hardware. It was easy to add support for 2.2 gamma in the parametric code. Of course I could create a new SDR transform for this by copying the P3D65 48nit one and changing DISPGAMMA to 2.2.