-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
closed loop feedback? #8
Comments
Hi @tractatus, thanks for your note. I agree completely, closed loop sequence modification is super important, and definitely something that I would want to do in my own stuff as well. Short answer is: it's still an open question, and I'd love to hear your thoughts. here are some of my first thoughts as i'm sure you've seen, One idea: I would like to see class MDASequence
axis_order: Sequence[str]
axes: Dict[str, Iterable] The closed loop logic then would need to be captured in the individual axis Iterable. For instance, take the time axis, which is currently captured in the A) have some additional stateful logic in part B there is more up to the actual acquisition engine. pycro-manager, for instance, has the concept of acquisition hooks that would perform the actual logic of updating the event sequence. So I guess the challenge for anyway, that's obviously not a complete answer. but I definitely agree that it's important ... and it would be nifty if we could capture the concept of dynamic closed loop logic in a declarative schema, without being totally dependent on the actual engine performing the acquisition. I very much welcome your thoughts! btw... I worked with Je a little bit when he was here at HMS, say hi! :) |
one more side note...
|
Wow yeah sounds that we are very much on the same page then. I will directly go in and checkout your run_mda method and simply translate it to C++ and start from there and as the process gets more mature the full aspects of closed-loop probably have been planned out.
I agree with this. The specifics of the dynamic properties should probably not be contained in the schema representation but rather just a human-readable way of quickly identifying the loops that exist and then further information is specified in the class (or even compiled program) that is the controller. Im aware of the |
awesome. makes sense.
I would also point you to the two other existing micromanager "engines" that I know about:
I'll also cc @nicost ... who I believe has also toyed with the idea of writing a core acquisition engine in C/C++ (which would be fantastic!). honestly, if you write an mmcore acquisition engine in C++, I suspect others might want to use it? |
Hi @tlambert03
I really like the idea of
useq-schema
!Over the last couple of days I've been working on putting together a basic C++ library that uses a combination of:
I primarily work in in situ sequencing method development (https://www.biorxiv.org/content/10.1101/722819v2).
One of the things we will see this year in in situ sequencing is an explosion of different commercial vendors offering "hardware boxes" that are essentially just a box with automated fluidics and an epifluorescent microscope to perform some iterative smFISH.
My idea with embarking on the above C++ library is rather that any microscope and hardware can be turned into a sequencing machine operating in a similar fashion to the Illumina Local Run Manager (keeping similar file conventions, user interface etc.).
I really want to use
useq-schema
to specify and make acquisition runs reproducible. Before embarking on this and digging deeper into theuseq-schema
I had one question:Question: Do you have any current plan on how closed-loop events could be handled within the
useq-schema
. In situ sequencing is full of closed-loop events. Let me give you an example:Closed-loop histogram equalization
: Traditionally each nucleotide can be represented by a single non-overlapping fluorophore. For example A, T, C, G could be represented by Alexa488, Alexa555, Alexa594, Alexa647. Before each sequencing cycle is started the microscope first goes to a region not imaged and takes some snapshots with a given exposure time and light power. The images from these snapshots are then used to compute histograms and extract statistics that are then used to inform the exposure time and light power etc. of each channel setting such that the histograms of each channel are as closely equalized as possible before starting the true acquisition.There are tons of similar events like this (checking that fluorophores have cleaved before starting the next cycle, adjusting laser power across z-axis etc.).
Do you have any good idea if events like this should already be represented at the level of
useq-schema
?The text was updated successfully, but these errors were encountered: