processTextField region

  • 1.2K Views
  • Last Post 21 October 2015
nwixsom posted this 20 October 2015

I have a question about exactly what coordinates define the 'region' within a PDF file. If I load the file into NitroPDF it says the doc is 1070.36 x 762 mm. If I open it using acrobat reader it says the doc is 42.14 x 30 in. Both reflect the same number. If I OCR the file (using submitImage and processTextField), the resulting XML file says width="16856" height="12000" resolution="400". I tried to pass region="15170,16856,10800,12000" and I get java.lang.Exception: Error: Invalid image region specified. So what exactly are the left, top, right, bottom units measured in for the region parameter?

Order By: Standard | Newest | Votes
Oksana Serdyuk posted this 20 October 2015

As I can see you have rearranged the field coordinates for the processTextField method. In the description of the method it is said that the coordinates have to be specified relative to the left top corner of the image and are specified in the following order: left, top, right, bottom. It means the following:

left – x coordinate of the top pixel of the field,

top - y coordinate of the top pixel of the field,

right- x coordinate of the bottom pixel of the field,

bottom- y coordinate of the bottom pixel of the field.

alt text

Attached Files

nwixsom posted this 21 October 2015

You're right, I got the order wrong. However, after fixing that, I've discovered a different problem. Using processImage I'm able to locate the text I'm looking for in the PDF. Here's the xml I get back.

<document xmlns="http://www.abbyy.com/FineReader_xml/FineReader10-schema-v1.xml" version="1.0" producer="ABBYY FineReader Engine 11" languages="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://www.abbyy.com/FineReader_xml/FineReader10-schema-v1.xml &lt;a href=" http:="" www.abbyy.com="" finereader_xml="" finereader10-schema-v1.xml"="">">http://www.abbyy.com/FineReader_xml/FineReader10-schema-v1.xml"> <page width="16856" height="12000" resolution="400" originalcoords="1">

<block blocktype="Text" blockname="" l="15853" t="11504" r="16206" b="11627"><region><rect l="16112" t="11504" r="16206" b="11505"/><rect l="15854" t="11505" r="16206" b="11506"/><rect l="15853" t="11506" r="16206" b="11624"/><rect l="15853" t="11624" r="16188" b="11625"/><rect l="15853" t="11625" r="16105" b="11626"/><rect l="15932" t="11626" r="15965" b="11627"/></region> <text> <par align="Justified"> <line baseline="11622" l="15862" t="11511" r="16200" b="11620"><formatting lang="EnglishUnitedStates"> <charparams l="15862" t="11516" r="15956" b="11616">A</charparams> <charparams l="15958" t="11570" r="15998" b="11588">-</charparams> <charparams l="16002" t="11514" r="16066" b="11617">6</charparams> <charparams l="16074" t="11513" r="16140" b="11619">3</charparams> <charparams l="16156" t="11514" r="16200" b="11616" suspicious="1">1</charparams></formatting></line></par> </text> </block>

However, if I try to use processTextField I don't seem to get all the necessary chars in the results. I'm passing this URL to the server

http://cloud.ocrsdk.com/processTextField?language=English&textType=normal&region=15000,10000,16856,12000

and these are the results I get back.

<document xmlns="@link" xmlns:xsi="@link" xsi:schemalocation="@link" version="1.0"> <field left="15000" top="10000" right="16856" bottom="12000" type="text"> <value encoding="utf-16">ject1995 Hospital Re-Skin
Accessible ParkingModificationsjet TitleWINDOW SCHEDULEslo: Bldg No: Floor Lev: Section::ale As indicated KP Proj. No. 121 -935-11wn Author Permitt Sheetickd By CheckerA-6^1w</value>

It does not find the A-631 as text in the region. I believe I'm passing a region that is correct (the lower right hand corner). But it does not look like the processTextField is getting to the bottom of the page or all the way right. Its getting A-6 but not the rest.

I'd prefer to use processTextField as I know what I'm looking for will be in the bottom right corner, so no sense in parsing the whole image just to get the 10% bottom right corner (it seems to take a lot longer to process the whole image instead of the bottom right corner as text) . What am I doing wrong in the processTextField? Thanks.

Oksana Serdyuk posted this 21 October 2015

Would you mind sending your input document to CloudOCRSDK@abbyy.com?

In general, when you use the field-level recognition it is recommended to specify the most exact coordinates of the field and set up the certain recognition parameters (the recognition language, the letter set, the text type, etc.). The text field should not contain extra elements as table borders or some pictures/icons. The fact is that automatic layout analysis is not available for the field-level recognition and the program tries to extract all text inside the specified field. Also please see the article with some details in our documentation.

nwixsom posted this 21 October 2015

Sent the attachment to CloudOCRSDK@abbyy.com along with a suggestion of another possible way to get what I'm looking for. If I generate a bitmap of the lower right corner and call processImage on that it should be a lot faster and return the correct results. Thanks and let me know if there is a way to make this work with processTextField of if using processImage on the small corner image will produce consistent results.

Oksana Serdyuk posted this 22 October 2015

We have received your e-mail and tested the both scenarios:

1) For processTextField we use the parameters below:

  • region=14878,11010,16548,11792 (these coordinates correspond the part of the document you would like to process)
  • language=English
  • textType=matrix
  • oneTextLine=false

and get the following recognition result (only text):

Fac No: Bldg No:    Floor Lev:  Section:Scale As indicated KP Proj. No. 121-935-11Drwn  Author PermitNo.By  SheetChckd By   CheckerA-631Issue Date 11/01/13 ^   'Of Sheets

The processing time is 91,7 seconds.

2) When we use the processImage method for processing your bitmap image alt text

we get the following results:

  • for the textExtraction profile (only text): alt text

The processing time is 1,7 seconds.

  • for the documentConversion profile (only text): alt text

The processing time is 2,5 seconds.

It seems that the second scenario is more preferable for using if it is appropriate for you.

Attached Files

Close