I’m trying to send an image to an Azure vision endpoint. The data stored in the DB looks something like this.
array(‘b’, [-119, 80, 78, 71, 13, 10, 26, 10, 0, 0, 0, 13, 73 … etc
Its converted to a byteArray to be packaged as the data
Byte Array Value:
The basic endpoint definition and instructions are the following.
https://eastus2.api.cognitive.microsoft.com/customvision/v3.0/Prediction/[project id]/classify/iterations/[iteration Name]/image
Set Prediction-Key Header to : key value
Set Content-Type Header to : application/octet-stream
Set Body to :
We had initially tried using the built in Ignition function, system.net.httpPost as our method to send the images to the endpoint, but we kept getting a “Bad Image Format” error returned from Azure.
The post hints about it being an issue with the byteArray, but from our testing it seems to be something happening in httpPost.
Next we pivoted to using the python libraries: Request (backed by URLLIB3)
• Using the requests library within the Ignition platform, sending images that are less than 64K works successfully as expected
• Using the requests library within the Ignition platform, sending images that are greater than 64K do not work successfully. We receive a timeout with a ConnectionAborted: BadLineStatus(‘’’’)
o Setting the Content-Length value in the header didn’t help either unfortunately.
As a validation step, I simply did an install of python 3.7, loaded up requests and urllib3 library and performed the exact same calls (fetched data from our database, called out to the Azure endpoint).
• Using the requests library from the command line against python sending images that are less than 64K works successfully as expected
• Using the requests library from the command line against python, sending images that are greater than 64K works successfully as expected
I understand that there are a lot of moving parts here…
• Ignition is jython - 2.7
• Requests and urllib3 are additional libraries
• The external test we performed where it works isn’t a good 1 to 1 representation, but it took the Ignition system / JVM out of the equation…
Since we can’t get the call to fail in the same way outside of the ignition environment, we’re struggling to get a good understanding as to why or where in the pipeline its failing. Any ideas about where this might be failing or a different method that is known to work for this kind of problem would be great.
I’d like to avoid creating a custom module just to get around this.