Change the channel?

[saskiad]

We have slightly different concepts of channels in both ophys and imaging (SPIM), and we're wondering if it's possible to combine this into a single class that gets used in multiple places.
From my understanding, in the SPIMs, what distinguishes the channels is the excitation pathway - i.e. different laser or laser wavelengths. While in ophys it's the emission pathway - i.e. different filters/detectors. And, @KasparP tells me they also use channels with different dilations where the excitation/emission pathway isn't changed but the PSF of the beam is.
So that would mean that the channel would encompass excitation and emission and dilation (and maybe a few other things). And in some use cases multiple channels would have the same laser source but different emission filters and in others in would be reversed.
How does that sit with people?

Can we try to nail down a definition of a channel to help clarify this? Perhaps the full light path used to collect an image - wherein multiple channels are imaging the same thing (have the same scan path) but collect different properties...

I'd love feedback on this @KasparP, @adamkglaser, @arielleleon, @DowntonCrabby, @sharmishtaa, @dyf, @miketaormina

[miketaormina]

I think your working definition is how people typically think of the concept of channels, that is, something that separates different signals from the same location. Channels on the SPIMs are tracking both excitation and emission (the latter is captured as the filter_wheel_index, which should have a spectral definition in instrument.json).

I'm not sure how the beam dilation fits in here, but I wouldn't mind if it were present in SmartSPIM data, either as an optional field or something that can take a value to indicate "no change from default," or something. There is a similar concept that may not be modeled for the SmartSPIM, which is that there are different cylindrical lenses on the excitation path that are used for different collection objectives. This isn't something that the AIBS instrument has used, but I think John has done some imaging with a lower mag objective on the AIND SmartSPIM. A quick look at the instrument generated metadata doesn't show this as being tracked, likely because the software has a fixed relationship between this and the collection objective. (The stages for these are modeled in the SmartSPIM instrument file, but their positions aren't captured in the metadata). This parameter might fit more naturally in the Tile object as it's own field, but I'm not familiar with its affect on signal in Kaspar's instrument. If it's really a size/shape of PSF only, then channel doesn't seem correct.

I think it would be difficult to accommodate if it required physical units, e.g., a direct measure of beam waist.

[adamkglaser]

Agreed with Mike. For the SPIM systems we changed both excitation/emission, which are captured already in the definition.

The dilation factor I can't ever see being used for the SPIM systems, but it could be added as an optional field. As Mike pointed out, I could live either in channel, or tile. It depends on how we are thinking about things. If we think of channels purely as differences in wavelength/spectra, it doesn't fit here. If we think of tiles as purely differences in spatial location, then it also doesn't fit here.

Slightly in favor of adding it to tile. Reading the tile metadata my mind would read it as "We acquired this tile at this location with this dilation factor..."

[miketaormina]

Hopefully this isn't too far off topic, but does the current tile spec accommodate a remote focussing objective's position? Is that just abstracted into the tile position? It's not the same thing, but it feels kind of similar in that there is some kind of "tuning" parameter that has an affect on tile position, depth of field, etc.

[saskiad]

I assume this gets abstracted into the position, but @adamkglaser can probably speak better to it.

[saskiad]

I think the difficulty that I've found here is that we need the channel to be both part of the instrument(/rig) and acquisition(/session). The channel in tile is only an acquisition thing, so we'd have to change some things up to make this work. Nothing crazy, but it's a different change than what I first imagined.