Looking for insight into parameter selection and visualizing the result

[Leo Goldstien]

Hi!

tl;dr - I want to apply openpiv to images of fluorescently labeled cell nuclei. The cells divide and migrate between frames and I'm interested in estimating a velocity field for this process. 

I'm setting up a pipeline to segment & track cell nuclei. Given an image stack I produce a table with (unique_id, t, x, y) for each nuclei. Separately, another table provides me a table of  (unique_id, track_id). Using both, for a given track I can calculate d(x, y)/dt. Averaging these derivatives over windows in each frame should provide a velocity field.

I'd like to compare this manual approach with the cross-correlation approach implemented in openpiv.

So far, I read most of the documentation, some of the code and concluded that openpiv should definitely work for my use case. Cells are quite a bit larger (as a fraction of the frame) than the features in example images, but I feel like selecting the right mix of window_size/search_area_size/overlap should still work. 

So far, I tried this, but overlaying the vectors ontop of the frame doesn't seem to look right. I'd love some insight into how to pick window/area parameters or direction as to how to optimize it myself. What am I missing?

Attached: two frames showing fluorescently labeled nuclei of dividing cells

Thanks,

Leo

[Ivan Nepomnyashchikh]

For PIV, we divide the image onto interrogation windows. Usually, those windows have the size of 32x32pixels or 64x64pixels. That's what's called window size in the link you gave. One such window will have only one velocity vector assigned to it.

Each interrogation window must contain around 8 particles (cells in your case). Each of those particles must move a quarter of the interrogation window size during the time between the images. The entire movement must lie within the interrogation window.

1. Estimate velocity of your cells in mm/s from the knowledge of your setup

2. From the calibration of your camera, you must know pix/mm (scale factor)

3. Use the scale factor to get velocity in pix/s

4. Since you know the time between the images and velocity in pix/mm, you can find how many pixels the cell moves during that time

5. Multiply that displacement by 4 and you get the size of your interrogation window

Also, each cell should better occupy more than 1 pixel, ideally 2 pixels.

Search area size and overlap - I would suggest not to bother with it now. Set them both to 0. They are the tools of fine tuning (and can be adjusted absolutely empirically, i.e. by trial and error). Get the interrogation window size right first. That's the tool of coarse adjustment.

Ivan

[Leo Goldstien]

Much obliged for the tips. I'll try that out

[Ivan Nepomnyashchikh]

Also, if the images you provided are the full size images - not just the portions of your images - you might be better off with PTV, rather than with PIV.

PTV is particle tracking velocimetry. There is a separate OpenPTV package for it. And there is a separate Google group for it (see the link in the README on the OpenPTV GitHub page).

Ivan

[Brian Mapes]

Another option is “optical flow” methods, in opencv, easily searched. Someone asked me why I chose PIV, it was mainly historical accident. 

Various papers engage in comparisons of that vs PIV, like this recent one. 

https://link.springer.com/article/10.1007/s40095-022-00519-z

Machine learning approaches are popping up all over. 

But I (new user) have grown to like PIV for its straightforwardness. 

Brian Mapes

--
You received this message because you are subscribed to the Google Groups "openpiv-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiv-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiv-users/0c7842eb-f9b0-43c9-b3aa-e3263a739032n%40googlegroups.com.

[Alex Liberzon]

Hi,

The objects are rather large for the typical PIV analysis. So you need to increase the window size, but then you loose resolution - you cannot get a vector per object as the grid is fixed, so you get some mixtures of motion and this leads to spurious vectors.

i suggest to use window deformation that copes better with such cases. I pushed a pull request from my fork.

https://github.com/leogolds/MicroscopyPipeline/pull/4

--

You received this message because you are subscribed to the Google Groups "openpiv-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiv-user...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiv-users/cb871811-9f0f-43fa-8e92-24950b798065n%40googlegroups.com.

[Alex Liberzon]

https://github.com/alexlib/MicroscopyPipeline/blob/feature/openpiv/openpiv-example.ipynb

[Alex Liberzon]