Parse A2B0 tag on ICC profiles

src/core/SkColorSpace.h

Index: src/core/SkColorSpace.h
diff --git a/src/core/SkColorSpace.h b/src/core/SkColorSpace.h
index 777be9da2b4ebaae9e918197517775adb2a82777..fb1ee4258337a7c37900cb8edd86e8020b00352f 100644
--- a/src/core/SkColorSpace.h
+++ b/src/core/SkColorSpace.h
@@ -35,6 +35,17 @@ struct SkFloat3x3 {
     void dump() const;
 };
 
+struct SkColorLUT {

[scroggo, 2016/04/27 20:18:46]

LookUpTable?

[msarett, 2016/04/27 21:17:58]

sgtm

+    static const uint8_t kMaxChannels = 16;
+
+    uint8_t                  fInputChannels;
+    uint8_t                  fOutputChannels;
+    uint8_t                  fGridPoints[kMaxChannels];
+    std::unique_ptr<float[]> fTable;

[scroggo, 2016/04/27 20:18:46]

Are we already switching to unique_ptr?

[msarett, 2016/04/27 21:17:58]

Is there a skia pointer that would work equally well here?  I used this on a
suggestion from Ben...was having trouble figuring out the right type to allow me
to transfer ownership properly.

[scroggo, 2016/04/28 12:16:02]

I know Ben was trying to convince us to switch from SkAutoTDelete to unique_ptr,
and mtklein/Hal have been doing some conversions/steps towards switching. We
also have SkAutoTDeleteArray, and both versions now inherit publicly from
unique_ptr, so I think you could use our wrapper classes, but given that we are
in the process of switching over I guess it's fine to switch early.

+
+    SkColorLUT() {}

[scroggo, 2016/04/27 20:18:46]

Can you rely on the generated version? On the other hand, should we disable copy
constructor, which won't do what we want? (Or does having the non-copyable
member fTable do that for us?)

[msarett, 2016/04/27 21:17:58]

I added this constructor in order to make this field const.  Some ICC profiles
don't use this - and then the compiler complains about leaving a const member
uninitialized.

I'm going to have to create some flags/bool to indicate which fields are
actually being used - we'll need this when we start applying these profiles. 
Maybe zero is a good indicator of "not in use".  I'll change this constructor to
zero the struct?
Having a noncopyable member makes this noncopyable.

I tried to explicitly delete the copy constructor because I thought it would be
good documentation.  Ex:
SkColorLookUpTable(const SkColorLookUpTable& that) = delete;

But somehow that causes the use of std::move not to compile...

[scroggo, 2016/04/28 12:16:02]

sgtm

+};
+
 struct SkPM4f;
 void SkApply3x3ToPM4f(const SkFloat3x3&, const SkPM4f src[], SkPM4f dst[], int count);
 
@@ -75,12 +86,17 @@ public:
     static void Test();
     void dump() const;
 
-protected:
-    SkColorSpace(const SkFloat3x3& toXYZ, const SkFloat3& gamma, Named);
-
 private:
-    const SkFloat3x3 fToXYZD50;
+    SkColorSpace(const SkFloat3& gamma, const SkFloat3x3& toXYZ, Named);

[msarett, 2016/04/27 18:56:45]

Reversed the order here to match the new constructor.  I think it makes sense to
list the parameters in the order in which they should be applied.

[scroggo, 2016/04/27 20:18:46]

sgtm

+
+    SkColorSpace(SkColorLUT colorLUT, const SkFloat3& gamma, const SkFloat3x3& toXYZ,
+                 const SkFloat3& toXYZOffset);
+
+    const SkColorLUT fColorLUT;
     const SkFloat3   fGamma;
+    const SkFloat3x3 fToXYZD50;
+    const SkFloat3   fToXYZOffset;
+
     const uint32_t   fUniqueID;
     const Named      fNamed;
 };