Werner,
Could you write me a line or two about these shifts we get?
Like: they're going to be some random, non-integer quantity, right?
Also, the rasterization that gets performed, is it anti aliased?
It would seem that though shifts and changes in the lengths of the staves
are "common", small and
> I would like to bring up the question if it is really necessary that
> we do all testing "end-to-end", i.e. from input ly code to
> pixel-based graphical output.
It's definitely necessary to do that, since we regularly had rendering
issues with Ghostscript. However, ...
> IIUC, we have an in
Hi Werner et al.,
I am thinking about a different approach, knowing, that I am likely
missing some details...
I would like to bring up the question if it is really necessary that we
do all testing
"end-to-end", i.e. from input ly code to pixel-based graphical output.
IIUC, we have an intermediate
> On 28 Jul 2024, at 20:43, Werner LEMBERG wrote:
>
>>> On top of the MAE algorithm we currently use, another algorithm
>>> might increase the penalty for small feature differences so that it
>>> is above our threshold.
>>
>> It gets into the construction of image comparison algorithms.
>> Per
>> On top of the MAE algorithm we currently use, another algorithm
>> might increase the penalty for small feature differences so that it
>> is above our threshold.
>
> It gets into the construction of image comparison algorithms.
> Perhaps using some exponential for differences, or make another
>
> On 28 Jul 2024, at 19:49, Werner LEMBERG wrote:
>
>>> I'm quite sure that behind the scene, for all GUIs, a metric gets
>>> computed to decide whether there are differences at all. We 'just'
>>> have to find one that fits our needs.
>>
>> It looks like you want a different property than an
>> I'm quite sure that behind the scene, for all GUIs, a metric gets
>> computed to decide whether there are differences at all. We 'just'
>> have to find one that fits our needs.
>
> It looks like you want a different property than an average metric,
> so perhaps what you have can be modified
> On 28 Jul 2024, at 16:26, Werner LEMBERG wrote:
>
>
>>> Anyway, AFAICS, it doesn't provide what we need for LilyPond.
>>
>> It seems hard to find what you are asking for, as most programs are
>> GUI oriented.
>
> I'm quite sure that behind the scene, for all GUIs, a metric gets
> computed
>> Anyway, AFAICS, it doesn't provide what we need for LilyPond.
>
> It seems hard to find what you are asking for, as most programs are
> GUI oriented.
I'm quite sure that behind the scene, for all GUIs, a metric gets
computed to decide whether there are differences at all. We 'just'
have to
> On 28 Jul 2024, at 12:05, Werner LEMBERG wrote:
…
> Anyway, AFAICS, it doesn't provide what we need for LilyPond.
It seems hard to find what you are asking for, as most programs are GUI
oriented. Some inputs, though: A program switching the images so that
differences like in your example ca
> I made a net search on “image compare program”, and found the link
> below. It does capture the image difference in your post above,
> music is listed as an application, and it says it is “open source”
> without detailing.
>
> https://www.robots.ox.ac.uk/~vgg/software/image-compare/
Thanks.
> On 27 Jul 2024, at 18:56, Werner LEMBERG wrote:
>
> I've posted a question on StackExchange, searching for a better
> regtest comparison algorithm
>
>
> https://computergraphics.stackexchange.com/questions/14143/search-for-special-image-difference-metric
I made a net search on “image comp
Am Sa., 27. Juli 2024 um 18:56 Uhr schrieb Werner LEMBERG :
>
>
> I've posted a question on StackExchange, searching for a better
> regtest comparison algorithm
>
>
> https://computergraphics.stackexchange.com/questions/14143/search-for-special-image-difference-metric
>
>
> Werner
>
We also
13 matches
Mail list logo
