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

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.



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.


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?!?

1 Like

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. 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 to assist further.


1 Like

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.


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).


1 Like

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?!?

1 Like

Good question! For general future reference with other files you may find the guide at useful for checking putative OME-TIFFs.


That’s useful, thanks @mtbc.

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:
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:

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:
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


That definitely helps to clarify things - thanks @SVI_Huygens

1 Like

Quick follow-up on this…

Having done some more investigating, it seems that @SVI_Huygens is, at times, reading multi-channel data as single-channel and this is what is causing the output of the deconvolution to be written as a single TIFF file, rather than separate files for each channel.

I’ve been doing some investigating and cannot figure out the cause of this. The data in question is a multi-position acquisition produced using MicroManager. Huygens interprets the first position as being multi-channel, but seems to interpret all subsequent positions as being single channel.

Any idea what could be cauising this?

Dear Dave,

I don’t think this is an issue in Huygens, but in the (lack of) OME XML meta-data in the tiff headers:

We have actually seen this behavior before on multi-position data acquired with MicroManager. In that case the problem was that only the first ome.tiff file in the multi-position series contained the correct header, whereas all other files in the series did not contain any OME header at all. Huygens therefore reads the other files as a single tiff stack (all channels are stacked), since there is no specification in the header about the dimensions, and only the first file in the series (which does contain the correct OME header) is read in as multi-channel.
According to the OME description (, the OME header should be included in the header of each individual TIFF file:

  1. A complete OME-XML metadata block describing the dataset is embedded in each TIFF file’s header. Thus, even if some of the TIFF files in a dataset are misplaced, the metadata remains intact.

It might be that some versions of MicroManager do not do this correctly in case of multi-position acquisitions, and only store the header in the first file. I don’t know the exact details which version(s) of MicroManager might have this issue and/or if this only happens with specific acquisition settings, but it might be good to check if your multi-position data also lacks OME header information in the individual ome.tif files, and if this is the case, I would recommend to contact the MicroManager team about a possible fix.

Kind regards,

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

1 Like

Thanks for the reply.

I suspected something similar but it’s good to have it confirmed!

I thought I’d resolved this issue today, but not quite.

If I just add the first file in the MM multi-position dataset when setting up a job in the Huygens batch processor, it seemingly loads the full series list without any problems. However, rather frustratingly, when running the batch tasks, it keeps overwriting the image outputs:

Is there a way to modify this behaviour, which would completely resolve the issues I’ve been having?

In case anyone else is interested, I received an update from SVI about this. Apparently there was an error in the file opener that they are endeavoring to correct - the problem will hopefully be resolved in the near future.