[WIP] Different radius per point#103
Conversation
…erent size per point'
|
@TeunHuijben is attempting to deploy a commit to the Chan Zuckerberg Biohub SF Team on Vercel. To accomplish this, @TeunHuijben needs to request access to the Team. Afterwards, an owner of the Team is required to accept their membership request. If you're already a member of the respective Vercel Team, make sure that your Personal Vercel Account is connected to your GitHub account. |
|
An owner of the Chan Zuckerberg Biohub SF Team on Vercel accepted @TeunHuijben's request to join. @TeunHuijben's commit is now being deployed. |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This looks neat! I requested access to the preview on Vercel. 🚀 |
…endent on whether size is included" ;
…anged via slider"
| updateSelectedPointIndices() { | ||
| const idOffset = this.curTime * this.maxPointsPerTimepoint; | ||
| this.selectedPointIndices = []; | ||
| for (const track of this.tracks.values()) { | ||
| if (this.curTime < track.threeTrack.startTime || this.curTime > track.threeTrack.endTime) continue; | ||
| const timeIndex = this.curTime - track.threeTrack.startTime; | ||
| const pointId = track.threeTrack.pointIds[timeIndex]; | ||
| this.selectedPointIndices.push(pointId - idOffset); | ||
| } | ||
| this.highlightPoints(this.selectedPointIndices); | ||
| } |
There was a problem hiding this comment.
I think this could get pretty slow with a lot tracks selected. My idea in #96 (comment) was to basically memoize this function. I think the cache can also be computed/updated when adding tracks instead of when the timepoint changes.
The tradeoff is more memory, of course. I guess it should be tested but I don't think it's that much.
There was a problem hiding this comment.
Thanks Ahsley, that is good point. I made a bit of a mess by including elements from #96 (@andy-sweet) in this branch without fully merging with that PR. The reason was that #96 diverged from main a lot earlier than this branch, which made merging difficult.
I have now updated updateSelectedPointIndices in the next commit by using memoization. I create a map that relates a CacheKeys to the selectedPointIndices vector. The body of this function is only evaluated the first time this combination of curTime and tracks is requested. Any future request, the vector is taken from the cache. The full cache is removed as soon as the user selects more/other cells, to prevent the cache from becoming too big.
Your suggestion of precomputing the cache every time tracks are added might be cumbersome in the case of many timepoints, but we could consider this.
The dataset here is too small to experience a speed-up, but if should be faster. Was this the idea you had in mind? Let me know if anything can be improved.
…ectedPointIndices is only updated if it hasnt been computed before for this combination of curTime and selected tracks
…the last selection of this frame
… radius) are used, and now we only need 1 conversion script that can handle both"
|
This big PR contains many features, amongst others:
|
2 participants
For embryos with only a few cells (10-100), showing only a scatter plot of points is too sparse to visually represent the embryo. One idea would be the give each point the "size" of the actual cell that it represents (could be all the cells the same size, or each cell a different size, dependent on the local density of cells).
In this PR, I changed
TrackManagerandPointCanvasto accommodate for each point having a different size. The size (radius) of each point is saved in thepoints_arrayzarr as fourth column (previously it had only 3 columns: x,y,z).Additionally, I have created a new conversion script
convert_tracks_csv_to_sparse_zarr_with_radiusthat works csv files that contain the 'radius' column, and incorporates this information in the zarr structure.This PR is represents more a 'continuous' track record of my changes. It is not a final PR that should be merged with main, at this stage. Any feedback is welcome.