Operating system: Windows
Slicer version: 4.11.0-2019-06-23
Expected behavior: display views normally
Actual behavior: slice-views displays lag.
You see, now I have an image which has a pixel-spacing 15nm (that means, 1.5e-5mm). I load this image to Slicer and it seems fine. But the mouse-scroll to change slices along views does not work (slower than usual, the slice-bar on the top of each view work fine though). So I try to put a fake pixel-spacing value as 1.5mm or even 0.015mm, it works fine to middle-mouse-button-scroll to browse slices along views.
This issue may be reproduced by yourself , trying to use that famous MRHead image, if you set image pixel spacing as 0.001mm, it’s fine. but if you set image pixel spacing as 0.0001 mm, then you try mouse-scrolling where you may see my issue.
Regardless of using Slicer for astronomy or microscopy, coordinate values should be in a reasonable range. You may run into various issues if you use coordinate values that are extremely large or extremely small.
Do not rescale your image if your problem is that the displayed unit is incorrect. Instead, change units in application settings / units section. Since units are rarely changed from the default, it may go unnoticed if usage of mm is hardcoded at some places. If you encounter such cases then let us know (if they are easy to fix then we may fix it, if not then we may ask for your help).
I may try to set up units for some certain images, but it is really NOT that convenient while we have images with pixel-spacing values ranging from 10mm to 15nm.
From a view of a scientist, pixel-spacing values should NOT bring such issues since a value is a value, a float is a float. Anyway, if you guys may solve this issue, that will be a big help and this also helps more applicable in a widely expanded range of industries.
@lassoan, I tried and think the lag is no much due to change in the units, but simply the slider has only 0.001 mm increments, so slices do not get changed until the units incremented more than 0.001 mm (which will take 10 slices in this scenario). We will encounter small voxel data more and more through SlicerMorph. I wonder if it possible to tie the precision of the slice views (current seems only three significant digits), to image precision of the volume being displayed?
Definitely, there’s a lot of room for improving support for different units and spacings, and supporting more than 3 digits makes sense.
One thing to keep in mind is that it’s not just a notation thing, the stability and even accuracy of a lot of floating point computations depends a lot on the range of values, so it’s good to avoid extremely large or small values and rather change the units.
Precision of that slider can already be set in Application settings / Units.
Units may not be respected everywhere right now, but probably should be fixable without too much effort in many places.
There are a few cases where some design changes would be needed. For example: The ruler, uses multiple units (not just mm but cm, etc.) to keep numbers easy to read. We should also ensure that units received from external sources are respected/converted (e.g., if a DICOM volume is loaded and application length unit is micrometer then spacing values should be converted accordingly).
True. I set it to 8 digits for length and it does display the full precision.
But still slices only updated if the increments is multiple of 0.001 (i.e., it doesn’t matter how many significant digits it display for the functionality).
If you use computers, it is important to understand the limitation of floating-point number representation. For example, regardless of what software do you use, if you have a small number, add a large number to it, subtract the same large number, then the result will be 0 (not the original small number). These kind of errors would happen all the time if you attempted to process images together that have vastly different scale.
You can have a look at this document describing some of the common issues.
Even if length scale difference between two data sets is “just” 6 magnitudes (mm/nm), it means that volume scale difference would be 18 magnitudes away. For example, if you compute the volume of a structure in the small image and volume of another structure in the large image then you can store the results in two separate floating-point variables (v1 and v2), but you cannot store the sum of these volumes (v1+v2) in one floating-point variable.
So my question is: is there a way to access “application settings/Units” via python? so that I may try to do python coding to change units based on my different-scaled images.
Thanks!