-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
java.lang.NegativeArraySizeException: -19035 on score from IMSLP220542 #531
Comments
Sooo... Just for fun I tried to debug this. 😄
At this point I'm out because I don't know exactly where the mistake happened. Are the calculated line clusters (first image) okay or are they wrong already? I'm certain @hbitteur could give us an insight 😉 |
Yes, Audiveris had problems with staff 7 and staff 10, clusters of staff lines separated by poor line portions did not get merged properly. Subsequent processing failed of course. So, we now have to investigate why the clusters merge failed. |
The problem is that there are almost no line segments on staff 7 to derive lines from. |
I don't know if we should keep this rather small run length value. The risk is of course to get a lot of false candidates for line portions.
In this case, it was obviously a good choice. |
With default 1.0 interline fraction, we have these filaments (on staff 7):
With 0.25 interline fraction, we now get these filaments (on the same staff 7): These snapshots explain the result. |
IMSLP is full of low quality, low resolution scans especially if they were made from older (last century) editions like the said sheet. The best solution is to re-scan the score with a higher resolution. |
Yes, of course. However, such exceptions drop the complete result, even if parts of later pages might be useful for faster recreation of a score. So, in my opinion, a useful goal for Audiveris would be "survive (almost) any score; but recognize only what's sufficiently clear". Re parameter adjustment, for an occasional user (again, like me), it's hopeless to know which parameters to modify and how. But this is a separate (usability) problem, and might actually be solved - or improved - by examples like hbitteurs, where I learned about minRunLength. Harald M. |
In Audiveris code, there is (I'd better say: should be) no technical constant hard-coded in the algorithms. A good example from the score at hand is this minimum length for a staff line candidate segment. A reasonable minimum length was set at 1.0 times the main interline value, rather arbitrarily but based on concrete input scores. So, when I ran Audiveris application on your score, I noticed the undetected staff and quickly suspected a lack of line segments to derive the staff lines from them. Advantage of the "Constants", any user can modify them, which I did: I reduced the minimum length from 1.0 down to 0.25 the interline value. And the result was OK on this example, so I posted this as a plain and temporary workaround for the case at hand. Later, I officially committed (0eb1894) this new value. But, FYI, this introduced a problem with some symbol extraction, that needed to be fixed (see commit d666582). These constants are not meant for the casual end user, this must be clear. It's only a low-level mechanism, and most high-level user actions usually end up playing with these hidden low-level constants. We have more than 800 such constants... Now, how could Audiveris "survive" any score and "recognize only what is sufficiently clear"? In the case at hand, a staff was not detected. Fine. What can Audiveris do with this? It does not even know that it has missed a staff. And what is the concrete meaning of "sufficiently clear", from a software point of view? Transcribing score images is an endless fight between a (slowly improving) software and a wide population of (sometimes very poor and crowded) images. We have decided to keep the end-user in the driver's seat, and offer visual feedback as well as convenient tools to check, orient and correct the transcribing software. This combination of an OMR engine and an OMR UI has proven to be the most efficient approach, globally. |
Thanks, and agreement, with all you say (if I may say so - I'm only a small trial user, learning myself how to integrate OMR into my score writing processes). Re "survive" and "recognize only what is sufficiently clear": These are just my expectations, and, as always with users, also I have only words, but not really clear expectations. Still, to try to explain what I meant:
Harald M. |
OK, I better understand your needs. An important point for you is that the OMR engine, when processing a whole book, be able to process the following sheets even if some severe exception is raised in the current sheet. I will double-check this "keep going" strategy in OMR engine code. |
No more activity on this issue. |
Not finding a clef on the 8th staff on page 1; and the 11th staff on page 3 leads to these exceptions, which abort the OMR process. I tried playing around with a few options with "clef" in their name - but actually, I have no clue what to do ... I also don't see any "spurious glyphs" that might lead to a problem.
(The score is definitely of a bad quality, so I understand that Audiveris does not like it; however 4 of the 6 pages where "more or less" OMRed, with - for me - useful results).
Here are all files as a ZIP - pdf, omr, log: IMSLP220542.zip
H.M.
The text was updated successfully, but these errors were encountered: