Users might run experiments and want to verify that the system is operating within expected boundaries. An example experiment might generate data for each imaging round sequentially, and to verify that an experiment is working as expected, each round could be processed as it appears up to peak calling. The number of peaks called could then be compared with the expected number, to a nissl stain, or some other QC criterion.
Eventually, users would like this to be automated, but for now would like to be able to visually inspect the peak call results for each imaging round as it is generated.
This could be "faked" in the current starfish by simply creating 1 field of view experiments. The downside to this approach is that it may not play well with any TileFetcher workflows that users have created.
This type of workflow could enable all kinds of cool accessory workflows which could extend the utility of starfish, for example, setting exposure time by creating a workflow that's run orthogonally to the main image processing workflow that simply checks the first few images of each imaging round on a single field of view.
This Issue has 2-3 stages:
[ ] A short vignette demonstrating a workflow over a partial FOV (single imaging round) using the current library and spec
[ ] A decision on whether ImageStack should be made more flexible to allow partial ranges of Indices that do not start at 0. For example, imaging rounds 4-6.
[ ] If we decide to do the above, A change to the spec and library to support it.
Users might run experiments and want to verify that the system is operating within expected boundaries. An example experiment might generate data for each imaging round sequentially, and to verify that an experiment is working as expected, each round could be processed as it appears up to peak calling. The number of peaks called could then be compared with the expected number, to a nissl stain, or some other QC criterion.
Eventually, users would like this to be automated, but for now would like to be able to visually inspect the peak call results for each imaging round as it is generated.
This could be "faked" in the current starfish by simply creating 1 field of view experiments. The downside to this approach is that it may not play well with any
TileFetcher
workflows that users have created.This type of workflow could enable all kinds of cool accessory workflows which could extend the utility of starfish, for example, setting exposure time by creating a workflow that's run orthogonally to the main image processing workflow that simply checks the first few images of each imaging round on a single field of view.
This Issue has 2-3 stages: