Overkill for the specific project at hand, as others have mentioned, but it does serve as a proof of execution for what is essentially “over the air retrofits to remotely upgrade pre-existing readouts to be digitally consumable”. A well-placed webcam could turn https://m.lightinthebox.com/p/50-100-mini-digital-lcd-indoor... ($20 AUD) into https://www.instrumentchoice.com.au/wifi-connected-high-accu... ($500 AUD). The other possibility is using other forms of computer vision beyond OCR to remotely digitize analog indicators like old-school pressure gauges.
I suppose they might have just wanted to whip something up using the equipment they had at hand, but you could easily solve the same problem with and off-the shelf device:
> Using what they had on hand vs buying a 2nd thermometer for a one time use. Hacker News of all places should embrace option 1.
Why? Time is valuable too. If I had to do the same thing and was more interested in getting the job done than building a Rube Goldberg machine, I'd totally buy a second thermometer that's suited to what I'm trying to do.
Of course, which is why it’s important to spend it learning new things.
You haven’t factored shipping into your time equation—get it done today (and learn something new) or wait 2 days for Amazon to deliver something I might only need once…I know what I’d do.
Even with all the power of AI you still need good judgement. Hours of work using AI, video processing, and cloud services, and the problem could have been solved with a off the shelf device that costs the same as the thermometer they were using.
Thousands of dollars solution vs tens of dollars solution.
Except it will be a complete dead end if they want to read some other instrument. We have no universal electronic interface for this sort of thing but human-like vision is a universal interface.
Isn't that an inefficient way to use ffmpeg to extract a frame every n seconds?
You'll read the first 10 seconds (d/n) times, for example.
Probably better to grab the frames and then rename them according to the time afterwards (because ffmpeg doesn't yet have timestampable output filenames.)
ffmpeg -i video -fps 1/10 output_%0d.jpg
j=10
for i in output_*.jpg; do
t=$(printf "${OUTPUT_DIR}/frame_%02d:%02d:%02d.jpg" $((j/3600)) $(((j/60)%60)) $((j%60)))
mv -f "$i" "$t"
j=$((j+10))
done
Although for big files, `-fps` turns out to be slow. https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/issues/4... is a much better solution - multiple `-ss` and `-i` on the same file. For the 14GB 4K video I tested, `-fps 1/462` was going to take ~4h, `-vf fps="fps=1/60"` was about 60 minutes, and the multiple `-ss` variant took ~35s.
Although the comment section has some critique for the exact methodology used, I quite like this. To me, it's a very real example of how ChatGPT speeds up a personal project to solve a niche problem.
Hmm, general-purpose OCR is a bit sucky for specialized stuff. I think it might make more sense to train a tiny OCR thing to read the multimeter, and I think the training would take seconds. You can even get ChatGPT to generate the training code. ;)
That sounds like fun but a lot of work. Perhaps pick a different general purpose OCR?
I've found PaddleOCR to work really well for non-tesseract friendly text. Throwing the results back at chatGPT for formatting / extraction solves mucking about with detection, cropping, processing etc.
I was going to do something similar. I've got a cheap AcuRite indoor/outdoor thermometer and wanted to save the outdoor readings periodically in a database.
The first plan was to periodically take a photo of the display with an RPi camera, extract the temperature from the picture, and put it in the DB.
But I wasn't going to bother with trying to use a fancy OCR library. I was just going to write something specifically for this task. It would not have taken a lot of code, because of the limited nature of the display.
The AcuRite display (and the display in the article) are using 7 segment digits at fixed locations.
For a 3 digits temperature reading that must be an integer in [-199, 199] there are 17 segments whose state you want to look at, and for each you just need to determine if it is on or off.
So it is just a matter of looking at 17 predetermined parts of the image, plus looking at some predetermined parts of the image that are always LCD background, and at some predetermined parts that are always LCD on (like the ℉ or ℃). Using the always background and always on parts as a reference you can decide whether the 17 segments are on or off.
My plan was to use color marker to add some red and green crosses to the case just outside the LCD the near the top corners of the LCD and near the bottom of outdoor digits.
It should then be straightforward given an image library that has a get_color_at(x,y) function to find those crosses, and to have a table of the aforementioned 17 parts plus reference parts that gives their locations relative to the crosses.
I then realized I'd be better off buying an RTL-SDR and putting it on the RPi, and running rtl_433. Rtl_433 knows how to decode the transmissions from the AcuRite outdoor sensor, and I could extract the data from the rtl_433 output to put in my database.
That approach has the advantage that rtl_433 also knows how to decode my AcuRite fridge/freezer thermometer sensor transmissions so I could also include those in my database.
Also, I was going to build a tipping rain gauge that summer and was going to use rtl_433 to decode its transmissions, so was already planning on getting an RTL-SDR for the RPi anyway, so it made the most sense to just push that purchase up a few months and not bother with the image processing approach.
