Hi Michael,

Your approach is more convenient than the current binarization section in the book parameters.
It's easy to use and we can observe the impact immediately when a parameter is modified.
I like it.

I suppose we can now remove the binarization section in the book parameters.
No big deal but I won't have time to do it before a few days. You can also take care of this on your own if you wish, just tell me.

Thanks,
/Hervé

Thank you Hervé for your encouragement! I can make that change in the book parameters. Now off to fix some bugs!

Hi Michael,

We have a problem with the BinarizationAdjustBoard automatically added to the Binary tab.

• In the normal case it works: the input image is read, converted to gray, and then fed into the binarization filter.
• But in a .omr file, the binary data of a sheet is kept as a local BINARY.png file within the .omr zip archive. When trying to display the binary view, the BinarizationAdjustBoard now tries to connect to some gray material (and for that tries to fetch the original input file, which may no longer be available...)

We should be protected against this, because we often want to simply have a look at the binary image (for instance to compare with the transcription results), without re-launching any binarization process of course.

WARN  []               BookActions 452  | Error in displayBinary java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getColorModel()" because "img" is null
java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getColorModel()" because "img" is null
	at org.audiveris.omr.sheet.Picture.adjustImageFormat(Picture.java:1128)
	at org.audiveris.omr.sheet.Picture.getGrayImage(Picture.java:536)
	at org.audiveris.omr.sheet.Picture.getSource(Picture.java:643)
	at org.audiveris.omr.step.BinaryStep.runBinarizationFilter(BinaryStep.java:118)
	at org.audiveris.omr.sheet.ui.BinarizationAdjustBoard.runBinarizationFilter(BinarizationAdjustBoard.java:292)
	at org.audiveris.omr.sheet.ui.BinarizationAdjustBoard.connect(BinarizationAdjustBoard.java:314)
	at org.audiveris.omr.ui.Board.setSelected(Board.java:479)
	at org.audiveris.omr.sheet.Sheet.createBinaryView(Sheet.java:597)
	at org.audiveris.omr.sheet.ui.BookActions.displayBinary(BookActions.java:444)

For the time being, I have simply commented out the line 597 in Sheet.java:

///baBoard.setSelected(true);

And I avoid to manually select the BinarizationAdjustBoard when I don't have the original source file!
But this is just a workaround...

Thank you for the detailed writeup Hervé! I should learn more about how your program functions in different situations. I'll look at how your program currently handles this and see if there is a good solution.

While you are at it, the label "Apply to all pages" would be better named "Apply to all sheets".
Because what we binarize is a (physical) sheet, not any (logical) page yet.
See this section in the handbook for an explanation of sheets vs pages.

Also, I noticed this line in the connect() method of BinarizationAdjustBoard, right after the comment
// Re-binarize image if the filter has changed

        if (sheet.getStub().getBinarizationFilter() != previousFilter) {

This is dangerous because it checks if the 2 items share the same address, while we just want to compare their values.
And actually, the addresses are different, hence the filter is always re-applied. Bad luck!

The line should be replaced by:

       if (!sheet.getStub().getBinarizationFilter().equals(previousFilter)) {

And indeed the filter is no longer re-applied if not modified in value.

This prevents the raise of exception when the input file is no longer available (see the previous message)

We could even keep the pre-selection of the BinarizationAdjustBoard (the line: baBoard.setSelected(true);)
But the user should not press any of the buttons (Apply, Reset, ...). Not very user-friendly! :-)

Perhaps the BinarizationAdjustBoard should be "selectable" (automatically or on demand) only if the input file has been successfully checked for availability beforehand.
What do you think of this approach?

Still reading the code of BinarizationAdjustBoard, I stumbled on this:

    //---------//
    // onEvent //
    //---------//
    @Override
    public void onEvent (UserEvent event) {}

My question is: if this board discards any incoming event, what is the rationale behind connecting it?

UPDATE: Answering my own question, you are using the callback on connect() to potentially re-launch the binarization.
In that case, I'd suggest:

• To remove the eventClasses item and replace it by null in the constructor
• To remove the call to super.connect() in connect()
• To remove the call to super.disconnect() in disconnect()