I saw the nodered thing, now this php thing, and there's my crappy batch script thing... I'm sensing that this is a very important application with many needles poking at it from different directions. This should be a hint to the BI devs at least.
I run nodered for all my homeassistant automations, so I'm fairly familar with it. I understand it has a less steep learning curve, but it is probably not the best tool for more advanced development going forward. Regardless what language/compiler/etc is used, I think it would be optimal if post processing efforts were combined to make a standard yet powerful cross/platform tool to go with BI, should BI lackluster on this end. I'm no CSE, but can help with beta testing/field reporting.
I would be really surprised to see any sort of post-processing built into
Blue Iris, unless there is some way to crowd-source the algorithms that would be needed to identify which of the thousands of US license plate designs is in the image and then pattern match the letters/numbers based on what is valid on that design. Even the commercial LPR systems I've worked with that cost 5 figures per installation only try to identify tags from a few states at a time by loading region-specific firmware. The type of pattern matching that may work for UK and EU tags just seems impractical in the US where each state can have between dozens and hundreds of different tag designs with different letter/number patterns.
I'd love to be wrong about this, and maybe with enough input the AI can learn to mostly pick the correct option, but it will require a huge set of images and I'd still have very limited expectations when dealing with the night time black and white IR reflective images, since a lot of the information that lets you identify a tag's design is lost in those images.
Trying to differentiate between zero and the letter O on US plates seems like a waste of time. A few states use both. Many only use one or the other. For searching and matching purposes, the two should be considered to be a single character. I don't know if it's possible in the UK for two plates to exist that only differ by the fact that one has an O and the other has a 0 in the same position. I'm pretty sure that is impossible in the US, as the FBI's NCIC system converts all Os to zeros in queries, and you don't want to be driving around with the vanity plate "ST0LEN" after someone else reports their vanity plate "STOLEN" as stolen.
(Maryland did allow the vanity plates "NO TAG" and "NO TAGS" at one point. That was either a brilliant move that meant they never had to pay a parking ticket, or a dumb move meaning they get thousands of parking tickets a year for other people's unregistered cars. My guess is it's probably the latter.
It's probably easiest to just normalize all the Os to zeros or zeros to Os in the database in the first place, but if you don't, it just pushes the issue to the query side of things. If I were looking through my data for the plate NOP102, I would, at a minimum, search for N (O,0) P 1 (O,0) 2. Even using Plate Recognizer as my ALPR engine, with its huge dataset and region-specific processing, I'd be searching (N,M, W,H) (O,0,Q,D) (P,B,R) (1,L,I) (O,0,Q) (2,Z) if I really wanted to do a thorough check for that tag in my database.