Bio-formats does not read tiff/mrc pixel size from drag and drop

Dear community,

I have two problems with opening files using Bio-formats.

  1. If I activate SCIFIO to open files (in Fiji) and want to use drag and drop (on the main Fiji toolbar) then pixel size is not read correctly from tiff and mrc files that are produced by Themo Fisher (former FEI) software. However, if I drag and drop the same files on “Bioformats Shortcut Window” then pixel size is read correctly for both formats. It seams that Bioformats can properly detect pixel size but drag and drop feature using main Fiji toolbar has some problems.

  2. Why mrc files are always vertically flipped in comparison to tiffs despite being converted form the same original file?

I have representative files here:

In that folder you will find:

Test.emd - original data file (by Velox program)
Test.mrc and Test.tif - files converted from the original (Velox)
Test.tif_to_IJ.tif - file was opened with Bioformats and saved with ImageJ tiff option

My system: Windows 10, Fiji 2.1.0/1.53c, Java 1.8.0_172

Hi @Alex_Mironov, what software are you using to do the original conversion between emd to mrc and tiff? I think the issue with the pixel size may be due to the units getting dropped in the conversion to tiff and different defaults being used.

Maybe it is helpful for others to know the history of your conversation during last days on the ImageJ mailing list, subject: File formats and pixel size

1 Like

Hi David! The conversion software is Velox that is used for image acquisition. But the problem is not there.
Pixel size (of mrc/tiff) can be read properly by Bio-formats if I drag and drop mrc/tiffs into “Bio-formats Shortcuts Window” (or use menu and open Plugins->Bio-Formats->Bio-Formats Importer). So, Bio-formats is able to use drag and drop function with proper reading of pixel size.
However, if I drag and drop the same files on Fiji toolbar (after selecting “Edit-Otions-ImageJ2-Use SCIFIO when opening files”) then pixel size is not read properly.
Even if these tiff files have private tags then these tag are OK for Bio-Formats in general as it able to recognize them.
There was some discussion in ImageJ mailing list about this problem (see the post from Peter). Wayne has suggested that this behaviour of Bio-Formats is possibly a bug. This is his quote:

“Bio-Formats will open images dragged and dropped on the ImageJ window when you enable “Use SCIFIO when opening files (BETA)” in Fiji’s Edit>Options>Image2 dialog but there appears to be a bug that causes the image size of your test image to be set to 0.00x0.00 pixels. What does work is opening the Plugins>Bio-Formats>Bio-Formats Plugins Shortcuts Window and dragging and dropping files on it.”

@Alex_Mironov thanks for following up on this.

For your first question, using the Bio-Formats command line-importer, the pixel size was accurately detected so the issue lies in the Drag-n-Drop logic as you mentioned. This is outside my immediate knowledge so I extended the tag of this post to include #imagej2 and #scifio as the maintainers might have more hindsights on what differs in this case.

For the second issue, using 3dmod (from the IMOD suite) as the reference software for validation, I confirm that the pixels are inverted alongside the Y axis

After reading the bytes on disk, Bio-Formats MRC reader performs an inversion alongside the Y axis as per the format specification. A previous thread seemed to validate this as the correct approach - MRC files are read in flipped in Y. Looking more closely at, this might be related to metadata-specific handling

Image data follows with the origin in the lower left corner, looking down on the volume. The first pixel in the file is the lower left corner of the first image; the first nx values are the lowest line of that image in Y. 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 case of the sample file uploaded above the extType is FEI2. @David_Mastronarde would you be able to comment on what the expected behavior should be?

I expect that 3dmod would display this file correctly, even though the type is FEI2 instead of FEI1. I was not aware that there was an FEI2, but the code is written to consider the basic type as “FEI” and thus sets the flag to do inversion when reading in to be stored in a right-handed array. The number is used as a separate version number.

1 Like

Thanks @David_Mastronarde, I have opened MRCReader: invert planes in Y for FEI variants · Issue #3706 · ome/bioformats · GitHub to capture this issue and conditionally invert the planes depending on the type of the extended header.

@s.besson Thank you for your help and explanations!