Skip to content
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

motion correction feature requests #184

Open
eflister opened this issue Jun 6, 2015 · 4 comments
Open

motion correction feature requests #184

eflister opened this issue Jun 6, 2015 · 4 comments

Comments

@eflister
Copy link

eflister commented Jun 6, 2015

  • all sima.motion.MotionEstimationStrategy choices seem to consider translation only -- tho this is often the most significant motion, there are also detectable rotation (and shear, tho less so) components, and many segmentation methods will be distracted if these are left uncorrected. matlab's imregtform has options to include rotation or shear -- of course it is not fast. i am happy to continue doing my motion correction in matlab, but pure sima users would benefit from the option to be sensitive to these other modes.
  • estimate() returns ints -- are corrections quantized to whole pixels? this seems an unnecessary introduction of error, esp for small structures like axons.
  • does estimate() rerun correct() (or v/v)? this is time consuming -- could alternative corrections be cached and queried like segmentations are?
  • can you document PlaneTranslation2D's method options? is correlation phase correlation? is ECC this or this?
@eflister
Copy link
Author

eflister commented Jun 6, 2015

does estimate() rerun correct() (or v/v)? this is time consuming -- could alternative corrections be cached and queried like segmentations are?

not clear from the docs, what i surmise is that both actually perform the time consuming estimation and alter the data, so they are idempotent in that subsequent applications of either result in zero corrections (at least if using the same strategy/parameters). why then do they have such different interfaces? if one wants to know the displacements (so must use estimate()), one can't specify correction_channels. correct(), but not estimate(), can stand as a ImagingDataset constructor, etc. from the docs/design, it looked to me that estimate() was just providing access to cached displacements previously computed by correct(), which seems like a better design to me, but then would want to be an attribute of ImagingDataset, not MotionEstimationStrategy. if caching alternative corrections ala segmentations is not worth it, i think the correct design would be for correct() to also return the displacements and to eliminate estimate() (or optionally replace it with a getCachedMotionEstimates() method on the ImagingDataset).

incidentally, if i have coacquired GCaMP and tdTomato, is there any disadvantage to including the GCaMP in motion correction? i can imagine the variable activity doing more harm than good, but don't have practical experience with which way the balanace typically goes. i want to know the displacements, so i cannot specify correction_channels.

@eflister
Copy link
Author

eflister commented Jun 6, 2015

i'm not understanding the displacements i get from estimate(). for my dataset which is 1 plane, 2 channels, 1 sequence, the displacements have shape (1,num_frames,1,2) (using PlaneTranslation2D). what are the singletons? i can see maybe you'd independently correct each plane, but what's the other one? you don't expect sequences to have the same num_frames, right? does anything make sure their other dims match? in general i can't tell from the doc how information is combined across sequences.

i don't see a way to add a “feature request” tag even though you request it here.

@eflister
Copy link
Author

eflister commented Jun 6, 2015

ah, just read about the hmm's granularity parameter probably relating to this. not the expected place to document the return value of a different method! and not clear to me how all those complex results could fit into two more singletons anyway...

@eflister
Copy link
Author

eflister commented Jun 6, 2015

comparing hmm (frame granularity), plane2d (defaults), and imregtform (rigid, defaults for monomodal, which is just mse gradient descent on the difference image) on the same tdTomato axon data:
imregtform
simahmm
simaplane2d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants