kiniry / straightener Goto Github PK

Example 1 (truncation):
$ python straightener.py test1.tif
Actual results: test1-unrotated.tif has timing marks on left and right sides 
cropped.
Expected results: nothing was cropped.

Example 2 (no truncation):
$ python straightener.py test2.tif
Actual results: test2-unrotated.tif is same as test2.tif, with nothing cropped
This is as I expected.

What is the intended behavior?  Why is this inconsistent across the two images? 
 Seems like test2.tif is handled correctly, and handling of test1.tif is a bug: 
what do you think?

I couldn't figure out how to get -g to output graphs.

After running python straightener.py -g test1.tif I could not find any output 
that provides graphs/visualizations of the lines found.

From the source code it looks like maybe it is intended to write to 
./binary_test1.tif and ./lines_test1.tif, but those files were not created.  
Pilot error?  Incomplete documentation?

In order to built a Python wheel for the straightener, I have to change the 
line in setup.py:

from distutils.core import *

to:

from setuptools import setup, Extension

without it, "setup.py bdist_wheel" will not work.

Here's a more extreme example of over-cropping:

$ python straightener.py test4.jpg
Expected output: test4-unrotated.jpg would look very much like test4.jpg 
(possibly slightly rotated)
Actuall output: yikes, almost all of the image has been deleted

Currently, when saving the output as PNG, the output file is quite large, 
seemingly larger than necessary.  For instance, ImageMagick can compress it 6x 
better than OpenCV.

Example:
$ python straightener.py test5.png
$ ls -l test5-unrotated.png
-rw-r--r--. 1 daw daw 5767409 Feb 11 18:31 test5-unrotated.png
$ convert -quality 50 test5-unrotated.png test5-unrotated-IM.png
$ ls -l test5-unrotated-IM.png 
-rw-r--r--. 1 daw daw 948592 Feb 11 18:32 test5-unrotated-IM.png

A plausible enhancement would be to pass appropriate options to OpenCV to get 
it to save the file more efficiently.  This may improve performance, because 
not as much data has to be written to disk.

However, this may not be so easy to implement, and it seems low priority.  I'm 
reporting this here only for future reference, in case we ever want to re-visit 
it in the future.

It looks like the main source of difference in file size between OpenCV and 
ImageMagick (at least in this case) is that OpenCV writes the file as color, 
whereas ImageMagick automatically detects that the image can be written as 
grayscale without loss of fidelity.  This seems to significantly shrink the 
output file.  It's plausible that one could write extra code to check for this 
case and then instruct OpenCV to write as grayscale if that wouldn't coss any 
loss of fidelity, but this would take additional work and may not be worth the 
effort.

I also checked whether differing compression levels might be responsible for 
this, but I don't think it is relevant.  (ImageMagick "-quality 50" seems a 
reasonable tradeoff; this corresponds to compression level 5 and no filtering.  
But setting aside the grayscale optimization, compression level doesn't make 
much difference for this example image.)  More recent versions of OpenCV may 
provide a way to control the compression level, e.g., along the following lines:

-     cv.SaveImage(outName, img)
+     cv.SaveImage(outName, img, [cv.CV_IMWRITE_PNG_COMPRESSION, 5, 0])

But this isn't supported in current OpenCV.  And in any case, the compression 
level doesn't seem to be the cause of the large output files, so this is moot 
anyway.