This year I had a few holidays to take. While on holidays, I remembered that earlier this year I've been asked why I don't go to YAPC. That was a good question indeed, but somehow there's never enough time to attend those talks for me, so I usually end up just checking out what people put on Youtube.

This year wasn't an exception and I started watching YAPC::Europe 2016 channel on my holidays. There were quite a few talks I found interesting. I usually tend to skip topics like "Language XYZ for Perl Programmers", but "Go for Perl Programmers" was nice to watch (possibly because I had to look at Let's Encrypt "Boulder" code in Go time to time). Some other topics of interest were:

• A tale of a Perl start-up
• How's the Perl Jobs market
• Symbiosis of Docker and Perl
• A few git bits
• A local search engine using Elasticsearch and Dancer
• 9 PostgreSQL features I wish I learned earlier
• Vulnerability discovery, response and remediation for developers

Among other talks that caught my eye, was the "Imager::Trim" one. Recently I have started to port some code to Windows and in the process I needed to replace the parts which were using GraphicsMagick with something that would rely on Imager, which comes pre-installed with Strawberry Perl. Interestingly enough, the talk mentioned that there was no automatic crop (or "trim") in Imager - that was something my GraphicsMagick-based code was running in a few places. So I've decided to give it a go and run a few images through Imager::Trim.

Unfortunately, I found that it doesn't quite suit my needs, because that seemed to be adding about 5 extra seconds per image to the process which was usually taking less than a second per image. While that would work for some applications, in my case it was a queue with a few hundreds of images per run, so that did not look like a viable option. I also noticed that a few grayscale images in the queue were left unprocesed and that attempting to crop twice (to remove secondary border for example) would fail without re-wrapping the returned Imager object again. That meant that I needed to create something new from scratch, keeping the following in mind:

1. It should be fast enough;
2. It should handle grayscale images;
3. It should use Imager's filters and plugins API;

So, having my "bespoke mode" on, I started with version 1.00. Why 1.00 and not 0.xx? Well, in this case we have a documented and stable API, the interface which is unlikely to change and the code that will stay largely the same and rather compact. So employing sort of Mozilla-like numbering made sense. We start with 1.00, then every significant enough change (such as major performance improvement or adding another module/script) would change the first digit after the dot, while minor improvement would change the second digit after the dot.

Five quick versions later, with a bit of holiday time borrowed, the code of Imager::Filter::Autocrop ended up with a nice number 1.23, which is now available on CPAN and GitHub. Apart from the library itself, it also includes a command-line utility (autocrop.pl) - so crop away!

Do I feel myself robbed of some of my holiday time? Absolutely not! It was actually nice to have this problem solved, especially knowing that this is something I will need quite soon too. It was also fun making it fast enough, and I'm pleased to say that there is no noticeable difference between the code running Imager::Filter::Autocrop and the original bit of code running GraphicsMagick trim, at least for those cases where I need this code to be run.

Finally, I enjoyed watching YAPC talks. I also believe that talks similar to Imager::Trim one are quite benefitial for the Perl community - they highlight specific issues (such as lack of particular feature in some libraries) and serve as an incentive to try to come up with new solutions.

P.S. I guess one day I should attend YAPC in person anyway :)