[qcms] Add a color profile white point transform api

third_party/qcms/src/chain.c

Index: third_party/qcms/src/chain.c
diff --git a/third_party/qcms/src/chain.c b/third_party/qcms/src/chain.c
index aa8506e41deeed4f2e19f2997cac000dc1c54b12..4e4b000a8a703e2c77cde569e069ded8d9daf01e 100644
--- a/third_party/qcms/src/chain.c
+++ b/third_party/qcms/src/chain.c
@@ -893,7 +893,7 @@ remove_next:
 }
 */
 
-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;
@@ -918,6 +918,9 @@ static struct qcms_modular_transform* qcms_modular_transform_create(qcms_profile
 		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;
@@ -984,7 +987,7 @@ static float* qcms_modular_transform_data(struct qcms_modular_transform *transfo
 
 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);
@@ -992,3 +995,27 @@ float* qcms_chain_transform(qcms_profile *in, qcms_profile *out, float *src, flo
 	}
 	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;
+}