Add YOLO OD inference plugin - #12
Conversation
|
Warning Review limit reached
More reviews will be available in 54 minutes and 29 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA new YOLO object detection plugin package is added, along with its registry entry, packaging metadata, documentation, and an operator that runs YOLO inference and writes bounding-box annotations. ChangesYOLO Object Detection Plugin
Sequence Diagram(s)sequenceDiagram
participant Lightly Studio
participant YoloObjectDetectionOperator
participant YOLO
participant annotation_resolver
Lightly Studio->>YoloObjectDetectionOperator: execute(session, context, parameters)
YoloObjectDetectionOperator->>YOLO: load model_path
loop per image sample
YoloObjectDetectionOperator->>YOLO: predict(image, conf=confidence)
YOLO-->>YoloObjectDetectionOperator: boxes with class, xywh, conf
end
YoloObjectDetectionOperator->>annotation_resolver: create_many(annotations, collection_name)
annotation_resolver-->>YoloObjectDetectionOperator: persisted annotations
YoloObjectDetectionOperator-->>Lightly Studio: OperatorResult
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
plugins/yolo_object_detection/Makefile (1)
1-13: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd standard
all,clean, andtesttargets to satisfy Makefile conventions.This file currently misses targets flagged by
checkmake; adding thin wrappers keeps lint/tools happy and improves developer ergonomics.Suggested refactor
.PHONY: install format type-check +.PHONY: all clean test +all: install + install: uv venv uv pip install -r ../../dev-requirements.txt uv pip install -e . @@ type-check: uv run mypy --config-file ../../mypy.ini . + +test: + uv run pytest + +clean: + rm -rf .venv .mypy_cache .ruff_cache🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/yolo_object_detection/Makefile` around lines 1 - 13, Add the standard Makefile targets `all`, `clean`, and `test` to comply with Makefile conventions. Update the `.PHONY` declaration at the top to include all, clean, and test targets. Create an all target that runs install, format, and type-check in sequence. Create a clean target that removes build artifacts and virtual environment files. Create a test target that runs any available test suite or coordinate existing validation targets. These thin wrapper targets will satisfy checkmake requirements and improve developer ergonomics.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@plugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py`:
- Around line 124-133: The bounding box dimensions (width and height) are being
rounded but not clamped, which can result in zero values for very small boxes
when passed to AnnotationCreate. After rounding the w and h values in the
bounding box extraction logic near the AnnotationCreate call, clamp both the
rounded width and height to ensure they have a minimum value of 1 to prevent
zero-area annotations from being persisted.
- Around line 116-143: The code accumulates all annotations from all samples in
a single annotations_to_create list before writing them to the database, which
can consume excessive memory on large datasets. Instead of collecting all
annotations in one list throughout the entire loop over samples, implement
chunked writes by writing annotations to the database after processing a
reasonable batch size (for example, every N samples or every N annotations),
then clearing the annotations_to_create list and continuing. This approach will
reduce peak memory usage and enable earlier database writes by calling
annotation_resolver.create_many at intervals rather than waiting until all
samples are processed.
- Around line 81-83: The operator lacks exception handling for three critical
failure points that currently crash instead of returning a controlled
OperatorResult. First, wrap the float() conversion for PARAM_CONFIDENCE with a
try-except block to handle non-numeric confidence values gracefully. Second,
wrap the YOLO() model loading call with a try-except block to catch model
resolution failures like HUBModelError or FileNotFoundError. Third, wrap the
inference call around line 118 with a try-except block to handle file read
failures or corrupted image data. For each failure point, log an appropriate
error message and return an OperatorResult with failure status instead of
allowing the exception to propagate and crash the operator.
---
Nitpick comments:
In `@plugins/yolo_object_detection/Makefile`:
- Around line 1-13: Add the standard Makefile targets `all`, `clean`, and `test`
to comply with Makefile conventions. Update the `.PHONY` declaration at the top
to include all, clean, and test targets. Create an all target that runs install,
format, and type-check in sequence. Create a clean target that removes build
artifacts and virtual environment files. Create a test target that runs any
available test suite or coordinate existing validation targets. These thin
wrapper targets will satisfy checkmake requirements and improve developer
ergonomics.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9081da59-c23d-4503-baa4-27ad7873be9b
📒 Files selected for processing (6)
plugins.tomlplugins/yolo_object_detection/LICENSEplugins/yolo_object_detection/Makefileplugins/yolo_object_detection/pyproject.tomlplugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/__init__.pyplugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py
|
/review |
JonasWurst
left a comment
There was a problem hiding this comment.
Lets give the user the option to define the source
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
plugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py (1)
111-115: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winDefer label creation until after confirming samples exist.
_get_or_create_label_map()is invoked before the no-samples early return, so an empty view can still create YOLO class labels in the dataset and then return “No samples found”. This is an unintended data mutation path.Proposed fix
- label_map = _get_or_create_label_map( - session=session, - root_collection_id=context.collection_id, - class_map=model.names, - ) - context_filter = None @@ samples = list(samples_result.samples) if not samples: return OperatorResult( success=True, message="No samples found for current view.", ) + + label_map = _get_or_create_label_map( + session=session, + root_collection_id=context.collection_id, + class_map=model.names, + )Also applies to: 130-134
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py` around lines 111 - 115, Move the _get_or_create_label_map() call in operator.py so it runs only after the no-samples check has passed, using the existing YOLO operator flow around the sample-query/early-return logic. Update the relevant paths in the main execution method so empty views return “No samples found” before any label_map creation or writes happen, preventing label mutations when there are no samples. If the same pattern appears in the other affected block, apply the same reordering there as well.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@plugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py`:
- Around line 92-94: The collection name assignment in operator.py currently
calls str(parameters.get(...)) directly, which can turn missing or blank
annotation_source values into unintended names like "None" or empty strings.
Update the collection_name logic in the operator’s parameter handling to read
annotation_source first, trim/normalize it, and only then convert or fall back
to the default yolo_auto_label__{model_path} value when the result is empty or
missing.
---
Outside diff comments:
In
`@plugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py`:
- Around line 111-115: Move the _get_or_create_label_map() call in operator.py
so it runs only after the no-samples check has passed, using the existing YOLO
operator flow around the sample-query/early-return logic. Update the relevant
paths in the main execution method so empty views return “No samples found”
before any label_map creation or writes happen, preventing label mutations when
there are no samples. If the same pattern appears in the other affected block,
apply the same reordering there as well.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b125d247-f966-4ba8-8623-1ab8d18af3a9
📒 Files selected for processing (4)
README.mdplugins/yolo_object_detection/README.mdplugins/yolo_object_detection/pyproject.tomlplugins/yolo_object_detection/src/lightly_plugins_yolo_object_detection/operator.py
✅ Files skipped from review due to trivial changes (2)
- plugins/yolo_object_detection/README.md
- plugins/yolo_object_detection/pyproject.toml
edbc55c to
4b31b2d
Compare
What has changed and why?
Adds a YOLO object detection plugin.
How has it been tested?
Manual testing.
You can also install it locally:
Did you update Readme.md and plugins.toml?
YOLO Object Detection Plugin
Adds a new YOLO object detection inference plugin (
lightly_plugins_yolo_object_detection) tolightly-studio-plugins.plugins.toml(source = local:plugins/yolo_object_detection) and adds docs to the mainREADME.mdandplugins/yolo_object_detection/README.md.YoloObjectDetectionOperatorthat runs Ultralytics YOLO inference on image samples in the current view/filter and writes bounding box annotations.model_path(defaultyolov8n.pt),confidence(default0.25, validated to[0, 1]), and optionalannotation_source(stripped; defaults toyolo_auto_label__{model_path})._WRITE_BATCH_SIZE = 100) viaannotation_resolver.create_many, and returns a “No samples found…” message when applicable.plugins/yolo_object_detection/pyproject.toml(package metadata, dependencieslightly_studio>=1.0.0,sqlmodel,ultralytics, and the operator entry point)plugins/yolo_object_detection/Makefile(install,format,type-check)LICENSEpip install git+https://github.com/lightly-ai/lightly-studio-plugins.git#subdirectory=plugins/yolo_object_detection/