Assigned
Status Update
Comments
va...@google.com <va...@google.com>
ar...@google.com <ar...@google.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]
so...@gmail.com <so...@gmail.com> #3
I also need this problem solved :)
so...@gmail.com <so...@gmail.com> #4
same :D
ar...@google.com <ar...@google.com> #5
+1
la...@gmail.com <la...@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.
lu...@gmail.com <lu...@gmail.com> #8
+1
vs...@autoeveramerica.com <vs...@autoeveramerica.com> #9
Would be great if this could be implemented.
Description
It was working fine for about a year, but Google raised the issue of v1 > v2 migration.
It has been occurring since then, specifically from January 2024.
I would like to declare in advance that this is not a problem limited to Japanese models.
The problem started with a significant delay in isFinal arrival on v1.
The isFinal arriving in response with an average delay of 60 seconds seriously disrupted the behavior of our application.
We were testing migration to v2 around this time, and in v2, isFinal calls worked as before with a VAD of about 600ms, so we decided to migrate to v2.
It was working fine for about 3 weeks.
However, around March 18, 2024, isFinal is no longer handled even in v2.
Our efforts were in vain.
Among the interim candidates received, candidates from the past 100 seconds are included each time, and the user
You will be forced to display too long sentences that are extremely difficult to read.
Why does "isFinal", which used to work, no longer work?
This problem occurs in many languages, including Japanese, Korean, and French, because en-US uses isFinal processing as before.
Is it possible for this isFinal issue to revert to its original behavior?