How about just running the pixel comparison only when the checksums don't match? Still not ideal, of course. -Greg.
On Mon, Jun 22, 2009 at 11:30 AM, Ojan Vafai <[email protected]> wrote: > This isn't the best, but it would be easy to add a flag to run-webkit-tests > that told it to always do the pixel comparison even if the checksums > matched. > Ojan > > > On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin <[email protected]> wrote: > >> >> 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<[email protected]> 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<[email protected]> >> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
