Although the main core of my workflow has drifted back to MediaPro, I still tinker with Aperture and Lightroom. I’ve stopped importing my DNG files into them but, somewhat perversely, I do still import my finished derivative files. This lets me play with things like slideshows and book generation without worrying about the conversion issues for my DNG files (in the case of Aperture).
As Apple release Aperture 2.0 this morning, I thought I’d download the trial version and play with it. There was a new feature (out of the 100 they list) that brought a smile to my face:
Reconnect override
Aperture 2 lets you “force-reconnect” images in the Managed Referenced Files window. Reconnecting to master images on a different drive is normally restricted to files that match in name, size, or date. If for any reason these attributes change in a way that makes normal reconnection impossible, you can hold down the Option key to force Aperture to reconnect to your masters.
Woo! This fixes a particularly stoopid gotcha in Aperture 1.5 - if you import images as referenced masters and then modify the metadata in the referenced master (say, using MediaPro to sync back a change), Aperture refuses to re-connect to the modified file. This is particularly frustrating and rendered Aperture useless for maintaining a shadow library of images that had externally managed files. At least now, I can force Aperture to reconnect against it’s better judgement.
Another new feature is long overdue too.
Duplicate detection on import
Click the new “Do not import duplicates” checkbox in the Import window, and Aperture suppresses the import of images already in the library.
That’s right. Aperture finally will do duplicate checking. Even better, the duplicate option shows up in the Import Automator action. I’m sure neither of these additions will get much press as they’re not that sexy but they really make a difference to the usability of Aperture. The eye candy is nice (and the simplified interface is an improvement) but it’s the small stuff like this that matters.
So a big “thank you!” to the Aperture development team for these additions.
I’ve had quite a few folks ask me recently about MetaSync. I suspect some of this is driven by the release of Office 2008 and the inclusion of Expression Media in the full package.
Funnily enough, I’ve been tinkering with MetaSync again after a long absence. Towards the end of 2007, I found myself growing dissatisfied with both Aperture and Lightroom in my current image workflow. There’s nothing that wrong with them per se, but I still use ACR in Photoshop CS3 for the bulk of my raw conversions. I did try using Lightroom for a while but I found it got really clunky when some images were offline. For big catalogs, it’s still really not an effective DAM tool at all.
The end result was that I found myself creeping back to iView MediaPro 3.1.3 - it’s not sexy but it doesn’t get in the way of my workflow, gracefully deals with offline media and is DNG-aware enough not to annoy me. It’s the least bad option, if you want to damn it with faint praise.
But of course, if I go back to MediaPro, I need to dust off my old workflow tools. One of the additions to Leopard was a scripting bridge to allow Applescript events to be generated simply from within Cocoa applications. This is an absolute plus for a tool like MetaSync, which relies on a lot of scripting to extract the metadata from MediaPro. MetaSync is currently an Applescript Studio application - adding more features than it currently has means that I either have to write a lot more Applescript (ugh) or write the new features in Cocoa and instantiate the whole thing from Applescript (bleah).
In Leopard, I get to re-write the whole thing in Cocoa. This is a Good Thing. My plan is to start working on MetaSync again fairly soon. Is there interest in making a version work with Expression Media? I can add this if there’s firm interest but I’m not going to write it on spec - I don’t use Expression Media yet (there’s nothing it does that I need).
One application that’s definitely missing from the plethora available for Mac OS X is a small, compact bug tracking tool for small software developers. I’ve used a variety of systems over the years but haven’t ever really been happy with them for personal use. I don’t want a web interface, multi-user options or integration with source control. All I want is a nice, clean database that allows me to keep track of the various problems and feature requests that users have reported. No mess, no fuss.
Because of this, I’ve been tinkering around with Bento over the past few weeks. And, with a little bit of adaptation, it looks like it might be ideal for small-scale bug tracking.
Here’s a list of active bugs and feature requests for RapidAlbum:
And here’s a detailed entry:
The theme that I’m using here is non-standard. The current selection of Bento themes is pretty horrible - it’s geared towards the sort of folks who think that Comic Sans is “cute”. However, if you open the Bento application package, it’s pretty straightforward (if you’re comfortable with a plist editor) to add a new theme that uses muted colors and a reasonable font. This limits the amount of eye bleeding that the current selection of Bento themes induces (what were they thinking?).
Bento also appears to be scriptable altho’ I haven’t started tinkering with that yet (an Automator action for parsing email messages and creating a new bug record would be ideal).
All told, it took under an hour of tweaking and configuring to get Bento set up for my bug tracking needs (and most of that was theme tweaking). That’s not bad at all.
I’ve just posted the latest minor release of RapidAlbum for download. You can pick up a copy here.
This version mainly fixes some annoying niggles and nits that users have reported. The big change is that RapidAlbum now creates empty metadata fields for all of the default IPTC and EXIF tokens if they’re not present in the image file. This means that you can edit and display information for images even if it’s not present in the original metadata - useful if you’ve got an album full of odd images.
Enjoy!
I’ve finally released a full version of RapidAlbum. The 1.0.2 release is available to download right now!
I’ll post more over the next few days about some of the changes in the final version of RapidAlbum. It’s seen some pretty large changes since the initial versions but it’s still fairly close to the original vision that I had for the plugin; a tool for building large photo websites with the minimum of extra overhead.
My thanks to all of the folks who tested and gave me feedback on RapidAlbum. I’ve still got loads of suggestions to build into RapidAlbum 2.0!
It’s been a bit over a month since I shipped the last build of RapidAlbum. Since then, we’ve had Leopard released and a couple of builds of RapidWeaver to fix various weird Leopard-related problems. Things seem to have settled down again.
I’ve cut RapidAlbum over to an XCode 3.0 project. Things went relatively smoothly but I did discover some weird translation problems when moving the old NIBs across to Interface Builder 3.0. Because of that, I’ve decided to cut a private release of RapidAlbum and ask for volunteers to test it before I release it en-masse.
It’s been tested on Tiger and Leopard, seems to be stable and fixes pretty much all the bugs that folks have reported to me (the most serious of which are related to the more complicated templates not working from within Blocks and custom file locations).
If you’re interested in testing RapidAlbum for me, send me some email via the contact page and I’ll point you at the disk image…
Cheers!
I’ve been out of town for the past week and a bit so I’ve a fairly heavy backlog of email and support requests. If you sent me email in the last week, don’t worry - I’ll get to it and get back to you. Might take a day or two tho’…
Cheers!
I was going to wait and cut the 1.0 release for real in a week or so. However, I added a few small new features to RapidAlbum and thought I should probably cut another minor release.
Since the first alpha build of RapidAlbum, I’ve had folks ask if I could add photo sorting to the albums. This is one of those things that is actually trickier to implement than it seems at first cut. I found myself tinkering one afternoon and realized that, due to some changes I’d made earlier, implementing sorting had actually become relatively easy. Hence the addition in the latest build.
I also fixed some fairly easy (and silly) bugs that folks had run across. I’ve broken the HTML internationalization support enough times for me to think that I need to really work on that stuff for the next build release.
Finally, I added templates for the Highslide and SmoothGallery javascript toolkits so that you can build albums based on them. I got a lot of requests for Highslide; although it’s only free for non-commercial sites, it seems to have a lot of fans and was easy to support. SmoothGallery was added because I was looking for a non-Flash slideshow. It’s actually very cool so I’m looking forward to incorporating it into this site…
Every photographer I’ve met has a photographic skill they know lags well behind the rest of their skillset. Me? It’s flash photography. In short, I suck. I was reminded of this a few weeks back when I shot some portraits for a friend. Nothing fancy but awkward lighting. We managed to salvage a few shots but it could have been so much better.
I’ve never been comfortable using flashes and have usually hated the results that I’ve gotten from them. In fact, I’ve gone to ridiculous lengths not to use a flash when it would have made my life so much easier. I’ve played with larger, studio flash setups from time to time (and been happier with the results) but they’re just not practical for a lot of the photography I find myself doing.
However, I stumbled across a website a few weeks ago that totally changed my outlook on this black art. Strobist is dedicated to flash photography using lightweight, very portable equipment. After reading through the Strobist 101 section and looking at the results, I was completely sold.
If you’re a flash-o-phobe like me, I strongly recommend checking out the Strobist website and Flickr photostream. Hopefully you’ll have the same “ding!” bell go off that I did…
I just pushed RapidAlbum 1.0RC1 for download! There are a bunch of changes in this release. As you can probably guess from the RC1 title, it’s pretty close to what I’m planning to ship for RapidAlbum 1.0.
You can grab a copy here -