Google Vision Api — Image Matching Use Case using the Web Entities
Say that you clicked an image and it’s an award winning photograph and your have hosted that in your licensed Image sharing website. People can pay you and get a copy of it. Now you wanted to find whether the image is being used anywhere else in the WWW and get the list of web sites hosting the same. Google Vision Api comes in for your rescue.
Whats the catch ?
Its not cheap but not expensive for the purpose it solves. Web Detection is our use case and is most priced one.
Response Time :
You must know that this API of Google is backed by a data science model and you cannot expect swift SLAs. Remember you are matching your actual image against the trillions of images Google has slurped over the years. Assuming you are working with best connection settings, your response time is going to be somewhere between 3–5 seconds.
Possible Blockers :
Easily you will land in a one of the Google Doc pages which will suggest you do this , in case you are using service account json file.
Not sure about others but this was a nightmare for me at least. Setting up a environment variable in a infrastructure entirely on cloud which is other than Google Cloud is no joke. That’s when I found this implementation.
I was not able to get this working until I did a git research on how to use the service-json file without setting it up as a environment variable. Once you have the service file to set the credentials we are all set to hit the API.
WorkFlow Ideas:
What if we are talking about millions of images ( get your credit card first ) for an enterprise or say 100,000 images. You need to have a mechanism to programmatically feed the image data and persist the outcome. This is where I split the work flow into 2 steps. For persisting AWS S3 was chosen using a Spark program and for hitting the VisionService a REST wrapper was written which was hit from Spark FlatMap.
In short, image urls are fed from Apache Spark Driver Program and for each Image url the wrapper service was hit.
Lets talk about throttling:
With all enthusiasm I chose 20 executors and ran the distributed job only to get punched with REST API throwing bunch of 500s ( could have thrown better messages, just a proof of concept you see !). Now what happened under the hood ? I made say ~100 calls each second and the Vision API is not yet designed to handle such a load.
The average SLA was~3 seconds so I need to throttle the calls and not keep the circuit cool. So I brought my executor count to 2 and now the job ran all well and stable.
15 is the magic number:
Till now I didn’t see it in any docs, but you can combine up to 15 image requests into 1 request and get the response back in order you submitted. The response time surprisingly was ~3 sec too. So the distributed job was wired in such a way to hit the service in 15 packed batches.
Conclusion:
Google Vision API is at its early stages and we can expect faster responses soon but for now I felt authenticating and throttling are the pain points with their implementation.
