-
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
Allow to restrict floodfill to a bounding box #8267
base: master
Are you sure you want to change the base?
Conversation
…en; also disable animations for the context menu
📝 WalkthroughWalkthroughThis pull request introduces a new feature allowing the flood fill tool to be restricted to a specified bounding box. The changes span multiple files in the frontend, adding a toggle in the toolbar to enable bounding box restriction for flood fill operations. A new constant and configuration option have been added to manage this functionality, with modifications to the flood fill saga and data cube handling to support the restricted fill mode. The implementation ensures that flood fill operations can be constrained within user-defined or automatically generated bounding boxes. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
…triction is user imposed; also fix close link in toast
…ox is not too large
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.
Actionable comments posted: 2
🧹 Nitpick comments (9)
frontend/javascripts/oxalis/model/sagas/volume/floodfill_saga.tsx (1)
35-102
: Ensure proper handling of failure reasons ingetBoundingBoxForFloodFill
In the
getBoundingBoxForFloodFill
function, when returning failure reasons, ensure that the failure messages are user-friendly and informative. This will enhance the user's understanding when the flood fill operation cannot proceed.frontend/javascripts/test/sagas/volumetracing/volumetracing_saga_integration.spec.ts (1)
Line range hint
330-347
: Improve test reliability with explicit undo actionsWhen performing undo and redo operations in the test, ensure that each action is awaited properly to prevent race conditions and enhance test stability.
Apply this diff to await undo and redo actions explicitly:
- await dispatchUndoAsync(Store.dispatch); + await dispatchUndoAsync(Store.dispatch); + await t.context.api.tracing.save(); - await dispatchRedoAsync(Store.dispatch); + await dispatchRedoAsync(Store.dispatch); + await t.context.api.tracing.save();frontend/stylesheets/trace_view/_action_bar.less (1)
71-74
: Consider using a more semantic class nameThe class name
.undo-redo-button
suggests specific usage, but the functionality (preventing width flickering) could be useful for other buttons. Consider a more generic name like.fixed-width-button
or.no-flicker-button
.CHANGELOG.unreleased.md (1)
16-16
: Enhance the changelog entry with more detailsConsider expanding the changelog entry to provide more comprehensive information about the feature:
-The fill tool can now be adapted so that it only acts within a specified bounding box. Use the new "Restrict Floodfill" mode for that in the toolbar. [#8267](https://github.com/scalableminds/webknossos/pull/8267) +The fill tool can now be restricted to operate within a specified bounding box. Enable the new "Restrict Floodfill" toggle in the toolbar when the fill tool is selected. If no bounding box exists when using this mode, a notification will be displayed. This feature helps prevent unintended fill operations outside the area of interest. [#8267](https://github.com/scalableminds/webknossos/pull/8267)frontend/javascripts/oxalis/default_state.ts (1)
87-87
: LGTM! Consider adding JSDocThe new configuration property is well-named and appropriately placed. Consider adding JSDoc documentation to describe its purpose and behavior:
+ /** When enabled, restricts flood fill operations to the current bounding box */ isFloodfillRestrictedToBoundingBox: false,
frontend/javascripts/oxalis/constants.ts (1)
336-338
: Consider adding more detailed documentation.While the comment explains the purpose, it would be helpful to document:
- Why the value of 10 was chosen
- What "more lax" means in terms of actual behavior
- The impact on performance and memory usage
frontend/javascripts/oxalis/model/bucket_data_handling/data_cube.ts (2)
501-509
: Consider adding more detailed documentation for the dynamic bounding box expansionWhile the implementation is solid, the comment could be more explicit about:
- The purpose of allowing multiple additions of the same bucket
- The implications of the "neighbour volume shape" concept
- How this relates to the new bounding box restriction feature
695-724
: Consider enhancing the progress loggingThe progress logging implementation could be improved:
- Consider using a constant for the progress update interval (1000000)
- Consider adding an estimate of total progress (e.g., percentage complete)
- Consider adding more context about the operation in the progress message
- if (labeledVoxelCount % 1000000 === 0) { - console.log(`Labeled ${labeledVoxelCount} Vx. Continuing...`); - - await progressCallback( - false, - `Labeled ${labeledVoxelCount / 1000000} MVx. Continuing...`, - ); + const PROGRESS_UPDATE_INTERVAL = 1000000; + if (labeledVoxelCount % PROGRESS_UPDATE_INTERVAL === 0) { + const message = `Flood fill: Labeled ${(labeledVoxelCount / 1000000).toFixed(1)} MVx`; + console.log(message); + await progressCallback(false, message);frontend/javascripts/oxalis/view/action-bar/toolbar_view.tsx (1)
1372-1405
: Consider enhancing the FloodFillSettings componentWhile the implementation is solid, consider these improvements:
- Extract the tooltip text to a constant for reusability
- Add a data-testid attribute for easier testing
- Consider using a memo hook for the toggle callback to prevent unnecessary re-renders
+const FLOOD_FILL_BBOX_TOOLTIP = + "When enabled, the floodfill will be restricted to the bounding box enclosed by the clicked position. If multiple bounding boxes enclose that position, the smallest is used."; function FloodFillSettings() { const dispatch = useDispatch(); const isRestrictedToBoundingBox = useSelector( (state: OxalisState) => state.userConfiguration.isFloodfillRestrictedToBoundingBox, ); - const toggleRestrictFloodfillToBoundingBox = () => { + const toggleRestrictFloodfillToBoundingBox = useCallback(() => { dispatch( updateUserSettingAction("isFloodfillRestrictedToBoundingBox", !isRestrictedToBoundingBox), ); - }; + }, [dispatch, isRestrictedToBoundingBox]); return ( - <div> + <div data-testid="flood-fill-settings"> <FillModeSwitch /> <ButtonComponent style={{ opacity: isRestrictedToBoundingBox ? 1 : 0.5, marginLeft: 12, }} type={isRestrictedToBoundingBox ? "primary" : "default"} onClick={toggleRestrictFloodfillToBoundingBox} - title={ - "When enabled, the floodfill will be restricted to the bounding box enclosed by the clicked position. If multiple bounding boxes enclose that position, the smallest is used." - } + title={FLOOD_FILL_BBOX_TOOLTIP} >
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
public/images/icon-restrict-floodfill-to-bbox.svg
is excluded by!**/*.svg
📒 Files selected for processing (18)
CHANGELOG.unreleased.md
(1 hunks)frontend/javascripts/components/async_clickables.tsx
(2 hunks)frontend/javascripts/libs/mjs.ts
(1 hunks)frontend/javascripts/oxalis/constants.ts
(1 hunks)frontend/javascripts/oxalis/controller/combinations/bounding_box_handlers.ts
(1 hunks)frontend/javascripts/oxalis/default_state.ts
(1 hunks)frontend/javascripts/oxalis/model/accessors/tracing_accessor.ts
(2 hunks)frontend/javascripts/oxalis/model/bucket_data_handling/bucket.ts
(2 hunks)frontend/javascripts/oxalis/model/bucket_data_handling/data_cube.ts
(4 hunks)frontend/javascripts/oxalis/model/sagas/volume/floodfill_saga.tsx
(1 hunks)frontend/javascripts/oxalis/model/sagas/volumetracing_saga.tsx
(3 hunks)frontend/javascripts/oxalis/store.ts
(1 hunks)frontend/javascripts/oxalis/view/action-bar/toolbar_view.tsx
(2 hunks)frontend/javascripts/oxalis/view/action-bar/tracing_actions_view.tsx
(2 hunks)frontend/javascripts/oxalis/view/context_menu.tsx
(3 hunks)frontend/javascripts/test/sagas/volumetracing/volumetracing_saga_integration.spec.ts
(4 hunks)frontend/stylesheets/trace_view/_action_bar.less
(1 hunks)tools/test.sh
(1 hunks)
🧰 Additional context used
📓 Learnings (1)
frontend/javascripts/oxalis/model/sagas/volumetracing_saga.tsx (1)
Learnt from: dieknolle3333
PR: scalableminds/webknossos#8168
File: frontend/javascripts/oxalis/model/sagas/volumetracing_saga.tsx:433-434
Timestamp: 2024-11-22T17:19:07.947Z
Learning: In the codebase, certain usages of `segmentationLayer.resolutions` are intentionally retained and should not be changed to `segmentationLayer.mags` during refactoring.
🔇 Additional comments (13)
frontend/javascripts/oxalis/model/sagas/volumetracing_saga.tsx (1)
13-13
:
Retain usage of segmentationLayer.resolutions
where necessary
According to previous learnings, certain usages of segmentationLayer.resolutions
should not be replaced with segmentationLayer.mags
. Please verify that all such intentional usages remain unchanged.
Run the following script to identify unintended replacements:
frontend/javascripts/test/sagas/volumetracing/volumetracing_saga_integration.spec.ts (1)
Line range hint 277-305
: Ensure consistent use of EXPECTED_HALF_EXTENT
in tests
In the new test case, EXPECTED_HALF_EXTENT
is calculated using Constants.FLOOD_FILL_EXTENTS
. Verify that this matches the actual extents used in the flood fill operation to ensure the test accurately reflects the behavior.
frontend/javascripts/components/async_clickables.tsx (1)
50-55
: LGTM! Good UX improvement
The addition of ConfigProvider to disable motion effects is a clean solution to prevent jarring animations during icon swaps.
frontend/javascripts/oxalis/model/accessors/tracing_accessor.ts (2)
91-95
: LGTM! Robust null handling
The function safely handles the case where tracing might be null by leveraging the existing maybeGetSomeTracing
helper.
97-104
: Consider memoizing the BoundingBox instances
Creating new BoundingBox instances on every filter iteration could be inefficient for large numbers of boxes. Consider transforming the bounding boxes into BoundingBox instances once, then reusing them.
export const getUserBoundingBoxesThatContainPosition = (
state: OxalisState,
position: Vector3,
): Array<UserBoundingBox> => {
const bboxes = getUserBoundingBoxesFromState(state);
+ const boundingBoxInstances = bboxes.map(
+ (el) => new BoundingBox(el.boundingBox)
+ );
- return bboxes.filter((el) => new BoundingBox(el.boundingBox).containsPoint(position));
+ return bboxes.filter((_, idx) =>
+ boundingBoxInstances[idx].containsPoint(position)
+ );
};
Let's verify the BoundingBox implementation:
tools/test.sh (1)
93-93
: LGTM! Improved test file filtering
The addition of grep -E -v "\.(md|snap)"
correctly excludes markdown and snapshot files from the test execution, making the test runs more focused and efficient.
frontend/javascripts/libs/mjs.ts (1)
253-255
: LGTM: Simple and correct implementation of vector product.
The prod
method correctly calculates the product of vector components, which is useful for computing areas (V2) or volumes (V3).
frontend/javascripts/oxalis/controller/combinations/bounding_box_handlers.ts (1)
245-247
: LGTM: Good type safety improvement.
The explicit third argument to V3.add
ensures a Vector3 is returned instead of Float32Array, making the code more type-safe.
frontend/javascripts/oxalis/store.ts (1)
397-397
: LGTM: Clean addition of flood fill restriction configuration
The new boolean property isFloodfillRestrictedToBoundingBox
is properly typed and well-placed within the UserConfiguration interface.
frontend/javascripts/oxalis/view/action-bar/tracing_actions_view.tsx (1)
Line range hint 499-507
: LGTM: Improved button styling consistency
The addition of the 'undo-redo-button' class to both undo and redo buttons helps prevent width flickering. The 'hide-on-small-screen' class on the redo button maintains proper responsive behavior.
Also applies to: 509-517
frontend/javascripts/oxalis/model/bucket_data_handling/bucket.ts (2)
42-45
: LGTM: Well-implemented throttled warning
The new warning function follows the established pattern of throttled warnings and helps prevent warning spam while maintaining error visibility.
780-780
: LGTM: Improved error handling consistency
Good replacement of direct warning with the throttled version, maintaining functionality while improving error handling consistency.
frontend/javascripts/oxalis/model/bucket_data_handling/data_cube.ts (1)
490-491
: LGTM: Good use of BoundingBox class for type safety
The parameter renaming and wrapping in BoundingBox class is a good practice that provides type safety and maintainability.
Also applies to: 510-511
} | ||
} | ||
|
||
console.time("applyLabeledVoxelMapToAllMissingMags"); | ||
|
||
for (const indexZ of indexSet) { | ||
const labeledVoxelMapFromFloodFill: LabeledVoxelsMap = new Map(); | ||
|
||
for (const [bucketAddress, labelMaskByIndex] of labelMasksByBucketAndW.entries()) { | ||
const map = labelMaskByIndex.get(indexZ); | ||
|
||
if (map != null) { | ||
labeledVoxelMapFromFloodFill.set(bucketAddress, map); | ||
} | ||
} | ||
|
||
applyLabeledVoxelMapToAllMissingMags( | ||
labeledVoxelMapFromFloodFill, | ||
labeledZoomStep, | ||
dimensionIndices, | ||
magInfo, | ||
cube, | ||
activeCellId, | ||
indexZ, | ||
true, | ||
); | ||
} | ||
|
||
yield* put(finishAnnotationStrokeAction(volumeTracing.tracingId)); | ||
yield* put( | ||
updateSegmentAction( | ||
volumeTracing.activeCellId, | ||
{ | ||
somePosition: seedPosition, | ||
someAdditionalCoordinates: additionalCoordinates || undefined, | ||
}, | ||
volumeTracing.tracingId, | ||
), | ||
); | ||
|
||
console.timeEnd("applyLabeledVoxelMapToAllMissingMags"); | ||
|
||
if (wasBoundingBoxExceeded) { | ||
const isRestrictedToBoundingBox = yield* select( | ||
(state) => state.userConfiguration.isFloodfillRestrictedToBoundingBox, | ||
); | ||
const createNewBoundingBox = fillMode === FillModeEnum._3D && !isRestrictedToBoundingBox; | ||
const warningDetails = createNewBoundingBox | ||
? "A bounding box that represents the labeled volume was added so that you can check the borders manually." | ||
: "Please check the borders of the filled area manually and use the fill tool again if necessary."; | ||
yield* call( | ||
progressCallback, | ||
true, | ||
<> | ||
Floodfill is done, but terminated because{" "} | ||
{isRestrictedToBoundingBox | ||
? "the labeled volume touched the bounding box to which the floodfill was restricted" | ||
: "the labeled volume got too large"} | ||
. | ||
<br /> | ||
{warningDetails} {Unicode.NonBreakingSpace} | ||
<a | ||
href="#" | ||
style={{ pointerEvents: "auto" }} | ||
onClick={() => message.destroy(FLOODFILL_PROGRESS_KEY)} | ||
> | ||
Close | ||
</a> | ||
</>, | ||
{ | ||
successMessageDelay: 10000, | ||
}, | ||
); | ||
if (createNewBoundingBox) { | ||
// The bounding box is overkill for the 2D mode because in that case, | ||
// it's trivial to check the borders manually. Also, don't create a bounding | ||
// box if the user restricted the floodfill to a user bounding box, anyway. | ||
yield* put( | ||
addUserBoundingBoxAction({ | ||
boundingBox: coveredBoundingBox, | ||
name: `Limits of flood-fill (source_id=${oldSegmentIdAtSeed}, target_id=${activeCellId}, seed=${seedPosition.join( | ||
",", | ||
)}, timestamp=${new Date().getTime()})`, | ||
color: Utils.getRandomColor(), | ||
isVisible: true, | ||
}), | ||
); | ||
} | ||
} else { | ||
yield* call(progressCallback, true, "Floodfill done."); | ||
} | ||
|
||
cube.triggerPushQueue(); | ||
yield* put(setBusyBlockingInfoAction(false)); | ||
|
||
if (floodFillAction.callback != null) { | ||
floodFillAction.callback(); | ||
} | ||
} | ||
} |
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.
🛠️ Refactor suggestion
Handle potential ongoing operations in floodFill
Before proceeding with the flood fill operation, consider checking if there are any ongoing flood fill processes to prevent conflicts or unintended behavior.
Apply this diff to add a check for ongoing operations:
+ const isFloodFillInProgress = yield* select((state) => state.uiInformation.isFloodFillInProgress);
+ if (isFloodFillInProgress) {
+ Toast.warning("A flood fill operation is already in progress.");
+ continue;
+ }
+ yield* put(setFloodFillInProgressAction(true));
...
// After flood fill completes
+ yield* put(setFloodFillInProgressAction(false));
Committable suggestion skipped: line range outside the PR's diff.
URL of deployed dev instance (used for testing):
Steps to test:
TODOs:
Issues:
(Please delete unneeded items, merge only when none are left open)