On 5/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Johannes Schindelin wrote:
> No. A perfect match would be 1. Which means that file should _not_ be
> flagged.
well whatever. I think it is wise to do a division, if only to get a
scale-free measure.
I'll think about it a bit more, but w
Johannes Schindelin wrote:
Hi,
On Thu, 4 May 2006, David Feuer wrote:
On 5/4/06, David Feuer <[EMAIL PROTECTED]> wrote:
Hm hm... Dividing by the area of the union is bad. Maybe divide by
the area of the old ones?
Wait a sec I'm not sure dividing by the area of the union is
really bad.
Hi,
On Thu, 4 May 2006, David Feuer wrote:
> On 5/4/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Wed, 3 May 2006, David Feuer wrote:
>
> > > If we're looking to measure small changes, area of union minus area of
> > > intersection, divided by the area of the union, woul
Hi,
On Thu, 4 May 2006, David Feuer wrote:
> On 5/4/06, David Feuer <[EMAIL PROTECTED]> wrote:
>
> > Hm hm... Dividing by the area of the union is bad. Maybe divide by
> > the area of the old ones?
>
> Wait a sec I'm not sure dividing by the area of the union is
> really bad. Getting a v
On 5/4/06, David Feuer <[EMAIL PROTECTED]> wrote:
Hm hm... Dividing by the area of the union is bad. Maybe divide by
the area of the old ones?
Wait a sec I'm not sure dividing by the area of the union is
really bad. Getting a value near 1 somewhere should be plenty to flag
the file.
Da
On 5/4/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
Hi,
On Wed, 3 May 2006, David Feuer wrote:
> If we're looking to measure small changes, area of union minus area of
> intersection, divided by the area of the union, would probably be
> good.
If a really nasty bug creeps in, which mak
Hi,
On Wed, 3 May 2006, David Feuer wrote:
> On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>
> > There are various ways of comparing numbers. The point is that you need
> > to know which pairs of numbers/rectangles/etc. to compare. For that, you
> > need to get the elements in a canon
David Feuer schreef:
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
There are various ways of comparing numbers. The point is that you need
to know which pairs of numbers/rectangles/etc. to compare. For that, you
need to get the elements in a canonical order, and that *must* be done
w
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
There are various ways of comparing numbers. The point is that you need
to know which pairs of numbers/rectangles/etc. to compare. For that, you
need to get the elements in a canonical order, and that *must* be done
with discrete quantitie
David Feuer schreef:
On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
If you have two different versions of LilyPond, the same object could be
subtly moved between the two. But if you measure the area of the overlap
area between old and new bbox, you have a pretty good idea how much th
David Feuer schreef:
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
You're relying on specifics of music notation, eg. existence of ledger
lines and bar lines. What do you do when there are just lyrics or chord
names, or when there are no barlines (unmetered music) or no noteheads
(clus
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
You're relying on specifics of music notation, eg. existence of ledger
lines and bar lines. What do you do when there are just lyrics or chord
names, or when there are no barlines (unmetered music) or no noteheads
(clusters).
I think a more
On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
If you have two different versions of LilyPond, the same object could be
subtly moved between the two. But if you measure the area of the overlap
area between old and new bbox, you have a pretty good idea how much the
result deviates from
Hi,
On Tue, 2 May 2006, David Feuer wrote:
> On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
>
> >
> > This is worse than what Han-Wen suggested. His suggestion is easy, makes
> > sense and would improve development. Why come up with other ideas?
>
> I don't understand what he means
On 5/2/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
This is worse than what Han-Wen suggested. His suggestion is easy, makes
sense and would improve development. Why come up with other ideas?
I don't understand what he means by bbox overlap areas. Maybe that's
my problem?
David
Hi,
On Tue, 2 May 2006, David Feuer wrote:
> One possibility: Take all image elements (on a high level I guess
> this would be grobs, on a low level it'd be stencil pieces). Separate
> them by type (stems here, noteheads there; rectangles here, glyphs
> there), and within each type sort them by
Hi,
On Tue, 2 May 2006, David Feuer wrote:
> On 5/1/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
>
> > You cannot just compare PNGs. The really important information is: where
> > is the object, not: what color is that pixel. Just think about the
> > consequences of a small adjustment of t
David Feuer schreef:
One possibility: Take all image elements (on a high level I guess
this would be grobs, on a low level it'd be stencil pieces). Separate
them by type (stems here, noteheads there; rectangles here, glyphs
there), and within each type sort them by left edge of bounding box,
bo
On 5/2/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
How will you deal with two images that have different sizes? What will
happen if the entire 2nd image is shifted vertically and horizontally by
two pixels. This typically gives a huge difference (all staff lines and
stems will no longer over
David Feuer schreef:
On 5/1/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
You cannot just compare PNGs. The really important information is: where
is the object, not: what color is that pixel. Just think about the
consequences of a small adjustment of the position. The difference of the
PN
On 5/1/06, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
You cannot just compare PNGs. The really important information is: where
is the object, not: what color is that pixel. Just think about the
consequences of a small adjustment of the position. The difference of the
PNGs is potentially quit
David Feuer schreef:
On 5/1/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Given that we haven't had anyone writing or modifying the backend in the
past 5 years, I doubt that there is much need for this.
I've been working on it ...
yes, but using your work as an argument for your work is a
Hi,
On Mon, 1 May 2006, David Feuer wrote:
> On 5/1/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>
> > it should take geometry and appearance into account, ie. where the
> > symbols end up on the page, and how large they are. What I would really
> > want is to have a similarity measure for th
On 5/1/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Given that we haven't had anyone writing or modifying the backend in the
past 5 years, I doubt that there is much need for this.
I've been working on it ...
it should take geometry and appearance into account, ie. where the
symbols end u
David Feuer schreef:
On 5/1/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
I don't see who would benefit from a refactoring of the backend, so IMO
it's a waste of time. By contrast, having a continuous distance measure
between different outputs would speed development up tremendously,
because
On 5/1/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
I don't see who would benefit from a refactoring of the backend, so IMO
it's a waste of time. By contrast, having a continuous distance measure
between different outputs would speed development up tremendously,
because we will be able to sp
David Feuer schreef:
One of the major problems is that we don't have a reliable way to test
LilyPond automatically: the output is a PDF file, and changes in
formatting may subtly alter PDF files between versions, which throws off
a diff or cmp with a reference file.
This sounds interesting. I
On 4/30/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
David Feuer wrote:
> On 4/27/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
>
One of the major problems is that we don't have a reliable way to test
LilyPond automatically: the output is a PDF file, and changes in
formatting may subtly alt
David Feuer wrote:
On 4/27/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Frankly, I'm a bit mystified why you're spending so much time on
building the ultimate postscript backend. The backend is not a
performance bottleneck. If you think the current PS code is inefficient,
then you should ha
On 4/27/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Frankly, I'm a bit mystified why you're spending so much time on
building the ultimate postscript backend. The backend is not a
performance bottleneck. If you think the current PS code is inefficient,
then you should have a look at the res
30 matches
Mail list logo
