-
Notifications
You must be signed in to change notification settings - Fork 6
FAQ
I've uploaded the resources I need for my workflow, but they're not appearing in the 'Available Resources' list of the input port resource assignment pop-up.
Most probably, this is just rodan taking its time. There can be a delay between uploading a file and that file actually appearing in the 'Resources' list. If you uploaded a resource right before opening the workflow, it might not appear in the 'Available Resources' list right away. All you have to do is leave the workflow page and come back to it and the file should appear. If it still doesn't, check that the file type is correct. The required file type for every input port is listed in the diagrams of each workflow (which you can find here for Pixel, here for the Interactive Classifier, and here for the end-to-end OMR workflow). If the file type of an uploaded file is wrong, that file won't show up in the 'Available Resources' list. On Rodan, the file type of a resource is listed after its name, under 'Type'. If the resource type is not what it should be, two things are possible:
- Check the original file you uploaded to make sure it's the correct type. If it's not, you'll have to convert it to the correct type before uploading it to rodan.
- If you definitely uploaded the correct file type but rodan is calling it something else, you can change a file type by selecting the resource and scrolling to the bottom of the right-hand menu. You should see a drop-down menu titled 'Type'. You can select the correct file type there.
That's just a Rodan quirk! It doesn't impeded Rodan's functions in any way, it just means you can't align your jobs nicely and keep them that way.
The Background removal job is removing elements from the foreground as well. How do I get them back?
As things are now (November 2024), you can't get elements back that have been removed by the Background removal job. If you feel that too many elements are missing, it's best to remove the job altogether. This will mean more work for the first Pixel iteration, because you have to paint over all the elements yourself. However, after that first iteration you can use the Fast Pixelwise job to pre-separate the layers. This usually works quite well, even in the early stages, so you really only have to do all the work once.
I've clicked on the black square and closed the tutorial pop-up, but I can't find the layer editing tools.
The layer editing tools are hiding at the bottom of the page, beneath the folio image. You can scroll down to them by bringing your mouse below the folio image, or using the scroll bar to the right of your screen.
This can happen in two ways: pixel is taking a moment to load, or an image size mismatch is at hand in a later iteration of pixel. In the first case, you can troubleshoot by zooming in a few degrees within pixel then to the original and it might snap to the correct place. Otherwise, try zooming in and out using your browser (command + for mac, ctrl + for windows etc.). From there, closing out and reopening the pixel tab can correct for this. In the second case, this usually happens if you are in an ensuing iteration of pixel, wherein you're using produced layers from the classifying job to "predict" pixel layers. You may have already done this image, or the image you've put into the classifying job at the top of the workflow is significantly larger (or smaller) than the original image. Try to keep your manuscript images all about the same size; if you need to resize your images make sure you're consistently resizing them by the same amount (e.g., always 50%, not sometimes 30% and sometimes 70%).
This may be for a few reasons.
- The images you're trying to add are too different. Backtrack a little to the most recent model which did work, and add one single new patch at a time. I recommend starting with a single page and its immediate neighbors. It is possible you may need to make distinct models per section of a manuscript or document (e.g., "early manuscript model" versus "late manuscript model").
- You don't have enough samples! There are twenty available sample inputs- you can use them all! Make sure you're grabbing multiple samples (at least two) per page.
- You don't have a training file as an input. You can use previous training files as inputs- experiment by adding other models which had worked successfully.
- The training isn't actually improving per round. Right click, or click and select 'settings', on the
Trainingjob in the workflow, and reduce epochs. The default is often significantly higher than what you actually need—try reducing to ten and move from there. This will also speed up your training time.
The most probable thing happening is that your number of output ports doesn't match your number of input ports. If you have five input ports (Image, Model 1, Model 2, Model 3, Background Model), you should have four output ports (Layer 1, Layer 2, Layer 3, Background layer). Even if you're only using Layer 1 in the Interactive Classifier workflow, the job will fail if it doesn't have the correct number of output ports.
I've finalized one run of classification and am using that data to classify another folio, but none of my previously classified glyphs are showing up in the 'Classified Glyphs' tab.
Two possible things could be happening:
- You haven't added the 'Gamera XML - Training data' input port to the
Interactive Classifierjob. Add that port and assign it the 'Training data' file from your last IC workflow. That should fix the problem! - You're mistakenly using your 'Classified Glyphs' in the 'Gamera XML - Training data' input port. Use the 'Training data' file instead and the 'Classified Glyphs' tab should be full!
The first thing to do here is to check the glyphs in the 'Classified Glyphs' tab to make sure that you haven't mistakenly classified a weird glyph as a neume. If all the classified neumes in that specific category look pristine, then there are two things that can help:
- One possible issue is that that specific neume class is just too big. If one neume category has significantly more neumes in it than the others (like if you have, say, 100 examples of puncta, but only 5 examples of podati), the IC will tend to gravitate towards that "heavier" category if it's not sure. It's best to try to keep all the neume categories as equal as possible.
- Another potential problem is that the weirdly shaped glyphs have nowhere to go. The IC has to classify every glyph it encounters; it doesn't know to dismiss a weird neume unless we teach it to. The way to do this is to create 'skip' classes. You can create several: skip.dot for dots, skip.patch for patches, skip.line for horizontal lines. Unlike the neume classes, where the name is extremely important, you can name the skip classes whatever you want! The whole point of them is that they don't have an assigned code in the MEI encoding file, so they'll disappear.
After all this, it's important to remember that the IC will eventually reach a point where it can't do better, regardless of how much more data you give it. When you recognize that you've reached that point, you'll know it's time to stop. Future mistakes can be fixed in Neon!
Regrettably we do not yet have the ability to de-select a glyph if it has been accidentally grabbed in a highlight (when you click and drag over an area to grab all glyphs) or when you are attempting to grab only one thing at a time. It is possible to grab multiple items at a time, either by clicking and dragging a field over the glyphs you want to select, by holding down shift while you click the glyphs you want to group on the image, or by holding down shift and clicking the glyphs inside the glyph window at the top of the page.
The most probable thing happening is that your number of output ports doesn't match your number of input ports. If you have five input ports (Image, Model 1, Model 2, Model 3, Background Model), you should have four output ports (Layer 1, Layer 2, Layer 3, Background layer). Even if you're only using Layer 1 in the Interactive Classifier workflow, the job will fail if it doesn't have the correct number of output ports.
Some of the layers coming out of Fast Pixelwise Analysis of Music Document, Classifying are completely empty.
The first thing to do is check that the output ports of the Fast Pixelwise job are correctly assigned to each column: layer 1 should go in the column on the left, layer 2 should go in the middle column, and layer 3 should go in the column on the right. The background layer shouldn't connect to anything.
If the ports are correctly assigned, then things might be trickier. One common problem is if the specific folio you're using is particularly damaged or faded; that can make it very difficult for the layer separator to do a good job. Check if other folios also produce empty layers; if not, then you might just have to correct the faded folio manually in Neon. If other folios are also not working, then either your layer separation training data isn't sufficient, or there's a problem with the job. Please report all issues here.
When I upload the file to Neon, there are a lot of glyphs on the margins of the page, or in other places that are not on the staff.
This is happening because "noise" on the page, like stains or bleed-through or creases, is being included in your layer 1 and then classified as neumes by the NIC. The longer solution is to go back to the Interactive Classifier step and refine the training data to exclude the noise as much as possible (this other FAQ could be useful). If you prefer to stay within the end-to-end OMR stage (fair), then you can change the settings of the Despeckle job of the left-most column of the OMR workflow. The purpose of that job is to reject any element of layer 1 that is smaller than a number of pixels you specify. The default number is 1, which means that every element, no matter how small, makes it through to the NIC. If you make that number higher, you'll be getting rid of a lot of small elements of noise. The ideal number really varies from manuscript to manuscript, so we recommend starting at 25 and going from there; if the job is removing too many glyphs from the folio, then make the number smaller, and if you're still seeing too many little spots, make the number bigger.
When I upload the file to Neon, I'm noticing that a specific glyph is systematically missing from the folio--I can see no inclinata, or no virgae, for example.
It's quite possible there's a discrepancy between the name you gave this glyph in the IC and the classification of that glyph in the MEI-encoding .csv file. When the MEI encoding job comes across a glyph name that is not present in the csv file provided, it can't encode that glyph, so it dismisses it. For example, if you called all stepwise podati 'neume.podatus.2' in the IC and they're classified as 'neume.podatus2' in your csv file, none of the podati identified by the IC will be encoded by the MEI encoding job, and your final transcription will be devoid of any stepwise podati.
If you definitely gave your glyph the correct name, then the IC is just having trouble identifying it. Make sure you have enough good-looking examples of that glyph in your training data. Also remove any partial or overly unusual glyphs from your training data. If the missing glyph is particularly fine or small, you may need to change the settings in your Despeckle job (see previous question).
This is because your layer separation models were only trained to recognize one colour of staff line. Because the staves are a different colour, no staff lines are found, so layer 2 is completely empty, so MEI encoding has nothing to encode and it fails. You have two options:
- If you have more than 10 or so folios with this new colour of staff, we recommend going back to the Pixel step and specifically training it to include the new colour of staff in layer 2.
- If you don't have too many folios with the new colour of staff, then it might actually be more efficient to just correct those outliers by hand. You can upload the folio pictures to Neon and select 'Create new MEI file' to do so.