SVS: fix a variety of small issues

[melissalinkert]

c574360 fixes #3986. Most data is unaffected, but CMU-1.svs now has different behavior. Compare showinf -noflat -omexml -series 1 and showinf -noflat -omexml series 2 with and without this PR. Without this PR, a label image is shown the one named macro image and a macro image is shown for the one named label image. With this PR, the names and images should match. I think this behavior change warrants a minor release, but happy to hear other opinions.

1b6da10 trivially fixes #4036.

593c819 fixes #3743 by setting the X and Y position on the full-resolution image to the Left and Top values respectively from the image description. This is different from what TIFFToDicom (as referenced in #3743) does; TIFFToDicom assumes both that the macro image is 1 inch (25.4 mm) high and that the full-resolution image is rotated 90 degrees with respect to the macro. With CMU-1.svs, TIFFToDicom sets the macro image to 0.0589mm/pixel with a plane position of (X=25.4mm, Y=75.434mm). The full-resolution image is set to 0.000499mm/pixel (which is correct), with a plane position of (X=23.449873mm, Y=49.7423mm). I am not entirely comfortable with applying those assumptions to all SVS files, so for now just the full-resolution positions are set with no correction or rotation applied. That's enough information for downstream applications to replicate the behavior in TIFFToDicom though.

#3682 was also tested in the context of this PR; I could not duplicate issues with removed label/macro images, so propose to close that issue as well. A few examples with removed macro and label images are added to the test repo as part of the corresponding configuration PR.

[sbesson]

• label/macro images of the sample files associated with Label and Macro images are incorrected indexed since 6.8.0 #3986 are swapped and now match the content of the IFDs. Also confirmed that SVS: handle optional label and macro images #3682 has been addressed in a previous Bio-Formats release and closed the issue.

• sample file from AFI / SVS: getMagnification results in NullPointerException #4036 now open without issue

• on the last issue (physical position of the whole slide image), I agree that the assumptions of TIFFToDicom cannot be applied to all SVS files. In the interim, storing the Top/Left metadata in the most relevant place in the OME model is certainly a good idea. I looked at the Aperio reference specification but could not find an official documentation for the two fields. Two quick questions:

  • is it safe to assume the value is always expressed in millimeters?
  • I understand Top to be the top offset but is PlanePositionY expected to capture the bottom offset instead?

[melissalinkert]

is it safe to assume the value is always expressed in millimeters?

I believe so. I'm not aware of a unit field for the position(s), and we know that the physical pixel size is stored in fixed units (micrometers). Until we have a counter-example, I think it's reasonable to assume the position units are fixed as well.

I understand Top to be the top offset but is PlanePositionY expected to capture the bottom offset instead?

PlanePositionX and PlanePositionY can refer to any location in the image; the schema does not define and has no way to specify whether those coordinates refer to the upper left, bottom left, center, etc.

[sbesson]

PlanePositionX and PlanePositionY can refer to any location in the image; the schema does not define and has no way to specify whether those coordinates refer to the upper left, bottom left, center, etc.

Thanks for the confirmation. As briefly discussed at the Formats meeting, this limitation unfortunately comes from the OME schema and is outside the scope of this PR.
Looking at the positive side, this change allows to store this position metadata in a relevant location of the OME metadata. feels like an improvement as opposed to keeping these values under a vendor-specific opaque key. Future validation of this work could look into consuming this positional metadata e.g. for visualization purposes.
Overall happy for this to be merged and included in an upcoming release of Bio-Formats. The discussion around orientation/origin can be revived based on concrete use cases as required

[dgault]

Restested again with CMU-1.svs, when using the noflat option the label and macro image are mislabelled without this PR. With this PR the names match the images. At this weeks format meeting we had a brief discussion on whether this would be a severe enough change for a minor release or suitable for a patch release. I am in agreement with Seb that since this is fixing a regression in BF 6.8.0 that it should be suitable for a patch release. Testing with BF 6.7.0 and the names and images also match, so this was a regression introduced in 6.8.0.

Retested the sample file from scratch/inbox/imagesc-81073 and it now opens without exception.