Assigned
Status Update
Comments
pl...@gmail.com <pl...@gmail.com> #2
I have informed our engineering team of this feature request. There is currently no ETA for its implementation.
A current workaround would be to check the returned "boundingPoly" [1] "vertices" for the returned "textAnnotations". If the calculated rectangle's heights > widths, than your image is sideways.
[1]https://cloud.google.com/vision/reference/rest/v1/images/annotate#boundingpoly
A current workaround would be to check the returned "boundingPoly" [1] "vertices" for the returned "textAnnotations". If the calculated rectangle's heights > widths, than your image is sideways.
[1]
ra...@google.com <ra...@google.com> #3
I also need this problem solved :)
pl...@gmail.com <pl...@gmail.com> #4
same :D
pl...@gmail.com <pl...@gmail.com> #5
+1
na...@google.com <na...@google.com> #6
+1
pl...@gmail.com <pl...@gmail.com> #7
This needs more attention. It's not just a display issue as described in the report. The co-ordinates returned in 'boundingPoly' are incorrect if the image was taken on a phone. All the x points should be y and vice versa.
The workaround does not make sense as "boundingPoly" [1] "vertices" for "textAnnotations" does not indicate the image dimensions - it indicates the dimensions of the relevant text block inside the image.
The workaround does not make sense as "boundingPoly" [1] "vertices" for "textAnnotations" does not indicate the image dimensions - it indicates the dimensions of the relevant text block inside the image.
ra...@google.com <ra...@google.com> #8
+1
pl...@gmail.com <pl...@gmail.com> #9
Would be great if this could be implemented.
ar...@google.com <ar...@google.com> #10
+1
pl...@gmail.com <pl...@gmail.com> #11
+1
ar...@google.com <ar...@google.com> #12
+1
va...@gmail.com <va...@gmail.com> #13
+1.
va...@gmail.com <va...@gmail.com> #14
The rotation information should already be available, basically the order of the bounding box vertices encode that rotation information:
https://cloud.google.com/vision/docs/reference/rest/v1/images/annotate#block
Could you please test and see if that works for your case?
Could you please test and see if that works for your case?
mi...@google.com <mi...@google.com> #15
Each bounding box on the page can have a different orientation, so it can be frustrating to figure out.
va...@gmail.com <va...@gmail.com> #16
+1
jo...@google.com <jo...@google.com> #17
"A current workaround would be to check the returned "boundingPoly" [1] "vertices" for the returned "textAnnotations". If the calculated rectangle's heights > widths, than your image is sideways. " - The proposed workaround does not work if the image needs to be rotated at 180 degrees. Any ETA after 2y and 1 day?
pl...@gmail.com <pl...@gmail.com> #18
+1
ri...@google.com <ri...@google.com> #19
+1
[Deleted User] <[Deleted User]> #20
+1
je...@google.com <je...@google.com>
fr...@gmail.com <fr...@gmail.com> #21
+1
Description
Difference in output when using different values for batchSize parameter. Tested with batchSize=1 and the output seems good while using batchSize=8 produced a very small output.
Some letters in the PDF does not match the output (OCR output quality)
Ex. సహకాసోదరునితో should be సహ=కాసోదరునితో
The sequence of words appearing is in incorrect order as compared to the actual PDF (OCR output quality)
Some characters are missing (OCR output quality)
Customer is looking/following this documentation [1]
See attached PDF file (AK-Sarga1-part.pdf) which contains "TELUGU" language.
[1]
Reproduction Steps: Used this command:
curl -X POST -H "Authorization: Bearer <AUTH_TOKEN>" -H "Content-Type: application/json; charset=utf-8"
With the following config:
{
"requests": [
{
"features": [
{
"type": "DOCUMENT_TEXT_DETECTION"
}
],
"inputConfig": {
"gcsSource": {
"uri": "[BUCKET]/AK-Sarga1-part.pdf"
},
"mimeType": "application/pdf"
},
"imageContext": {
"languageHints": [
"te"
],
"textDetectionParams": {
"enableTextDetectionConfidenceScore": false
}
},
"outputConfig": {
"batchSize": 8,
"gcsDestination": {
"uri": "gs://sriramayanamfiles/pdf-test/"
}
}
}
]
}