Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Color per tracks. #254

Merged
merged 7 commits into from
Oct 23, 2023
Merged

Color per tracks. #254

merged 7 commits into from
Oct 23, 2023

Commits on Oct 23, 2023

  1. Rework the track ID feature. 

    Iterate over sorted roots, so that the track id has the
same order than in default TrackScheme. So the track with
track ID 0 is the leftmost in default TrackScheme, and it
increases from left to right.
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    0535046 View commit details
    Browse the repository at this point in the history

  2. Add a bimap between vertices of the branch graph and the core graph. 

    Also fix the javadoc of bimap for the branch edges.
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    9a001aa View commit details
    Browse the repository at this point in the history

  3. A Glasbey LUT. 

    Copied and adapted from TrackMate.
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    9ad8f24 View commit details
    Browse the repository at this point in the history

  4. A color generator that gives one color per track. 

    It works like this:
- First all the roots of a graph are collected.
- They are sorted alpha-numerically, so that they are iterated in
the same order than for default TrackScheme (with no fusion points).
- Each root is given a color from the Glasbey LUT, in order. This
ensures that all track color generators will give the same color
for one vertex.
- When the color for a vertex is quiered, we look in a cache. If the
color is not in the cache, then we iterate 'upward' in the graph
(reverse depth-first order) until we meet a spot that has a color
in the cache. All the spots we iterated until then receives this
color in the cache.
- For edges, we quiery the color of the source vertex.

The color generator listens to graph changes, so that new colors are
generated when the user adds a new track or split one in two.
Its de/registration as a listener must be handled outside.
Listening to graph changes can be paused.
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    7bec7a4 View commit details
    Browse the repository at this point in the history

  5. Use track coloring in all Mastodon views. 

    Also the corresponding GUI state is properly de/serialized.
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    2b84d3a View commit details
    Browse the repository at this point in the history

  6. A class that listens to a graph to provide the set if its roots. 

    Similar to RootFinder, except that it tries not to walk the full
graph everytime it is queried for the roots.

The root set is updated by listening to graph changes. So to work,
aninstance of this class must be first registered as a GraphListener
to the graph it will analyze, and then have its graphRebuilt() method
called once.

If this works well, this should be transferred to mastodon-graph,
in the package org.mastodon.graph.algorithm
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    8f9503a View commit details
    Browse the repository at this point in the history

  7. Rework the track color generator for better performance. 

    I foresee that it will not be good to generate the track colors,
by waling the full graph ONCE per opened view TIMES ONCE per
change in the graph.

So this version:

- Is based on the RootProvider, and listens to it to only regenerate
the cache when the set of roots changes.

- There is only one common instance of the track color generator,
use by all views, and it is registered as a manager in the window
manager. I took some care of what happens if several threads try to
query the track color concurrently, at least partially.

- The color cache is regenerated only if there is a change in the
root set AND if at least one view is using the 'Per track' coloring
mode.
    @tinevez
    tinevez committed Oct 23, 2023
    Configuration menu
    Copy the full SHA
    be01fb1 View commit details
    Browse the repository at this point in the history