[qcms] Add a color profile white point transform api

third_party/qcms/src/chain.c

 /* vim: set ts=8 sw=8 noexpandtab: */
 //  qcms
 //  Copyright (C) 2009 Mozilla Corporation
 //  Copyright (C) 1998-2007 Marti Maria
 //
 // Permission is hereby granted, free of charge, to any person obtaining 
 // a copy of this software and associated documentation files (the "Software"), 
 // to deal in the Software without restriction, including without limitation 
 // the rights to use, copy, modify, merge, publish, distribute, sublicense, 
 // and/or sell copies of the Software, and to permit persons to whom the Software 
@@ skipping 875 matching lines @@
 remove_next:
                 curr_trans->next_transform = next_trans->next_transform;
                 next_trans->next_transform = NULL;
                 qcms_modular_transform_release(next_trans);
                 continue;
         }
         return transform;
 }
 */
 
-static struct qcms_modular_transform* qcms_modular_transform_create(qcms_profile *in, qcms_profile *out)
+static struct qcms_modular_transform* qcms_modular_transform_create(qcms_profile *in, qcms_profile *out, bool pcs_xyz_only)
 {
         struct qcms_modular_transform *first_transform = NULL;
         struct qcms_modular_transform **next_transform = &first_transform;
 
         if (in->color_space == RGB_SIGNATURE) {
                 struct qcms_modular_transform* rgb_to_pcs;
                 rgb_to_pcs = qcms_modular_transform_create_input(in);
                 if (!rgb_to_pcs) 
                         goto fail;
                 append_transform(rgb_to_pcs, &next_transform);
         } else {
                 assert(0 && "input color space not supported");
                 goto fail;
         }
 
         if (in->pcs == LAB_SIGNATURE && out->pcs == XYZ_SIGNATURE) {
                 struct qcms_modular_transform* lab_to_pcs;
                 lab_to_pcs = qcms_modular_transform_alloc();
                 if (!lab_to_pcs) 
                         goto fail;
                 append_transform(lab_to_pcs, &next_transform);
                 lab_to_pcs->transform_module_fn = qcms_transform_module_LAB_to_XYZ;
         }
 
+        if (pcs_xyz_only)
+                return first_transform;
+
         // This does not improve accuracy in practice, something is wrong here.
         //if (in->chromaticAdaption.invalid == false) {
         //      struct qcms_modular_transform* chromaticAdaption;
         //      chromaticAdaption = qcms_modular_transform_alloc();
         //      if (!chromaticAdaption) 
         //              goto fail;
         //      append_transform(chromaticAdaption, &next_transform);
         //      chromaticAdaption->matrix = matrix_invert(in->chromaticAdaption);
         //      chromaticAdaption->transform_module_fn = qcms_transform_module_matrix;
         //}
@@ skipping 46 matching lines @@
                 dest = src;
                 src = new_src;
                 transform = transform->next_transform;
         }
         // The results end up in the src buffer because of the switching
         return src;
 }
 
 float* qcms_chain_transform(qcms_profile *in, qcms_profile *out, float *src, float *dest, size_t lutSize)
 {
-        struct qcms_modular_transform *transform_list = qcms_modular_transform_create(in, out);
+        struct qcms_modular_transform *transform_list = qcms_modular_transform_create(in, out, false);
         if (transform_list != NULL) {
                 float *lut = qcms_modular_transform_data(transform_list, src, dest, lutSize/3);
                 qcms_modular_transform_release(transform_list);
                 return lut;
         }
         return NULL;
 }
+
+qcms_bool qcms_profile_white_transform(qcms_profile *profile, float XYZ[3])
+{
+        static qcms_profile xyz_pcs_profile;

[robert.bradford, 2015/12/02 15:25:39]

What's the rationale for this? Is this a performance critical path where we're
happy to increase our memory usage by 264 bytes for everyone (irrespective of
using this function?)

[Noel Gordon, 2015/12/03 03:14:50]

Nope, not perf critical.  The chrome memory usage +264 bytes, per renderer, is
probably not a worry. Better still, how about we ditch it?  I only needed it to
provide the existing code with an output profile, since that what it wanted. 
I'm gonna change that existing code so I don't need to do that at all.

+
+        if (xyz_pcs_profile.pcs != XYZ_SIGNATURE) {

[Justin Novosad, 2015/12/02 15:40:08]

Is qcms not concerned about thread safety?

[Noel Gordon, 2015/12/03 03:14:51]

Yes it is, always.  We currently create profiles on the Blink main thread only. 
And that'd be where we call this code, so we'd be thread-safe in our use-case.

More generally, profiles and transforms are created on our main thread.  But
these profiles and transforms may be used on any thread _when they are being
applied_ to do color correction.  And there we need thread-saftey, and qcms is
indeed thread-safe in application (when being applied), in all cases.

+                memset(&xyz_pcs_profile, 0, sizeof(xyz_pcs_profile));

[robert.bradford, 2015/12/02 15:25:39]

static variables are initialised to zero always, no need to memset.

[Noel Gordon, 2015/12/03 03:14:51]

Ack, but ditched the static anyway.

+                xyz_pcs_profile.pcs = XYZ_SIGNATURE;
+        }

[robert.bradford, 2015/12/02 15:25:39]

Alternative (using C99 initialisers):

static const qcms_profile xyz_pcs_profile { .pcs = XYZ_SIGNATURE };

In this case, static const would go in the text segment vs BSS.

[Noel Gordon, 2015/12/03 03:14:51]

Ditched the static profile, but thanks for the tip. C99 is so ... so 1994 :)

+
+        struct qcms_modular_transform *transform_list = qcms_modular_transform_create(profile, &xyz_pcs_profile, true);
+        if (transform_list != NULL) {
+                // Calculate how the given profile transforms white input color to PCS XYZ space.
+                XYZ[0] = XYZ[1] = XYZ[2] = 1.0f;
+                qcms_modular_transform_data(transform_list, XYZ, XYZ, 1);
+                XYZ[0] *= 1.999969482421875f;

[Noel Gordon, 2015/12/02 10:38:34]

Note: qcms_modular_transform_data internally scales XYZ by one on this number. 
Here we unscale it back to produce conventional unscaled XYZ output.  For
example, D50 in XYZ [0.9642, 1.0000, 0.8249].  If the profile is valid under the
white point test, the output of this routine would be [0.9642, 1.0000, 0.8249],
viz., D50 in unscaled XYZ.

[Justin Novosad, 2015/12/02 15:40:08]

Readability nit from a qcms outsider: put this number in a constant with a
meaningful self-explanatory name.  Ex: "ReciprocalTransformGain". Also, could
you express this factor in terms of existing constants? Actually, I just peeked
at qcms_modular_transform_create_input and saw the same literal there.  I find
this constant very odd. I am guessing it is somehow related to the epsilon of
the fixed-point type 2*(1-1/(2^16)), but there is no explanation, which is a bit
disconcerting.

[Noel Gordon, 2015/12/03 03:14:51]

On 2015/12/02 15:40:08, Justin Novosad wrote:
That constant factor is interesting.
Exactly, it is indeed very odd, and thanks for looking into it.  I'm unsure of
what it's about, I found no qcms change log that describes it "why", etc.  I
added what we do know to a comment.

Then I remove the static profile, patch #2 uploaded.

+                XYZ[1] *= 1.999969482421875f;
+                XYZ[2] *= 1.999969482421875f;
+                qcms_modular_transform_release(transform_list);
+                return true;
+        }
+
+        return false;
+}