• “Next up, a cure for cancer.” — ubercurmudgeon [Ars Technica]
• In 1937, F. Scott Fitzgerald made the equivalent of $485,894.64 [Wikipedia+Wolfram-Alpha]
• “Tracing The Office’s Rise From Midseason Also-Ran to Nine-Season Behemoth” [A. V. Club]
• How to import .eml files into a Maildir [Paul Sinnet’s Blog]
• “You’ve managed to go a thousand centuries without your head getting crushed under the back wheels of a bus. Kudos.” — Sahasrahla [reddit]

We live in an age of exceptionally cheap storage. Right now, I can buy an external hard-disk 2TB in size for £70. As such, storing a large amount of almost any kind of file isn’t really an issue.

In light of that fact, running any sort of optimisation that results in savings of less than one percent of your total hard-disk size might seem unnecessary. It probably is unnecessary, but having grown up with computers where the hard-disks were initially measured in the tens of megabytes, I haven’t quite been able to shake the feeling that every byte that can be saved should be saved. (It’s likely there’s also a certain element of technical vanity involved too.)

One of the ‘easy’ targets of this optimising impulse was my iPhoto library. Using jpegoptim, it’s possible to reduce the file-size of images without any loss in quality.

My iPhoto library started 14.3GB in size,¹ and seemed like it could benefit from a little optimisation. It also seemed easier than trying to sort through them. As with all endeavours like this, it also offered a great opportunity to learn a bit more about using a cornerstone *nix tool — in this case, find.

How to Do It

Before You Even Think About Starting

The optimisation process itself is lossless — file-size savings come from re-organising the Huffman tables within the images rather than reducing their quality, but you need to make sure you have at least one known-good backup of your iPhoto/Aperture library before proceeding.

This command shouldn’t result in any data loss, but it does overwrite the original images with the new, optimised copies, so there is the potential for data loss.

So, before going any further, make sure you have at least one backup because I accept absolutely no responsibility if this backfires horribly and wipes out your photo library/ies. You do this at your own risk.

Also, make sure you don’t have iPhoto or Aperture running when you carry out the optimisation. It probably won’t cause any problems, but I’m not sure, and it seems sensible not to have it accessing the photos as you’re attempting to optimise them.

Pre-requisites

Now that you’ve got a known-good backup in place, you’ll need the following two tools:

• A version of find

  I’ve tested this using Mac OS X’s built-in (BSD?) find, and the version of find that comes as part of the GNU findutils package. Both work equally well for this, and both accept the same syntax.

• jpegoptim

  If you’re brave, you can install it from source.

  If you’re lazy like me, you can install it using MacPorts, which I use for all my package management.

Where You Need to Be

To optimise your iPhoto library — and only your iPhoto library — you need to be inside its bundle. (If you run with from the root of your home directory, you’ll optimise every image it comes across in there.)

Assuming you have your library in the default location, this is really straight-forward: just cd into it, like so:

cd ~/Pictures/iPhoto\ Library/

(For your Aperture library, just type Aperture instead of iPhoto. If you wanted to carry out the same optimisation on photos in your Dropbox, cd into it and run the command — it’s designed to be ‘location agnostic’.)

The Command Itself

Now that you’re in your iPhoto library, simply type the following command into your shell and hit enter:

find . -iname '*.jp*' -exec jpegoptim -opv {} \;

The command contains several parts:

• find . -iname '*.jp*'

  This part invokes find to recursively locate files within the current directory (and its subdirectories) of any name (the first ‘*’) with extensions beginning ‘jp’, which means find will pick up both .jpg and .jpeg files.²

• -exec

  This simply tells find to pass any matching files to the following command.

• jpegoptim -opv {} \;

  This invokes jpegoptim to optimise the images. The following flags (o, p, and v) tell jpegoptim to carry out the following actions on the images it’s processing:

  • o - overwrite original image with the new, optimised image;
  • p - preserves file modification and creation dates;
  • v - verbose, so reports after each file is optimised, and by how much.³

  The trailing ‘{} \;’ is required by the find command to operate correctly on the images being passed to jpegoptim: {} is replaced by the filename, and the \; is the escaped terminating ; character, required to tell find there are no more commands to be executed.

The command itself can take anything for several seconds to several hours to run, depending how many photos it finds. You can keep working on other things whilst it does it, though your Mac might get a little warm on the bottom as it’s working, and your hard-disk will be active almost constantly.

The End Results

My iPhoto library:

• Size before: 14.30GB
• Size after: 13.69GB
• Size saving: 0.61GB
• Percentage saving: 4.27%

A friend of mine is a much more enthusiastic photographer than I; the combined size of his iPhoto and Aperture libraries was 41.72GB without any optimisation.⁴

The results of his optimisation:

• Size before: 41.72GB
• Size after: 40.70GB
• Size saving: 1.02GB
• Percentage saving: 2.44%

Conclusions

I can’t explain why Iain’s optimisation, on a percentage basis, was less successful than mine. The best idea I have is that some cameras produce more optimised photos than others; Iain’s photos were taken with better cameras than mine, so it’s possible that higher-end equipment does a better job of optimising the photos on the fly.

Purely in terms of space saved, it probably isn’t worth it unless you’re on a relatively small SSD where each gigabyte saved represents a more substantial percentage of your total storage. If, like me, you’re constantly battling to find more space, then it also becomes worth it, especially if you have a truly massive library. And the final benefit is that it reduces the upload time and space used if you backup or sync your library to your Dropbox, where space is definitely at a premium.

An incisive and succinct re-stating of a long-winded, self-indulgent blog post. That the title perfectly captures the pomposity of the original whilst also being laugh-aloud funny makes this just perfect.

On a phonebox on the corner of Golf Rd., Bieldside, Aberdeen.

Can’t say I disagree with the sentiment.

This tutorial, if it can be called such, presupposes two things: you see some value in version control of your blog,¹ and that you’re relatively comfortable in the shell. I’m not going to make any effort to persuade you that this is worth your time, and I’m not going to make any effort to teach you how to use git. There are lots of great tutorials, written by people much smarter than I, which will do just that.

Whether it will be useful for your workflow will depend on your workflow. If you only ever write posts in a web-based post editor, it’s almost certainly useless to you; it will only work if you write locally, using a text editor of some description, and save it locally. It works to a certain extent if you work on files in your Dropbox, but you’ll still need access to your computer to carry out the commits (unless you use the script below).

Another, easier, option for Mac users is to use iCloud and Mac OS X’s built in versioning. I avoid this option personally because it doesn’t give me the control I want and because, conceptually, I’m inured to a files-in-directories mindset. For my own comfort, I need to know where the files are; “they’re in iCloud” is too nebulous and fuzzy a concept for my mind to comfortably grasp.

Setting up a git repository for your blog posts is the same as for your programming work:

1. cd into the appropriate directory;
2. git init;
3. git add --all (this is the lazy way of doing it, and saves the hassle of adding each file individually);
4. git commit -am 'LOL first commit OMFGBBQ'.

Any subsequent changes, additions, or deletions are handled in the usual manner.

This process can be slightly inconvenient if you don’t use a shell text-editor. One way around this is this very kludgey shell script²:

#!/bin/bash 

cd ~/Documents/Blog;
git add --all;
git commit -am 'Automated commit';

I’m almost certain that the above script is a clumsy way of doing this, and there’s probably a way to automate the description to include details of the files changed. The script is also hosted on Github, so you can fork it if you want to, or grab it from there. Alternatively, free to e-mail me to tell me I’m an idiot and explain how I should have done it.

The major downside of this script is that you’ll commit without any premeditation or thought behind it, and your commits have no meaningful description listed — just “Automated git commit” for each and every one. As a result, it makes useful version control much harder. The other potential downside is that it adds everything (--all) in that directory tree every time it runs; it can be mitigated with a few tweaks to your .gitignore_global file.

The overall usefulness of version control for a blog’s posts is probably questionable at best, and may not be worth the effort it requires to implement. It’s likely that roll-backs to earlier versions will never be required, but having the option is never a bad thing. In the year or so I’ve been doing it, I’ve rolled-back twice, but found the real benefit is the discipline it enforces on my otherwise chaotic workflow. More than that, it’s a worthwhile habit, and one I wish I’d cultivated earlier: if I had, I wouldn’t have fallen victim to the major versioning problems I suffered during my last huge project of typesetting a book.

Pitch-perfect, and, best of all, it chimes with my own mean-spirited views on photography and “sharing”.

Via Merlin Mann.

• Fifty Shades of PM
• The PM Who Loved Me
• Ganttraker
• Quantum of AGILE
• A Gantt of Thrones
• The Phantom Stakeholder
• The Stakeholder Strikes Back
• Chasing PMPs
• Withnail & KPI
• The Man in the Iron Triangle