Hello,
We have a following open question: is it possible to get rid of classifier (in FC, in SDK) without losing recognition performance?
We have tens of layouts and we use a tree classifier that just copies the static elements of each layout, so each "layout" just
does the "double job", matching agains same static elements, and each template is made "clever" enough to match on its own
class of images and not to match on "foreign" class. So should the recognition without classifier be the same by speed?
And, another question, connected with the question above: does anybody know the order of layout matching in FC SDK? Is it
the same order as we loaded the fcdot files or something else? Is it actually some stable order or it can be random?
Thanks
We have a following open question: is it possible to get rid of classifier (in FC, in SDK) without losing recognition performance?
We have tens of layouts and we use a tree classifier that just copies the static elements of each layout, so each "layout" just
does the "double job", matching agains same static elements, and each template is made "clever" enough to match on its own
class of images and not to match on "foreign" class. So should the recognition without classifier be the same by speed?
And, another question, connected with the question above: does anybody know the order of layout matching in FC SDK? Is it
the same order as we loaded the fcdot files or something else? Is it actually some stable order or it can be random?
Thanks
コメント
1件のコメント
You are not required to us classifier. In the app side, it is as easy as unloading the .cfl file in the Batch Type setting under Recognition. (default batch type if you don't have batch type - Project - Project Project). As for the FCE side, it depends if you calling the fcproj project or the .fcdot file. If you are using the fcproj file, then you can remove it from the project. If you are using the fcdot file, then just don't call the classification in your code.
Speed wise it would depend on the a couple things. First off Classification projects only work with docdef that use FlexiLayout. If you are only processing fix forms, then classification project will do nothing for you. If you have a couple semistructure doc def, classification might not help you out speed wise. If you have a couple hundred then yes classification would definitely help you. It really depends on how long it takes to go through all the FlexiLayout matching.
The logic is as follows when processing using the project:
Images comes in.
Does is match the first fix form (Look at the DocDef list in your project. It goes in order from top to bottom)
-If it matches, it stops
-If it doesn't match, it will go to the next FixForm DocDef on the list
-If it doesn't match, any of the FixForm DocDef it will go onto the FlexiLayout
Does the Project have a Classification Project
-if it has a Class Project, it will get run. If it matches one of the class, it will get sent to the that layout it links to
-If it doesn't have a Class Project, it will run all the FlexiLayout. What ever has the best score will get chosen.
I know I left a couple other step like "use first acceptable FlexiLayout Option, Layout with Headers, etc, but that's the overall logic of it. Attached is also a flowchart I receive from one of the ABBYY trainer when I attended the class.
Another option to speed up processing, is to use batch type and add only a smaller set of DocDef from your project to use. This way you do some presorting ahead of time and processing wise, it has a smaller number of DocDef to deal with.
サインインしてコメントを残してください。