Pyramidal CZI images and the color of 'unscanned' regions

This question relates to Qupath 0.2 thresholder problem Zeiss.Z1 WSI – and I hope @r100gs doesn’t mind I’ve included some of the screenshots from there below.

The ability to read Axioscan images with Bio-Formats is wonderful (thank you!), but there one niggly issue that makes handling them properly difficult: specifically the color used to fill in ‘unscanned’ regions is sometimes white and sometimes black… within the same image.

For a multiresolution pyramid, this is especially troublesome because corresponding regions can appear as either black or white depending upon the zoom level… i.e. when zooming in/out the color for specific blocks changes. Thresholding (and much else) would be much simpler if Bio-Formats was able to fill unscanned regions consistently with the same color – ideally white for brightfield images and black for fluorescence.

You can see the trouble in @r100gs’s screenshots (albeit overlaid with pixel classification) below:

The curious appearance in the first image is caused by the pixel classification being applied at a different resolution from the one at which the image is being viewed… so that ‘green’ indicates classified dark pixels. At the classification resolution everything that looks black in the screenshot is actually white – so the result is ‘correct’, even though it looks very wrong.

Is there any chance this could be resolved within Bio-Formats directly – either by default, or with an optional flag? I see there are references to ‘Brightfield’ in the OME XML, so I imagine something like this here might work… but I’ve no idea of the wider implications.

if (isRGB() && isBrightfield && emptyTile) {
  // Fill the buffer accordingly
}

Alternatively, is there sufficient information available through Bio-Formats that I could add the necessarily logic to QuPath to ‘correct’ the color where needed?

Thanks!

Edit: Well, upon closer investigation I don’t think my above suggestion is much use… maybe the Arrays.fill(buf, (byte)0) line is more relevant.

2 Likes

This issue I opened may also be relevant: https://github.com/glencoesoftware/bioformats2raw/issues/45

1 Like

Thanks for raising the issue Pete, it is something which has been encountered before in other formats as well. I have opened a GitHuib Issue for the request: https://github.com/ome/bioformats/issues/3614

We will have to go through the various different use cases but my initial thought is that having it as a configurable option would be indeed be one possibility that would provide the desired results.

4 Likes