Translate box dimensions from API call

[gadget-man]

I'm trying to get a snapshot of an event and get the closest possible bounding box for the associated license_plate.

I appreciate that the box dimensions in an mqtt message won't always align with the snapshot, particularly if it take a few ms to grab the snapshot after receiving an MQTT message.

To get around this, I'm making an API call to get the screenshot (GET /api/events/<id>/snapshot.jpg) and immediately get the event data (GET /api/events/<id>).

However, I've noticed that the box dimensions for a license_plate attribute in the API call are decimals, as distinct from x_min, y_min, x_max, y_max based on the image size within MQTT messages.

My question is simple - how to I translate the box coordinates in a GET /api/events/<id> so that I can manually draw a bounding box using a python draw command? I've tested the obvious of multiplying each of the 4 coordinates by image_width and image_height as appropriate, but I don't get a box anywhere near the right position on the snapshot.

I suspect I'm doing something very obvious, but can't work it out!

plate = ( final_attribute[0]['box'][0]*image_height, final_attribute[0]['box'][1]*image_width, final_attribute[0]['box'][2]*image_height, final_attribute[0]['box'][3]*image_width ) draw.rectangle(plate, outline="green", width=2) _LOGGER.debug(f"Final Plate: {plate}")

[NickM-27]

The data is stored in events as x_left, y_top, width, height and they are relative based on the detect width and height as you guessed

[gadget-man]

Thanks. x_left and y_top - so to get (x0, y0, x1, y1) I'd need ([0], [1]-[3], [0]+[2], [1]). I'd have thought ([0], [1], [0]+[2], [1]+[3]) would have been more logical?

[NickM-27]

so to get (x0, y0, x1, y1) I'd need ([0], [1]-[3], [0]+[2], [1])

no

I'd have thought ([0], [1], [0]+[2], [1]+[3]) would have been more logical?

that is how you would get the coordinates of the box

[gadget-man]

Ok, worked it out thanks! However, we're still seeing inconsistencies between the coordinates returned in GET /api/events/<id> when drawn on a snapshot requested immediately before it using GET /api/events/<id>/snapshot.jpg. Presumably this is because of the way Frigate processes snapshots and continuously updates them based on the best score. Is there a way to get the confirmed coordinates for a license_plate (Frigate+ only) for a snapshot image that we can be confident align?

[NickM-27]

I've not had issues using the MQTT attribute box and the latest.jpg with some padding on the crop

[gadget-man]

Ah, do you mean GET /api/<camera_name>/latest.jpg? I've been using GET /api/events/<id>/snapshot.jpg

[gadget-man]

So as soon as we receive an MQTT message that we want to process, grab latest.jpg rather than snapshot.jpg?

[NickM-27]

That's what I do, works well for me

[gadget-man]

Just in case anybody else stumbles across this: it turns out that my original plan of getting the latest snapshot, then doing an API call to get the event data does provide very reliable box / license_plate coordinates to allow you to draw your own box around the plate.