Fill color configuration

[melissalinkert]

trafficstars

See #3795 and https://github.com/glencoesoftware/bioformats2raw/pull/65 for prior work on this topic.

Some formats allow sparse pixel data, which means that a particular image tile may contain pixels that have no value stored in the file(s). This is especially true for whole slide formats. Most readers fill these undefined pixels with 0s, which doesn't always match the vendor software or users' expectations. Brightfield slides in particular are usually expected to have undefined pixels set to 255 (i.e. white).

To better address this across all readers, one approach would be:

• Define a new IFormatReader method Color getFillColor() which returns the ome.xml.model.primitives.Color that will be used for undefined pixels (the return type is up for debate). By default this returns black/0.
• Define a new IFormatReader method setFillColor(...) which allows the color to be changed. This alters the value returned by getFillColor().
• Add an option to bfconvert/bioformats2raw/etc. that calls setFillColor.
• Update to always use getFillColor() as the default pixel value. This might be worth adding to FormatTools.checkPlaneParameters (or some other method that all openBytes implementations call), and would need to be changed in the ~20 places where Arrays.fill(buf, (byte) 0) is called by openBytes.
• Update individual readers to override getFillColor() if color metadata is defined or can be inferred for a particular format. This could be limited to the readers for whole slide formats, at least to start.

Specific API changes are up for discussion, as is the priority since this would require at least a minor version update.

[joshmoore]

In an ideal world, would this be a model update?

[melissalinkert]

I think ideally, we would be able to set something like NaN as the default pixel value, and the fill color would be a true rendering setting that you could change in viewers and converters. No strong opinion on whether or not this belongs in the model right now though.

[petebankhead]

FWIW this would be enormously helpful for some people using Bio-Formats via QuPath. Filling with zero has caused problems, e.g. https://forum.image.sc/t/qupath-0-2-thresholder-problem-zeiss-z1-wsi/41594