Yes we do need a few tests set aside for this. Agreed. I was thinking about antialiasing and such, it's possible a different approach might work: render at a somewhat higher resolution, then backshift and blur everything a bit (say a gaussian of 2 pixels or so, just a touch). That might make enough of a "moat" between good and bad to make it fine for comparisons
On Tue, 30 Jul 2024, 11:30 Han-Wen Nienhuys, <hanw...@gmail.com> wrote: > On Mon, Jul 29, 2024 at 11:10 AM Werner LEMBERG <w...@gnu.org> wrote: > > > > > > >> It would seem that though shifts and changes in the lengths of the > > >> staves are "common", small and relatively benign problems, > > >> rotations and scales (magnifications) should be considered major > > >> disasters, right? > > > > > > Rotations do not generally happen. Virtually all the positioning is > > > rectilinear, and scaling is also not common. What happens that > > > objects end up in different locations, and sometimes variable > > > objects (slurs, beams) have different sizes. > > > > BTW, I got an interesting reply on StackExchange; maybe you two (Luca > > and Han-Wen) want to comment on it. > > > > > https://computergraphics.stackexchange.com/questions/14143/search-for-special-image-difference-metric/14145 > > AFAICT, this just does some fuzzing so that single-pixel > differences/shifts do not generate differences. > > I had an idea of what one could do, but really, we first need a > representative test set of image pairs, both pairs with important > differences and spurious differences, so we can see what a new > algorithm looks like. > > The idea is that we'd want to trigger less on diffuse lines of > difference (shifted staffline), but more on concentrated blobs > (disappearing symbol). Here is a suggestion > > * generate images without anti-aliasing > * generate the image diff > * for each changed pixel, count the number of changed neighbor pixels. > * for each pixel, take max(changed - THRESHOLD, 0) > * then do MAE or some other metric on that image. > > By setting THRESHOLD = 2, you could make single line differences > disappear. (We'd need to make sure to make the resolution such that > stafflinethickness is at least 2 pixels, or otherwise dramatic changes > in staff positioning would not trigger anything.) > > Alternatively, on the diff image, you could segment the diff into > connected components, and weight the errors by the minimum of {x-size, > y-size}. Thus, a line has a diameter of only 1 pixel, but missing > notehead is much larger. > > Without a test set, it's hard to see if this is really a big > improvement, though. > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen >
