Hi everyone,
I think there are a couple of posts about units some of which have been answered in length such as here: Fix custom unit management · Issue #5040 · Slicer/Slicer · GitHub
But I am finding surprising that by creating a nrrd file using imageJ, set in microm, it can not be recognised as such and converted in mm in slicer automatically.
Is this something that may be fixed in the future ? Could my ImageJ settings be wrong even though metadata clearly show um in imageJ, and changing this to microm does not solve the problem in slicer ?
Thanks
Thats probably a problem in ImageJ A functional but incompelete NRRD header looks like this:
NRRD0004
# This NRRD file was generated by pynrrd
# on 2019-08-02 13:02:24(GMT).
# Complete NRRD file format specification at:
# http://teem.sourceforge.net/nrrd/format.html
type: uint8
dimension: 3
space: right-anterior-superior
sizes: 259 258 421
space directions: (1,0,0) (0,1,0) (0,0,1)
kinds: domain domain domain
encoding: gzip
space origin: (0,0,0)
spacing comes from the image directions. But without the NRRD field space units (Teem: nrrd: Definition of NRRD File Format), it is not clear whether 1 in this case is millimeters, meters, or microns, because there is no explicit unit defined. That’s an unfortunate side effect of NRRD writer used. Possibly that’s what ImageJ is doing that.
if you can obtain the header of the NRRD file you can check it for yourself. If the space unit defined as micron, and slicer is reading it as mm, than that would be a slicer issue and please report to us. Otherwise, if the header is incomplete, there is not much Slicer can do. You will be better of using the ImageStacks in Slicer to avoid issues like this.
Thanks Murat,
I have checked nrrd at the end of my ImageJ preprocessing pipeline.
Units are set correctly in the meta data:
space units “microns” “microns” “microns”.
and I checked the header in a text editor, the units are indeed microns.
indirect question: I haven’t changed ‘microns’ to ‘um’ in my header, would that help ?
Opening this correctly set file in Slicer, image spacing is not converted to the right units but keeps the values set by imageJ. So if I have 2 um voxels as defined by my header, I get 2 mm voxels in Slicer. So we are keeping mm as units but manually change the Image spacing to reflect the true voxel sizes as it was suggested in other posts. This should be a quick fix but really my post was about : can we have slicer recognising the units as they seem to be correctly set up in the ImageJ output file.
But there’s more:
Once processed in Slicer (rotation and croping), and saving the corresponding nrrd file, that nrrd file looses the units in the header.
Also, indirect question: Is this implying that nrrd is not the best format to work with ? what is a good alternative considering our images are pretty big?
Best
I can confirm that if you replace the “micron” with “um” “um” “um” slicer does indeed recognize units as micron. However, there is a weird bug, in which it then multiples those values by 1000, practically bringing the units back to millimeter scale. So for a NRRD header:
space directions: (35,0,0) (0,35,0) (0,0,35)
space units: "um" "um" "um"
slicer volumes module report the spacing as 35000 microns.
@lassoan @pieper can you take a look?
I think NRRD is still the best format to use, perhaps until ZARR becomes more mature and commonly available in software package. You have couple options:
- You can use
ImageStacksmodule in SlicerMorph to import your data into Slicer as opposed to Fiji, and enter the resolution in millimeters scale (so 0.035 as opposed to 35 microns). - You can save your data from fiji, but manually change the headers to bring the scale to mm units and values.
@pieper @lassoan
We really have to fix that because entering a spacing value that is 1.24 microns as 0.00124 requires way to many significant digits, and can potentially cause precision issues during volume calculations and other things.
1 Like
Thanks Murat,
and I agree having something reliable in terms of units would be ideal.
What about this part of my post:
Once processed in Slicer (rotation and croping), and saving the corresponding nrrd file, that nrrd file looses the units in the header.
Is this expected behaviour. I use the latest stable version (5.6.1) on linux
thanks again for all your hard work and making this tool available to the community
My experience is that expressing everything in mm is the most reliable path. The units infrastructure in Slicer works for some things but probably not all. It was added after the core code was in place.
I realize that for small specimens using mm could cause numerical instability, but I haven’t seen that tested thoroughly. Perhaps try your desired operations in by making using the true small spacing in mm or by pretending that microns are mm and converting back to um in the end and see if the results are significantly different. Then compare that with using the um and the units infrastructure. Reporting issues based on this analysis could help narrow down where units support needs work and how it should be prioritized.
The other issue is data interoperability. We do need the specify the units of the data saved in NRRD, which appears is currently missing in files written by Slicer.
Yes, we are testing this and will report back.
Here are some results.
I loaded the same volume twice. One has the image spacing 0.00125mm, and the other one is 1.25 mm. In this case we are pretending we have a 1.25 micrometer resolution.
Then I segmented 3D sphere using 10% diameter of screen resolution, and the proceed to calculate label statistics.
The good news on this part is results are correct.
Obviously some programs may not like the precision required for such small numbers, but at least we are not seeing a loss of precision within Slicer. Not sure what would happen if I go one order magnitude down, though. With lightsheet and confocal microscopy it is possible to image below micron resolution routinely.
Then I converted these segmentation to models, and that’s where we have a problem:
The volume and SA of the model created from 0.00125 lost a lot of significance as it is reported. The precision of the displayed fields cannot be increased by the usual CTRL+ (I assume that’s because they are not user editable fields).
@coco for the being, if you can set the units in Fiji to mm, and then calibrate and export your data from it, I think you will be fine.
@lassoan @pieper but the lack of space units field in the Slicer written NRRD needs to be addressed. That’s a data integrity and interoperability issue.
1 Like
Yes, IMO this is still the recommended approach.
Yes, that one sounds pretty straightforward.
Thanks for investigating this. Agreed, getting units support to work well is an important feature that requires more work.
2 Likes
We have an issue where we collect all the problems (mostly incomplete implementations) related to units. The hardcoded unit in Models module’s Information section is already included.
The fix for the model information section may be very simple: set the quantity property in the spinbox widget that displays the result.
Thanks all for all your feedback on this,
As far as I can see, the model information does not allow setting the number of digits so I am not sure if what you say Andras (re easy fix for model informations) are instructions to users or developpers.
In any case, the model information tab would not be used to extract datas, correct ? I have only started playing with models and metrics we used were extracted directly from segments which according to Murat, do not have issues.
Thanks again for looking into this.
You can adjust the precision for surface area display in application settings / Units section. The only problem is that the widget that displays the surface area in Models module does not use this setting, so a little development work is needed.