[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: search for better regtest comparison algorithm
From: |
Luca Fascione |
Subject: |
Re: search for better regtest comparison algorithm |
Date: |
Tue, 30 Jul 2024 11:47:48 +0200 |
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, <hanwenn@gmail.com> wrote:
> On Mon, Jul 29, 2024 at 11:10 AM Werner LEMBERG <wl@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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
>
- Re: search for better regtest comparison algorithm, (continued)
- Re: search for better regtest comparison algorithm, Werner LEMBERG, 2024/07/27
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/27
- Re: search for better regtest comparison algorithm, Werner LEMBERG, 2024/07/27
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/27
- Re: search for better regtest comparison algorithm, Michael Käppler, 2024/07/28
- Re: search for better regtest comparison algorithm, Werner LEMBERG, 2024/07/29
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/29
- Re: search for better regtest comparison algorithm, Han-Wen Nienhuys, 2024/07/29
- Re: search for better regtest comparison algorithm, Werner LEMBERG, 2024/07/29
- Re: search for better regtest comparison algorithm, Han-Wen Nienhuys, 2024/07/30
- Re: search for better regtest comparison algorithm,
Luca Fascione <=
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/30
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/29
- Re: search for better regtest comparison algorithm, Han-Wen Nienhuys, 2024/07/29
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/29
- Re: search for better regtest comparison algorithm, Werner LEMBERG, 2024/07/29
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/29
- Re: search for better regtest comparison algorithm, Michael Käppler, 2024/07/31
- Re: search for better regtest comparison algorithm, Werner LEMBERG, 2024/07/29
- Re: search for better regtest comparison algorithm, Luca Fascione, 2024/07/29
- Re: search for better regtest comparison algorithm, Han-Wen Nienhuys, 2024/07/29