• Failed to import events: Unable to process your iCal/CSV file. (Google, Bing)
• HTTP/1.1 403 Google Calendar doesn’t support storing of “To Do” (VTODO) components (Google, Bing)

It appears as though Google Calendar is choking on both the VTODO and VALARM stanzas within the export file.

VTODO data is easy to remove, as it will appear near the end of the export file.  Find the first instance of “BEGIN:VTODO,” and remove all data beginning with that line and ending with the final “END:VTODO” instance (take care not to delete the “END:VCALENDAR” line, as it will invalidate the export).

VALARM data is problematic, as it is nested within each VEVENT stanza.  Depending on the size of the export file, it could easily contain hundreds or thousands of these.

The fast and dirty solution is to remove these elements from the iCal export file, and then import the “clean” version into Google Calendar.  Note that imported events in the target Google Calendar will no longer contain alarms–these events will need to be updated manually, if desired.

Following is a simple Python script that will remove these stanzas and produce a new file that should import properly.  After downloading, be sure to edit the INFILE variable at a minimum.

Head on over to Code for the latest version (iCal-to-GCal).

It’s worth noting that this script can be used to quickly remove data from any file that contains similarly-formatted information.  Just update the TAGS list accordingly.

UPDATE01: Wondering whether the integration of Tasks into Google Calendar will alleviate the VTODO handling issue?

The problem arises when I’m viewing content on my mobile phone, as the concept of a bookmarklet in any mobile browser that I’ve had the pleasure of using does not exist.  To make matters worse, I’m one of the five or six people on Earth who does not own an iPhone.  So, the surely-pleasant Instapaper apps are dead to me.

For some time, I’ve been using the “Send this Page” functionality built in to my mobile browser to e-mail pages to a mailbox for further processing.  Some simple mailbox rules and a short list of known source addresses make this a viable solution.  Unfortunately, viable is never good enough.

To scratch this itch, I’ve thrown together a small collection of scripts that will:

1. Retrieve messages from an IMAP mailbox (this needn’t be a dedicated inbox–a specific folder, Gmail label, etc. will suffice).
2. Validate senders using a whitelist.
3. Extract things that look and smell like URLs from message bodies (should handle crappy HTML messages, too).
4. Submit URLs to Instapaper.

Surprisingly, it works (for me).  Requires Python 2.5+ (haven’t tested with 3.X, but should work), and an IMAP-enabled mailbox of some sort.

Head on over to Code for the latest version (IPMailer).

The file that you’re looking for is located at /Users/[USER]/Library/Preferences/org.xlife.NewsFire.plist, and is best edited with PropertListEditor.app.

If you want a complete purge, delete the Feeds array, and create a new one in its place.

This tip brought to you by fs_usage -ew | agrep -i 'newsfire;open'.

1. Download video from the camcorder using the Sony-provided HDD Handycam Utility (crap) within a Windows VM.
2. Move videos from the offload directory to ~/Movies/Sony Handycam/Originals on the host system.
3. Send the offloaded .mpg files to VisualHub (MP4, highest quality, H.264 encoded), saving to ~/Movies/Sony Handycam/Exports.
4. Open iMovie and import Exports/* as new iMovie event, allowing iMovie to move files from Exports to ~/Movies/iMovie Events.

Sony: Please stop sucking ass, and produce some useful software for the creative world’s most popular operating system.

Apple: Please stop sucking ass, and build MPEG-2 handling and playback capability into iMovie and Quicktime, respectively.

UPDATE1: About the MPEG-2 component included with iMovie ’08

UPDATE2: After raising a stink, I figured that I’d spend a little more time trying to figure out how to make my Handycam work with native iMovie ’08. Turns out that you have to turn on the camera, wait for OS X pick it up as a USB storage device, and then hang tight for three or four minutes until iMovie detects that your USB storage device is actually a camcorder, and presents the import dialog. I’m glad that I can import native MPEG-2, but am somewhat puzzled by the delay.

1. Frequently fails to wake from sleep. Or, simply gets out of sync with the lid’s open/closed status. Same result: Useless computer.

After closing the lid, the system consistently goes to sleep properly. Upon opening the lid, however, the system may or may not come back to life. When it doesn’t wake properly, it will sometimes respond to gentle prodding: pressing and holding down a key, or pressing (but not holding down) the power button.

I’ve also had some success with outright trickery: I’ll close and then immediately re-open the lid, in which case I can catch the password prompt (which appears when the lid is closed?) before it disappears.

2. Hotkeys for Expose and Active Screen Corners up and disappear.

Just what it says. They all reset to inactive. I change the settings, and they work just fine . . . until they don’t.

It should be noted that this doesn’t happen particularly often. And occurences don’t necessarily coincide with PRAM/SMC resets, software updates, etc.

3. I’m not prompted for a password when the system wakes from sleep.

Yes, the box to require a password when waking from sleep is checked. No, I haven’t recently reset PRAM or SMC. And no, it doesn’t happen often (twice now, in as many months). It can be fixed by rebooting the system.

Despite the frequency, this issue is terrifying. Not because the screen saver password is particularly useful from a security standpoint (it discourages lurkers, but doesn’t address data loss as a result of theft). It’s terrifying because I no longer trust OS X to honor my preferences, security-related or otherwise.

Forums are rife with folks suggesting that maybe affected users aren’t letting the screensaver activate (I am), or that the system isn’t truly sleeping (it might not be, but the LED on the lid release indicates that it is).

And that’s all for now.

In lieu of a review, I thought it would be useful (and fun) to document my past and present workflows, and explain the reasons for my move in light of this evolution.

The Beginning

For years, my workflow consisted of a relatively simple multi-application process:

1. Import photos into a hybrid date- and event-based folder structure (YYYY/MM_EventName) using Windows XP’s Scanner and Camera Wizard
2. Open Picasa and review photos, deleting the crap
3. Make any drastic cosmetic adjustments using the Gimp
4. Make adjustments to exposure, contrast, and sharpness using Picasa
5. Upload to [some sharing site] using [some sharing site]‘s crappy web-based upload interface.

Of course, for years, I was shooting with one of two point-and-shoot cameras and dealing exclusively with JPEG output. I also wasn’t applying keywords, copyright/credit, or any other metadata to my images. I was shooting, filtering, uploading and never looking back.

In early 2007 I purchased my Canon EOS 400D, and out of necessity this workflow changed (albeit not much):

1. Import photos into a date-based folder structure (YYYY/MM/YYYY-MM-DD) using Canon’s EOS Utility
2. Open Canon’s ZoomBrowser to review photos, deleting the crap
3. Make basic adjustments to exposure, contrast, and sharpness within ZoomBrowser, then export adjusted images as JPEG files
4. Make any drastic cosmetic adjustments using the Gimp
5. Import photos into Picasa and apply keywords*
6. Upload to [some sharing site] using [some sharing site]‘s crappy web-based upload interface.

I was still using close to the same number of applications within my workflow, but on account of the JPEG export and keyword application, processing even small groups of photos was now eating up a significant chunk of my time. There had to be a better way.

Around the middle of 2007, I started shopping for a software solution that I could use to optimize my workflow and buy myself a little more free time.

The Requirements

In order of importance (descending):

• Built-in image acquisition capability, with a configurable file and folder naming mechanism
• Support for all common RAW file formats
• A robust image editing and adjustment capability (the latter being more important, but the former being important enough that a good editing or touch-up capability could be the deal-maker for one application).
• Crazy support for metadata manipulation
• Ability to re-locate images on disk
• Ability to move originals into and out of the application’s library as needed
• Ability to take images off-line, while maintaining the ability to search for or browse the same
• Ability to create dynamically updating albums based on image metadata
• An extensible export mechanism, so that images can be submitted to on-line services without having to export JPEG or TIFF files first
• An interface that takes advantage of multiple displays when available
• Full-screen editing

I certainly didn’t pull this list of requirements out of thin air. I’d seen my share of photographic workflow software reviews, and I more or less knew what features were available. I just didn’t understand how similar features compared across applications, nor did I know which application was most likely to meet my requirements.

Lik many an amateur photographer before me, I quickly narrowed the field to two applications: Adobe Lightroom and Apple Aperture.

The Skinny

Both applications support–to varying but satisfactory degrees–all of the features on my must-have list. And I saw this coming. Both applications were designed by companies with a rich history of support for visual artists. Thus, my decision would be made based on the details of each feature’s implementation, and the overall polish of the applications, from the look and feel of the interface, to the performance and customization provided by import/export facilities. On to the high points . . .

• Lightroom is useable on a dual-display system, but lacks the interface customization provided by Aperture.
• I actually prefer Lightroom’s default screen configuration, but have since come to love the Aperture interface (more on that later).
• Both applications have adequate image editing and adjustment capabilities, and both perform these tasks in a completely non-destructive manner. That said, Aperture’s full-screen editor and heads-up displays blow away the best that I’m able to get out of Lightoom.
• The Lightroom interface is definitely more responsive than the Aperture interface. Select an action within Lightroom, and that action takes place. Right away. Whereas Aperture will occasionally present you with a pretty, spinning wheel. It’s not a drastic difference, and a little extra memory makes it (almost) a non-issue, but it’s worth mentioning.
• Aperture makes management of original images a little less painful. If you’re in a terrific hurry, you can import your photos without regard for their destination on disk, and very easily re-locate them after the fact. I was somewhat disappointed with (or scared by) Lightroom’s affinity for its library. I don’t recall exactly what it was that turned me off, but I do remember feeling guilty for attempting to store my images outside of the library.
• Both applications provide an extensible export facility, and both enjoy an energized user base that’s willing to devote time to plug-in development.
• Both applications have powerful metadata manipulation, although I’m partial to the way that Aperture presents metadata groupings and allows for the definition of presets.

The Verdict (I know: The article title is a spoiler.)

Both applications more than meet my needs, but I find that Aperture is better suited to true workflow optimization. Don’t get me wrong: Lightroom is workflow. But it’s Lightroom’s workflow, not my own. And while all of my technical requirements are met by Lightroom, being able to access any of the application’s features from any point within the creative process is a huge win for Aperture. Directly related to this point, Aperture’s interface can be very quickly customized to the point that almost any portion of the interface that meddles with the desired workflow can be cast aside, never to be seen again.

The other win for Aperture is the tight OS X and iWork/iLife integration. Being able to call up Aperture albums within iMovie, Keynote, and iDVD is huge. I can organize all of my images just the way that I want them to appear in an exported product, and keep those albums in my proverbial hip pocket until I need to drop them into a media project. And when I want to make that addition, it takes seconds, and I don’t have to context-switch away from the application on which I’m focused. My initial goal was time savings, and time savings external to my imaging workflow application are as important as the time savings that I enjoy while manipulating the images and library itself.

Summary (For the impatient)

Both applications are capable, and both have their strengths and weaknesses. A lot of the traits that Lightroom users love, Aperture users dislike (or despise), and vice versa. In my opinion, it comes down to control. Some users like the fact that their workflow is neatly defined and enforced by their software, whereas others prefer that their software get the hell out of the way, so that they can do as they please. I definitely fall into the latter category, and Aperture very much suits my need for an application that provides me with the functionality that I require, when and where I require it, and otherwise fades into the background while I work.

—-

* You can apply keywords to RAW files within ZoomBrowser, but these keywords don’t survive an export–they’re only useful as long as you’re using Canon’s image browser.