Files questions

A complete list of the supported file formats is available here.

These functions can be found in Huygens Essential and Professional under the Tools -> Convert menu. In Huygens Professional this is also listed in the Operations Window under the Convert menu. For more information on the importance of having the right image dimensions for deconvolution, please visit Convert Data Set.

This can be done in the Professional with options listed under the Tools menu and in the icon task bar. Some options may be greyed out and will only be activated if you first select the to-be-added image and copy it with the "Copy" option. The "Copy" option is available under "Edit" and as an icon in the task bar.

Yes, there is no need to uncompress them. In Linux you can gzip all .ids files in a directory with:
gzip *.ids
or for better compression (more time-consuming):
gzip -9 *.ids
To unzip:
gunzip *.gz

The Z-direction in 3D files from Nikon confocals is not always correctly displayed unless the 'Huygens compatible' option of the EZ-C1 acquisition software by Nikon is used when saving the data. To switch on the 'Huygens Compatible' option follow these steps in the EZ-C1 software:

- Click on 'File|Save As':
- Select the '*.ids' format and press the 'Options' button.
- The second property page called 'ics' shows the 'Huygens Compatible' checkbox. Please check this option and press the 'Setup' button to fill in all the Huygens specific information.

If the Tiff series is numbered with Leica style extentions the series will be read as a 4D multichannel timeseries. So instead of just a sequential numbering they should be numbered like:
psa-880_Series08_t00_z000.tif psa-880_Series08_t00_z001.tif ... psa-880_Series08_t01_z000.tif psa-880_Series08_t01_z001.tif ... psa-880_Series08_t09_z027.tif psa-880_Series08_t09_z028.tif

Huygens Pro has a lot of conversion utilities and tools to shuffle frames and channels around. See Operations Window -> Convert

Lastly it is possible to edit the ICS file like:
layout parameters 4 layout order bits x y z layout sizes 8 256 256 64
layout parameters 5 layout order bits x y z t layout sizes 8 256 256 16 4

The only tricky thing is that the field separators must be tabs, not spaces.

Yes. After you load them, we advise you to review the microscopic parameters. You can do this in all viewers or by right-clicking on the image and selecting "Edit Parameters" or "Parameter Editor" (depending on the product).

If requested, a single channel image will be exported to a multi-tiff file. Multiple channel images will be exported to a RGB 8bit multi-tif
file (if only two channels are present the last B channel will be empty, and if more than three channels are present they will be discarded).

It also writes (and reads) as 16 bit tiff, one channel per tiff. In the case of multi-channel 3D or 4D images the Leica style suffix numbering style is used.

This happens in cases where the name ends with a number. While saving an image stack as 'tiff', Leica style numbering is used. If the name ends with a number the number will be trimmed at saving and new characters added according to the Leica style numbering: starting '000' to '019' (for a stack with 20 slices). If you wish to save your stack with numbered information add a '_' or '-' like 'decon1-'. The stack will be saved as a tiff series: decon1-000.tif, decon1-001.tif, etc.

This is not possible. The SVI ftp server is for uploading only. All available files for users are in this wiki. See e.g. the Download page.

There is a problem with compressed image data in LSM files: sometimes the compression format is not quite correct. The Huygens reader will continue reading past such defects. Since they seem to occur always at the end of the data little or no image information is lost.

Yes. Huygens is equipped with a Tiff 6.0 compatible reader which is capable of reading 16-bit tiffs.

Rename your successive planes (files) to make them a series with equal base names, like:
yourFile1.tiff -> newFile000.tif (or tiff) yourFile2.tiff -> newFile001.tif etc.

Huygens will read the stack as a single 3D image by selecting the image newFile.000. (Or you may skip the first N planes by opening newFileN).

In case you have multichannel images or time series you have to follow the Leica-style name convention in order to read in the tiff series as a single image. See Renaming Tiff Series and Leica Tiff.

If the particular program is able to save images in binary form or forms with a simple fixed header follow this procedure:
  1. In the foreign software, save the image in binary from, for example to foo.raw. If this is not possible try saving to a fixed header format and strip the header.
  2. Create an image in the Huygens System of exactly the same dimensions and microscopic parameters as the image you have saved in binary form. Save it in the default ICS format, for example foo. It creates the foo.ics/foo.ids file pair.
  3. Rename foo.raw to foo.ids. This over-writes the original foo.ids but you don't need that any more.
  4. Open the foo.ics/foo.ids ICS file pair in Huygens.

Save the images either as Imaris-Classic or ICS. ICS is preferred, but unfortunately Imaris does not write ICS files always correctly. The Huygens software has built-in workarounds to still read such files. It should be noted here that microscopic parameters are often missing in ICS files written by Imaris.

The current native file format for Imaris is an HDF variant. Huygens supports the HDF format as well and should not give problems when loaded in Huygens. However, Imaris stores the metadata in a separate section, which is not read properly. In some cases a black border could be added to the image, which can be cropped using the crop-tool.

The previous native file format for Imaris was 'Imaris3'. Huygens does not support the Imaris3 format directly; instead Imaris3 files, being a Tiff variant, are read in by the standard Tiff library which only recognizes the first plane.

Yes. However, Imaris Classic files do not contain all microscopic parameters needed for deconvolution. For example, the microscope type and pinhole size are missing. In case you're working with Nipkow or 2-photon systems, the excitation photon count and pinhole spacing are also absent from the file. Missing parameters are substituted by an external Tcl filter. To be on the safe side, it is always a good idea to check important parameters like sampling densities and the NA.

Yes, Huygens can export numbered TIFF series with time, z and channel index suffixes according to the Leica scheme.

Or if you have the following option in your license you can exchange data easily between LASAF/X and Huygens:

Voxel values larger than 32767 are represented as negative numbers in the signed format used by the software. You can solve the problem by running some Tcl operations. Suppose you named the image with the wrap around problem `wrapped' you can correct this with the following Tcl operations:
<1> wrapped clip -> a <2> wrapped - a -> c <3> a convert -type float <4> c convert -type float <5> c * -1 -> b <6> b max 1 -> b <7> c + 65536 -> c <8> c * b -> c <9> a + c -> psf
This gets you the corrected image in float format.

The Image Cytometry Standard (ICS) was first proposed in:
  • P. Dean, L. Mascio, D. Ow, D. Sudar, J. Mullikin, "Proposed standard for image cytometry data files", Cytometry, n.11, pp.561-569, 1990.
More information and source code under the LGPL license is available on GitHub

Take for example a three channel 8-bit tiff image with xyzt dimensions with each channel being 3 GB in size.
In order to stabilize each channel accurately at sub-pixel level, it must be converted to floating point (32 bit) making it 4 times larger, so 12 GB. Because all 3 channels must be stabilized at the same time, the complete 36 B file must be used.
The same size is needed for the intermediate, and for the final result. Counting to 108GB.

Moreover, the addition of extra borders, also known as padding, may be necessary to account for all movements. So the more movement in various dimensions the more padding is needed. Some datasets have been subjected to so much movements that an accurate correction requires padding of nearly the same amount of memory as the initial, intermediate, and corrected image altogether. In our example that would be another 100 GB on top of the 108 GB, totaling 208 GB of memory.

Thus, if you have several large channels with multiple dimensions and much movements with an expected memory need that exceeds the internal memory of your computer, we recommend to look at enlarging the swap-space in your hardware. In that way the memory is expanded significantly, be it at the price of slowing down the processing. You can use our file size calculator to determine the actual size of your image.