Color per tracks. #254
Merged
Color per tracks. #254
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Also fix the javadoc of bimap for the branch edges.
Copied and adapted from TrackMate.
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.
Also the corresponding GUI state is properly de/serialized.
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
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
force-pushed
the
track-color-generator
branch
from
9b02d0c
to
be01fb1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new coloring feature: the spots and links are colored by the track they belong to, picking a color in a Glasbey-like LUT:
The colors are generated on the fly and are not stored in the project.