trick of the week: autocropping

Right… first off, check out the demo in either Firefox or Konqueror (I haven’t tested in IE yet, so can’t be certain that it works there yet (if not, I’ll fix it tomorrow)).

Impressed yet? No? Read the source.

If you are still not impressed, then you are obviously not a web developer :-).

The trick is based on an old CSS trick which I first saw done by Eric Meyer (Curvelicious).

The way he did it was to painstakingly split a curve image into slices, and apply floats to them individually.

At the time, I was pretty gobsmacked – it was a simple idea, but very effective.

However, as time went on, I grew jaded, in that “experienced web developer” way. Nowadays, if it adds any more than a few characters to the source, then I think it is too bloated.

So – here is a way to do the same trick, minus the bloat!

Simply add a class “autocrop” to the image that you want sliced up, and attach a JavaScript that will handle to splitting.

The advantages to this: very little bandwidth wasted, no time wasted by the designer painstakingly slicing the image apart.

Most of the files needed are contained in this archive. Just add a /i/blank.gif image and for IE, Dean Edwards’ ie7 script (for the XMLHttpRequest object).

5 Comments.

  1. Once again, your solution is ingenious. However, I wouldn’t recommend this method for sites with high traffic due to the weight it puts on the server hardware. It could be minimised by using some sort of cacheing of the responses. Of course, this is most likely obvious to you and anyone that’s ever programmed graphics, but I feel like I must point out that get/setPixel-type of functions are *the* slowest methods of accessing image data and gd’s imagecolorat (though highly optimised) is no different in this aspect.

  2. Oh yes, and the demo does work in IE, however it has some problems (IE apparently thinks that the slices’ Z-index is higher than that of the text’s).

  3. Thanks, Markku. I had considered caching, of course, but in the interest of simplicity, left it out of this “proof of concept” – note as well that the script currently assumes the image is a PNG, where a more complete solution would load from generally any format. Also, the script assumes your float is on the left.

    I would be interested to see a faster method to grab the needed colours. I am not proficient with graphical programming, so worked by basically choosing the simplest and clearest route, then seeing what functions PHP provided to match what I needed.

  4. I must say that I’m unfamiliar with the API that GD offers to PHP, but I believe there ain’t no faster way to do what you’re doing. However, we can always cheat 🙂

    First of all, GD is internally highly optimized; currently what you’re doing is reading just parts of the image (I believe it’s because of the speed issue). However, using PHP to resample the image to a “better” size; ie. round(original_img_height / wanted_strip_height) using imagecopyresampled and changing it to grayscale (just interested in the lightness of the pixels? after all, that is what you’re doing manually) using imagecopymerge with a suitable precreated grayscaleimage might speed up things. However, as I said, the method you’ve chosen might just be the fastest method there is… I’d need to do some testing to prove (or disprove) my theory on the effect these changes would have on the speed.

  5. klog » return of the autocropper - pingback on September 26, 2007 at 9:40 am

Trackbacks and Pingbacks:

%d bloggers like this: