Output image is incorrectly clipped when rotation angle is 90 degrees.

[jeffstearns]

Imagine a document in landscape mode. It is wider than it is tall.

The document happens to have an image with many vertical lines. DeskewService.deskew() decides that the image is skewed by 90 degrees.

deskew() rotates the image by 90 degrees, producing a portrait image. Unfortunately, it writes this image to an output document in landscape mode.

Thus a portrait image is now clipped to the dimensions of a landscape document.

(I did some trial-and-error editing of GraphicsService.rotateImage() but didn't stumble upon a fix. I'm a complete newbie with openCv and PIL, so this should be no surprise.)

I attached the input and output images.

Please let me know how I can help! thanks

[JPLeoRX]

Well... Let me see what I can do about properly rotating the image from landscape to portrait modes. Yes, the behaviour you're experiencing is because the rotate method is usually expected to work with values in -10 to +10 degrees range, so it preserves the original width/height of the input image, in your case - landscape mode dimensions.

I need to point out one more issue - the images you provided are not really fitting for this deskew method, I was aiming to build this for text-based pages, like PDF scans of documents and etc. Nevertheless I'll try to fix the rotation problem that you described.

[jeffstearns]

JPLeoRx - Thanks for your interest. I completely understand that deskew() isn't intended for graphic images.

I'm working on a driver for my Fujitsu ScanSnap document scanner. It's a great piece of hardware, but Fujitsu abandoned the Mac driver several years ago. The hardware works well, so I've been working on a driver of my own. Everything is implemented except deskewing. I've tested 4 or 5 different deskew implementations, and yours is the clear winner. It's faster than most, generates clean output documents, and usually produces images that are aligned within a degree or so.

I scan a variety of documents with varying amounts of text and images. Pages are intermixed, and occasionally include a page that's very graphics-heavy. It's not practical to selectively turn deskew on and off for individual pages.

Frankly, I'm impressed your code it does so well on my test documents. The image I'm using here is the most severe test of all. The only hiccup I've seen so far is this bug that causes data loss.

thanks again!

[JPLeoRX]

When testing with your original image I cannot reproduce the 90 degree skew angle calculation, on my local machine opencv estimates the angle of your image to be 0.93.

But regarding the rotation issue - I can reference you to another project of mine, https://github.com/JPLeoRX/tekleo-common-utils, this is a somewhat shared codebase for various commonly used methods. I've just added an OpenCV section into it.

If you go to this script and look at rotate method you can now decide what rotation approach to use - either bounded to your original image size, or free rotation that will change your image dimensions to fit the whole rotated contents of the image. I hope it will be easy to integrate this solution into your code.

I'll also update the original opencv-text-deskew project to use this shared library

[jeffstearns]

JPLeoRx - Thanks for your suggestions.

It's strange that our two computers calculate such different angles.

For the record, I'm using an up-to-date Mac with

• Python 3.10.2
• Pillow-9.0.1-py3.10
• opencv_python-4.5.5.64

Double-checking the versions of the underlying libraries:

%cat site-packages/PIL/_version.py
# Master version for Pillow
__version__ = "9.0.1"

%cat site-packages/cv2/version.py
opencv_version = "4.5.5.64"

This is the input image that I uploaded:
>>> from opencv_text_deskew.services.deskew_service import *
>>> imageCv = GraphicsService().openImageCv('/Users/jps/tmp/floorplan.jpg')
>>> angle=DeskewService().getSkewAngle(imageCv)
>>> angle
-90.0

If I make minor changes to the document (by saving it in a different format, for example), the calculated skew angle may be slightly different. But I always get results close to -90 degrees:

This is a copy of the input image with a minor format change:
>>> angle
-89.06080627441406  # Interesting that this is -0.93 away from -90.  Coincidence?

Thanks again for this code and for your help with making it better.

[jeffstearns]

Just fyi, here are some test text documents. They're probably a more realistic test of the deskew code.

I printed a text page on paper in landscape mode.
I then scanned it in a sheetfed document scanner; this introduced a tiny bit of real-world skew.
The scanned image was in portrait mode, as I'd expect from my document scanner.

I rotated the scanned image into landscape mode and saved a copy.

It's interesting that deskew computes a skew angle of (approximately) -90 degrees for both documents. I expect that one angle should be ~-90 degrees, and the other would be ~0 degrees.

I hope they're useful to you. thanks!