MRCReader: invert planes in Y for FEI variants

[sbesson]

See https://forum.image.sc/t/bio-formats-does-not-read-tiff-mrc-pixel-size-from-drag-and-drop/53695

More specifically, from https://bio3d.colorado.edu/imod/doc/mrc_format.txt

IMOD will always write files in this orientation but will recognize files with an inversion in Y (first row of pixels as the highest line in the image) in two cases: 1) the extType is FEI1 and the imodStamp is not present; or 2) the mapr value is -2.  The latter has been discussed as a convention but will likely crash software not recognizing it.

In the reader, the following code path handles the inversion in Y and should probably be made conditional to the value of extType

https://github.com/ome/bioformats/blob/dfbf7ab4b61950460b0b1cfd054ce971b9d85ca6/components/formats-gpl/src/loci/formats/in/MRCReader.java#L129-L138

Scanning quickly our representative MRC files, I did not find any FEI sample. The sample file uploaded in the forum post is of type FEI2 and should be minimally used to test this behavior

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/bio-formats-does-not-read-tiff-mrc-pixel-size-from-drag-and-drop/53695/7

[sbesson]

From additional discussion with @melissalinkert, I came across https://www.ccpem.ac.uk/mrc_format/mrc2014.php which I think is the official specification for the MRC file format and defines the FEI1 and FEI2 types for the extended header.

Interestingly, unlike the IMOD page, the MRC specification does not define the expectations in terms of origin/orientation. The relevant paragraph of the specification is most relevant

Handedness

The handedness of the data block is not well defined by the MRC2014 standard. Conventionally, many pieces of software have treated the data as right-handed, with the origin in the bottom left corner of a 2D image and the Z-axis pointing out of the screen.

However, this approach is not universal, and some packages treat the data block as left-handed. An example is FEI's EPU data acquisition software, which places the image origin in the top left, as documented in appendix C of the EPU User Manual.

Proposals for indicating the data handedness in the file header are under discussion, but for now, the only way to be sure of the handedness is to check the behaviour of each software package individually.

From my side this reclassifies the scope of this issue as an enhancement rather than an bug. Since the user expectation is largely implementation specific, we might need to put the behavior behind an option.