If all else fails, you can use Imager, and the ->getwidth, ->getheight and ->getpixel methods to read the image pixel by pixel to find the leftmost non-alpha pixel and the rightmost non-alpha pixel (and top/bottom), and then use ->crop to crop the image.

Handwavy outline.

• Use Imager to load the image
• Start at the top row. Assume the width of the transparent extent for both left and right is the width of the image; similarly the top and bottom is the height.
• Walk each row and find the length of the transparent extent to the left and right
• If that length is less than the current maximum, remember it as the new current maximum
• At the same time you're going to want to look and make a similar determination for the extent in each column
• After you've walked down each row you know the width of the left most and right most transparent chunks; so crop horizontally from there over. And you should also have the vertical extents as well.

The other two answers are good (and way better than my approach), but I'd share my thoughts anyway.

As .xpm data is extremely easy to analyse, I'd do

$ convert -transparent-color Black file.png file.xpm
[download]

Where Black should be replaced with a color not in the image. Then analyze the .xpm and use that to crop the image.

To be completely dynamic, you can repeat the process for Black, White, and Red and take the minimum margins of the three analises.

PDL might be a faster way to implement the approach Fletch suggested.

Intriguingly, there's no cropping type functionality in core PDL. A bit of a ponder suggests a good approach would be to (for rows), assuming an image of (rgba,x,y):

$non_blank_rows = ($img->slice('(3)') != 0)->orover;
($low, $high) = $non_blank_rows->which->minmaximum;
[download]

Then do the same for $img->xchg(1,2) for the columns, and hey presto, there's your bounding box!

It turns out that making this broadcast properly over multiple images was impressively hard.

which had a hardcoded limitation that it would only work on a 1-dim ndarray (fixed by imitating PDL::VectorValued's strategy of having a "how many set for each vector" output ndarray).

Then actually using that with minmaximum also posed a problem, since the number of values per image might vary (in other words, the outputs might be ragged) - fixed that by having which fill the unset index-values with -1, and then setting that as the badvalue for the output ndarray, so minmaximum would ignore them.

After that, the rest was easy! The new PDL::Image2D::crop works on a mask, so the above snippet would call

$x1x2y1y2 = ($img->slice('(3)') != 0)->crop;
[download]

I would say an OpenCV interface for PDL is pretty imminent / at the "prototype" stage right now!