Dont set z scale

[will-moore]

This comments-out the setting of Z-scale, which I find causes various issues (testing with
napari==0.3.5).

Testing with a Z-stack image of size_Z = 50, with pixel size X: 0.633 and Z: 0.2 microns. Available at
https://downloads.openmicroscopy.org/images/DV/elena/P-TRE/P-TRE_21_R3D_D3D.dv

Without this PR, we set scale = [1, 3.0161362196625654, 1, 1], which causes the Z-slider to report an index of Z-1.
See first screenshot:

• The max Z index is 48 (should be 49).
• The current index in the screenshot is showing as 0, when the slider has been incremented 1 place from the left. (left-most position also shows index of 0).
• get_plane() is correctly loading Z-index of 1 from OMERO.

• If I then click to add a Shapes layer, the Z-index slider shows that I am now on index 3 / 149 (without changing the Z-index) and Shapes drawn on this layer have coordinates of Z-index: 3. The current save_rois() code for saving ROIs back to OMERO will therefore save these on Z:3 (instead of Z:1).

If I try a different Z-scaling, manually setting the scale to [1, 2.0, 1, 1] (for testing), the initial Z-slider shows a max of 49 (correct).
When I switch to Shapes layer, I see a max-Z index of 99.
As I increment the Z-slider through the 99 indices, I see an unpredictable mapping between Z-slider and the Z-index of planes loaded from OMERO, with some planes being displayed for 3 Z-indices and some for only 1 (instead of 2 each as you might expect):

• slider: 0, plane: 0
• slider: 1, plane: 0
• slider: 2, plane: 1
• slider: 3, plane: 2
• slider: 4, plane: 2
• slider: 5, plane: 2
• slider: 6, plane: 3
• slider: 7, plane: 4
• slider: 8, plane: 4
• slider: 9, plane: 4
• slider: 10, plane: 5

So, when saving a Shape back to OMERO, it's hard to map Z-coordinates from napari to a plane in OMERO (without a look-up table as above).

[codecov-commenter]

Codecov Report

Merging #15 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #15   +/-   ##
======================================
  Coverage    0.00%   0.00%           
======================================
  Files          11      11           
  Lines         723     718    -5     
======================================
+ Misses        723     718    -5     

Impacted Files	Coverage Δ
src/napari_omero/plugins/loaders.py	0.00% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9fbea12...4a209cb. Read the comment docs.

[tlambert03]

sure that's fine. sorry I uncommented out that bit from what you had in the original repo. I had followed along a bit with the discussion on image.sc ... but somehow missed this point when I tested and mistakenly thought it was working. It's a bummer, but ultimately it's a napari bug, and the real fix will come with the world coordinate refactors in the works.

[will-moore]

No problem. I think things have improved in napari since that discussion, but not there yet.

I think I guessed why the mapping of Z-index to OMERO planes above is "unpredictable". Probably due to python3 rounding behaviour "if two multiples are equally close, rounding is done toward the even choice". https://docs.python.org/3/library/functions.html#round
So it should be possible to predict which plane the user is viewing when they add a shape to a particular Z-index.
But still, I think the current user experience is still a bit confusing.