Interesting concept. Like you, I also have been unable to dedicate typing time to the problem, but I didn't stop musing about how to do this. I have prototypes from that feature tracking idea, but they're not as conclusive as they could be. While working on them, one thought I had was about the meaning of "large" vs "small" difference between two images. And I must admit, maybe due to my graphics background, the idea of tracking the objects instead of the pixels, still seems like the better concept to me.
I do find your concept interesting though, I'm not sure what smoothing filter you're using, but I wonder if this is a case where traditionally "bad" filters would actually be advantageous here. Usually the "box" filter is considered the worse, on account of the substantial ringing it exhibits. Your description of the effect of the filtering captures well what happens when the difference is "well inside" the kernel's support, but I'm wondering what can be gained by reasoning about the effect of the edges: for result pixels coming from a kernel position that "cuts in half" a region of difference, what happens? If your filter has nice smooth tails, like a gaussian or whathaveyou, there will be "no effect" when the size of the difference is small wrt the size of the kernel, while there will be a larger and larger difference as the two sizes become close to each other. If your filter has marked sharpening in it, say like a sinc, catmull-rom, mitchell/netravali, it'll probably have a somewhat beneficial border effect that might help difference detection, while possibly being a little less hysterical about the "arrival" of a difference like a "box" would. Everywhere-positive kernels like hann, hamming, blackmann-harris, I would suspect will perform somewhere half way between the mush of the gaussian and the happytrigger-ness of a sharp-cutoff filter. Seems like this should be studied across a variety of input differences. -- Me, I had been musing if instead one could simply scan the EPS or PDF and put all objects into a quadtree, potentially even allowing for a modicum of scene alterations to score extra low (if the staff moves down 2 pixels all noteheads will have moved "for no real good reason", but that seems like a condition that's real easy to detect). Once you have a global scene-to-scene (score-to-score) transform, you discount that, and use minimum distance to reconcile objects, and then report on objects present on one side only, or with distances that are inappropriate (vertical seems like it would be a _much_ bigger deal than horizontal, for example). I never started writing this on account of Werner's worry that this would turn into too big of a rewrite, though. Anyways, I decided now to leave a note about it At this time I am very busy with work and some renovations at my house, and unfortunately I have no time to dedicate to this kind of thing. I expect this to ease up in a few months. I do read these messages with much interest, though L On Sat, Jun 14, 2025 at 8:59 PM Dan Eble <nine.fierce.ball...@gmail.com> wrote: > On 2025-06-14 14:24, Han-Wen Nienhuys wrote: > > didn't look around for test data; if someone can point me to commits that > > yield interesting image diffs, that would be helpful. > > The most recent example that comes to mind is mentioned in > https://gitlab.com/lilypond/lilypond/-/merge_requests/2675#note_2538235937 > > Less-recent changes with interesting below-threshold differences relate > to dashed and dotted bar lines. git log -S "dashed bar" or "dotted bar". > > 152a28103106cbe6556c40dc40a544cf8bd94136 fixed intermittent differences > in dot placement. That looks like it would be relatively easy to > revert, but you might have to run the test many times to see the problem. > -- > Dan > > > -- Luca Fascione
