To counter other’s points on pricing - in the end it’s a question of utility vs price. 1k$ per year to cut time to count by 80% may be a great deal to many.
the article said it saved about three months of labour. if best alternative is someone counting in old labour intensive way with annual salary of around $50k then that's an O($10k) profit.
In this case, it would be reasonable that the person who uses the app would be responsible. The app takes the image and labels every pearl with a number. So the person just needs to check there were no missing or mislabeled pearls, which is much easier than counting.
In the example I would expect the app to get it right every time. In a more fuzzy setting it would still be faster (thousands of times) and [generally] more accurate but a person can account for how important accuracy is.
I guess the numbering added to the image is brilliant. A human can gaze over that and see something wrong right away.
Of course, but $100 per year to do the same is an even better deal.
I can only assume that their support for custom requests is absolutely incredible, because it should be pretty trivial for any potential competitor to put up a similar concept for a tenth of the price and still be making a profit.
But that's always the case with enterprise software I suppose. The improvement from 98% to 100% "quality" (whatever that means) is well worth a drastic price hike for most businesses.
This was my first thought: I could do this in half a day.
Then you look at their site and all the domains of application. My guess is they probably use a variety of models to get 100%: edge detection, CNN-style object detection, all sorts. And then aggregate/choose between the resulting predictions. Then they will probably have some layers of geometrical estimators.
The challenge here is 100% and on a wide variety of images. They'll need to maintain and collect data across a lot of domains, and find ways of coping with non-ideal ("in the field") input.
Google Lens isn't going to include a menu item for every single computer vision task with a simple specialized solution.
OpenCV provides circle detection out of the box: https://docs.opencv.org/3.4/d4/d70/tutorial_hough_circle.htm... The only part that's somewhat difficult is tuning the parameters correctly. I've found setting all thresholds very low (generating lots of false positives) and then culling overlap to work very well when I had to count individual atoms in electron microscopy images a few years ago.