- This topic has 16 replies, 3 voices, and was last updated 5 years, 8 months ago by
.
-
Posts
-
Yup, you’re right the 3D LUT “white point” can be defined and/or modified by the “Calibration” tab, and “Absolute” intents will adhere to that white point and NOT the white point of the “source colorspace”.
I was 100% wrong in interpreting the documentation. It never crossed my mind that I was mistaken (read: “absolute” to the “source colorspace” and not “relative” to my display white point). This is one of the few times my pedantic OCD was a good thing.
Cheers for that! Now I need to remake some profiles for my other displays (if needed, else remake 3D LUT).I apologize if you feel as if you’re simply repeating yourself, some things simply don’t click with me unless it’s done a specific way that I can’t predict.
No, it’s fine. I already got a good impression on what I might need to improve/implement (i.e. including 3D LUT target whitepoint and not original simulation profile target whitepoint in reports).
That could be a bug in Argyll’s targen then. Did this happen with your custom charts or during the “auto-optimized” mode of DisplayCAL? Did you use a preconditioning profile (using LUT-based profiles for pre-conditioning can cause this to happen if the recorded response is not well-behaved enough, so one way to avoid it is to only used shaper + matrix based pre-conditioning profiles)?
It was a pre-conditioned profile, which was created with the “auto-optimized” test chart. I’ll try that out next time it happens.
I was 100% wrong in interpreting the documentation. It never crossed my mind that I was mistaken (read: “absolute” to the “source colorspace” and not “relative” to my display white point).
Basically what happens is, the calibration target whitepoint is also used for the 3D LUT source colorspace. Maybe it would make sense for me to show that whitepoint on the 3D LUT tab, so it’s clearer.
It was a pre-conditioned profile, which was created with the “auto-optimized” test chart. I’ll try that out next time it happens.
That would explain it then. The end result of an auto-optimized run is a LUT-based profile (unless you deliberately change profile type to shaper + matrix), if you then manually use that as a preconditioning profile in the testchart editor, you could run into the problem I described (note though that the “auto” mode will always use a matrix based profile for preconditioning, so that in itself should not be affected).
