Fiji / Bio-Formats does not recognise Huygens output as multi-channel

fiji
bio-formats
imagej
svi-huygens
#1

Hi All,

This is a relatively minor issue, but a bit of an inconvenience for our users.

I have noticed that, regardless of which output format I choose to save deconvolved images from Huygens, when I subsequently import said images into FIJI via Bio-Formats, it is not recognised as a multi-channel dataset. So, for example, a 3-channel dataset with, say, 20 Z-slices, will be recognised as a single channel stack with 60 slices.

This is obviously easily rectified by converting to a hyperstack, but it would be useful to find a fix to avoid confusion amongst users.

Thanks,

Dave.

#2

We have good experience saving results in ics/ids (Image Cytometry Standard) file format. That way, both dimensionality and spatial calibration are well preserved.

Did you try that format as well?

In case you used tiff files, the problem with tiff is that there is no standardized way of defining more than 3 dimensions: multi-dimensional datasets will always be saved as a multi-plane tiff, but there’s no way to tell whether the planes came from one (z) or more (z,channel,time) additional dimensions. ImageJ saves this information in a custom tag in the file header, but that way of saving metadata is not standardized across different software applications.

#3

Thanks @imagejan,

No, admittedly I only tried the TIFF and OME options.

I am aware of the need for a tag/metadata to interpret multi-dimensional TIFFs, but assumed that these outputs would be saved in such a way that at least Bio-Formats could interpret them correctly.

Certainly with OME format I would have thought should be the case?!?

#4

Hi @djpbarry,

I concur with your previous statement. Bio-Formats should be able to properly detect the dimensions of OME-TIFF files.

As a control test, could you try opening one of the sample OME-TIFF files e.g. http://downloads.openmicroscopy.org/images/OME-TIFF/2016-06/bioformats-artificial/multi-channel-z-series.ome.tiff in your Fiji distribution with Bio-Formats?

If the former file correctly opens as a 3 channel, 5 Z-sections image (as it does on my local distribution), we might need you to upload a failing sample file to http://qa.openmicroscopy.org.uk/qa/upload/ to assist further.

Best,
Sebastien

#5

Hi @s.besson,

I can confirm that the sample OME-TIFF file opens correctly.

I have uploaded an example of a multi-channel OME-TIFF output from Huygens that FIJI opens as a single channel TIFF.

Dave.

#6

Dear Dave,

The Huygens file uploaded as QA 21657 has an extension of *.ome_cmle.tif but is not actually an OME-TIFF, it’s just a regular TIFF file whose description mentions ImageJ (with slices=243, frames=1, nothing obvious about channels).

Cheers,
Mark

#7

Thanks @mtbc,

Didn’t occur to me that it might just be a regular TIFF.

I guess that begs the question of why @SVI_Huygens is claiming to produce OME-TIFFs when it is not?!?

#8

Good question! For general future reference with other files you may find the guide at https://docs.openmicroscopy.org/latest/bio-formats5.9/users/comlinetools/xml-validation.html useful for checking putative OME-TIFFs.

#9

That’s useful, thanks @mtbc.

#10

Dear Dave,

Thanks for pointing this out. I can definitely understand the confusion:
Although Huygens can read OME-TIFF, Huygens cannot save data as OME-TIFF. If we do mention/claim this somewhere in our documentation or in the software, then please let us know so that we can update/fix this!

I believe the confusion arises from the fact that Huygens can save data as OME-XML, which was implemented in Huygens already in the earlier days of the OME standard. OME-XML is actually a different from OME-TIFF, in that all the meta-data and pixel data is stored into an XML file. This format is also superseded by the OME-TIFF standard: https://docs.openmicroscopy.org/ome-model/5.6.3/ome-xml/index.html
When you choose to save as ‘OME-XML’ from Huygens, you should end up with a file that has *.ome as file extension (notice there is no *.tif at the end).
When you choose to save as TIFF from Huygens, then this is not OME-TIFF, but regular TIFF, so there will be no XML included in the tiff header.
Individual channels will be saved as separate TIFF files by Huygens. You can optionally choose to include all z-planes in one Tiff-stack, or also save the individual z-planes as individual files. The naming convention is explained here: https://svi.nl/NumberedTiff

Although I don’t have access to your uploaded file, @mtbc mentioned that your uploaded file had an extension of *.ome_cmle.tif This looks like as if the data originally was an *.ome.tif file (which Huygens can read), and it was processed with the CMLE algorithm by the batch processor (which adds the _cmle to the filename). You chose to save as regular tif, so the result will be stored as *.ome_cmle.tif
Because the .ome is still included in the filename of the result, this may add to the confusion that the result has something to do with OME, while it is actually not. I will report this to our development to see if we can improve this by discarding the .ome at the end of the filename when reading in OME-TIFF files in Huygens.

We also definitely support the advise mentioned by @imagejan that ics/ids is a great alternative when you work with Huygens and ImageJ. The ICS standard is also fully open source (under GNU Lesser General Public License), and since a few years this format is maintained by SVI: https://svi-opensource.github.io/libics/
ICS is (as far as I’m aware) supported by BioFormats as well, and since it is open-source, anyone is free to create their own reader/writer for this file format.
With other file formats we have struggled to store multi-dimensional data and microscopy parameters. With ICS this is not an issue, and it has the additional advantage that we can store all the microscopic parameters correctly.
Some classical examples for which many file formats have minimal support (or sometimes even require ‘hacks’) are for example storing: STED optical parameters, Light-sheet optical parameters and extra pixel data dimensions such as tiles, angles, detectors or a combination of them. As a modern practical example: with the Zeiss Airyscan you could potentially have a single dataset that consists of multiple: z-planes, channels, time-series, tile positions along with a ‘detector dimension’ of size 32. Many file formats would struggle with data that has so many dimensions, but ICS can handle such complex multi-dimensional data very well.

Hope this clarifies things a bit more. But if you have any further questions, just let us know.

Kind regards,

Remko Dijkstra
Imaging Specialist
Scientific Volume Imaging b.v.
Makers of the Huygens Software

#11

That definitely helps to clarify things - thanks @SVI_Huygens