Add support for space-time markers and LSM/FLIM raster measurements

[marktsuchida]

This follows discussion in #44. We agreed there that this should be merged after a v0.5 release, so I'm marking this PR as draft for now.

The first of 2 commits adds the fields for indicating detector ids used for "space-time markers", and to indicate which detector id is used for which FLIM/LSM functionality (i.e. pixel, line, or frame clock).

The second commit adds the fields to record measurement setup for raster scans (LSM), including FLIM. Compared to #44 (where we discussed fields /setup/flim_*), I have changed this to a subgroup /setup/raster, after noting that it can be used for any SPC LSM, not just TCSPC FLIM.

The two commits are orthogonal to each other.

Cc: @smXplorer and @talaurence.

[marktsuchida]

Appreciate any comments or suggestions for change. BTW Is there any plans about when v0.5 will be releasd?

[smXplorer]

Appreciate any comments or suggestions for change. BTW Is there any plans about when v0.5 will be releasd?

@marktsuchida Will look at this next week hopefully.

[marktsuchida]

Transplanting @smXplorer's comment:

Not sure whether assuming that horizontal calibrations are identical in X and Y is general enough? As a matter of fact, I encountered a case of a scanner that scanned at an angle... that is where the X and Y directions where not orthogonal. In other words, one may potentially want to provide means to specify each direction individually (in terms of spherical angles and step size? but what about resonant scanner where this notion might not even be applicable?).

I agree, but as with the case of bi-directional scanning (see above), I don't know if this is essential in the immediate next release. Not opposed if a very simple and unambiguous spec can be created.

Resonant scanners could record the H-sync (line clock) in at least a few ways, and the metadata needed to express the required linearization probably needs some work to get right. I'm interested in this, since as of recent we have one in the lab, but I also think it would be okay to leave this for later. I think for this we likely want to use a different overall "type" (as opposed to the default raster).

[harripd]

I agree, but as with the case of bi-directional scanning (see above), I don't know if this is essential in the immediate next release. Not opposed if a very simple and unambiguous spec can be created. ... I think for this we likely want to use a different overall "type" (as opposed to the default raster).

I think I agree about the next release not needing to support the full range of scan types, but we do want to include a field for the type of scanning, so we have extensibility in the future.

To the group for space-time modulation, add a string scan_type of which in the current spec we will provide limited options.

• "raster" defined as @marktsuchida has defined
• "generic" the space-time modulation group that contains two arrays (comments welcome), this group's purpose is to provide a way for any modulation to be implemented, but is inefficient, as each position and time of movement is recorded.
  • time_divisions (integer 1D array) the times when the scanner moves, in the clock rate of the experiment
  • positions (float 3xN array) the xyz positions of each "pixel"
• bidirectional (least likely to be implemented in this version) like raster, but accounts for differences in even and odd lines etc. as per @marktsuchida 's comments

[harripd]

Also, as a quick thought, if we are moving towards having future support for other scan methods, maybe instead of space_time and raster maybe we rename one or both of these to scan as an easier to understand word for those reading this in the future.