Merge Criteria
When a merger is detected for a cluster \(\tilde C_k^{t_i}\), a set of steps is followed to protect the classes against sorting errors in particular blocks. First, if more than one of the classes with \(Ov_{j,k}^{t_i}>0.5\) were "new classes" in block \(t_{i-1}\), they are merged into a single "new class" in block \(t_{i-1}\); if this results in just a single class associated to the merger, that class is labeled as a "new class" and matched with \(\tilde C_k^{t_i}\). Next, if there is only one "new class" and only one "old class" associated to the merger, these classes are merged as a single "old class" in block \(t_{i-1}\) and matched with \(\tilde C_k^{t_i}\) .
In general, the cluster labeled as a merger will have a set of classes from the previous block associated to it, which we call the "merge list" ML. The first time the merger cluster is detected, it is actually considered as a temporary merger (see Fig. \ref{595195}D left). In this scenario, the overlapping sets associated to the classes from the list ML will be included in the next block, to give the algorithm a chance to find them separately and continue the individual track of the putative neurons (see Fig. \ref{595195}D middle). This procedure is repeated for \(MS=3\) consecutive blocks as long as the detected merger is associated to the same ML list (see Fig. \ref{595195}D right). If the situation persisted for all \(MS\) blocks, the merger is then confirmed, a new class is associated to the merger cluster in all \(MS\) blocks, and the individual classes from the ML list "disappear", i.e. they are no longer used to create overlapping sets in the following blocks and will therefore be no longer tracked individually.