I wanted to load a stack of images stored in a single tiff file of microscopic data, but only the first image is loaded.
The dataset is approximatly 5Gb and its dimensions are 2159x2560x548, the bit depth is 16 bit. If I resample the stack to have dimensions of 1000x1186x250 in Fiji, it manages to load it.
I am working in a workstations with Intel Core i7 @3.6Ghz, 128 GB RAM, Nvidia GTX 750 Ti, and Windows 10.
Do you have any idea how can I solve it?
Thanks a lot in advance and congrats for such great piece of software!
I am not sure if Slicer supports Z-stacks saved as a single TIFF file. You have sufficient RAM to load your data unreduced. As @lassoan suggested, try saving it as NRRD out of FIJI.
Dear Andras and muratmaga, thank you very much for your reply.
Fiji can indeed save as MetaImage or NRRD, so I will try that. Thanks for the advice!
On the other hand, Slicer seems to support Z-stacks save as a single TIFF file, since it has no problem in loading my dataset when resampled to reduce the number of sections. Maybe it is a problem of the amount of sections - who knows.
One more comment to Andras, many microscopes output their images in OME-TIFF, which I think should not be considerer a “consumer image file format”. I am not aware of how big is the amount of microscopist users of Slicer, but maybe it could be super useful if Slicer has support to Bio-formats (https://www.openmicroscopy.org/bio-formats/).
Thanks for the additional information. With standardization efforts such as OME, file formats such as TIFF may become a standard file format for microscopy. To achieve that, vendors would need to coordinate between each other and retire the ridiculous number of other file format variants.
Current microscopy situation looks like radiology image file formats before DICOM standard was mandated. Do you know how widely DICOM format is used by microscopy community?
Bio-formats could be added as an extension to Slicer, but it would be better if there was one or few widely use file formats that the microscopy community would use and we could then add support for those in Slicer (probably through ITK).
It is indeed a very complex situation, in my opinion. There is the attempt of OME to bring all the formats together, but then every microscope company has its own format: Leica has .lif, Zeiss has .czi, Abberior has .msr, etc. On the other side, there are also some preference of formats among the analyst community, like .hdf5.
To my knowledge, I know no microscopy system that uses DICOM.
Microscopy is a big field with a lot of different use cases.
Most related to Slicer’s core uses is pathology imaging. Even here the vendors have many competing proprietary systems, but there is a workable DICOM standard for pathology slide imaging and it has a lot of advantages.
@pieper can you comment on the license problem? So all Slicer extensions has to be BSD license or only the core as distributed by Kitware?
Pathology is the immediate link to the microscopy and Slicer, but there are many 3D fluorescent imaging users in developmental biology world that can benefit from the core visualization and segmentation functionalities of the Slicer.
And not only in developmental biology. I work in auditory neuroscience and it is great not only for visualization but also for segmentation and for creating volumes and surfaces out of histological stacks. I really think the amount of users from other disciplines will increase sooner than later (at least I am recommending it to anyone who needs to reconstruct anything in 3D)
Software with restrictive and viral licenses is not allowed in Slicer core or in any of the libraries that Slicer core uses.
You can use GPL code in extensions, as long as you clearly communicate that in the extension description and documentation. However, many people will not even touch software with such license, so this solution can only be considered a partial, temporary solution.
I understand that this temporary solution would be a relief for many users, so if you can spend time on making it available then it is great. I think the microscopy community should also come up with a few recommended open standard formats and push the vendors (and open-source toolkit and application developers) to support those.
Thanks Andras. Good to know about license issues. I can understand why a company like Kitware may want nothing do with GPL, but why would a user not use an extension if it is based on GPL?
I don’t do microscopy myself, but my impression of the field has been such that they are not big into data exchange (since the assumption is you should be able to replicate the experiment, the critical piece of information is the protocol, not the image). But with more quantitative studies and move towards that reproducibility that may change.
I am not sure if we can take on the OME as a project, but we will sure discuss it…
For high-level components that can be easily replace by alternatives of they are not critical (e.g, just make things more convenient), using restrictive license is acceptable.
However, if you invest significant amount of time into developing new software tools or processing workflows then you don’t want to depend on any third-party component that would restrict how you can use and distribute the result of your own work. Even if you don’t mind sharing all your source code and refrain from all commercial activities, your potential users and collaborators may reject your work because of this.
I haven’t used it myself, but ITK does have optional support for Bio-Formats already, via SCIFIO.
Alternatively, there is an LGPL-licensed, clean-reimplementation reader library called OpenSlide, which may be supported (to some extent) via a new ITK remote module. OpenSlide supports many common formats, but unfortunately, as far as I understand, their funding lapsed/developers left/etc., and none of the commercial users or other community has really picked up the slack – so it is only minimally maintained right now. In particular, they do not have support for modern Zeiss format (CZI) which is a significant limitation. (Bio-Formats does, via a Zeiss-contributed, GPL-licensed reader implementation).