Skip to content
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

Improve feedback when ALPR/platerecognizer gives no results #383

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

josephfrazier
Copy link
Owner

From the Slack thread at https://reportedcab.slack.com/archives/C9VNM3DL4/p1664032483942889?thread_ts=1657582859.783929&cid=C9VNM3DL4:

yeah... it looks like this one did get resized to within the
platerecognizer API file size limit (though, interestingly, the initial
run of the sharp library actually increased the size), here's
the server-side logs when I run the webapp locally.

image buffer length BEFORE sharp: 2185751 bytes
image buffer length AFTER sharp: 2649569 bytes
orientImageBuffer: 741.517ms
file size is greater than maximum of 2411654 bytes, attempting to scale down to width of 4096
file size after scaling down: 2054754 bytes

and the platerecognizer API responded with no results, indicating that
it was able to process the image, it just couldn't find a plate
😕here's the API response that went to the browser:

{
  "processing_time": 128.126,
  "results": [],
  "filename": "1510_1xG41_e12aa9e8-4915-4219-bcbb-5f11417c81f2.jpg",
  "version": 1,
  "camera_id": null,
  "timestamp": "2022-09-24T15:10:28.270005Z"
}

Maybe a good next step would be to make the error messaging
differentiate between the following two cases:

  • there was an error processing the image, such as it being too large for the API
  • the API processed the image, but didn't find any plates

This would make it easier to understand what's going on, without me
having to try the image myself and look at the logs to figure it out

From the Slack thread at https://reportedcab.slack.com/archives/C9VNM3DL4/p1664032483942889?thread_ts=1657582859.783929&cid=C9VNM3DL4:

> yeah... it looks like this one did get resized to within the
> platerecognizer API file size limit (though, interestingly, the initial
> run of the sharp library actually increased the size), here's
> the server-side logs when I run the webapp locally.
>
> ```
> image buffer length BEFORE sharp: 2185751 bytes
> image buffer length AFTER sharp: 2649569 bytes
> orientImageBuffer: 741.517ms
> file size is greater than maximum of 2411654 bytes, attempting to scale down to width of 4096
> file size after scaling down: 2054754 bytes
> ```
>
> and the platerecognizer API responded with no results, indicating that
> it was able to process the image, it just couldn't find a plate
> 😕here's the API response that went to the browser:
>
> ```json
> {
>   "processing_time": 128.126,
>   "results": [],
>   "filename": "1510_1xG41_e12aa9e8-4915-4219-bcbb-5f11417c81f2.jpg",
>   "version": 1,
>   "camera_id": null,
>   "timestamp": "2022-09-24T15:10:28.270005Z"
> }
> ```
>
> Maybe a good next step would be to make the error messaging
> differentiate between the following two cases:
>
> * there was an error processing the image, such as it being too large for the API
> * the API processed the image, but didn't find any plates
>
> This would make it easier to understand what's going on, without me
> having to try the image myself and look at the logs to figure it out
@josephfrazier josephfrazier temporarily deployed to reported-web-alpr-no-re-dsrnbc October 2, 2022 00:37 Inactive
Comment on lines 655 to 660
if (err == 'license plate (image was read, but no plates were found)') {
throw err;
}
console.error(err.stack);

throw 'license plate'; // eslint-disable-line no-throw-literal
throw 'license plate (image could not be read)'; // eslint-disable-line no-throw-literal
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if using parenthetical text is the best way to convey what happened, especially if GPS and/or timestamp also could not be read. For one, users may not read all the text, so it may not be clear what happened with the plate-reading.

@@ -648,9 +652,12 @@ class Home extends React.Component {
this.attachmentPlates.set(attachmentFile, result);
return result;
} catch (err) {
if (err == 'license plate (image was read, but no plates were found)') {
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of copy/pasting this exact error message, we should probably make a constant for it.

@josephfrazier
Copy link
Owner Author

I'm starting to think this code could first use some cleanup and automated tests, so I can feel more confident about changing it without needing to manually test things as much. Since #252 also affects error-handling, maybe it'd be good to think about both this change and that one, when considering how to refactor

@josephfrazier josephfrazier marked this pull request as ready for review October 20, 2022 22:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant