-
Notifications
You must be signed in to change notification settings - Fork 2
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.
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
color legend #31
Comments
The colors seem to come from here:
|
Yes, I confirmed that the color come from there! |
@megbalk My suggestion was related to the input CSV file columns: hdr-bgnn/BGNN_Core_Workflow#24 (comment) |
yes sorry, I created some confusion with my comment (I mixed up conversation), but in the same way the lookup table trait/color could be stored in a config file. |
So the idea is we would let users customize the colors for the various segments? "I want a blue dorsal fin." |
this is where is hard coded in the class used in the trait. Morphology-analysis/Scripts/Traits_class.py Lines 24 to 28 in e1f5cb6
|
Ok I see but I feel that is to much front end, make things look good or customize for user? |
@muratmaga could you elaborate on the use case for this change? Thanks. |
That is the link Murat post during the meeting |
@thibaulttabarin Meghan included this already in her OG post above. |
I think the point here is to have these kinds of static (two or multi-dimensional) tables be in a place where they aren't buried deep in the code (such as being hard-coded in some object's constructor method as is the case here), and where if desired (for optics or other reasons) or necessary (segmenting more or differently named traits, for example) they can be modified by a project or user without fundamentally altering the codebase. Whether that's a file in non-Python syntax, or a Python data structure defined in its own file or as part of a file that defined multiple such static data structures, doesn't matter, it's either way conceptually a configuration file. |
So there are multiple levels of things going in here. First, and foremost I would like to avoid this mistake done by Nvidia developers, which was hard coding labels in a ML Segmentation framework: https://github.com/Project-MONAI/MONAILabel/blob/52b8758ce70fbcee9fc1735e18ac8f784f0ba200/sample-apps/radiology/lib/configs/deepedit.py#L36-L55 At the minimum, this should be a user configurable setting, so that people can use whatever label they need to use. Secondly, the selection of labels and indices is completely free when you are working with a single dataset. But still, it is better to pull terms from an ontology, which probably also a has a unique identified attached to it. That way, you can start making your own lookup tables with indices, and colors. I provided the Terminology module of Slicer as a related concept. They use a complex JSON schema, e.g., this uses the terms used in DICOM standard , but it can be simplified to match your needs. My point is that this is not an easy thing to do, and there can be multiple solutions with different complexities. I just wanted to make you aware of it early on. |
Moved this from BGNN_Snakemake to Morphology_Analysis. I also added the label "enhancement" as this will be a great feature for version 2.0.0, after we have a working version for the minnowTraits project (version 1.0.0). |
Create a look up (number) for each segmentation so that it is scalable, as suggested by @muratmaga.
See example for Slicer.
Or @johnbradley suggested making a configuration file.
The text was updated successfully, but these errors were encountered: