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
