On Thu, Nov 25, 2010 at 05:45:36PM -0000, Phil Holmes wrote: > It wouldn't take me long to write a C# program (less than a day, I'd > guess) that reproduced quite a lot of the regtest checker > functionality and did a pixel-by-pixel check for image changes.
Hmm. It shouldn't take a huge amount of time to compare each pair of regtest images -- they're named, so you'd be comparing something like 500 pairs of .png images. (Neil: were you thinking of something else?) The bigger concern is about false positives. If your program notified you about any pair of images with any pixel differences, you'd be swamped with meaningless changes. Our regtest checker does some kind of thresholding which doesn't display significantly changed images, but I'm not certain how that works. I don't think you can just look at the number of changed pixels. A tiny change to spacing could give you a huge number of changed pixels [which wasn't important], while a missing augmentation dot [a serious problem] would only give you a tiny number of changed pixels. Then again, we're not talking about relying on this new checker exclusively, and the current system isn't perfect either. I don't think that using both systems would add a huge amount of extra time to the Bug Squad duties. > I've done the latter bit in about 20 minutes on the figured bass png > that started this discussion. The difference file it produces is > attached. I'd be quite happy to do this, but wouldn't do it if it > was felt to be stepping on other toes. I don't know python well > enough to try looking at the existing file. I realise this couldn't > be run as part of the build process, since it's windows only, but > I'd be happy to run it locally and when I shuffle off the coil > others _could_ do the same. You wouldn't be stepping on toes, but writing it in C# introduces a few inefficiencies, which you noted: - can't be added to the build process. (no, I cannot forsee ever adding mono to gub) - most developers can't use it [without installing mono]. I have two alternate suggestions: 1) write it in C#, then add a Frog tracker issue to port it to python. If there's an existing, working, program, then writing a python version would be easier. 2) treat this as a long-term project, and slowly write a python version yourself. We use python a lot in lilypond, and it's quite a nice and easy-to-learn language, so learning python could have other benefits down the road. (potentially in your daily job, in addition to lilypond stuff) I'm *not* suggesting that you try to modify the existing python script or the build process -- writing a separate python script to do your comparison would be much easier. Once such a script exists, it could be merged into the build process relatively easily. Cheers, - Graham _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
