Hash .pngs instead of SkBitmaps.

Hash .pngs instead of SkBitmaps.

This has the nice property of being able to double-check hashes after the fact.

mtklein@mtklein ~/skia (hash-png)> md5sum bad/8888/3x3bitmaprect.png
deede70ab2f34067d461fb4a93332d4c  bad/8888/3x3bitmaprect.png

mtklein@mtklein ~/skia (hash-png)> grep 3x3bitmaprect_8888 bad/dm.json
   "3x3bitmaprect_8888" : "deede70ab2f34067d461fb4a93332d4c",

I have checked that no two premultiplied colors map to the same unpremultiplied
color (math nerds: unpremultiplication is injective), so a change in
premultiplied SkBitmap will always imply a change in the encoded
unpremultiplied .png.  This means, it's safe to hash .pngs; we won't miss
subtle changes.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/e2d4eb70724475035d6148ba279f9cb1c2433564

[mtklein, 2014-09-08 19:09:32]

mtklein@google.com changed reviewers:
+ jcgregorio@google.com, mtklein@google.com, stephana@google.com

[jcgregorio, 2014-09-08 19:15:38]

On 2014/09/08 19:09:32, mtklein wrote:

LGTM

[mtklein, 2014-09-08 19:34:24]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-09-08 19:35:29]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/549203003/60001

[commit-bot: I haz the power, 2014-09-08 19:42:26]

Committed patchset #4 (id:60001) as e2d4eb70724475035d6148ba279f9cb1c2433564

[mikerreed, 2014-09-09 03:26:27]

On 2014/09/08 19:42:26, I haz the power (commit-bot) wrote:
> Committed patchset #4 (id:60001) as e2d4eb70724475035d6148ba279f9cb1c2433564

Are all png compressors precisely the same? I thought there were chunks/parts of
the stream that were optional/etc, which might generate different hashes, but
whose pixels (when decoded) would be equal.

[jcgregorio, 2014-09-09 12:22:04]

On 2014/09/09 03:26:27, mikerreed wrote:
> On 2014/09/08 19:42:26, I haz the power (commit-bot) wrote:
> > Committed patchset #4 (id:60001) as e2d4eb70724475035d6148ba279f9cb1c2433564
> 
> Are all png compressors precisely the same? I thought there were chunks/parts
of
> the stream that were optional/etc, which might generate different hashes, but
> whose pixels (when decoded) would be equal.

But does it matter? The files are only written by DM which should serialize them
the same way, but even if it didn't would it make a difference since the hash is
really just a way to identify the file. We're planning on storing a list of
hashes
that are valid per test, so the determination of equality isn't done by hash but

is instead stored within skiacorr.com.

[reed1, 2014-09-09 13:01:34]

On 2014/09/09 12:22:04, jcgregorio wrote:
> On 2014/09/09 03:26:27, mikerreed wrote:
> > On 2014/09/08 19:42:26, I haz the power (commit-bot) wrote:
> > > Committed patchset #4 (id:60001) as
e2d4eb70724475035d6148ba279f9cb1c2433564
> > 
> > Are all png compressors precisely the same? I thought there were
chunks/parts
> of
> > the stream that were optional/etc, which might generate different hashes,
but
> > whose pixels (when decoded) would be equal.
> 
> But does it matter? The files are only written by DM which should serialize
them
> the same way, but even if it didn't would it make a difference since the hash
is
> really just a way to identify the file. We're planning on storing a list of
> hashes
> that are valid per test, so the determination of equality isn't done by hash
but
> 
> is instead stored within http://skiacorr.com.

If DM is solely used by the bots, then it may not matter. If it is a general
tool for testing, then it may be valuable to pick a metric that is usable in
multiple contexts.

[mtklein, 2014-09-09 14:24:06]

Took me a while to get there, but I'm back to thinking hashing the original
SkBitmap was correct.  We want to be testing Skia, not Skia plus some arbitrary
PNG encoder.

Naming files based on their own hashes is nice, but I think we can depend on
Google Storage for consistency rather than have to check it ourselves.  In the
worst case, we'll find a file's corrupted and just delete it and rebaseline.

On the other hand, naming files based on the hash of their original content will
improve our sharing ratio.  We'll have baselines per test, which is nice on all
fronts: storage, computation, rebaselining cognitive load, and as a sort of
converge-all-the-platforms progress meter.

Going to undo this as part of landing those other pending CLs.