Funny how the whole article talks about this approach, and then at the end shows the approach failing in the real world. I don't know about you, but I can't conclusively come up with a license plate in that final video.
You can get much further by applying deconvolutions and using more math. I've been meaning to put some time into this myself but never got it off the ground.
I wonder if the author would be open to making e.g. the car data available?
Here you go:
- The stabilized frames out of blender (with 4 blurry frames in a separate folder): https://breaking.systems/plate_frames_sorted.zip
- The original video in case you'd like to improve the stabilization as well: https://breaking.systems/plate_vid_orig.mp4
Would love to hear back in case you'll tackle it!
But I wonder how to actually do it, do you have concrete ideas for a simple algorithm?
Depending on camera movement (and whether you might get "ground truth" information from pixels entering and leaving the areas near the borders) the system will be more or less well-conditioned. I'm going to try this for the data the author graciously provided and report back!
- http://www.eyetap.org/papers/docs/mann94virtual.pdf - http://wearcam.org/orbits/index.html
I seem to recall that there used to be a video showing this approach in action. As input it took a video panning across a shelf full of books where the resolution was so low that the titles were illegible. And as output it produced a video with higher resolution and all the titles easily readable. Unfortunately I can't find that video any longer.
Interesting - this is same incorrect use of e.g. that the author made in a couple of places. Contrary to (apparently popular) belief, "i.e." and "e.g." can't simply be used as direct replacements for their English equivalents.
"e.g." is used to introduce one or more examples that satisfy a previously provided general form, for example:
I prefer fruit, e.g. apples or pears, over vegetables. Apples and pears being examples of fruit, not that an example is needed in this case, but for the sake of simplicity.
In the former example, "the car data" is not an example of "making".
"i.e." follows a similar rule. If there are exceptions for either, I'd be interested to know of them.
In any case, what I wrote is really just a shorthand for more cumbersome formulations (like "...open to making your data, e.g. the car [data], available?" - that would hopefully be correct?), and reducing text is the whole point of using an abbreviation in the first place. But I'm open to striving for more consistent usage, so if you can refer me to some kind of authority on how to mix Latin abbreviations with English text, I'd be curious about it!