You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tika.apache.org by Chris Mattmann <ma...@apache.org> on 2021/01/13 02:17:00 UTC

Re: [EXTERNAL] Re: Rotation script

Same we used Python long ago b/c we couldn’t find any decent native alternatives

+1 to using a native one

 

 

From: Tim Allison <ta...@apache.org>
Reply-To: "user@tika.apache.org" <us...@tika.apache.org>, "Allison, Tim (US 174B-Affiliate)" <ti...@jpl.nasa.gov>
Date: Tuesday, January 12, 2021 at 6:12 PM
To: "user@tika.apache.org" <us...@tika.apache.org>
Subject: [EXTERNAL] 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 <pe...@torch.ai> 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.