Antonio Diaz Diaz wrote: > I have in the to do list for ocrad a "crop" option, and I am in fact > so impressed with what you are doing that I think I am going to > implement it in the next version (0.15). That would be awesome!
I've also realized that my speed specs I listed were actually all from the 32 bit AMD 3200 (71 ppm). I re-ran the benchmarks on the 64 bit AMD 3200 and got 120 ppm. It's amazing to me the difference, considering the hardware specs are the same, one is just compiled for 64 bit mode. Of course every ounce of speed I squeeze out means less hardware purchases later. > So `ocrad file.pbm --crop 0.0,0.0,0.5,0.5' would process the upper > left quadrant, and `ocrad file.pbm --crop 0,0,500,500' would process > the upper left 500x500 pixel square. > Would the rotate option be applied prior to the crop? I'd hope so... or perhaps have it decided order based on the order you give the option in the command line? > >> Bet you guys never thought ocrad would be used for that, eh? ;-) > > Really no. :-) I'm known for pushing the limits... ;-) I once used custom code + dd + mt + OpenOffice to read 1.5 million MS word documents stored in a proprietary Unix database on tape, and convert them into TIFF files for an imaging system. I found out OpenOffice has a HUGE memory leak when printing from the command line lol. Every 500 conversions I had to do a kill -9 on OOo or I ran out of memory. > > Some day you have to tell me who are you working for. ;-) http://www.hcrimaging.com/ - we scan medical records for hospitals. -Tony I'm also the author of CheckBook Tracker http://freshmeat.net/cbtracker _______________________________________________ Bug-ocrad mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ocrad
