Open manerotoni opened 1 year ago
I think we should ask on the forum.
Yes. I just would like to log here the different behaviors.
Which prompted me here: https://github.com/napari/napari/issues/4861
Still unsure why we are still seeing this, the bug was closed and fixed in August last year
It reads quite similar to what we see
I tried to reproduce the error-behavior. It depends on the scaling factor which is super weird. So we should be able to report it.
From most of the images, the slider is independent of the scaling. It just shows the frame position. I guess this is the expected behavior. The values at the left gives the calibrated coordindates rounded to int (arguable why to round the value)
https://neubias.github.io/training-resources/spatial_calibration/index.html#explore3D The slider always gives me the position of the slice ranging from 0-5 (6 Z-slices in total). This is independent if you load with scales or not.
https://neubias.github.io/training-resources/multidimensional_image_basics/index.html#xyz 40 slices, slider gives 0-39 as expected. No difference is scales are on or off
https://neubias.github.io/training-resources/multidimensional_image_basics/index.html#xyzc Image has 41 slices. In calibrated set the last plane is really gone! The uncalibrated slider range is 0-40, the image with scales is 0-39.
I would say that we are facing exact the same problem and that the bug is not resolved.
You can try different values of the scaling. Depending on the value you get a different behavior. Correct should be 41 slices. Slider from 0 to 40.
I think the behavior is explained in https://github.com/napari/napari/issues/4861#issuecomment-1201195259
and
https://github.com/napari/napari/pull/4889#pullrequestreview-1057494514
In the example above: the z stack has a total range of 41 (planes) * 0.1 (um/plane). It seems in napari, the number of slices is computed with the “//“ operator:
( 41 * 0.1 ) // 0.1 = 40 for some floating point errors.
In the above issue it does not seem that this is an easy thing to fix without introducing other bugs, such as the opposite error (having one extra slice for the same floating point error).
It might be something we have to live with for the time being.
Hi @grinic, the expected behaviour is that the slice shown in the slider should be independent of the scaling. These are just the dimensions of the numpy array. This is most of the time the case. If you look at the slider it does typically not change with the scaling.
I would like to see the complete stack when I load an image. What happens is that in some cases some slices are just not shown. This is a big BUG.
Why does napari recompute the slice number at all? This does not make sense.
What is shown in the left corner as number is the rescaled coordinate, ideally it should be a float number.
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
Hello @tischi, @tibuch , @grinic, and everyone in the course,
the display of scaling in Napari is confusing. I am not sure it is a bug, I think it is more a feature that is lacking.
It looks that Napari has a different behavior than expected from ImageJ.
It looks that positions shown in Napari in the left corner are always integer values. The slider is integer values but somehow converts to something scaled.
May be we should not perform a rescaling in physical size but only care about the anisotropy? Something like
scale = [size_z/size_x, 1, 1]