-
Notifications
You must be signed in to change notification settings - Fork 24
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
Fix rendering missing data black and wrong segment id being displayed #5674
Conversation
onChangeRenderMissingDataBlack = async (value: boolean): Promise<void> => { | ||
Toast.info( | ||
value | ||
? messages["data.enabled_render_missing_data_black"] | ||
: messages["data.disabled_render_missing_data_black"], | ||
{ timeout: 8000 }, | ||
); | ||
this.props.onChange("renderMissingDataBlack", value); | ||
const { layers } = this.props.datasetConfiguration; | ||
const reloadAllLayersPromises = Object.keys(layers).map(async layerName => { | ||
await clearCache(this.props.dataset, layerName); | ||
await api.data.reloadBuckets(layerName); | ||
}); | ||
await Promise.all(reloadAllLayersPromises); | ||
window.needsRerender = true; | ||
Toast.success("Successfully reloaded data of all layers."); | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method was used nowhere. It was forgotten to be removed while reorganizing code in the #5384 pr
The performance test: How I did it: This is the result of the performance test on this branch with only the segmentation layer enabled in mag2 using the mag 16 as a fallback: This is the result of the performance test on Tool used for these calculations: https://www.calculatorsoup.com/calculators/statistics/statistics.php Thus rendering the filling the lookup buffer with fallback bucket addresses should be even faster than filling it with data from the current mag and should not make any performance difficulties. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really great PR 👍 I especially like your detailed description of status quo, old reasonings and the solution.
Regarding your performance measurements: Am I getting this right, that the look up buffer is quicker to update when it's only filled with fallback data? If so: perfect 😄
frontend/javascripts/oxalis/model/bucket_data_handling/data_cube.js
Outdated
Show resolved
Hide resolved
Yeah, I came to the same conclusion 🤷♂️ 🎉. Maybe it is faster because fewer buckets need to be looked up 🤷♂️ |
…-rendering-missing-data-black
…eminds/webknossos into fix-rendering-missing-data-black
This PR tackles two issues:
In the first case, there are simply much fewer buckets of the fallback mag (exponentially decreasing with the mag difference) that are added for many buckets in the rendered mag (exponentially increasing with the mag difference) to the lookup table. Thus the exponential increase and decrease should cancel out each other.
URL of deployed dev instance (used for testing):
Steps to test:
Better test locally. First, read the whole steps. It would be good if you have another dataset that has a segmentation for all 16 mags and a color layer with all 16 mags. This might show some edge cases that did not appear with the ROI dataset.
Issues:
[x] Updated (unreleased) migration guide if applicable[ ] Updated documentation if applicable[ ] Adapted wk-connect if datastore API changes[ ] Needs datastore update after deployment