Linking ignores empty frames

[caspervdw]

I just came across a peculiar issue: if I have a single blinking particle and link this with memory=0, this still results in a complete track. I would expect the tracks to be separated at frames where the particle is not found.

Because link_df iterates over all unique framenumbers, it ignores empty frames. I think this is not the desired behaviour, but correct me if I'm wrong.

[danielballan]

Agreed. That is not the correct behavior.

On Fri, Oct 9, 2015 at 11:27 AM Casper van der Wel notifications@github.com
wrote:

I just came across a peculiar issue: if I have a single blinking particle
and link this with memory=0, this still results in a complete track. I
would expect the tracks to be separated at frames where the particle is not
found.

Because link_df iterates over all unique framenumbers, it ignores empty
frames. I think this is not the desired behaviour, but correct me if I'm
wrong.

—
Reply to this email directly or view it on GitHub
#292.

[tacaswell]

That does not sound like the desired behavior at all.

[nkeim]

trackpy has always been fairly agnostic about frame numbering. I'm pretty sure that except for the storage classes, frame numbers are never required to be integers, or evenly spaced. I know specifically that the prediction framework is written to accommodate arbitrary sequential real numbers, and that these are used in the unit tests. This is because prediction requires not just the order of frames, but their times as well.

Secondly, skipping frames is sometimes desirable. Momentary vibrations or camera glitches can make certain frames unusable. So sometimes the behavior Casper describes is desired, and the "correct" behavior may be a surprise to the user.

So we should tread carefully here. Whatever we do to link_df(), I think that link_df_iter() should not assume successive integers.

[tacaswell]

Maybe we should crib the ndimage labeled image api and add an optional expected_frames kwarg to link_df_iter which lists the expected frame numbering. If it is None, it just runs through them as-is, and if it is given will only link on those frames, both inserting missing frames and skip existing frames as needed.

[caspervdw]

We should require memory to have the same units as the frame column, which narrows down its dtypes to integer and floats. Also most of the functions in tp.motion expect numbers (integers). For a momentary vibration or camera glitch, time does go on and linking trajectories through such a glitch (with memory=0) should still result in broken tracks, in my opinion. That's what the memory function is for right?

Consider one blinking particle and one stable particle, both isolated. If you track this (no memory), you will have broken tracks for the blinking particle. If you now remove the stable particle, you will suddenly have a single track for your blinking particle. This makes linking (in some cases) dependent on other particles that are arbitarily far away. Which is not good, it should be an intrinsic property of the isolated particle.

So I would argue for a default behaviour of expected_frames that checks for the minimum difference between frame values and inserts empty frames if one frame is missing.

[nkeim]

@caspervdw, that's a very good point about memory. That might be a simple way to address the "glitch" scenario that will work for most users of link_df(). I'm starting to see that it makes sense for link_df() to be strict about successive integer (or rounded float) frame numbers. Maybe it could issue a warning the first time it encounters an empty frame?

(The reason I say "rounded float" is that there are plenty of ways to represent/store tracks data that prohibit mixing types. So I don't think trackpy should ever be strict about the dtype of frame unless absolutely necessary.)

To me, the underlying problem is that when features data are passed as a single DataFrame, there is no way to denote an empty frame. link_df_iter() does not have this problem. If you want the empty frame to be considered, include it in the sequence; if you want it to be skipped over, don't (and leave a 2_t_ gap in the frame numbers). So I don't see how expected_frames does anything but add complication. If we still think it's a good functionality to have in trackpy, maybe we could add a separate function that pre-processes input to link_df_iter().

[danielballan]

I agree with @nkeim on this -- I'm against expected_frames and for strict interpretation of frame as a successive integer.

[caspervdw]

So what should the default behaviour of link_df be? I would say, interpret 2t gaps as 2t gaps, so insert empty frames in the levels generator. If the user wants to intepret 2t gaps as t gaps, then he should renumber the frames or use memory.

The expected_frames could also be replaced by ignore_gaps.

link_iter doesnt support empty frames so there is some work there too.

[danielballan]

Yes, I would call that the "correct" behavior.

Users can ignore gaps by renumbering their frames column. I think adding a kwarg here is doing too much in one step -- the same kind of thing that I did with the overloaded locate API that I now regret.

[tacaswell]

Agree that all of these are better suggestions than expected_frames.

The frame numbers should be integers as they are indexes into a sequence of
discrete ordered measurements. I think folding the time delta information
into the frame index is trying to do too many things at once.

On Sat, Oct 10, 2015, 11:47 Dan Allan notifications@github.com wrote:

Yes, I would call that the "correct" behavior.

Users can ignore gaps by renumbering their frames column. I think adding
a kwarg here is doing too much in one step -- the same kind of thing that I
did with the overloaded locate API that I now regret.

—
Reply to this email directly or view it on GitHub
#292 (comment)
.

[caspervdw]

PR #293 replaces this. Closing.