Fix --fill-value to use setFillColor(...) API
#257
Conversation
...so now this option can be used with all readers.
| @@ -1069,10 +1069,17 @@ public void setFillValue(Byte fill) { | |||
| * for brightfield. | |||
| * | |||
| * @return fill value for missing tiles | |||
| * @deprecated use getFillColor() | |||
There was a problem hiding this comment.
As this is planned for 0.10.0, is there a value in going through a deprecation rather than dropping these in favor of the new API defined upstream?
There was a problem hiding this comment.
I wasn't totally sure what the best approach would be here, so went with deprecating to be on the safer side. If we're all OK with just removing getFillValue() and setFillValue(), I'm fine with that - it would only impact anyone using MiraxReader directly, either by extending the reader or by calling those methods directly.
|
|
||
| @Override | ||
| public Byte getFillColor() { | ||
| Byte color = getFillColor(); |
There was a problem hiding this comment.
In my testing this caused a java.lang.StackOverflowError: null due to the infinite recursion
There was a problem hiding this comment.
Should be fixed with e3dd7ca.
...so now this option can be used with all readers.
Noticed while working on #256 that
--fill-valuestill only applied toMiraxReader. Given thatsetFillColorandgetFillColorwere added toIFormatReaderin Bio-Formats 6.13.0 (see ome/bioformats#3963), this updates--fill-valueto make use of this new API. Several of the readers didn't make use ofgetFillColor()inopenBytes, so that's been fixed too.