Incorrect inputstart and inputend in OMERO 5.3.3 import

Dear OMERO Team,

We are having an issue after importing MRC files generated from TIF files with IMOD’s tif2mrc. For example, for entry
https://empiar.org/entry/10310#imageset_2

the file that is produced from tif2mrc has the following header:
RO image file on unit 1 : empiar_10310_20180813_platynereis_parapodia_amst_aligned.mrc Size= 47448608 K

Number of columns, rows, sections … 3337 3703 1966
Map mode … 6 (unsigned 16-bit integer)
Start cols, rows, sects, grid x,y,z … 0 0 0 3337 3703 1966
Pixel spacing (Angstroms)… 1.000 1.000 1.000
Cell angles … 90.000 90.000 90.000
Fast, medium, slow axes … X Y Z
Origin on x,y,z … 0.000 0.000 0.000
Minimum density … 0.0000
Maximum density … 65535.
Mean density … 10974.
tilt angles (original,current) … 0.0 0.0 0.0 0.0 0.0 0.0
Space group,# extra bytes,idtype,lens . 0 0 0 0

So we expect to have inputstart to be 0 and inputend to be 65535. However, after the import we get the following:
inputstart -0.109860777854919
inputend 0.205897629261017

and so we have to modify it manually in the database. The OMERO version that we are using is rather old - 5.3.3. Is this something that might improve when we upgrade to the latest version or is some way to fix this?

Many thanks and best regards,
Andrii
EMPIAR Team

Dear Andrii,

thanks for reporting the issue and poting at public EMPIAR dataset. I used the first four TIFF files and the tif2mrc utility from IMOD to create a test MRC file as mentioned above.

Importing the file into the OME demo server using the latest released server/web seems to correctly set the minimum/maximum values of the rendering settings at import time.

Overall, it feels like upgrading the software might address your issue. If it does not, we would probably need more details about the conversion mechanism and/or access to a sample file.

Sebastien

PS: while importing, I noted the image used for this example is large enough (3337 x 3703) so that it is recognized as pyramidal by OMERO. Given the MRC file does not contain any pyramidal resolutions, the server will convert this file into some internal pyramidal representation. To avoid data duplication/unnecessary processing, it might be worth considering the generation of your combined image in a multi-resolution format natively supported by the software. We can discuss this in a separate thread if you are interested.

1 Like

Dear Sebastien,

Thank you for checking on this. It is good to know that the latest version works well, a great reason for us to update.
Please feel free to specify the preferred way to import such a stack of tifs in this thread. One of the reasons we are using mrc is because this is the format that is being processed by our current pipeline set up for EMDB entries. It does rotations as well as creates “thumbnail” images as can be seen on the left hand side at
https://www.ebi.ac.uk/pdbe/emdb/3dbrowse/empiar_10310_20180813_platynereis_parapodia_sift_aligned

Best regards,
Andrii