feat(alerts): display detection crop overlay on main image#209
Conversation
Surface optional crop_url returned by /sequences/{id}/detections
when with_crop=true. Field is nullable for older detections without
a crop.
Display the optional crop image returned by the API as a small thumbnail pinned to the top-left of the detection viewer, with a toggle button alongside the existing bbox toggle. The overlay is only rendered when crop_url is present.
Add buttonDisplayCrop / buttonHideCrop in en/fr/es/de under the alerts namespace.
Replace 'crop' with 'recadrage' which is the correct French term.
Place the crop preview opposite the detection: top-left when the bbox center is on the right half of the image, top-right otherwise. Avoids the overlay sitting on top of the smoke.
Use close-up / gros plan / primer plano / Nahaufnahme to better convey that the inset shows a zoomed-in view of the smoke.
Render the crop at its native 224px width to match the model input size, so reviewers see the full-resolution close-up.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
I have a few questions to discuss together. |
|
Hi Mateo, thanks for making a first proposition to #203 ! At this stage of the discussion, provided the crop dimensions remain 224×224, I will try to include the full crop ! Now, as discussed and pointed out in your comment, the crop image must not alter the "map zoom" (At least we need to avoid it) What about a display that’s always at the bottom right if the light is mainly in the left-hand area (the centre of the bounding boxes of the sequences? Or just the first one?), and vice versa? So, when might this approach cause problems? |
…verlay # Conflicts: # src/components/Alerts/AlertDetails/AlertImages/AlertImages.tsx # src/services/alerts.ts
…verlay # Conflicts: # src/components/Alerts/AlertDetails/AlertImages/AlertImages.tsx
|
Hi @fe51 , I updated the PR to have the crop at imge bottom, let me know what you think |
|
Thanks a lot for the PR !
|
|
Hi @fe51 , as discussed on the side, I've updated the button. For the second question, I'd actually suggest the opposite: making a change on the engine so it applies everywhere, even when it's not a 4K cam. It acts as a kind of zoom, which is pretty handy. 
|
|
I agree. Hence, OK for functionnal aspects Then, to be reviewed and merge only when crop is available for any alert (api side)) ? |
| others_bboxes: z.nullable(z.string()), | ||
| created_at: z.iso.datetime({ local: true }), | ||
| url: z.string(), | ||
| crop_url: z.nullable(z.string()).optional(), |
There was a problem hiding this comment.
To have both null and undefined covered you should use nullish : https://zod.dev/api?id=nullish#nullish
There was a problem hiding this comment.
Good call, switched to z.string().nullish()
MateoLostanlen
force-pushed
the
feat/detection-crop-overlay
branch
from
ad46791 to
1d8d5ba
Compare
|
Hi @m-julio, I haven't tested it on mobile yet. How do you usually do it,through the Vercel preview? I don't think I have access to it, so let me know how you go about it |
|
Hi @m-julio, just tested on mobile it works |
…t/detection-crop-overlay
3 participants
Why
Make faster decisions on small fires from afar. The crop gives reviewers a tight, zoomed-in view of the smoke so they can confirm or dismiss without waiting on the full frame.
Companion PRs:
Demo: https://www.loom.com/share/0f5a3c5310044779abf3bb9dcdbc02ec
Note on the demo: the source images are already compressed HD frames, so the actual resolution benefit of the crop isn't really visible in the video. On real raw frames the close-up will be noticeably sharper.
What changes
crop_urlreturned byGET /sequences/{id}/detections(withwith_crop=true) in the detection schema.buttonDisplayCrop/buttonHideCroplabels in en/fr/es/de (close-up / gros plan / primer plano / Nahaufnahme).How to test
Run against the dev env with the engine and api PR branches. Heads-up: the current engine PR loops the same image, which makes the demo less convincing. For testing prefer the
send_detection_crop_changing_imagesbranch on pyro-engine, which is the same PR plus image rotation. A separate PR will fold that change into engine soon.Note
This is a first proposal, fully open to discussion on both design and implementation. Feel free to commit directly on this branch if needed.