[Ideas] Ways to improve the ophys module

[CodyCBakerPhD]

i) Create a separate neurodata type for OpticChannels, rather than them being a special thing generated by the ImagingPlane table

This will give the ability to reuse the same optic channels across different ImagingPlanes

ii) Generic MicroscopySeries to replace OnePhotonSeries and TwoPhotonSeries; I also saw a recent talk where 3P was gaining popularity; we've also used OnePhotonSeries for light sheet data before and that association raised eyebrows

[CodyCBakerPhD]

@alessandratrapani @weiglszonja @pauladkisson This is the first issue in which to compile all our ideas / pain points for improving the ophys representations

[pauladkisson]

Ideas that I have come across:

• BackgroundResponseSeries to represent background 'neuropil' activity without calling it an 'ROI'.
• Volumetric Sampling Rate vs. Frame Sampling Rate for depth imaging
• Multiple Optical Channels for 1 ImagingPlane doesn't match metadata

[CodyCBakerPhD]

BackgroundResponseSeries

Would that link to a separate PlaneSegmentation table too?

[CodyCBakerPhD]

• emission_lambda is dependent on the indicator and is used to represent the filter used by the optic channel
• The full information of the emission is a spectrum not a scalar but it is determinable via the indicator using external resources
• Whereas excitation_lambda is a property of the optic channel
• one subject could have multiple expressed indicators, indicator should be a list attached to the Subject
• but, should maybe be its own neurodata type so that it can link to the optic channel since an optic channel exists to target the emission from a specific indicator (not several indicators); perhaps the optic channel field would be target_indicator
• multiple indicators are excited simultaneously by the same excitation lambda
• a more modular neurodata type, perhaps Microscope, subtype of Device which could have properties describing a laser or LED properties
• excitation strength can be time-dependent as seen in fibre photometry; this is used more commonly now with a single indicator but multiple optic channels to discriminate functional vs. anatomical for example

[CodyCBakerPhD]

Current draft proposal:

OpticChannel is a new neurodata type that can exist independently of the ImagingPlane

• it has filter information, how much is still up to discussion (manufacturer, model number)
• main property describes the spectrum being filtered

Microscope is a new neurodata type, subtype of Device

• has attributes describing the excitation pattern (potentially over time) used, similar to command voltage; or a scalar if no variation was used

ImagingPlane is modified to only describe physical space, either of disjoint planes or contiguous volume

MicroscopySeries is a new neurodata type that describes 1P, 2P, 3P, light-sheet, widefield, confocal images

• a regular scan line rate (because of the reliability of piezo design) is available as an attribute for 2P/3P but would be None for others
• a regular plane acquisition rate (because of the reliability of piezo design) is available for any volumetric plane to describe the delay between plane acquisitions relative to the start of acquisition of each frame
• this should remove the unit attribute because it is always otherwise set to n.a. or a.u. (quantal flux can be calculated after the fact but raw imaging would never have)
• resolution is not relevant to microscopy, more of an ephys relevant value

[weiglszonja]

SegmentationImages should also have a link to which plane segmentation they belong to. Currently they are added to an Images container and the only way to determine which plane they belong to is relying on the name of the container.

[CodyCBakerPhD]

@weiglszonja This would apply to all other summary images as well, right?

[weiglszonja]

@CodyCBakerPhD Yes, like what we see for Pinto with the contrast, PCA and vasculature "masks".

[alessandratrapani]

looping @h-mayorquin in

[pauladkisson]

Hey guys, I found a nice paper on future trends in microscopy here. There are a few new developments that I think we should watch for such as bar code labeling that uses multiple fluorophores for each molecule to allow scientists to look at more markers simultaneously.

[pauladkisson]

Based on the discussion in ndx-holographic-stimulation, should we also include changes in the Ogen module? Or should we limit those to a separate extension?

[CodyCBakerPhD]

If we're extending ogen to include ogen from a 2P system, and the metadata for all that overlaps, then probably yes

[CodyCBakerPhD]

From NeurodataWithoutBorders/helpdesk#64 (reply in thread) posted by @ehennestad

I would argue that the indicator should not be coupled to an optical channel. True, optical channels should be optimised to capture signal only from the indicator of interest and block out other indicators but this might not always be true (bleedthrough is a common problem). Furthermore, multiple indicators are present in an imaging plane, regardless of the configuration (filters) of the optical channel and whether or not an optical channel is active or not. On the other hand, I understand that the imaging plane is an abstraction and in the ideal case it is coupled to a "perfect" optical channel and thus capturing only one indicator. I don't have a strong opinion either way, I was just curious what is common practice.

[ehennestad]

I really liked this suggestion though:

but, should maybe be its own neurodata type so that it can link to the optic channel since an optic channel exists to target the emission from a specific indicator (not several indicators); perhaps the optic channel field would be target_indicator

I still think it makes most sense to define the indicator somewhere else (e.g associated to the subject), and keep the optical channel independent from it. The optical channel is the same from one session to the next, independent of what kind of subject or indicator is being imaged.

[weiglszonja]

@alessandratrapani @pauladkisson FYI:
Multichannel volumetric imaging NEP nwb-extensions/nwbep-review#3

[CodyCBakerPhD]

Something else that's come up in my latest conversion is a slightly irregular Z-axis (depth) on each frame acquisition, such that a regular grid_spacing as we have now doesn't exactly capture that descriptor of the volume