I plan to do this myself at some point, but thought Skip (or someone else) might want to beat me to it: Google/UNLV have (re)released an open-source* OCR engine, which they claim is better than any other open-source OCR engine. So it would be interesting to compare the classification with this to that with ocrad. http://google-code-updates.blogspot.com/2006/08/announcing-tesseract- ocr.html =Tony.Meyer * The license is a bit vague, unfortunately. They state it can be freely used/distributed for research/development, and that for commercial use you have to contact the authors. However, they don't cover the middle ground (non-commercial non-research), which SpamBayes falls under.
Tony> I plan to do this myself at some point, but thought Skip (or Tony> someone else) might want to beat me to it: Tony> Google/UNLV have (re)released an open-source* OCR engine, which Tony> they claim is better than any other open-source OCR engine. So it Tony> would be interesting to compare the classification with this to Tony> that with ocrad. Tony> http://google-code-updates.blogspot.com/2006/08/announcing-tesseract-ocr.htm... Thanks, I'll try to take a look when I get a chance. Alas, the SF link is currently giving an Internal Server Error message. (Jeez, what are the chances???) Tony> * The license is a bit vague, unfortunately. They state it can be Tony> freely used/distributed for research/development, and that for Tony> commercial use you have to contact the authors. However, they Tony> don't cover the middle ground (non-commercial non-research), which Tony> SpamBayes falls under. I suppose we ought to contact the authors, just to be on the safe side. Skip
skip> Alas, the SF link is currently giving an Internal Server Error skip> message. (Jeez, what are the chances???) Back now. Downloaded successfully. Tony> * The license is a bit vague, unfortunately. skip> I suppose we ought to contact the authors, just to be on the safe skip> side. Perhaps it's not necessary. The README file says: This package contains the Tesseract Open Source OCR Engine. Orignally developed at Hewlett Packard Laboratories Bristol and at Hewlett Packard Co, Greeley Colorado, the majority of the code in this distribution is now licensed under the Apache License: ** Licensed under the Apache License, Version 2.0 (the "License"); ** you may not use this file except in compliance with the License. ** You may obtain a copy of the License at ** http://www.apache.org/licenses/LICENSE-2.0 ** Unless required by applicable law or agreed to in writing, software ** distributed under the License is distributed on an "AS IS" BASIS, ** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. ** See the License for the specific language governing permissions and ** limitations under the License. The Apache license is fine for our use, right? Skip
skip> Alas, the SF link is currently giving an Internal Server Error skip> message. (Jeez, what are the chances???) skip> Back now. Downloaded successfully. And built successfully, with a couple tweeks. After a bit of juggling, I got the executable into the proper spot, ran it, then got a segfault. Unfortunately, the README file includes this: The C++ code makes heavy use of a list system using macros. This predates stl, was portable before stl, and is more efficent than stl lists, but has the big negative that if you do get a segmentation violation, it is hard to debug. It's certainly not ready for prime time. Skip
Tony> * The license is a bit vague, unfortunately.
skip> I suppose we ought to contact the authors, just to be on the safe skip> side.
Perhaps it's not necessary. The README file says:
This package contains the Tesseract Open Source OCR Engine. Orignally developed at Hewlett Packard Laboratories Bristol and at Hewlett Packard Co, Greeley Colorado, the majority of the code in this distribution is now licensed under the Apache License:
[...]
The Apache license is fine for our use, right?
Sigh. I don't know how I missed that (right at the top of the README), and yet managed to read the bit later on.
And built successfully, with a couple tweeks. After a bit of juggling, I got the executable into the proper spot, ran it, then got a segfault. Unfortunately, the README file includes this:
The C++ code makes heavy use of a list system using macros. This predates stl, was portable before stl, and is more efficent than stl lists, but has the big negative that if you do get a segmentation violation, it is hard to debug.
It's certainly not ready for prime time.
:( Ah, well, it was worth a shot. Thanks for doing the work! When I find some time to do some proper evaluation of the new experimental options, I might try it as well, as see how I go (out of curiosity). Were you building on OS X? =Tony.Meyer
participants (2)
-
skip＠pobox.com -
Tony Meyer