By using a continuous transformation, we can identify structural changes of the augmented merge tree and we know the exact time and the correct order of all events. This allows us to compile tracking information event-by-event and to understand feature tracking as an independent extension of the transformation process. Although it is necessary to transform the fully augmented merge tree to notice all topological events, for feature tracking, it suffices to track only the unaugmented merge tree, i.e. the superarcs. This is because once we keep track of all regions accurately, the regular nodes neither affect the number of features, nor their hierarchy or properties. Because regular nodes are stored implicitly together with the superarcs, quality measures can still be determined for each feature.
As already mentioned in the algorithm overview in Chapter 6.2, the time-varying merge tree supports feature tracking in terms of the superarcs for the complete function, or in terms of the components of specific superlevel sets. For both cases, we present operators to extend the merge tree transformation.
6.4.1
Tracking the Complete Function
Between two time steps, superarcs may be born, die, or match with a superarc of the following merge tree. For birth- and death-events we keep track on which parent superarcs they take place because the tree may undergo many changes. For example, a newborn superarc may move within the tree, or it may give birth to other superarcs. Similarly, a superarc on which another superarc died may move or die. In rare circumstances, an arc can also give birth to the arc it dies on afterwards. Therefore, we have to store tracking information recursively. To display superarc relations later on in the visualization, each superarc needs a representative. We use its upper supernode for this purpose. Leaf superarcs are thus represented by their maxima, and inner ones by their upper saddle node. For each transposition, we verify if the superarcs of the tree are affected. If necessary, we create or destroy tracked superarcs accordingly, and we record on which superarcs these changes take place. If superarcs do not change, we still record when regular nodes change their association to a superarc, and we update a superarc’s representative if required. Updating the representative is important because a moving feature can be represented by a completely different set of grid vertices in the next time step.
Implementation
For every superarc we maintain a tracking record that stores the following information: the initial representative, the current representative, the superarc born from, and the superarc died on. Initially we determine all superarcs of the merge tree, set their representative, but leave the entries for superarc “born from” and “died on” empty. We also store for each node to which superarc it belongs. Regarding the nomenclature, being born on another superarc means that the lower node which becomes a new critical node after the transposition changes its superarc affiliation to the newly created superarc. That is, the new superarc gets born on the superarc the lower node belonged to before the transposition. The opposite defines the meaning of a superarc dying on another one.
Tracking features of the complete function happens event-by-event and is thus an independent part of the transformation process (Algorithm 3, step 34). One possibility to track superarcs, including their precise place of birth/death and correct times, is to consider the node types before and after an arc collapse and to handle this event according to the case table shown in Figure 6.3. The table summarizes all possible configurations of an arc collapse. They result from taking all combinations, but neglecting symmetrical events (e.g. “a saddle node rises above a maximum” versus “a maximum falls below a saddle”) and impossible events (e.g. “two maxima
A
0 1
A
A
0
0 only twochildren
0 A regular passes maximum saddle passes regular regular passes regular saddle passes saddle regular passes saddle
this node is the new representative of its superarc
B new superarc that is born on superarc / node's superarc @superarc / node
this node changes superarc affiliation
this and all nodes until the next saddle change superarc affiliation
@s
Dm @node2
D node1's superarc dies on node2's superarcnode1
@b Ds @s B only two children 0a 0 0a only two children 0 none 1 one 1
more than one, not all
A
all
number of upper node's children that become lower node's children after collapse
@B' B @r B'=B1 @s B @s B @s D2s1 saddle passes maximum + 1 0 1+ 1+ 0a B @s2
Figure 6.3: Case table to track features of the complete function: The case table summarizes how tracking records are updated according to the node types of the swapping nodes before and after a single transposition. For every possible configu- ration (dotted boxes), the bold arc is about to collapse and all possible results are shown to the right. In principle, superarcs die when supernodes pass each other, and a new superarc is born when the passing node becomes a supernode.
swap”). Possible results of a configuration reflect possible changes of l’s upper link. Furthermore, the table indicates in which configurations superarcs are born or die and in which cases a node’s superarc affiliation changes.
The tracking consists of creating, destroying, or updating affected tracking records after every arc collapse. For example, if before a transposition the lower node is a saddle s and the upper node is a regular node r (cf. Figure 6.3, right column, second
row) and both nodes are saddles after the transposition (case 0), a new superarc is created with s as its current representative and s’s previous superarc as the “born from” entry. Then we set r to be s’s previous superarc’s new representative and update the superarc connecting both nodes. For simplicity, events relating to the minimum of the tree are considered to be either regular or saddle events.
Post-Processing
Once the transformation, and thus feature tracking, finishes, we know for each original superarc whether it matches a superarc in the final merge tree or whether it dies. For dying and newborn superarcs, we also know where exactly the death and the birth happen; this information is recorded in the “born from” and “died on” entries of the tracking records.
Because a function’s main features naturally appear as maximum-saddle pairs of significant persistence, size, or stability, we restrict further processing only to leaf superarcs. To create pairwise relations between original and final superarcs, we post-process the tracking records (Algorithm 3, step 37) as follows: If the “died on” entry for an original leaf record is empty, we associate that record’s initial representative with its current representative, and store this as a match record. If the “died on” entry of an original leaf record is not empty, we recursively follow it until we reach the record where “died on” is empty. We associate the original record’s initial representative with the found record’s current representative and store this as a death record. Finally, for each new leaf record, we recursively follow the “born from” entry, associate the found record’s initial representative and the new record’s current representative, and store this as a birth record. This produces a set of records, classified into either match, birth, or death events, that describe how features of the complete function, as described by leaf superarcs, relate to each other between the original and the final tree.
6.4.2
Tracking Superlevel Sets of the Function
In addition to the analysis of the complete function, analysts also study the evolution of threshold-based features. In this case, one is interested at which times superlevel set components appear, join, split, or vanish; or if components belong together in both time steps. Note that these events do not relate to the homonymous events of the complete function: while a birth/death event in the complete function means the appearance/extinction of a new/existent superarc in the tree, a superlevel set component gets born/dies if an existent superarc just starts/finishes containing a
particular value . That is, even if the structure of the merge tree does not change at all, a superlevel set can exhibit manifold changes just because nodes of the dynamic tree change in their values. To notice all topological changes of the superlevel set, we need to find out at which times superarcs of the time-varying merge tree start or finish containing . This requires awareness of structural changes of the complete function because newborn superarcs could affected the superlevel set.
When a superarc starts or stops containing the threshold , we store the event’s type, its time, and the participating superarcs as a superlevel tracking event. Suc- cessive events of each component are then linked together to obtain a complete description of the changing superlevel set. Source of these linked events is either a new component that gets born during the transformation, or a component that already existed in the first time step. If a superarc contains throughout the whole transformation, the superlevel set component directly matches in both time steps.
Implementation
Tracking a superlevel set also happens simultaneously to the merge tree transfor- mation. However, the transformation is only based on arc collapse events, i.e. on those events that potentially change the tree’s structure. Because this implies that we could miss that one or more tree nodes pass value between two consecutive transpositions, we have to extend the transformation’s granularity to cope with tracking events of superlevel set components.
Before the transformation starts, we determine for all critical tree nodes the time when they pass according to linear interpolation. Pass-times are then added to a priority queue that is used during the transformation at two places: Before performing an arc collapse, we handle “outstanding” tracking events in the queue, i.e. those with a pass-time smaller than the current arc collapse time. After the arc collapse, we update the priority queue based on the node type of both involved arc nodes. If a regular node becomes a critical node we determine the time when it passes and potentially add it to the priority queue. Likewise, if a critical node becomes regular after the arc collapse, we remove it from the priority queue. Note that once the transformation has finished, the queue could still contain pass events that occur subsequent to the last arc collapse.
To handle a critical node n when it passes value , we identify the superlevel tracking event based on n’s node type, e.g. whether it is a saddle or a maximum, and whether n passes from below or above. Figure 6.4 summaries all possible configurations and their corresponding superlevel tracking event types. Newly generated superlevel tracking events are stored together with n’s adjacent superarcs
from above
maximum - birth event
minimum - death event
saddle - merge event
maximum - death event
saddle - split split
minimum - birth event
from below
ε
Figure 6.4: Event types for tracking superlevel set components: Superlevel set components appear, join, split, and vanish when superarcs of the varying merge start/stop containing threshold . The type of the superlevel set component’s topological change depends on the type of the critical node passing value (red line) and whether it passes the threshold from below or from above.
to connect them with their future events. The transformation’s pseudo-code shown in Algorithm 3 also indicates at which places the transformation needs to be extended in order to track superlevel sets (Steps 6, 35, and 36).