[15:37:27] <wiredfool> My one reservation at this point is that the tests don't test for correctness. They test that a file is returned with the right metadata and the right plugin type.
[15:37:46] <wiredfool> Plugin Type is not something I care about, as long as it's an image.
[15:38:20] <wiredfool> But if we replace this with a C implementation, then there's no test that we've done it right. Nor if we run this on a Big endian machine.
[15:38:41] <wiredfool> (but coverage is an excellend 9something percent)
[16:49:23] <jleclanche> wiredfool: there's jpg format but that's super rare and not implemented in the version i gave you
[16:49:35] <jleclanche> everything else is nonlossy
[17:03:14] <wiredfool> jleclanche: it doesn't look wrong from examination. I'd have to trace through it to see if it's doing what I think it is through
[17:03:22] <wiredfool> but now, I've got to make dinner
[17:04:15] <jleclanche> yeah Im off for a while as well
[21:53:37] <wiredfool> two issues: 1, bytes() == str() in py2.x, so that bytes([r,g,b,alpha]) turned into the string '[0, 0, 0, 0]', of which you were taking the first 4 characters.
[21:55:30] <wiredfool> The second is that imagemagick has slightly different bits on the dxt5 image, it's interpreting the color as (00, 6d, ff, ff), where the color should be (00,6c,f8,ff), at least according to the non-imagemagick'd target image for the dxt1 image.