Do not convert scale metadata from micromanager

[talonchandler]

Possible fix for #418.

iohub convert now passes scale metadata by default, which means that micromanager's pixel sizes get saved into the scale metadata.

This means that recOrder now has two sources of truth for it's scale metadata: the scale metadata of the input zarr and the scale metadata that the user enters in the "pixel size" and "magnification" textboxes. This causes problems because the ome-zarr reader treats the zarr's scale metadata as truth, so when you try to compare data from the GUI to data from a file the scale is incorrect: see #418.

I can see two ways to solve this:

1. Treat the zarr scale metadata as truth. This would mean removing the "pixel size" and "magnification" fields from the recOrder GUI, removing the yx_pixel_size field from recOrder CLI, and forcing all recOrder==0.4.0 sessions to set the correct pixel size in the micromanager's pixel size calibration tool. This is a reasonably large change.

2. Continue to treat the recOrder GUI as truth and do not pass scale metadata through iohub convert. This is the one-line fix implemented here. This means that scales will be [1,1,1,1,1] throughout recOrder sessions. This means that you can easily compare everything, so it "fixes" [BUG] GUI-generated layers are incorrectly scaled #418.

I am leaning towards solution 2 for recOrder==0.4.0, and we can use solution 1 for recOrder==1.0.0.

Note: recorder reconstruct will continue to pass its input metadata through to the output, so mantis can continue to use recorder reconstruct.

[codecov]

Codecov Report

Merging #419 (563fd04) into overlay-on-top (1921be3) will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           overlay-on-top    #419   +/-   ##
==============================================
  Coverage            8.31%   8.31%           
==============================================
  Files                  26      26           
  Lines                4523    4523           
==============================================
  Hits                  376     376           
  Misses               4147    4147           

Files Changed	Coverage Δ
recOrder/acq/acquisition_workers.py	0.00% <ø> (ø)

[deprecated-napari-hub-preview-bot]

Preview page for your plugin is ready here:
https://preview.napari-hub.org/mehta-lab/recOrder/419
Created: 2023-08-19T01:23:03.197194

[ziw-liu]

I will add correct scale information for all of the add_image functions in recOrder to fix this.

This from #418 (comment) seems nicer to me. The old dataset problem can be solved by having a button to set layer scale to identity.
We can still use the GUI scale as the 'source of truth' for yx_pixel_size.

[talonchandler]

I will add correct scale information for all of the add_image functions in recOrder to fix this.

Thanks for bumping. I've given this some more thought, and I will add a third option:

3. recOrder passes scale metadata and uses it for napari visualizations, but recOrder does not use scale metadata for reconstructions. Does you think this is intuitive behavior @ziw-liu? I'm having a tough time deciding between these three options.

Option 3 will require that all add_image calls are scaled using micromanager's metadata that is converted to zarr. This will require emitting the scale from the acquisition threads, but it will work.

Also, if we choose 1 or 3 I agree that a having a Scale selected layers to identity button (or similar) will be easy to implement and useful.

[ziw-liu]

3. recOrder passes scale metadata and uses it for napari visualizations, but recOrder does not use scale metadata for reconstructions. Does you think this is intuitive behavior @ziw-liu? I'm having a tough time deciding between these three options.

Is it reasonably easy to compare those 2 scales and raise a warning if they don't match? It might even serve as a reminder that the user forgot to set those GUI values correctly.

[talonchandler]

Is it reasonably easy to compare those 2 scales and raise a warning if they don't match?

I like this idea. I'll try out option 3 with warnings early next week. I'll leave this open for now in case that fails.

[talonchandler]

Closing this...#426 merged instead.