Represent filter spectrum?

[dyf]

Currently we describe imaging filters as band/high/low pass, but do not attempt to describe the filter spectrum. Do we want to attempt this, and if so how?

An example of something provided by the filter manufacturer.
https://www.semrock.com/FilterDetails.aspx?id=FF03-525/50-25

@saskiad, @adamkglaser, @miketaormina

[dyf]

To me this is probably encapsulated by the make/model of the filter, so it's just a question of how accessible we want to make this to ourselves and to users later down the line.

[miketaormina]

I think that 99% of the time, the (center, width) for a bandpass and (cut on/off) for the others will be sufficient. These are typically in the part number. The efficiency within that window is one thing that isn't captured by those numbers, but it's something people don't often think about, for better or worse.

The main situation where someone will want the actual spectrum programmatically available would be computational un-mixing (?). I'm not aware of anyone currently doing that, especially on a production scale, but @adamkglaser and Kasper are the people I would place bets on doing that at some point. I'm not even sure it is the case that it would be used, as un-mixing algorithms probably take a matrix of channel/channel cross-talk, which would be either calculated (or directly measured) from both excitation and emission spectra.

The multi-band filter class is something that could end up with a custom optic which might not have a detailed spectrum associated with a part number. The exaSPIM may be an example of this, as the filter will at the very least be a custom size (and so have a weird part number).

An example transmission curve I checked today had about 600 (wavelength, transmission %) pairs, which isn't large, but will definitely clutter the human readable nature of the instrument JSON.

Also, for what it's worth, it looks like the OME spec allows a CutIn, CutOut, and Transmittance. It's unclear if these are restricted to one or if a multi-band filter can be constructed by including many.

[adamkglaser]

Agreed with everything Mike mentioned above. I had originally envisioned that the part # would be sufficient, either since it contains some of the information like cut on/off wavelength(s), or could be looked up with the vendor to get this information. Although there is a small chance that the part could be discontinued.

I think the levels of complexity would be:

• Only capture part #. Assumption that the detailed specs will always be available from the vendor if needed. Some information could be grabbed from the part # naming nomenclature.
• Also capture explicitly some of the important values, such as CutIn, CutOut, etc. as specified by OME. Or we come up with something similar, but of our own.
• Comprehensively cover all of our bases and store / log the ASCII data for each filter, which is available from the vendors. https://www.semrock.com/_ProductData/Spectra/FF03-525_50_Spectrum.txt.

I am open to any of the above, depending on how thorough and open we would like to be.

[miketaormina]

fourth option is somewhere between the second and third:

Allowing a list of tuples in the form of (cutin, cutout, t%).

1. longpass is represented by (lambda1, None, 0.99)
2. shortpass is represented by (None, lambda1, 0.99)
3. single band pass is represented by (lambda1, lambda2, 0.99)
4. notch filter (lambda1, lambda2, 0.001)
5. multi-band [(lambda1, lambda2, 0.95), (lambda3, lambda4, 0.99)]

If someone wants a more complete description, they fill in the places between pass bands with the appropriate (small) transmittance.

The None values could be replaced by the appropriate wavelength that information is available for, since no information is known outside of those windows.

[miketaormina]

Oddballs like tunable filters would need to be tracked with a new class and dichroics are becoming less relevant with laser excitation.

[dyf]

Defer to @saskiad, but my preference would be to wait to add complexity to the schemas until needed.

[dyf]

Which is to say, either leave it at part number as we are doing now, or add a reference to a URL (a bit like a protocol).

[saskiad]

I thought we had landed on simply using the part number for this. I'm open to adding the details - I like the idea of adding the info that OME does - but I guess the place where I get unsure is how we do this for other components that aren't as striaghtforward as filters? It seems odd to add parameters for some components but then not for others.

[saskiad]

Also, I do think that the more information we can provide the better - it's the consistency that I'm worried about.

[adamkglaser]

For now maybe we stick with just the part #? Which should in theory be sufficient to get the full detailed spectral data if necessary. And we can modify/revisit this in the future if needed?

This conversation might be relevant to how we document/open-source various hardware projects (rather than capture in instrument schema). As part of the hardware repos, perhaps we include this type of detailed data, not only for transmission spectra for filters, but other hardware devices as well.

[dyf]

Sounds like we have a path forward - let's leave it as a part number for now.