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.
There was a problem hiding this comment.
Retested the last commit with a sample fluorescence MRXS dataset. This was converted into OME-Zarr via bioformats2raw using the default fill color and 3 values set via options --fill-value=0, --fill-value=100 and --fill-value=255
Confirmed that the OME-Zarr display as expected with the default value still being set to 0 as per the modality
No objection to keeping the deprecation warnings for now and drop in a follow-up 0.x.0 release
...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.