[Imaris Software For Mac Os X
Eliora Shopbell
I am not sure that for very large data sets this will be enough. Currently the bottleneck to use different software is data refactoring.In a facility we have different users and that are familiar with this or the other software. For instance I help performing the assembly of the data using BigStitcher, but then the user would like to investigate the data using imaris.
Would it not be great to have one hdf5 container that can then be opened by several software (e.g. BDV, Imaris, ilastik) without conversion? Just by creating an additional configuration file without duplicating the data and waiting for the write process to finisg. The question is whether this could possible at all and what is missing for it? In a past discussion with @Christian_Tischer and a @akreshuk group member it seemed that a BDV/Imaris/ilastik portable format could be possible. What is your opinion on this?
Dear Antonio,
two thumbs up for this. There is really no point in reinventing the wheel over an over, and at least the hdf5-based file formats share quite a lot of fundamental concepts. Just know that for the commercial vendors it can be a bit difficult to commit to something because the commitment has to come from some higher authority.
All the best,
Mario
However, in the mean time it would be nice to avoid very lengthy conversion. For instance BDP2 from @Christian_Tischer creates a small .ims file and several .h5 files that can then be loaded in Imaris without further conversion. Imaris files can on the other hand be loaded in BDV.
The data at the end is the same, but the path where the data is stored is different. The question is whether one could create a kind of header file so that Imaris could just open h5 files generated by BDV without conversion. Ilastik opens plain Hdf5 so one has just to figure out which resolution to open.
I agree with you. It is not a new container/file format that will save us from the conversion hell. Developers need to write files that are compatible with each other software, this can be complicated as one needs to agree on which specification. Having more generic reader that are flexible enough to understand a bunch of specifications is also a possibility. In the worse case have ask for user input.
There seem to be some good news here: Update JHDF5 library to 19.04.0 Issue #181 scijava/pom-scijava GitHub
So, it may become feasible on the Java side to read and write little hdf5 header/wrapper files that make things more compatible.
Surfaces created with labkit should be batchable in Imaris. However, there is a reported bug that might describe your situation. The bug says that surfaces parmeters with labkit created via BatchCreationWizard do not work in batch while surfaces created in Surpass and stored from there do work. Did you store the parameters from surpass?
Labkit version for Imaris is specific. The labkit ui interface for imaris is also specific. The one for imaris has a slightly different name to select when you install labkit for the first time as from the official website install instructions. This version has a button to finish the labeling and return to imaris.
I guess this two version might not be able work together. However, as long as you install only the imaris version and unselect general version, and that the update did not affect the other dependent jars, imarislabkit should still work even if you update Fiji. If not work, you can try update imarislabkit again before you use it (as if re-intall it)-- it will check the compatibilities and downgrade several dependent jars that has been unintendedly updated beforehand.
I created surface using this imbuned ML module inside an image (which ran well) and saved as a batch file.
Alternatively, I created the batch file from Arena. The surface was also created during batch creation.
Put another way, is there any way to get imaris objects like filaments, surfaces, spots OUT of imaris and into a format that is usable in other software (like Fiji, etc.)? Ideally, I want just a 16 bit tiff label matrix, but anything can help.
AFAIK the objects will not be saved when you use Save As TIFF, only the Volume. One can also read the .ims files (Volume) directly into Python. I use Imaris daily, and when I need the Surface-Spots-Filaments out, I use the object to mask one of the channels (any channel), I set the voxels outside to zero as usual, but I also set the inside voxels to a fixed value, e.g. 10. This creates a new channel that corresponds to the inside of the object, and can be saved out in one of the ways above.
I hope this helps a bit.
The shame about this way is that touching objects in Imaris will be touching elsewhere. Usually I can work around this (usually make new surfaces from a distance transformation of the original surfaces so they 1 pixel shrunk) but it would be useful to get label images out of Imaris as default.
I am currently using brainreg for automated registration of different atlases to our datasets of cleared mouse brains. Mostly worked with allen_mouse_10um and 100um as well as perens_lsfm_mouse_20um.
However, I would now like to use the registered data for segmentation of specific brain regions from our dataset and have different issues with that. I would be really grateful if someone with more experience might be able to help.
I would first like to view the registered atlas together with the original dataset in imaris, but for some atlases I cannot finding the right settings for displaying the atlas outside of napari properly (e.g. in imageJ or in imaris). In napari, the intensities that encode the different regions are automatically visualized using a proper LUT. Any tips on how to achieve that with ImageJ and Imaris, too? Would it make sense to convert it into RGB before importing it into imaris? I guess the reason is that some region IDs have very high values compared to the others. Therefore, there seems to be no contrast setting that can display both intensity ranges at the same time.
Option 2: Upscaling the registered atlas to the resolution of our dataset.
But then, I would not have any .obj files available to import as surfaces in imaris, as they are not part of the napari brainreg output, right?
And I assume the segmentation in brainrender will not work with the atlas registered to our dataset, is that right?
I did not attempt to upscale the atlas using python so far, though.
Sorry I think I misunderstood. Is the aim to segment the region boundaries for a specific brain structure in each of the samples, and then visualise/analyse them, to e.g. compare sizes between groups?
Yes, exactly. E.g. comparing size, staining intensity or staining patterns of a specific immunmarker etc.
Thanks for your suggestion! I might try that one.
Until then I will probably stick to a (little cumbersome) workaround I found yesterday: Using ImageJ for setting a threshold for a specific intensity value (region ID), set the background to NaN and then exporting a binary segmentation image for Imaris.
At first I had the same idea as you - find a way to get .objs into Imaris. I tried it, and realized that Imaris only accepts .wrl or .iv meshes when loading an external object. You can export from .obj to .wrl but only with a very old version of Blender (2.49).
I have tried using BIRDS in the past and did not have any luck getting the plugin to run properly. From their GitHub page, it kind of looks like they made it and then stopped supporting it. If anyone ends up having luck getting this work, please let me know!
So for example, if I register my original size transverseTIFFS (2 uM x 1.8 uM x 1.8 uM) to the coronal 25 uM atlas, would I simply upscale that coronal registered atlas result to 50 uM x 45 uM x 45uM?
Even if we prefer to rely on fully open-source solutions, Imaris has been a great tool during the past years. As we already developed a EasyXT in Matlab, we decided to go with one of our favourite tools: Fiji.
Briefly, EasyXT-Fiji will allow you to use Imaris as a minion from Fiji, for example using a groovy script you can open an imaris file, detect spots and surfaces in Imaris, get their masks of labels in Fiji, make use of your favorite ImageJ plugin and send back to Imaris additional channel and objects.
Currently, we are working on getting the API to work and stabilize, before creating ImageJ Commands that can be macro-recorded. This project is mainly intended to be used as an API when writing Groovy scripts. For that purpose, the demo folder might be the most interesting!
Thanks for including 3D ImageJ Suite in this project. Regarding dependencies usually I ask the user to install the dependency (in the case of Fiji it is quite straightforward) in order to avoid multiple versions of the same library. I also have a backup copy (if the author allows it) of a working version of the library in case something goes wrong.
Hi @romainGuiet @oburri ,
I just recently installed and tested you EasyXT-Fiji, and as expected it was working nicely out of the box as advertised
I was wondering, when fetching surfaces from Imaris, would it be possible to directly fetch them as label images instead of binary images? I had the feeling that touching objects that have been separated using a watershed in Imaris would still appear to be merged in the binary image in Fiji.
Thank you for sharing this awesome project!