Color by attribute

[TeunHuijben]

I closed #147, and started a new one on this topic:

This PR will implement the option to color the cells based on some attribute. The attribute could be any column added to the tracks.csv, or calculated features from the coordinates (think of velocity, direction, etc.)

Implemented:

• dropdown window with attribute options
• embed extra columns from tracks.csv into Zarr Store
• update dropdown window options based on fields in .zattrs
• load extra Zarr fields when attributes are chosen in the dropdown
• use a proper colormap
• use the CZI-SDS inputDropDown (not mui/material)
• add legend/colormap indicator
• add colormaps (categorical/continuous) and move them to a general location (together with trackMaterial colormaps)
• config option to choose colormaps (for categorical/continuous attributes)
• add toggle button to enable/disable coloring cell by attribute
• let the conversion script detect categorical/continuous features
• make test for conversion script with attributes
• give conversion script the option to add specific columns (instead of all columns)
• dropdown/toggle only visible when attributes are provided
• colorBy state saved in viewerState, to maintain when copying URL
• config option to deactivate default attributes (x-pos, y-pos, etc.)
• config option to deactivate this features all-together (even if attributes are provided)
• reset dropdown when new dataset loaded
• update readme on how to add attributes
• incorporate color-by-attribute in example notebook
• place datasets with features in proper locations

Bugs:

• inputText for dataURL no longer turns red when URL is false (the team behind SDS is working on this, see Red outline of InputText component for DataURL #158)

Example datasets:

• Drosophila: https://public.czbiohub.org/royerlab/zoo/misc/tracks_drosophila_attributes_norm_bundle.zarr/
• Ascidian: https://public.czbiohub.org/royerlab/zoo/misc/tracks_ascidian_withSize_withFeatures_bundle.zarr/
• Zebrafish: https://public.czbiohub.org/royerlab/zoo/misc/tracks_zebrafish_displ_norm_bundle.zarr/

Example of coloring based on z-coordinate:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
intracktive	✅ Ready (Inspect)	Visit Preview	Jan 23, 2025 8:57pm

[TeunHuijben]

Hi @andy-sweet and @aganders3,

This PR is a bit bigger and contains the feature to color cells based on provided attributes. In short, 1) extra columns in the tracks.csv file are saved in the Zarr Store, 2) the UI has a toggle and a dropdown menu where the user can select the feature used for coloring the cells. The Zarr Store encodes the names of the features and the type (categorical/continuous). The user can set the colormaps in the CONFIG, and there are separate colormaps for categorical/continuous features.

Considerations for review:

• is this the best way to save/chunk the attributes into the Zarr Store?
• for the larger datasets (zebrafish), I feel that coloring the cells according to a attribute that is loaded from the Zarr Store, make the viewer slower. Would you see any opportunity for speed-up? (the fastest way to would be to add the features to the points Zarr array ([x,y,z,attribute1,attribute2,...,x,y,z,attribute1,attribute2], but this would create a very large points array in the case of many attributes, especially since most of them are usually not used)
• the "quadrants" coloring option is to show categorical features, not because it is useful

Thanks!

[aganders3]

It looks like you're creating another ragged array in the top-level of the Zarr bundle as attributes that is roughly the same shape as points (well, num_attributes * 1/3 the size). Is that right? With the same chunking as points this should only be one extra request when the timepoint changes - I don't think that should be a huge deal but it is some overhead.

I agree packing it all into points is probably not optimal if there will be a lot of unused attributes. You may have the same issue in attributes if you have a lot of attributes saved. What about making attributes another group, and inside you could have separate arrays for each attribute?

[TeunHuijben]

Hi @aganders3, thanks for having a look! Yes, that is correct, attributes is a dense ragged array. The chunking is different from points though, where points is chunked per time, attributes is also chunked per attribute. In this way, only the requested attribute at the current timepoint is fetched (I hope I implemented this correctly).

What do you mean with "making attributes another group"? Do you mean to make a second zarr store with only the attributes? Or can we make a second group within the tracks_bundle.zarr store? I might be unfamiliar with the definitions or store/group/array. Because right now, attributes is an extra (the fifth) array within the same store.

[aganders3]

The chunking is different from points though, where points is chunked per time, attributes is also chunked per attribute.

Ahh, I see. I missed this distinction and thought the attributes were still interleaved. Never mind my suggestion then, I think this achieves the same thing!

[andy-sweet]

I'm still making my way through this, but left lots of minor comments and one or two more important ones. Will try to take another look tomorrow.

Qualitatively, I noticed a minor performance hit, but not enough of one to block this feature which seems really useful!

[andy-sweet]

I think the zarr storage format and fetching (when needed) is as reasonable as prior choices we've made, so I don't have any feedback related to that or the Python conversion code/tools.

My main comment is about the how you handle the state related to the attribute drop-down box value changing. I previously left some related comments, but I made those a bit more tangible by trying some changes that I think simplify things and also fix some bugs: https://github.com/royerlab/inTRACKtive/compare/color-by-attribute...andy-sweet/refactor-attr-options?expand=1#diff-8e6c274c4241821e809d16fcd06bc109ba41bb7a0583f9ad766ed92bb8230671R8

I don't think you should blindly merge those changes, but I think the approach there is easier to follow and importantly does not make the library code depend on definitions from React components.

[TeunHuijben]

Thanks a lot for the reviews @andy-sweet and @aganders3 🙌
I am working on the final minor issues, and then it's ready to merge