Closed aamster closed 1 year ago
@morriscb currently this code writes the traces into an output directory in <specimen>/<session>/DECROSSTALK/ophys_experiment_<oeid>/roi_traces.h5
for example.
This is what I think you mentioned doing in your note. I do think that decrosstalk should rather take as input the traces, rather than producing them. But that is out of scope for this PR.
What change specifically are you requesting?
Nice. Sounds good, just wanted to make sure where things were going. Initially when I read over the code it didn't look like the traces were being persisted at all. Must have missed that line.
Yeah, it would definitely make sense to pull trace extraction out of this in the future and just load the previously calculated traces. I don't think there is any real difference between the methods used. Something we can do in the future as unfortunately we are hamstrung by the DECROSSTALK module being used by LIMS and any changes we make would require a change in the strategy.
The sensor that blocks the
ophys_processing
dag from running will be worked on separatelyAlso:
OphysExperiment.rois
to returnOphysROI
objects, needed to update the decrosstalk flags. Also refactors it to pull the mask values all at once instead of 1 at a time, which is faster. AddsOphysROI.to_dict
andOphysROI._mask_values
Additional testing
Manually tested
decrosstalk_trigger
anddecrosstalk
(in debug mode)