Browsing Posts tagged Aperture

You know those moments of calm near the end of the movie? You finally relax. Christine the psychopathic car has been fed into the crusher and is just a harmless cube of scrap metal, or the Balrog is tumbling down into the abyss, and the hobbits are safe. While the credits haven’t yet begun to roll, you’re already thinking about the best way back to the car, maybe so you can nip into Bar Italia or back past that interesting-looking pub you noticed earlier in the evening. Maybe you will be allowed that pint after all? A nice cosy feeling, isn’t it? And then, all of a sudden the beast springs back to life. Well, with Apple barely able to give Aperture away at half price, its market share evaporating with the deafening silence about its future, suddenly it’s on your tail, growling furiously. Did you spill your popcorn?

I was a bit surprised, certainly by the timing, but only the week before it was released I had been mentally drafting a post asking where – if anywhere – Aperture 3 might go. My guess was that it might look for space upmarket by offering multi-user capability. After all, Aperture and Lightroom users struggle when more than one person needs to work on a shoot. Alternatively I wondered if they might try to break out of the ghetto and attack Adobe on both fronts by going cross-platform. Even to a “Mac user through and through” like Richard Earney, being limited to Mac is a disadvantage for Aperture users. Being the minority program and then limited to one computer brand means the third party ecosystem is always going to be less extensive – fewer learning resources, fewer plug-ins, fewer friends to learn from, but most of all, fewer sales for Apple. So fundamental changes – going multi-user or cross-platform – were how I thought Apple would try to recover all that lost ground, if they thought there was still money in it.

Neither speculation was right. Instead “one more push” seems to be the strategy – pouring effort into matching Lightroom’s localised adjustments while bolting on a couple of prominent features from elsewhere.

Instability – take the fanboys’ word for it

One thing that is very obvious is that Aperture 3 has been rushed to market and has stability problems. My own experience has not been too bad – my single crash occurred 10 minutes after installing the program – but I’ve heard reports of much worse from Mac-using friends. But rather than rely on hearsay, even a self-confessed Aperture fanboy such as Scott Bourne is “averaging one total Aperture crash every 90 minutes”, as he writes in Very Cool But NOT Ready For Prime Time. Openly admitting his “rooting for Apple and Aperture” bias, Bourne “can’t advise serious photographers to trust Aperture 3.0″.  Also see Rob Boyer The Best And The Worst. Again, a source biassed towards Aperture and Apple has stability problems.

In the “Lightroomsphere” such guys would be beta testers and would have given the program a tough workover well before its release, but it’s obvious that hasn’t happened. It would no doubt run counter to Apple’s culture, but maybe they need beta testers who aren’t yes men?

Adjustments – the big catch-up

The big new feature that any photographer must welcome is that Aperture 3 has now got localised adjustment brushes. They seem to work well, neither better nor worse than those in Lightroom 2. Their naming seems more task-oriented, so Aperture has a “soften skin” brush while the Lightroom user can get the same effect by choosing a negative Clarity value or by choosing a brush preset – called “soften skin”. So Aperture 3 has caught up – it needed to.


A curious aspect of how Aperture 3 implements local adjustments was brought to my attention by Gilles from Utiliser Lightroom. Aperture creates a hidden TIF file for each local adjustment that you apply to an image. Here I applied two brush adjustments to Billy, skin smoothing around the face, and sharpening just around his eyes, so two of these hidden mask files were built. Amounting to 250kb for just two adjustments to one image, these TIFs could soon add up. But the main reason for mentioning them is that they may also explain why Aperture seems to allow only a single application of each brush adjustment on a certain spot, unlike Lightroom where you can brush on the same adjustment again and again – four or five skin smoothing adjustments on the same wrinkles, for example.

There are lots of other minor tweaks in the adjustment area. Presets mean that gullible Aperture users can now be duped into paying for fake film and other special effects. Black and white is still perfunctory, with no ability to split tone, and there’s nothing as intuitive as Lightroom’s wonderful targeted adjustment tool (you can’t help but feel Apple would have found a catchier name for that) for painting global adjustments while keeping your eyes on the picture.

Old problems remain. Richard Earney also points out Apple’s slowness in supporting new cameras, while Gilles tells me that Aperture’s new rendering engine only supports 7 camera bodies.

And Aperture still trails badly in simultaneously making identical adjustments to multiple images. It’s still stuck in the “lift and stamp” or “copy and paste” days – 5 keystrokes compared to the single one needed when you’re working in Lightroom AutoSync’s mode. So in terms of adjusting your pictures, Aperture 3 has barely caught up in terms of what you can achieve, and still lags in efficiency.

Places – yes

Of the other two major new features, the GPS feature “Places” is certainly the more polished. Just like 2 or 3 years ago Microsoft added Virtual Earth to Expression Media, essentially Apple have dropped in Google maps and then written a bit of code around it.

So it recognises GPS data that’s already been added to images and it displays them on a map, while also allowing you to drag images onto a map and storing the co-ordinates. Unfortunately, while GPS data is written into any files exported from the system, it doesn’t let you update the originals’ EXIF information. In many ways it’s much better to geotag in something like HoudahGeo so your GPS data isn’t totally dependent on Aperture but is available to any other program. But overall, I like this feature. I just doubt that it will make anyone move to Aperture – if GPS data is important for your photography, you’ve probably covered that base long ago.

Faces – right idea, cheap-looking implementation

The other big new feature, Faces, has a curious sandy-gravel background which doesn’t match Aperture’s professional appearance and readily betrays its origin in the consumer-oriented iPhoto given away with every Mac. This background shouldn’t even be a preference.

There is significant value in having a tool dedicated to letting the user record who is in a photo and find photos containing that person. iView/ExMedia recognised this need and provided its People field, and it’s a shame that Lightroom 2 provides no other mechanism other than using keywords (what if you don’t want your kids’ names to be in images that may get online?). So I’ve no doubt recording people’s names is a plus for Aperture.

Unfortunately, apart from the gravel, what makes Faces seem such a trivial feature is that it is strapped up to facial recognition. As far as I can tell, you have to let Aperture go through trying to detect faces – you can’t just say “there’s Charlie the Cavalier King Charles Spaniel”, tag those images and move on. But I did like how it auto-completes names by referring to your Mac’s address book or Mail (not sure which, but it’s looking up something from wholly outside Aperture).

In my test the face recognition works well enough, so once I had added Billy Bragg’s name to one photo, it detected him in 7 of the 8 other frames from that day. However, typing in his name would have been a lot faster. Equally, while I also liked how it displayed other faces that it had detected, effectively offering me a to-do list, in practice this was less helpful when a set of pictures showed a crowd and lots of different faces were in-focus. It also managed to suggest that someone I identified in a wedding picture was also in a picture of a horse – so there’s a lot of hit or miss here.

So, while recording names in the catalogue is certainly a worthwhile addition, the facial recognition aspect seems more of a distraction – as well as a processing hog. It also dazzles the unwary user into overlooking that the identification data  is stored only in the catalogue and can’t be saved back to the files or to XMP sidecars. Apple (and McCreate) have failed to notice that almost a year ago the IPTC introduced the Person Shown field and that in any case the XMP concept allows anyone to add their own metadata. So face data is only available so long as you keep using Aperture – from a DAM perspective, that’s not very good practice.

Metadata – finally it reads from sidecar files

It was always odd that Aperture couldn’t read sidecar XMP files, yet was always able to write them when you exported duplicates of your originals. This meant it was easy to abandon Aperture and take your keywords and other metadata with you, but much harder to import existing sidecar-based metadata if you were coming the other way. Aperture 3 has rightly corrected this imbalance and can now read metadata from sidecar files. Good move.

What ever happened to never touching your raw files?

Another interesting detail is that it looks like Apple have gained access to camera makers’ proprietary file information. This certainly has benefits – I like View > Show Focus Points.

But the surprise is they have also used this access to write IPTC metadata directly back into your raw files. That’s a brave decision, as Nikon’s amazingly-unreliable SDK used to be a great way to corrupt your pictures. And it’s also quite a big about turn – remember how loudly Aperture once promised to leave your raw files untouched?

Also see David Rieck’s important article issues with how Apple Aperture 3 writes metadata, to which I linked yesterday. It highlights major weaknesses in how Aperture preserves metadata that’s already in your pictures – when it writes back metadata entered in Aperture, that existing metadata can be lost.

A similar problem affects star ratings that have been applied in other programs – Aperture 3 fails to read them! Moving to Aperture would mean doing them all again. For a while there was a support note indicating this failure is in fact a design decision because ratings and labels aren’t part of XMP 1.0. But when you think about it, that’s very weak. Aperture is finally reading sidecars so that users can bring in existing metadata that has been created in third party applications, so it should be allowing for the “non-standard” ways that ratings are used in third party apps. It’s a bit like me refusing to read a post because the author can’t spell or clearly can’t use apostrophes properly. The fact is, in the real world, just like folk don’t know their “it’s” from their “its”, ratings and labels are stored in non-standard ways. Fair enough for Apple to write those fields in the standard manner, but it’s lame to try to cover their failures by hiding behind standards. It’s obviously a stock excuse they’ve just dug up – and again shows the weakness of yes-man user testing. Update: And guess what, despite there being no standard, that support note was soon suppressed and reading star ratings was one of Aperture 3′s first bug fixes.

In each case, the underlying fault is hiding behind a narrow interpretation of standards and a too-limited view of what to do when there are inconsistencies in how the standards have been applied in practice. This is a tricky area – one wouldn’t expect anyone to get it right first time – but let’s not pretend there isn’t a nasty problem.

The end

And my conclusion? It’s a bit like you think you’ve finally got someone out of your life, you’ve got some beer in, and you were happily moving on. But then your errant lover shows up on your door, says she/he has cleaned up her/his ways and has a couple of new features, a cheap boob/moob job. Not really enough to turn back the clock….

PS I’m aware of the McCreate article that rolls out Apple’s party line. While I have no problem with it taking quotes from this post, I have not given permission to use my text in full or to use any images and am surprised at the McCreate author David Schloss’s loose attitude to copyright infringement.

I'll be posting some of my own thoughts on Aperture 3 soon, maybe tomorrow. But I just noticed David Riecks has some issues with how Apple Aperture 3 writes metadata and I recommend you read his article very carefully indeed:

Apple has made some significant changes to how Aperture handles metadata with this latest release. However, the ways in which this has been done should be of great concern to professional photographers that work with other programs, or hand off their metadata-rich files to others who need to be able to access the full range of that information.

You shouldn't be concerned if you use Aperture 3 on your own Mac, don't typically use embedded metadata, and don't share your images with others, or work with other programs such as Adobe Photoshop. Even if you do use metadata to describe your images, and only need to find them on your local computer, you should be fine.

You should be concerned if you use Aperture to write metadata to files you use with other programs, share with others or share on the Internet. For example if you do additional work in Photoshop or Lightroom, and then archive your images using other programs, you need to understand what is happening, or risk having some or all of your metadata disappear.

Good DAM practices aren't just about only ever using any one program, or placing all your trust in one company, even Apple.

Enough rope?

No comments

Audioboo seems to be a Twitter for podcasts, but at least on the latter a poor choice of words can easily be forgiven and it seems to take more than a single 140 character tweet to eliminate any ambiguity and clarify the true stupidity of a point. By contrast, listen to the unbelievably shortsighted recommendation in this 3 minute Lightroom & Aperture Tip podcast. The presenter, who should really have remained anonymous, only “sees nothing wrong” in lots of small catalogues because he hasn't looked too deeply and doesn't see it as fragmenting control of his pictures. I'm not against having more than one catalogue, and a “work in progress” catalogue can be a good workflow providing you consistently move its contents over to your master catalogue when they're finished. But setting an arbitrary number like 10,000 items on a catalogue (evidence, please), or even having a new one for each shoot, and worse still, leaving the catalogues in this way? To take this BridgeThink to an extreme, maybe we should have one catalogue per picture, and then there'd be no risk whatsoever of over-10,000 item databases going “dicky”. But rather like I wouldn't tell my Jamaican neighbour what should go in her curried goat, and she wouldn't pay attention if I did (not least because I'm largely-vegetarian), maybe that recommendation should only be for Aperture?

A late winner

No comments

I imagine this will interest a very small crowd, but here's a year-old presentation to a Mac developers conference by Adobe's Troy Gaul on how Lightroom is coded. He shows the development environment they needed to build because they were using Lua rather than a more widely-used language. One thing (as well as a new term) that I picked up was that there was a “stretch goal” to produce a development tool for plug-in authors as (hot news folks) “it might get a little tedious” to use a text editor to write code. No sign of it yet, but here's hoping (after all, Ryan Giggs just hit a 5th).

Also read John Nack's post on Lightroom beating Aperture 6-1 - more for the comments from the crowd.

Rob Boyer's All Things Photography blog includes Aperture tips and has also ventured into the dangerous waters of direct Aperture versus Lightroom comparisons. While overall Rob's about as fair and balanced in advocating Aperture as I am in preferring Lightroom, some judgements fall in Lightroom's favour. For instance, see his comparison of Aperture and Lightroom keywording:

[In Aperture] you can do crazy stuff like running scripts that smash the entire hierarchy into each of your images based on the specific keywords but that sort of defeats the purpose. Lightroom on the other hand will export the entire hierarchy for each specific keyword, but wait there's more, for each and every keyword Lightroom let's [sic] you specify whether or not to include the parent keywords and… whether to export it at all.

…Score a big win for Adobe Lightroom 2 versus Apple Aperture 2 when it comes to keyword functionality.

While I think his conclusion is right in this case, it shows a couple of dangers of such comparisons.

One is that it's easy to have misconceptions about how people actually use “the other” program's better features. Lightroom's keywording is so very flexible that a lot of people are led to abuse its power, exploiting the feature to add keywords which do not describe the image. So I've heard plenty of cases of people including workflow-related keywords like “not done”, “developed”, “final”, or including stock agency names as not-to-export keywords. Worse still is when they're encouraged to exploit Lightroom's keywording in this way without always understanding that it is a workaround for proper database and cataloguing features. While the keyword-abusive approach can certainly be made to work, sooner or later someone forgets to tick that do-not-export box, there's a need to exchange metadata with another app, or the export flag is misread by a bug in a new version's upgrade process. Suddenly you've got private keywords, custom metadata, getting into files exported from the system, and your filters and smart collections are picking up items with “workflow keywords” when they're supposed to target proper, descriptive keywords. Isn't any workaround always destined to be a dead end?

Rob's post is also a great example of the dangers of considering a single feature in isolation, because while Lightroom's keywording may well be better than Aperture's, the feature's flexibility allows Adobe to get away with failing - unlike Aperture - to include a proper custom field feature, which is where custom metadata really belongs.

Trojan horses

No comments

Not long ago I almost linked to Micah Walter's Inside Aperture article Seeing RED. He's now doing more video and is having problems managing the new file types:

What would save my day would be Aperture. If only Aperture supported AVCHD (and many of the other tapeless formats) I could import my AVCHD card just like I do with my DSLR. It could import any stills from my HD camera, as well as all of my native clips. It could allow me to preview my clips, maybe even set in and out markers and I could select a batch of clips and still frames to send off to Final Cut Pro for production. Final Cut could be responsible for converting the clips to QuickTime format (or not) and everything would just be in one place in an Aperture project.

Can't recall why I didn't link to it - probably because he is explicitly talking about "proper" digital video - but now it's worth comparing with Sean MacCormack's post Video and Lightroom:

In these days of convergence, where 2 of the newest DSLRS offer HD video recording capabilities (albeit basic), and almost every compact has some kind of video mode, I'd like to see Lightroom support Video. At minimum, I'd like it to import the video with my images. Preferably, I'd like to be able to playback the video and perhaps add basic metadata (copyright, keywords etc). I have no expectations of being able to edit video, or even work on colour, brightness etc. I just want to have my video managed with my images.

What we're seeing is the start of a battle for the soul of Aperture and Lightroom. Yes, I know that sounds almost as ludicrously-hyped as the Strictly Come Dancing judge saying John "the dancing pig" Sergeant had made the show a laughing stock, but both Aperture and Lightroom users fall into two distinct camps over this issue. On the one side are those who only see the Aperture and Lightroom as Photoshop substitutes for the DSLR era. And on the other are photographers who need a tool for photographers - which need not be limited to photographs.

I have negligible interest in video - photography's decisive moment satisfies me much more than video's hoovering-up process - but I've always been very much in the latter camp. As part of photography-centred projects and tasks, I might have PDFs such as contact sheets or layouts, Word documents such as correspondence or invoices, sound clips to include in the DVD of a wedding shoot, while it's crazy that Lightroom can send to Photoshop HDR merging yet be unwilling to manage the 32 bit output files.

I'm very much a believer in database-powered applications for managing picture collections, so the solution isn't Bridge, much-improved though it is, as it remains a Windows Explorer or Finder with knobs on, which can only ever tell you where files happen to be now, not where they should be. So I've always wanted Lightroom to be an iView with raw processing, not a narrowly-pretty face for Adobe Camera Raw.

I'm not sure if proper video and the convergence issue are a pair of Trojan horses (these are the days of Boris says teach yobs Latin and Greek and Obama's classical oratory) or perhaps they are twin battering rams? Either way, wheel them up, now please.

Update - 5-6 comments were lost during my web site changeover. They were both pro and against.

Over at the McCreate site (which first adorned the web as Aperture Professional Users Network, soon dropped the word “Professional”, and then dropped the rest) John Omvik does a lengthy comparison of Aperture 2.1 vs Lightroom 2.0 – Different Approaches to Local Image Corrections:

So Which Method is Best?

Both methods offer advantages and disadvantages for local corrections. After working with both I have to say that I am very impressed with the speed and flexibility the Adobe solution offers. I like the open plug-in concept from Apple, but feel that the implementation leaves much to be desired, especially as it relates to the rest of the non-destructive workflow.

My ideal solution would be a plug-in architecture that would allow for 3rd party plug-ins to be integrated in the processing pipeline offering the extensibility of Aperture with the speed and non-destructive functionality of Lightroom.

Pravda extolling the virtues of capitalism? But these are days when the Russkies are oil rich capitalists and the Yanks are merrily nationalizing the banking system….

It's easy to see real positives in Aperture's announcement of plug-in architecture. Taking advantage of existing third party tools can quickly flesh out its features, while positioning it at the centre of a viable “ecosystem”. Meanwhile third party developers can be working on fully-integrated solutions.

On the other hand, it's a long way short of the original concept of the one ring to rule them all, and might even be seen as defining limits on what's going to appear in the core product.

In any case, even if that fear's untrue, it seems pretty obvious that people don't really want to pay for a range of plug-ins for essential tasks like noise reduction or lens distortion - they will do so, but reluctantly, as a distress purchase. Then there's the hassle each time the host or the plug-in upgrades, or the palaver of tracking down licence numbers when you get a new computer (I'd love to know how many Mac users actually use the automated transfer processes). And when your chosen plug-in developer vanishes? Hopefully the plug-in works in the host's next version, and in cases like noise reduction, there'll always be a replacement, at a price. But will any of your settings transfer? Should you welcome plug-ins so uncritically, forgetting that you have grudgingly accepted you'll always be shelling out for them? Or should you demand the functionality in the box?

It's for reasons like this that I've never been particularly enamoured of plug-ins for Photoshop - only NoiseWare and PTLens have ever made it past an upgrade or change of computer - and I have the same doubts about them in Aperture and Lightroom. Still, it is the accepted wisdom that plug-ins played a seminal role in Photoshop's early history and so they have acquired a semi-mythical status. Questioning their virtue seems as heretical as doubting the Founding Fathers or Good Queen Bess, or Ivan the Terrible if you're Russian.

Just as these personalities can symbolize their nations, and embody certain values, so in the field of digital imaging the term plug-in has a history and a special meaning. It's certainly great PR to announce Aperture has plug-ins, but we're talking about a program whose raison d'etre is non-destructive editing and non-modality. So how can the current crop of external TIF editors in modal windows really be dignified with the term “plug-ins”? Fundamentally that's the question Lightroom product manger Tom Hogarty asks in Plug-in or External Editor? when he explains why we haven't seen image processing plug-ins for Lightroom is because of the:

incredibly powerful link between the raw and rendered workflow, and half measures (my emphasis) with marketing spin labeled as “plug-ins” are not the highest priority for the Lightroom team.

Not surprisingly, that touched a raw nerve, so over at AUPN Micah Walter has a crack at gerrymandering the term plug-in by including batch processing (by which criterion a command line program might qualify as a Lightroom plug-in, let alone Noise Ninja's new standalone) and tries to shift attention to what the plug-in specification allows. Derrick Story makes the same point:

Some of the advantages of the plug-in architecture include: access to metadata, batch processing, Raw processing, and control over Aperture objects.

Surely that's a bit like saying you're already a Latter Day Saint because one day your unborn grandchildren are going to become Mormons? If the host program's essence is as a non-destructive editor, a true plug-in operates within that concept. Until then, all you've got is an external editor strapped on in a modal window.

Ian Wood ( here too) has written an interesting and lengthy Aperture versus Lightroom 2 beta comparison.

He admits “Obviously I'm pretty biased towards Aperture (contributing to an Aperture blog, writing Aperture-related software, top-rated poster on the Apple discussion forum, posting on pretty well every Aperture-related forum on the net etc.), but I like to think I can put together a reasonably balanced list of pros and cons. The comments on those pros and cons, on the other hand, will be strictly personal… ;-)”

Fair enough - both in terms of sufficient knowledge and admitting up front to being an Aperture enthusiast. It's therefore hardly surprising that the choice of language supposedly describes the opposition's strengths yet carries a barb (it all reminds me of hearing Bill O'Reilly on Fox commend Kerry not for being more eloquent than Bush but as “more glib”). So I don't think I would have spun Lightroom's clear advantage in non-destructive local adjustments quite as “assuming you're happy using beta software and a warning that rendering of your images will probably change when the final version comes out.” Probably? Maybe. Significantly? Well, in a few cases and for even fewer people. And once we're comparing released products? Then the caveat will be completely irrelevant and Lightroom's local adjustment advantage will be even clearer.

Let's look at another Lightroom advantage: “Cross-platform. This may be vital to you, it may have no effect whatsoever.” There you go again. Let's rephrase this - one might say you're not forced to buy a Mac to use Lightroom, or you could say it as Aperture won't work on non-Mac computers. Cross-platform running doesn't sound so minor any more, does it? While anyone with any sense doesn't routinely move current work between platforms (I do so all the time), Ian's also looking “years down the line”, and it really should be a big concern that the program you use to manage your archive is limited to one platform. Now, with a bit of thought you can reassure yourself that Aperture does allow you an appropriate exit strategy, but failure to run on both the major operating systems is not something that should be dismissed so lightly.

Again, is it really an advantage that Aperture has editing plug-ins? Of course, no-one's against plug-ins and the name harks back to a warm misty time before most of us used Photoshop and when, according to accepted wisdom, plug-ins helped Photoshop rise to its lofty position. Perhaps they did, but we're not in such a virgin wasteland any longer. Would you really pay $250 for Nik's Viveza for local adjustments, when Lightroom has it in the box? Isn't the existence of plug-ins bound to stunt development of similar features within Aperture? Short term gain, long term $pain?

“Bigger marketshare” is a Lightroom advantage, “but nobody seems to know by how much.” Well, the last figures I saw indicated that, even when we gerrymander and only let shiny white Mac users in the voting booth, 2:1 were opting for Lightroom, while forum posts on pro-oriented sites show a much higher ratio. Share is, to some extent, irrelevant anyway - all you need is a sufficiently large support/learning ecosystem - but it's weak minded to dismiss it on the basis of ignorance of the balance. You're already finding many more learning resources for Lightroom and once Adobe addresses the wider market place you're going to find an awful lot more third party solutions for a cross platform application that has a bigger share of the whole market.

I do agree with some of the points. For example, custom fields should have been in Lightroom from day 1 and still aren't in the LR2 beta, LR2's smart collections remain more limited than Aperture, needlessly so, and Aperture has more flexible print layout and book output. I would also like Lightroom to allow scripting, though I disagree about its importance in a class of software whose raison d'etre is to process images in volume and eliminate much of the need for scripting and other ways of automating. Some other pros and cons are more or less irrelevant - eg what's the value of a full screen mode when you're covering it up with a tools palette? - or so down to personal taste that they have no value. And of course, the old modal canard is there and as off beam as usual - I do actually prefer Aperture's pre 2007 Microsoft Office style interface, but rename Lightroom's modules something like task-dedicated workspaces and you're putting a wholly different spin on the design, aren't you?

But more seriously, so much so that the comparison is unbalanced, is that Ian has made a big mistake in leaving out at least one Lightroom feature - Auto Sync mode. Some like me work in this mode almost all the time because you can select any number of images and then make an adjustment that applies to all selected pictures at once. In Aperture - and correct me if I am wrong - an adjustment only applies to the current image and you're then forced you to do a lift and stamp to apply that change to the others. You can work much faster with Lightroom's Auto Sync than you ever can with Aperture's lift and stamp two step.

Another big omission is adjustment presets. Ian rightly points out that you can apply these upon import in Lightroom, but the much more powerful application is that each Lightroom preset can contain adjust multiple parameters, while Aperture presets are still limited to just a single parameter. Again, you can get your work done much faster in Lightroom.

Ian also downplays another big disadvantage of Aperture. “Organisation within Aperture is mostly 'virtual' - it's not reflected in the Finder. Whether this is a con and never a pro I?ll leave you to decide for yourself.” Now that's what I call a cop out. Of course, you can import your files into Aperture so that your projects mimic your folder structure, but after the point of import there's no guarantee that the catalogue and your drive structure remain in sync - this basic control goes up in smoke the moment you move a folder in Finder or move a project in Aperture. This leaves you wholly dependent on Apple's backup and on staying with Aperture. By comparison, Lightroom shows both the physical folders and virtual hierarchical structures (which are multipurpose too). While displaying the folders does lead some Lightroom users down the dead end of trying to use their folder structure to describe their pictures (eg wildlife/animals/big cats/), it also allows you to apply proper long term DAM principles of using your folder structure for a robust backup that's agnostic of platform and cataloguing software.

Of course, people like Ian or me can spin every feature each way we want, but we do agree on one thing - “The best advice, I find, is to download both the trial versions and set aside a solid block of time to test them heavily, making sure to watch as many tutorial videos as possible.” That is the only way to decide.

Competition

No comments

It's not a secret that I find Lightroom the best application for reviewing, adjusting and applying initial metadata - I'd pretty well finished processing last weekend's 2,100+ raw files by Wednesday morning. Equally obviously, it's not the only program that aspires to manage and process large numbers of pictures. I'm immediately referring to the Mac-limited Aperture, but it's interesting to see others moving into this database+processing arena. There are hints of a SmartFlow from Microsoft, and Robert Edwards pointed out some of the features that are going to be in Bibble 5. Click one screen grab and you'll see the cataloguing system, click the other and there's local adjustment within the application (ie not via some pixel rendering plugin or Photoshop).

I can't shake off the feeling that right now there's no Manchester United that wins the DAM+P market with style - man, yesterday was so tense - but just a bunch of functional Chelseas (without the kleptocratic funding of course). Eventually a winner will emerge, but let's hope that there's plenty of competition between at least four teams.

Last year I posted a note on how to move master pictures from Aperture to Lightroom and transfer any metadata that you had entered. Essentially you used the Export Masters command and told Aperture to put the metadata in XMP sidecars. This worked fine for raw files, but not for originals whose file formats were publicly documented such as DNGs, TIFs or JPEGs. Adobe (rightly) expects metadata to be embedded in the file and not in a sidecar, so Lightroom or Photoshop wouldn't read any Aperture captions or keywords in those files. There was a workaround, but it required you to keep your head screwed on.


No longer. I've just had it pointed out that Aperture 2.1's Export Masters command now has an extra option - writing the metadata to the file. So you could just select all the files, and choose that option. It embeds the metadata in raw files too, which you may or may not like. (If not, run Export Masters twice with the sidecar option for raw files and the embedded option for the rest).

It strikes me as odd that they should give priority to this feature. Apart from being limited to the Mac, Aperture still doesn't read xmp sidecars upon import, so there can be two barriers to moving to Aperture. But yet they now make it easier to move your pictures and metadata away from Aperture and to Lightroom. An odd commercial decision, but maybe I should learn to “Think different” ?

Shush

No comments

Take a look at Jeff Schewe's teasing post in a thread about Aperture 2.1 and its dodge and burn utility:

what are you gonna be doing next Wed, April 2nd? (I actually already know what you'll be doing but I can't really tell ya)

Rendering out the raw file to run a Photoshop type plug-in on the gamma encoded file (making a tiff) is NOT the way I want to be dealing with raw files. Dodge/Burn, and optimal output sharpening can/should/will all be done right in the raw workflow. That would be the Lightroom way…

iDrive

No comments

What a lousy week. Sunday's high - United going 5 points clear against the Scousers - was sorely dented the following afternoon when a Mac user drove his Volvo into the side of my car, which had been parked in front of the house. As if I've not said some nice things about Aperture recently! Another whole day then went down the drain trying to unblock a panicking friend's email before finding that it wasn't the free antivirus or firewall that someone had installed, or some problem at the recipient's end, but her ISP blocking an innocuous letter combination in a single plain text, attachment-free message. It was one of those weeks when you never even start one of the things you'd planned to finish.

But at least the week's ending nicely, with news of a private re-enactment event down in Hampshire this weekend, and this afternoon I picked up a courtesy car so I can get down there tomorrow for the dawn assault with muskets and cannon. That should rudely awaken the locals. And though I don't use Aperture seriously, it's still good to see that today they've introduced 2.1 with a sort of dodge and burn tool.

Local adjustment was something I thought they would have introduced if they had wanted Aperture 2 to make a big splash, rather than just halt the drift away to Lightroom. But it's here now and shows one future direction for these DAM+Processing apps.

One thing to notice is that Aperture's dodge and burn has not been implemented within the main interface but in a plug-in window. This contains the sort of tools you might expect - brushes and size, feathering and strength sliders - and it looks consistent with some at least of Aperture's existing buttons. Still, when lack of modularity is supposed to be such an Aperture strength, it's odd that they've gone for a separate, modal window.

The other interesting detail is what happens once you're done and you click Save - a new TIF file is created. In other words, dodge and burn is not implemented like other adjustments as non-destructive parameters, which take up negligible disc space, but it is an old fashioned destructive tool. Oh well - better watch out for the iVolvo again.

XMP madness

No comments

Of course, you’ve got to be sceptical of a PC-using Lightroom author’s opinions on Aperture, even if he also uses a Mac and pretends to know a little bit about using it to manage and process his pictures. After all, would you listen to his view on driving a BMW once you know he’s driven Audi for 15 years? Or when he tells you what’s wrong with Liverpool when his loyalties lie firmly at the other end of the East Lancs Road? Perhaps you would.

I particularly rate James Duncan Davidson’s posts because he’s an Apple-using switcher, moving from Aperture to Lightroom – the decisive issue being working speed, not brand loyalty. His Aperture 2 quick impressions picks up on many of the points I keep banging on about. He likes preview mode and the belated addition of background processing, but he also picks up on one of Aperture’s strangest failings:

The lack of support for XMP sidecar files on import is puzzling. You can export XMP sidecar files, but not import. This little issue is going to cause a bit of a problem for people wanting to import large collections of RAW files that already have metadata into Aperture. It should be easier to round trip this information. Of course, what I?d really like to see is Aperture be able to interoperate fully using XMP data with other applications like Bridge and Lightroom, picking up changes as they happen either in sidecars or embedded into files. Currently, this is just a dream.

He’s not the only one dreaming. But the thing is, it’s not sci fi or voodoo – Aperture 1 was actually designed long after it was obvious that XMP metadata was the way to go. Writing XMP sidecars, but not reading them, is simply mind-numbingly stupid. And frankly, it doesn’t sound very Apple-like to leave Aperture’s exit door wide open, but bolt the entrance and burn the welcome mat.

Progress chasing

No comments

Looking over the fence as one does, and no doubt breaking a couple of biblical commandments, one Aperture feature that I've always liked is Smart Albums. Partly for me it's a very simple principle - any database-driven application should let users save any queries and search criteria. Modern business systems also help control and drive the workflow, so that call centre guy in India escalates your issue to his supervisor, who logs on in California and sees a task on her action list, while her manager reviews exception reports and overall clear-up rates, and no doubt wishes he'd never heard of outsourcing and offshoring. Data already present in the system is leveraged (forgive me) to drive the process forward and exceed customer expectations.

OK - and before I career off into a Scott Adams mission statement filled world - principle and analogy are all very well and good, but where does this help the photographer? Well, Aperture's smart albums are even better in v2.0 and you can now find pictures based on the adjustments you've applied, as well as on their IPTC metadata. How can this work in practice.

Let's imagine you're working your way through all those pictures from a trip, a wedding, or an event. To borrow a certain phrase, how many hundred images do you want to process today? You're a visual kind of guy? OK, then scan all those thumbnails or check them all full screen. You don't just do it once, do you? One pass is needed to check your copyright is there, another confirms the final white balance, another the overall brightness and contrast, and so on. How well are you doing? Exactly how efficient or certain is all this going to be? Still got the time or the enthusiasm, or would you prefer action lists, like those call centre guys in their suits and ties? Here you go then, a smart album shows you all the pictures without adjustments:

It's quality control as well as progress chasing, because smart albums let you target specific adjustments that might be important for the type of work you do. For example, part of a shoot might be in low light with high ISO settings, and you want to be certain that you set every image's noise reduction parameter. Here they are:

Get the idea? Pulling it all together, you can control a job by building the project as a series of to do's, where smart albums (the purple folders) first help you monitor your metadata entry - click on one to check you've not forgotten to add your copyright, or on another to check no pictures have gone missing. Then you move onto adjustments, and can quickly see which images are untouched, which haven't got edge sharpening etc. And then last of all might be some overall checks, a smart album to highlight any images that don't meet a minimum standard for adjustments - say noise reduction, edge sharpening, and a white balance setting. To top it off, because systems aren't everything, there's the blue “Checked and ready to go” folder.

I suppose I do have a lingering doubt - isn't this methodical, one step after another approach, one thing that Aperture lovers say they simply don't, can't follow? After all, they're artists. Is it too linear, too Lightroom? [A somewhat mischievous point thrown in as revenge for the umpteenth time they've played the irritating MacBookAir ad while I've been writing this in front of the telly]

With systems like Aperture and Lightroom, all the necessary information is there already. There's EXIF information to identify noisy high ISO images, or those on a lens which has chromatic aberration problems at a certain aperture. There's IPTC or other descriptive metadata might let you target just those pictures which you rate sufficiently to show the client. And there's the editing adjustment data, just begging to be exploited. That's the opportunity opened up by these changes to smart albums.

I don't do much tethered shooting and don't have much feel for how common a requirement it is. But for some it obviously matters a lot, and it's no surprise to see that Aperture 2.0 has introduced a tethered mode.

This morning I tried it out with a Nikon D200 (it's worth noting you have to set its USB connection to peer to peer mode). After choosing a project, you then begin a tethered session by setting where the files should be written. You're not forced to select its black hole (OK the managed folder) but can send them to a regular “referenced” folder, and can set filenaming options and add some descriptive metadata like your copyright. You then see this little palette, which you can move out of the way, and then fire the shutter with its Capture button. Once the new image arrives on your computer, it is immediately selected, on a second monitor if you like. It's basic but works just fine.

Because of the way Aperture's adjustment presets are granular (comparison with Lightroom here) you can't add any initial global adjustments like white balance or highlight recovery during the tethered capture phase. So you're then into the horror of Lift and Stamp, which is not a patch on Lightroom's super Auto Sync mode, and even some way behind its more prosaic alternatives, Sync, and Cut and Paste.

But I do like the feature and am sure it will be popular. Since I have no other camera control software on my Mac, Aperture can serve as my tethered capture utility for Lightroom….

Update:
Transfer rate looks like 1.75 Mb per second. D200 15.75 Mb raw files appear in Aperture in just over 9 seconds, arriving a fraction earlier in Finder. This is under OSX 10.4.11, USB 2.0, on a MacBookPro with 2Gb Ram. Aperture 2.0 was in Quick Preview mode, which uses the embedded JPEG and so eliminates any raw rendering delay, and I was looking for the new shot to appear on my second monitor (a neighbour's cat was the art director). To eliminate any camera buffer issues, I tested with single shots - though I later found that Aperture wouldn't in fact let me make further captures during those 9 seconds. I don't do a lot of tethered shooting, but I wonder if the transfer speed and lockout make this feature unworkable.

Aperture 2.0 speed

No comments

There's little doubt that Aperture has been harmed by being slower than Lightroom on equivalent Apple hardware - as well as by being worse than glacial on non-Apple computers. For myself, I never found version 1.56 was too bad on my MacBookPro with 2Gb RAM - slower though not impossibly so was my feeling. But I was very interested to see if 2.0 would be any quicker than the previous version, let alone a match for Lightroom

Overall, in my view 2.0's performance is definitely no worse than before, and Apple aren't strong-arming users into upgrading their hardware again (further evidence it's a 1.7?). And it is pretty clear that plenty of effort has indeed gone into making the program appear faster. So it quickly announces it has finished importing new pictures, even though to do anything useful with them you still have to wait while it quietly builds thumbnails and previews. Of course, speed that is apparent-only is no bad thing for the user, and helps the fanboys get away with blanket claims. But even when you define speed more a bit more tightly - as what really saves you time - I think one can point to Aperture 2.0 having taken some big steps forward.

One is Quick Preview mode (more here). You activate the mode by hitting the keyboard shortcut P (or via the button dumped down in the bottom right corner of the screen - yes, all those fiddly little buttons are still all over the place). Once in Preview mode, the program displays the JPEG preview that the camera added to the raw file, which means you can browse through pictures at lightning speed. You will not see any adjustments that you've made to the pictures, but that's irrelevant when you're under time pressure doing your initial review, working out what you've got and deciding on keepers and duds. I'd say Aperture 2.0's browsing speed is close to PhotoMechanic, the gold standard, and for some users that's going to be a big plus.

The other step forward is a bit of catch up with Lightroom. For this type of workflow application, the previous omission of background processing was little short of bizarre and meant you had to wait for big jobs to finish. Exports now happen in the background, so you can get on with other work while the program saves out TIFs or generates a web site. OK, things slow down a bit but you can't have it all - for some users, background processing of exports will greatly improve start to finish times.

So two days running, I say something nice about Aperture. Well, it is Valentine's Day.

PS For fair and balanced views of Aperture 2.0, see

One thing that always puzzled me about Aperture was that it treated DNGs as raw files, and wouldn't read them if they had originally been shot on a camera it didn't support. Reading DNGs as DNGs would, at a stroke, have extended the range of cameras the program supported. And that is what Apple now seem to have done, as AUPN writes:

Once files [from unsupported cameras] are imported as DNG, a new option will be available in the “RAW Fine Tuning” section of the Adjustment inspector, which indicates that the file is being adjusted using the DNG decoder. This box reads “2.0 DNG” and changes to the image using the 2.0 DNG converter are made based on the DNG specification of the file.

If the DNG is for a file that Aperture can already support (or if the file is viewed after support for a format is added) there will be the standard choice of processing the image using the Aperture 2.0 conversion, by selecting “2.0″ from the drop down menu. The idea here is that the specific Aperture conversion does a better camera-specific job than the generic DNG does….

The new DNG support opens up worlds of possibility for Aperture users, and in fact we've recently imported thousands of images from previous test shots from cameras like the Kodak DCS Pro SLR/n and several Hasselblad backs. It's great to be able to work with these legacy files using the powerful adjustment tools in Aperture.

As well as this nice feather in Aperture's cap, it also now reads the metadata in DNG files (though it still fails to read raw files' XMP sidecars). Taken together, these changes benefit those of us who don't get the Mac thing and/or see no benefit in switching to Aperture. Why? Well, because these are both moves that really help cement the value of DNG as an archival format.

You see, I do say nice things about Aperture now and again.

Ever have problems remembering your keyboard shortcuts? Some people just print them out and stick them to the monitor, while I go try use one new shortcut every day, but if you're an Aperture user, what you need is AUPN's long sleeve t shirt.

Update - Aperture 2 has just sneaked out. I suppose I am surprised that it looks so unexciting, as if they've copied a few of Lightroom's adjustments - Recovery, Vibrancy, Definition (ie Lightroom's lousily named Clarity which I always call Punch) - and then done a lot of tidying up to its remarkably fiddly interface.

The detail is here:

  • Proper DNG support so Aperture will now read files shot on a camera or camera back not natively supported by Mac OS X. If Adobe support it, Aperture will do so too. Given the recent fiasco over supporting new Canon and Nikon pro cameras, that's a very wise move indeed.
  • There is no mention of importing IPTC-XMP, which would make it a lot easier for new users to migrate their metadata inwards, but it's even easier for people to leave Aperture as it now embeds IPTC data in RAW files on export.
  • Background processing is now there, at least for exports like Lightroom, which should speed up end to end workflow.
  • There's an option to use the embedded JPEG from camera when possible - that will speed up early comparison and weeding out duds.
  • There's also a lot of good stuff like changing how Aperture searches within stacks - by default it now searches all items, not just the picks - and smart filters can now target adjustments - something I'd love to see in Lightroom.

But Aperture 2.0 looks like it's mainly about fine tuning and streamlining is clearly the buzzword. Streamlining's a very attractive word, but dangerous too, as if you're struggling for real excitement. And it's still limited to the Mac.

I've said before that O'Reilly's Inside Aperture and Inside Lightroom blogs have been getting a bit tired lately. Folk evangelize about how their chosen program has revolutionized some aspect of their work, when either program - or indeed earlier DAM programs - would have done so. This is just one where you could just as well swap over the product names - “You need to present your photos. With a multimedia projector, and with your Mac and Aperture, you can create a quick showcase.” Hey, with a multimedia projector, and with your PC or Mac and Lightroom, you can create a quick showcase. It's all rather like “Thanks to the leadership of Comrade Napoleon, how excellent this water tastes!”

But one of the better writers there is James Duncan Davidson, on the Lightroom side but who had switched from Aperture, and his latest post The Economics of Online Backup looks at the costs and practicalities of online storage as they are right now:

As I see it, I need a much bigger pipe to the Internet to make these kinds of backups work well long term. Until Verizon FIOS shows up, or I score some really choice client gigs that really add to the bottom line and can put in my own dedicated T3, I'm a bit too bandwidth constrained to make it work out. This, however, is how things stacks up for me. After running the numbers yet again, I'm going to stick with my current program of rotating drives to a safe deposit box which has a nice cafe next door in which to get a cappuccino in. But, I'll keep running the numbers every so often and at some point, maybe the equation will change answers.

“In the cloud” storage cost remains too high, and the bandwidth and the time demands are even more prohibitive. But does anyone doubt the time will come?