>But does the same thing apply in this case? It's not really using all of tess4j. Just 1 package from it
Sorry, I should have checked on this exact point before responding. If it isn't massive and has no native libraries, y, let's go for it. Let me look into it a bit today. On Tue, Jan 12, 2021 at 10:42 PM Peter Kronenberg <[email protected]> wrote: > I sort of see your reasons for not using Tess4j to replace the current > command line calls to Tesseract. But does the same thing apply in this > case? It's not really using all of tess4j. Just 1 package from it > > > ------------------------------ > *From:* Tim Allison <[email protected]> > *Sent:* Tuesday, January 12, 2021 9:11:58 PM > *To:* [email protected] <[email protected]> > *Subject:* Re: Rotation script > > I really like the idea of moving to pure Java for deskewing. We chose not > to use tess4j earlier as a Java binding for tesseract because it requires > native code....[1] > > If we can do it with another call to tesseract from the command line or if > there is a fairly lightweight pure Java, ASL 2.0 friendly image library > that works well, that would be great. > > [1] > https://issues.apache.org/jira/browse/TIKA-2293 > > On Tue, Jan 12, 2021 at 8:28 PM Peter Kronenberg < > [email protected]> wrote: > > I'd been meaning to ask why you calculate the rotation with a Python > script. As far as I can tell, that is the only reason for the Python > dependency, which just adds a little (lot?) more complexity to the whole > project, as well as who knows how much extra overhead there is to make the > Python call. (not to mention, it took me practically a whole day last week > to get all the dependencies working on a Linux system in order to be able > to run Rotation.py) > > But now, I have a more important reason to question this. The Rotation > script does not work very well. I ran it on the attached files. I started > with the straight file and rotated them using Irfanview (15 = 1.5, 25 = 2.5) > Rotation.py returns 0 for the 1 and 1.5 degree file. And it returns 1 for > the 2 degree file. And it seems to always return an integer, or at least > rounded to an integer. > > Here is a simple Java routine which does the same thing and it appears to be > far more accurate. It uses Tess4j > > <dependency> > <groupId>net.sourceforge.tess4j</groupId> > <artifactId>tess4j</artifactId> > <version>4.5.4</version> > </dependency> > > > import com.recognition.software.jdeskew.ImageDeskew; > > import javax.imageio.ImageIO; > import java.awt.image.BufferedImage; > import java.io.File; > import java.io.IOException; > > public class GetAngle { > > public static void main(String[] args) throws IOException { > BufferedImage bi = ImageIO.read(new > File("c:\\Testfiles\\Dickens_skew25.png")); > ImageDeskew id = new ImageDeskew(bi); > double imageSkewAngle = id.getSkewAngle(); // determine skew angle > System.out.println(imageSkewAngle); > } > } > > I've been poking around this code and might actually do the change we > discussed about not doing the rotation when the angle is 0, as well as > allowing rotation even if you're not doing the pre-processing. I'd be glad > to take a look at this as well if you think it's a worthwhile direction. > >
