Links vs Tracks and Linearity

[simleo]

In our spec we should better clarify what we mean by "linear" and, consequently, what exactly differs between a link and a track, since according to the current version the only difference is that the former is linear while the latter isn't.

Object identity is also tightly related to the above, since defining links and tracks essentially amounts to stating which frame regions are actually instances of the same object across different time points.

The current gap closing example is the one that best exposes this ambiguity.

Does "linear collection" mean "a collection of object instances that represent the same object across contiguous frames"? If so, a gap event cannot even be represented by a link. Does it mean "a collection of object instances that represent the same object across different (not necessarily contiguous) frames"? If so, since we allow a link to encompass more than two frames, the links table in our gap closing example should contain only one link with all the objects in it (and there should be only one track consisting of that single link):

Link_ID	Object_ID
1	1
1	2
1	3
1	4

Another way to put it is this: since we have defined a track as "a collection of links", but we allow links to span more than two frames, when is a collection of links a link itself, and when is it another entity (track) instead? Following the above, we only have a "real" track in cases containing split and merge events, where different object histories become related.

Another potential problem is that in our split example we are arbitrarily assigning the connection between object instances in frames 1 and 2 to the first link.

This basically amounts to saying that the object described by the second link has been "generated" by the one described by the first link, which maintains its identity throughout the whole frame sequence. If we want the two objects starting from frame 3 to have an equal status, we should use three different links:

Link_ID	Object_ID
1	1
1	2
2	2
2	3
2	5
2	7
3	2
3	4
3	6
3	8

The same goes for the merge example, with directions reversed.

[gsergeant]

The difference between tracks and links are events (gap, split, merge). Links are essentially connected by these events. Indeed, if there are no events, a track will be the exact same as a link.

For me, links represent an object across contiguous frames. However, since we needed to encode a gap event somehow, we cannot strictly follow this definition. If we agree to however, we could follow your reasoning @simleo and have it represented by one link. But then, in order for a user to find a gap event, they would constantly have to refer back to the objects_table for the frame information.

I like your second proposition, the question of "maintained identity" is a valid one.

[pcmasuzzo]

OK, good call. Here my two cents.

1. A linkis a linearcollection of objects across time frames (not necessarily contiguous). As such (i.e. linear), a link brings together 1 parent object to 1 child object (1:1 relationship).

2. A trackis a collection of links (1 track has 1 or more links, 1:n relationship), and therefore a (non-linear) collection of objects. As such (i.e. non-linear), a track brings together 1 parent object to 1 or more children objects (1:n relationship, splitevent), or 1 or more parent objects to 1 child object (n:1 relationship, mergeevent). If there are no events, a track has1 link in its collection (NB a track is not a link, has 1 link), i.e. 1:1 relationship between tracks and links.

Now, if we agree on definition at point 1, @simleo table above for the gap-closing event certainly makes sense:

Link_ID	Object_ID
1	1
1	2
1	3
1	4

However, in this representation we would miss the repetition of the Object_IDreference across links, and therefore the encoding of the gap-closing event.

Thoughts on how we could fix this? And are points 1 and 2 clear?

[simleo]

One way to bring both @pcmasuzzo's and @gsergeant's remarks together and resolve the missing event problem would be to state something like the following:

• A link is a collection of objects that represent the same entity (e.g., cell) across time frames, where each object is related to exactly one other object in the sequence. This can be either:

  • A sequence of related objects in consecutive frames
  • A gap closing, i.e., a collection of two objects that appear in two non-consecutive frames but still represent the same entity

• A track is a collection of links related by split and merge events.

This would mean that the only valid option for representing the gap closing example is the one we have labeled with "C":

I think having only one valid way of representing a link is a good thing, since it simplifies the spec and helps with the creation, validation etc. of data packages. This was also my intent when proposing the new track table for the split event.

One point where we have to be careful with the terminology is when we want to distinguish between the "real" object (I have used "entity" for this above, but there may be a better word) and its representation in a single frame (this is what we are currently calling "object").

[gsergeant]

Coming back to this issue, keeping in mind the discussions of the Essen workshop.

1) Our idea of links may not be set in stone. Thinking of graph-theory edges here, but that should be kept out of this issue here IMO.

2) Regarding maintained identity of objects and having an unambiguous representation of links: Having one link continue after a merge/split event may not be ideal for various reasons. What about using the examples below? They are already present in this repository at the moment. @simleo already proposed it above for a gap-closing event and I agree with this representation. We can do something similar for splits and merges:

• Split + gap closing example C:

• For a normal split event, since I can't seem to link to my Onedrive image file here, just imagine the previous example, adding an object in frame 3, and replacing the blue link with a green one.

3) Though I like the above definition of links and tracks by @simleo a lot, can we here still refer to gap-closing as an event? No right? Strictly, it would be a type of link. I could be imagining a problem where there is none though... It does not mean our tabular representation of gaps would be different.

Am I missing anything else that was discussed?