Just so I'm not all negative, my suggestions after consulting with Tony:
1) Make Linux behavior match Windows, ignoring the recommendation in
the comments below.
2) Rebaseline everything on Linux. :(
3) Now converting from a PNG file to expected output is easy on all
three platforms:
convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum
(Not certain if Mac uses BGRA images, though.)
On Mon, Jun 22, 2009 at 10:24 AM, Evan Martin<e...@chromium.org> wrote:
> Since I'm waiting for a build I sat down to implement this.
>
> But our image checksums are not checksums of the image files :(, but
> rather checksums of the pixels stored in the image.
>
> And Tony points out that our image checksumming is completely insane:
>
> =====
> // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want
> // to keep it. On Windows, the alpha channel is wrong since text/form control
> // drawing may have erased it in a few places. So on Windows we force it to
> // opaque and also don't write the alpha channel for the reference. Linux
> // doesn't have the wrong alpha like Windows, but we ignore it anyway.
> #if defined(OS_WIN)
> bool discard_transparency = true;
> device->makeOpaque(0, 0, src_bmp.width(), src_bmp.height());
> #elif defined(OS_LINUX)
> bool discard_transparency = true;
> #elif defined(OS_MACOSX)
> bool discard_transparency = false;
> #endif
>
> // Compute MD5 sum. We should have done this before calling
> // device->makeOpaque on Windows. Because we do it after the call, there are
> // some images that are the pixel identical on windows and other platforms
> // but have different MD5 sums. At this point, rebaselining all the windows
> // tests is too much of a pain, so we just check in different baselines.
> ====
>
> To be more clear, here's a table of the platforms and their behaviors.
> O=opaque, T=transparent.
> (Sorry for my ghetto proportionally-spaced table here.)
>
> Win Mac Lin
> cksum O T T
> png O T O
>
> I conclude that on Linux, you cannot go from the PNG file back to the
> checksum in the presence of alpha.
>
>
> Just for fun I played around a bit with commands like:
> convert path/to/pngfile rgba:- | md5sum
> and wasn't able to repro the checksums I'm seeing.
>
> It looks ok from
> convert path/to/pngfile rgba:- | xxd -g4
> (the RGBA<->BGRA problem doesn't apply for this black and while png file...).
>
> In summary: tears.
>
> On Mon, Jun 22, 2009 at 3:20 AM, Dean McNamee<de...@chromium.org> wrote:
>>
>> Last week I updated our DEPS to pull in a newer version of Skia. I
>> was stumped at a few cases where the checked in PNG looked completely
>> wrong, but yet it was passing on the buildbots. There was no way that
>> image could have been the output.
>>
>> It just dawned on me today, but I haven't verified it. I can dig up
>> my commit to verify it, but I'd say 99% sure this was the case.
>>
>> If the checksum is valid, we don't even go to the PNG. Therefor I
>> believe we have a bunch of layout tests where the checked in PNG is
>> completely wrong, but the checksum is right.
>>
>> I don't have the time right now, but it would be great if someone
>> could write a script and clean this up.
>>
>> Thanks
>> -- dean
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
