Class-Based Cuboid Dimensions
Minimum and Maximum Cuboid Volume is a sanity check that validates the computed three-dimensional volume of every cuboid annotation against the class-specific volume range defined in the project ontology. Volume is calculated as the product of the cuboid's length, width, and height. When the result falls outside the permitted range for that object class, the tool surfaces an immediate visual cue - helping annotators catch volumetrically impossible annotations before they progress to QA.
Volume constraints are defined per class in the project ontology. A cuboid may have individually plausible dimensions yet still produce an impossible overall volume - this check catches that case.
Use Case
Individual dimension checks (length, width, height) are necessary but not sufficient to guarantee volumetric realism. A cuboid can satisfy each individual dimension constraint while still producing an implausibly large or small total volume - for example, a pedestrian annotation that is just within width and height limits but has an exaggerated length that inflates the volume beyond what is physically plausible for a human body.
Minimum and Maximum Cuboid Volume addresses this by:
Computing volume in real time as cuboids are drawn or adjusted (Length x Width x Height)
Comparing the result against the minimum and maximum volume defined for that class in the ontology
Displaying a visual cue within approximately 2 seconds whenever the volume is outside the acceptable range
Referencing class-based volume limits, so the same computed volume may be valid for one class and flagged for another
Common scenarios include:
Pedestrian or cyclist cuboids that are slightly stretched along one axis, creating an implausibly large combined volume
Small objects (traffic cones, debris) annotated with a cuboid that is proportionally too large Edge cases where a single very thin dimension combined with large planar dimensions results in a volume that is technically non-zero but physically unrealistic
Benefits
For Annotators
Rapid Visual Feedback - The cue appears within approximately 2 seconds, allowing correction before the annotator progresses to the next frame or object.
Class-Aware Enforcement - Volume thresholds are drawn directly from the ontology, so annotators are always working against the correct class-specific standard.
For Project Managers
Reduced QA Burden - Volumetrically invalid annotations are resolved at the labelling stage, reducing the frequency and cost of downstream corrections.
Consistent Cross-Annotator Standards - All annotators are evaluated against identical ontology-defined volume ranges, eliminating variability in interpretation.
Steps to Use
Define Volume Constraints in the Ontology
Navigate to the project ontology (category schema) settings.
Locate and enable the Sanity Checks section.
For each object class (e.g., Car, Pedestrian, Cyclist, Truck, Traffic Cone), add or update:
Minimum volume (m³) — the smallest physically plausible volume for that class
Maximum volume (m³) — the largest physically plausible volume for that class
Save and publish the recipe. Thresholds apply immediately to all active tasks on reload.
If unsure of appropriate values, refer to class dimension guidelines: min volume = min L × min W × min H; max volume = max L × max W × max H.
Respond to the Visual Cue
If the computed volume falls below the minimum or exceeds the maximum for that class, a visual cue appears on all the affected cuboids on the timeline.
The cue distinguishes whether the volume is too small or too large.
Determine whether it is a genuine case or resize the cuboid to bring its volume within the valid range.
The cue clears automatically once the volumne is within the permitted range.
Best Practices
Derive Volume Limits from Dimension Guidelines - Compute min and max volumes (min L × min W × min H and max L × max W × max H) to ensure internal consistency between checks.
Add a Tolerance Margin - Include a small buffer above and below the physical limits to account for LiDAR measurement uncertainty and legitimate annotation variance, avoiding excessive false positives.
Document Volume Ranges in Annotation Guidelines - Publish the class-specific min/max volume table in the project's annotation guidelines so annotators understand the constraints in context.
Handle Edge Cases Explicitly - Define and communicate a procedure for objects that are genuinely outside the typical volume range (e.g., articulated trucks, collapsed objects) so annotators know whether to adjust, of flag.
Last updated