Provide three more folios of manually labeled Hufnagel dataset

[JoyfulGen]

• Three more folios of manually labelled Hufnagel. I'll do one from the same manuscript Kyrie used, and two from Saint-Gall 438. @kyrieb-ekat let me know if you'd rather I stick to that manuscript you started with! (Incidentally, what manuscript is it? The file name is just Antiphonal.)
• A new csv mapping file for Hufnagel notation

@Yueqiao12Zhang I'll get those to you as soon as possible!

UPDATE: Here are the resources!

The csv annotation files:

Hufnag_annotations_CantusMAp.22.csv
Hufnag_annotations_St Gall 176v.csv
Hufnag_annotationt_St Gall 022r .csv

The images I used:

Annotated_hufnag_folios.zip

And the mei encoding csv file:

csv_hufnagel_latest.csv

[Yueqiao12Zhang]

Thank you very much! This will help a lot.

I want to confirm on how your mapping file will look like.

Hufnagel-example.csv

This one was by Kyrie, you can just tell me about the differences.

[JoyfulGen]

@Yueqiao12Zhang the mei mapping file isn't quite finished, but it will look like this:

csv_hufnagel.csv

This file different from the one Kyrie gave you; that one (as I understand it) is the list of neumes that she identified in the VGG Image Annotator. I'll also be giving you three more of those when I finish doing my own annotations on three new folios. The csv file attached here, though, is the file that the mei_encoding job in Rodan will need to assign the correct mei encoding to each neume that the IC has found.

• The name column indicates which neume we're talking about. When a neume has one or more numbers after it (podatus2, torculus32), those numbers indicate the interval(s) between the notes of the neume. So 2 is a second, 3 is a third, etc.
• The classification column contains the name that will be given each neume in the IC. The ones that I put in are suggestions based on the system we used for square notation. We can change them later!
• The width column has to do with how the different components of the neume are arranged spatially. You can find an explanation of that here: https://github.com/DDMAL/e2e-omr-resources/wiki/5.0-Resources-for-OMR#understanding-the-mei-mapping-file.
• And the mei column contains the correct (I think!) mei encoding of that neume.

I hope that all makes sense! I'll upload the completed file tomorrow. Please let me know if you have any questions.

[lpugin]

I have a few general questions regarding the encoding and the rendering implementation plan for Verovio.

What is going to be distinguishing Hufnagel (rendering) from the current rendering we have in Verovio. I am assuming this requires more changes than changing a font. Am I right?

If yes, what is going to trigger the Hufnagel rendering? I can see two possibilities. One to have a new value for staffDef@notationtype. Something like neume.hufnagel in the same way we have tab.lute.german. I think that this could be a viable option only if the neume IG can have some sort of a plan (and agreement) of the possible values to expect here. Also, the number of types should remain a small number (i.e., max around 10). For reference, lute has tab, tab.guitar, tab.lute.italian, tab.lute.french, and tab.lute.german. If using @notationtype is not really an option, then we can have a Verovio option.

Whichever solution is used, the next question is whereas the encoding of the neumes (with neumes and nc) differs, if not, then we can have something similar to french and italian tablature, where, with the same encoding, changing the notation type produces a different rendering.

If neumes are encoded differently, then rendering Hufnagel without the appropriate notation type (or Verovio option) would not work (and maybe yield some warnings).

If needed, a having a specific font is also possible (in addition to the notation type or option). Verovio also supports loading a font with only a few glyphs, with fallback to the normal font (Leipzig or Bravura) for all the glyphs not in the font. So that could be a font with even only one or two glyphs. It might be good to keep in mind what will happen if the font is not supplied, though.

One thing we could investigate is the use SMuFL glyph alternates, but this is not implemented in Verovio and I don't know if this is available for neume glyphs. We can look into it.

Sorry if I am missing something (or even the obvious), I am not familiar with Hufnagel notation...

[JoyfulGen]

@Yueqiao12Zhang, here are three new csv files of annotations, along with the three images I used:

Hufnag_annotations_CantusMAp.22.csv
Hufnag_annotations_St Gall 176v.csv
Hufnag_annotationt_St Gall 022r .csv

Annotated_hufnag_folios.zip

I followed the naming system I established in the mei_encoding csv file. I included intervals also, in case you want to use this data as a foundation for Hufnagel neume recognition in general; let me know if that's not useful, and I can easily re-make the annotations without the intervals.

I ended up using folios from St. Gallen, Stiftsbibliothek, Cod. Sang. 438 and Cantus MA Impr. 1537, because those were the two manuscripts @annamorphism pointed out as having the most standard-looking notation.

As for the mei_encoding csv file for Hufnagel notation, I was wrong about finishing it today (sorry!). I ended up with some questions after annotating. @annamorphism, could you take a look at the file here as soon as possible and let me know what you think?

@lpugin I'll answer your questions in another comment, to keep things tidy.

[JoyfulGen]

@lpugin I can't answer all those questions, but I have a bit more info that might be useful to you.

Hufnagel notation is significantly different from square notation, but it uses the same basic neume names. In other words, it also has c clefs and f clefs, virgas, puncta, podati, clives, and the lot, but those symbols are different from the square notation ones. You can take a look at what those neumes look like in Hufnag notation here.

What @annamorphism and I proposed was to use essentially the same mei encodings for the Hufnag neumes as the square notation neumes, and then have them rendered in Hufnagel symbols instead of square notation symbols. This would indeed mean having a completely new font. I think @Yueqiao12Zhang and/or @zih-syuan are working on that. As far as Neon is concerned, we thought of adding a sort of toggle to the upload menu, where users can indicate whether they want to work in square notation or hufnag when they upload and pair new files.

We've been discussing Hufnagel implementation here and I detailed Anna's and my proposition for the mei encoding here.

[Yueqiao12Zhang]

Thank you very much! I have tested out how they work today:

Need further clarification:
What is the meaning of the letter 'a' or 'b' after clivis2?
What is divisio.maior?
I don't see neume.distropha in the MEI cheat sheet. Is it an appropriate encoding?

[JoyfulGen]

Need further clarification: What is the meaning of the letter 'a' or 'b' after clivis2?

There are two types of clives in this notation. The clivis a looks like this:

And the clivis b looks like this:

So for every interval of clivis, there's a clivis a version and a clivis b version. There are more images of both types here.

What is divisio.maior?

The divisio is a vertical line on the staff, that sort of looks like a barline today. The divisio maior is a divisio that only covers half the staff, whereas the divisio maxima covers the whole staff. In this image, the pink box is around a divisio maior, and the blue box is around a divisio maxima.

I don't see neume.distropha in the MEI cheat sheet. Is it an appropriate encoding?

I'm waiting for @annamorphism's opinion on how we should encode this! I'll send you the completed version as soon as we've made a decision. UPDATE: The csv file is complete! I'm going to put it in the first comment of the issue, so that it's easy to find.

Could you try testing it out on this folio? This is from the same manuscript that I used, and I wonder how good of a job it'll do.

[annamorphism]

sorry, where do we not have distropha? (I thought they've been represented in Neon as long as I can remember...)

[annamorphism]

Could you try testing it out on this folio? This is from the same manuscript that I used, and I wonder how good of a job it'll do.

looks like somebody ca. 1580 thought these chants were pretty worthless ("nihil valet") so I hope get better results!

[JoyfulGen]

sorry, where do we not have distropha? (I thought they've been represented in Neon as long as I can remember...)

Oh in here https://docs.google.com/spreadsheets/d/1fU9vMN8HVyFrcK5oFh9SSRsd6SjU1TF0dwYkPAlsgb8/edit?gid=0#gid=0. But if they're in Neon I can go get the mei encoding, one second!

Edit: In fact I cannot see a distropha in Neon. @annamorphism do you know what the mei encoding of it should be?

[annamorphism]

I meant that the "element info" in the sample files on Neon thinks this:

is a distropha :

and it's in the MEI like so:

.

(note that Neon doesn't really care about the head shape for this purpose--two virgas, or a virga and a punctum, or two inclinata, or whatever, would all work as long as they repeat the pitch.)

[Yueqiao12Zhang]

Could you try testing it out on this folio? This is from the same manuscript that I used, and I wonder how good of a job it'll do.

Hi Gen, thank you for giving me more test cases!

In addition to this raw image, the current IC would need a separate JSON/YOLO text file indicating the bbox of the music glyphs to predict correctly. I will ask Kyrie first to see if she can generate one with Mothra annotator.

This is generated end-to-end from raw image to music labels (including YOLO model) without any manual labelling. From my amateur point of view it looks pretty, and it's beyond my expectation.