[SCHEMA] Add light-sheet microscopy acquisition metadata fields

[kabilar]

Here we propose adding metadata fields for light-sheet microscopy acquisition. Although these fields could fit within the OtherAcquisitionParameters field, we felt that it would be better to formally define these parameters alongside the broader community.

cc @emineozeen @balbasty @blankenp @jimmyjam100 @ayendiki @satra

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.07%. Comparing base (75ceda1) to head (ef05543).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2448   +/-   ##
=======================================
  Coverage   83.07%   83.07%           
=======================================
  Files          22       22           
  Lines        1696     1696           
=======================================
  Hits         1409     1409           
  Misses        287      287           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[effigies]

To be clear, these are being applied to all microscopy images:

bids-specification/src/schema/rules/sidecars/micr.yaml

Lines 30 to 34 in ef05543

	MicroscopyImageAcquisition:
	selectors:
	- datatype == "micr"
	- suffix != "photo"
	fields:

Do they apply to all, or only certain types?

[kabilar]

To be clear, these are being applied to all microscopy images:

bids-specification/src/schema/rules/sidecars/micr.yaml

Lines 30 to 34 in ef05543

	MicroscopyImageAcquisition:
	selectors:
	- datatype == "micr"
	- suffix != "photo"
	fields:

Do they apply to all, or only certain types?

Hi @effigies, I am not sure if these metadata apply to modalities other than light-sheet microscopy (i.e. SPIM). This spec seems to cover a lot of modalities. I would imagine that the metadata apply to a subset.

[effigies]

If they only apply to SPIM, then let's put them in their own table, e.g.,

SPIMAcquisition:
  selectors:
    - suffix == "SPIM"
  fields:
    ...

Then add text and a macro in the relevant section of the microscopy markdown file.

[kabilar]

If they only apply to SPIM, then let's put them in their own table, e.g.,

SPIMAcquisition:
  selectors:
    - suffix == "SPIM"
  fields:
    ...

Then add text and a macro in the relevant section of the microscopy markdown file.

I have pushed a commit with these updates. Thanks.

[effigies]

Works from the BIDS side. Any SPIM users/experts want to chime in?

[balbasty]

I've asked our optics team (@blankenp and @emineozeen) for a review (full disclosure: we are all collaborators of @kabilar, so not an entirely independent review). Here are their comments:

Some of the proposed keys could apply to other (non-SPIM) microscopy systems:

• ExcitationWavelength
• EmissionWaveLengthRanges
• LaserPowers
• FrameAxis is the point-scanning direction and could apply to other systems
• FrameRate can apply to all scanning camera-based systems
• StageVelocity can apply to any microscopy system that is using a stage for scanning rather than a galvanometer

Only one key seems SPIM-specicfic:

• SheetAngle

Other precisions:

• FrameRate and StageVelocity are supposed to be synchronised, so maybe not needed to have both (although they do represent two different parameters of the system)
• The separate acqusition of image and background frames may be quite specific to our group

And then question from myself, as a downstream user:

• Is it well specified what X/Y/Z correspond to, in terms of image axes (yes in OME-zarr, not sure about e.g. tiff)
• X/Y/Z seem to have standard meaning in the SPIM world
  • x = point scanning direction (at each step, one (y,z) image is acquired)
  • z = through the tissue depth
  • y = tiling direction (once all x steps of a strip have been acquired, the stage moves along y and the next strip is acquired).
  • -> Should this mapping be saved nonetheless in the metadata? While our use cases relates to an experimental system where the raw data is saved and shared, the _SPIM suffix also applies to data from commercial systems where the X/Y/Z mapping could be different.
• It's not clear to me if the sign of X/Y/Z has a standard meaning.