Batch autocrop images to fixed size?

[Karyudo]

Well, that's disappointing: this single (if lengthy but elegant) line of IM script worked well on exactly one image before I hit problems again. The next image I tried has a little piece of white lint on the black background, and of course it gets included as part of the image worth keeping, so the crop is wrong.

Fundamentally, this solution isn't implementing the sort of algorithm that a human would, which is why it fails on things a human wouldn't. This is also why I really wanted to see a solution that uses Hough lines. It sure seems like the only way to ensure the deskew, de-perspective, and crop operations are done correctly is to find a reasonable bounding box of four lines, then do everything wrt their intersection points. Just like a person would.

I kinda want to just "Shut up and take my money!" this: I'd pay to have this solved in a few hours by somebody who's already good at IM, rather than stumbling along for weeks through frustrated forum posts and experimentation. I don't even need to have exclusive access—if a solution were good enough, I'd want it available for anyone else to use or build on.

[fmw42]

Likely issues are if you have to shave more bright areas from your background or increase the fuzz value. Perhaps you can post the new image that has trouble and I can review.

The problem with hough lines is that you often get too many lines. How do you automatically decide which to use.

Did not snibgo provide a solution for the line intersections? Sorry I am on a Mac and not Windows, so anything I coded would not help.

[Karyudo]

This is an image that gets cropped poorly: https://www.dropbox.com/s/hzufilf9ndz2tuq/E10250_0.jpg It's that speck up in the top left that messes with the result.

I figure it'd be better to worry about the problem of too many Hough lines once actually having too many Hough lines is the problem—and that only after the problem of what to do with even the exactly correct number of Hough lines is solved.

I could imagine that perhaps choosing very long thresholds for line length might help? Or perhaps it would make sense to deskew first? Maybe that's all irrelevant: I figure maybe I don't have to care how many Hough lines there are; only that they all intersect at (or very near) one of only four points that are within maybe 100 pixels of one of the corners of the image? [Edit: In a first attempt, I got six Hough lines more than 200 pixels long for the above sample image, and only four intersections of the six Hough lines I got above are in the corners, as expected.]

Anyway, it seems sort of pointless (haha) to worry about getting exactly four Hough lines before a workflow solution for at least the idealized case is found.

As for the code from snibgo, as nice as it may be, I (personally) don't know how to take that .bat snippet for finding the intersection of two lines and turn it into a function that takes .mvg as input and returns four intersection points for additional IM processing. That's where I see it being smarter to commission a complete solution from someone who already knows what they're doing.

In any case, I certainly can't imagine I'm going to have the problem that topRenu has in his ANPR (automatic number plate reader) implementation (viewtopic.php?f=1&t=34098).

[fmw42]

Since you have some noise in your background, we can modify the process by using -mophology or other denoting methods and get the crop coordinates. The start with the original and crop using the crop coordinates. So try this

Code: Select all

magick "sample1.jpeg" -background "gray(60)" -deskew 40% +repage -write mpr:img \
-morphology open octagon:2 -fuzz 35% -set option:cropbox "%@" +delete \
mpr:img -crop "%[cropbox]" +repage -shave 5x5 "$sample1_result.png"

magick "preview.jpeg" -background "gray(60)" -deskew 40% +repage -write mpr:img \
-morphology open octagon:2 -fuzz 35% -set option:cropbox "%@" +delete \
mpr:img -crop "%[cropbox]" +repage -shave 5x5 "preview_result.png"

[Karyudo]

OK, that was a little hard to parse, but I think I got there in the end. That result looks pretty great. I fiddled just a little, and am now using:

Code: Select all

magick "image_0.jpg" -background "gray(60)" -deskew 40% +repage -write mpr:img \
-morphology open octagon:2 -fuzz 35% -set option:cropbox "%@" +delete mpr:img -crop "%[cropbox]" \
+repage -level 12%/100%/0.95 -shave 3x3 "image_0_processed.jpg"

Now, how does one go about batch processing a whole directory full of images, or even a whole directory of directory of images? I'm assuming this can be done with BAT files or PowerShell—can you recommend a good, practical example someplace that I can crib from (complete with issues like "the convert issue" that's mentioned at http://www.imagemagick.org/Usage/windows/ already solved in the code)?

[fmw42]

You are using Unix syntax above. I thought your were on Windows, unless you are using Win 10 Unix. If so, then

Code: Select all

create a new empty folder to hold the output (new_folder)
cd current_folder
for img in *; do
magick "$img" -background "gray(60)" -deskew 40% +repage -write mpr:img \
-morphology open octagon:2 -fuzz 35% -set option:cropbox "%@" +delete \
mpr:img -crop "%[cropbox]" +repage -level 12%/100%/0.95 -shave 3x3 \
"path/to/new_folder/$img"
done

[Karyudo]

Heh. I actually did use Windows syntax (i.e. I took the "\" off the end of each line to make it one long command), but edited it back for the post so that it didn't need a horizontal scroll bar.... I hope that doesn't mean some of the stuff in the middle that I don't quite understand (e.g. the "%@" and mpr:img parts) isn't actually being used like it should be?

I'll see if I can translate your Unix "pseudocode" to .bat or .ps1.

[fmw42]

If you remove the \ and keep as one long command line it should be fine. My code is actual bash scripting code and not pseudocode.

[snibgo]

Now, how does one go about batch processing a whole directory full of images, or even a whole directory of directory of images?

You could put it in a for loop that you paste as a single line into a console window, but I suggest a BAT script. I assume you want to process all the files in the currect directory, writing outputs to a subdiirectory called "newdir". Don't forget to double "%%" for BAT syntax. I find scripts easier to understand when chopped into logical lines. Something like this:

Code: Select all

md newdir

for %%F in (*.*) do magick ^
  "%%F" ^
  -background "gray(60)" -deskew 40%% +repage -write mpr:img ^
  -morphology open octagon:2 ^
  -fuzz 35%% -set option:cropbox "%%@" +delete ^
  mpr:img -crop "%%[cropbox]" +repage ^
  -level 12%%,100%%,0.95 ^
  -shave 3x3 ^
  "newdir\%%F"

Your "-level" syntax is wrong. The docs http://www.imagemagick.org/script/comma ... .php#level say the elements should be separated by commas, not slashes.

If instead you want to process all subdirectories, see "help for", but it's a bit trickier as "%%F" will also contain directory names, and the subdirectory "newdir" will also be processed, which you probably don't want.

[Karyudo]

Thanks, snibgo, that should save me hours of trial and error later today!

Your "-level" syntax is wrong. The docs http://www.imagemagick.org/script/comma ... .php#level say the elements should be separated by commas, not slashes.

Somebody should tell IM, then, because slashes work! (I looked up the syntax the other day, and then couldn't remember whether it was slashes or commas. Tried slashes first, they worked, so I left it....)

[snibgo]

Somebody should tell IM, then, because slashes work!

Yes, IM is generally lax about checking syntax. This is a nuisance, because a script that works today might break next week or next year when the syntax-checking becomes tighter. It is wisest to do what the docs say, even if something else works.

[Karyudo]

Yeah, I've already corrected it. I had to test whether the results came back the same, anyway, and I only have the one instance, so it's not onerous to get it right.

[fmw42]

I do not think Canny/Hough lines will work that well. It is too hard to tune to avoid too many similar lines. I spent some time and finally got it down to 4 lines, but they will not crop well even if you get the line intersections as you can see from the lines drawn.




Unix syntax

Code: Select all

convert  sample1.jpeg  \
\( +clone -canny 0x1+10%+90% +write sample1_canny.png \
-background none -fill red -stroke red -strokewidth 2 \
-hough-lines 9x9+130 \) -composite sample1_hough.png

For windows, replace end of line \ with ^ and remove \ from before ( and before ).

Canny:




Hough:



Scripting to get line intersections is possible, but is OS dependent and I only script Unix bash.

Feel free to vary the hough parameters to see how you get more similar lines (due likely to the aliasing/stair-stepping of the canny line edges due to rotation). Larger thresholds remove longer lines. So you need to make the threshold just right to keep only the main edges. But as you can see this does not catch the right edges.


It turns out better if I do the -deskew first, but you need to use a background color close to your scanning background.

Code: Select all

convert  sample1.jpeg  -background "gray(60)" -deskew 40% \
\( +clone -canny 0x1+10%+90% +write rectangle_canny2.png \
-background none -fill red -stroke red -strokewidth 2 \
-hough-lines 9x9+130 \) -composite sample1_hough2.png

Canny:




Hough:


But the threshold still needs to be just right.

However it is possible that using the accumulator value to get the 4 longest lines may allow one to relax the threshold.

[snibgo]

As I understand it, "-hough-lines" works by trial and error, in increments of one degree. So the error could be up to 0.5 degrees. The error in Fred's example labelled "Hough:" is about 0.46 degrees.

[fmw42]

The hough transform transforms the image into an accumulator array at distance from the top left to any line and in 1 degree increment, so it is of dimensions diagonal x 180 degrees. To find lines it searches the accumulator for high density regions. So snibgo is correct in that the accuracy is limited to about +-0.5 degrees. But visually, the results I have presented after deskew, seem to match the edges of the image acceptably in my opinion. The key here seems to be the deskew and using a background color that closely matches the color of the scanning background so that no new strong edges are created by the deskew.