While publishing my book Get Your Head Around Aperture 1.5 I figured out how to create high-quality page thumbnails like the one above. It is almost possible to read the body text, and the small blue title is certainly readable: Importing Images From A Single Folder, even though the characters are tiny. The word Images is only 5 by 19 pixels.

I first tried taking screen shots and reducing the images in Photoshop, but that resulted in a horrible loss of detail and a very fuzzy look. The page size reduction was being carried out as though it were a photograph, not a page of text. I needed a way of maintaining the character information through the size reduction.

To create the high quality page thumbnails I printed the pages I needed to a PDF file:

Then viewing the generated page in Preview, reduced the page size until it was what I needed:

Since the PDF was being rendered at the reduced size, the detail was still present. Last, I took a screenshot with SnapzPro2 and added a thin border and drop shadow with the media inspector in RapidWeaver:

This also gives me an image with the drop shadow rendered in: I just click and drag the image from the published web page to my desktop.

Tags: Thumbnails, PDF, Get Your Head Around Aperture, Books, Documentation, RapidWeaver, Screen Shots, Photoshop

FlickScreen uploads screen shots to Flickr. That's it. If you do a lot of screen shot taking and uploading, then it may save you a step or two many times over.

Tags: Flickr, Screen Shots

I notice that since upgrading to 10.4.11 (still not running Leopard here), Safari no longer stores its web icons in files. Instead it uses a SQLite database. This is a feature of the new version of Safari. My ~/Library/Safari folder looks like this:

I can use SQLite Database Browser to see what is inside:

Safari used to get slower and slower maintaining a huge folder tree of tiny web icons: I used to delete mine every so often to clear them out. This solution should cut down on disk space use and be much faster after months of browsing.

Tags: Safari, Database, Updates

File Juicer is a small Mac OS X application that extracts images, movies, text, and other useful data from practically anything. It's useful to Aperture users in two important ways: it can recover usable images from the library if the masters are lost and and can scrounge deleted images from memory cards.

One of the hazards of working with referenced image masters is that their management is the responsibility of the owner. Accidental deletions are not that uncommon, and if that happens then while Aperture can display the images, it cannot export or otherwise use any of the versions that are based on the lost masters. If the masters are truly lost -- no back ups, nothing in the trash -- then whatever images can be found become valuable.

If high resolution previews were generated, then these can be extracted from the Aperture library by simply selecting the thumbnail images in the browser and dragging them to the desktop. They will be in JPEG format and at a size and resolution that depends on the settings in Aperture's preferences:

If there are no previews, then attention turns to the thumbnail files that Aperture stores in each project. It is these images that are used to display the on-screen thumbnails in the browser pane and as placeholder images in the viewer while Aperture processes the RAW image. The files that contain the thumbnails are called AP.Tinies, AP.Minis, and AP.Thumbnails and contain images at 32, 256, and 1024 pixel sizes respectively. They are also present in exported projects, but not in vaults.

To get to the thumbnails, I control-click on the library and select Show Package Contents. Then I navigate down to the project of interest and open that with a control-click and Show Package Contents:

The AP.Thumbnails file is one big chunk of binary data, but inside there are complete JPEG images. File Juicer will go into it and locate and extract the JPEGs without knowing the format of the file.

I launch File Juicer and check that the preferences are set to include JPEG images (at least):

I also make sure that the extracted files will be stored somewhere sensible, such as on the desktop, because I don't want the extracted images put inside my Aperture library:

With the selections I have made, File Juicer will put each image type into a separate folder and create a parent folder for those. It will also get an HTML index file for easy browsing. To start scanning for images, I drop the AP.Thumbnails file from my project onto the main File Juicer window and wait for it to process:

After processing I get a new folder on my desktop containing the images:

And I can either open the jpg folder and browse the image icons in the Finder (or watch a slide show), or click on the index.html icon and see all the images in a browser window as a panoramic display:

Now my images have been extracted, I can reimport them into Aperture and sort through them. They will be smaller then the originals -- only up to 1024 pixels on a side-- and there will be one image per version. So a single lost master will result in five recovered JPEGs if it had five versions in that project. This is good because I get my adjusted images, albeit at low resolution.

Since File Juicer is scavenging for JPEGs rather than following any information that Aperture provides, there are some side-effects. The first is that there may be old images or possibly corrupted images in the folder of JPEGs. The second is that the names of the images are sequential and bear no relationship to the order in which they were taken or anything else. The third is that there is no EXIF or other metadata in the JPEGs, so all the keywords, camera and shooting data are lost.

File Juicer will also recover RAW and other images that have been deleted from camera cards, so if masters have been lost it is possible that they can be obtained that way. The process is very similar to the thumbnail recovery described here, except that there is an extra step at the beginning where File Juicer creates a disk image of the card and scans that.

The File Juicer web site has a page dedicated to its use with Aperture, and one about RAW image formats.

Tags: Aperture, Recover, Masters, Referenced, Deleting, Bone-Headedness, Hacking, Previews

Each holiday season I get time to play with Garageband and add slightly to my musical skills. This year's creation is called Faraway Home (2m 30s, 192kbps AAC):


[You should be able to see a Quicktime controller above and play it straight from the blog. If you don't, see the iCompositions link at the bottom of this entry.]

It is loop-free and made of nine tracks: two lead, two bass, two percussion, two rhythm, and one atmospheric. To hear it well you need some good bass to reproduce the very low notes. I'm using Garageband 3 on Tiger, a 24" iMac and a 49-key M-Audio keyboard.

This time around I set out to create all my instruments, and find a way of getting some emotion into the piece. This is tricky because my musical skills are limited and I don't have a lot of experience with synths. Along the way I discovered how useful the track echo can be.

I started out experimenting with track echo and had two instruments derived from a synth pad, one in each ear:


The track echo takes into consideration the beat of the music, so it can be used to create extra notes, especially with tremolo and auto-panning. That experimentation led to a version that made the left ear lead the right ear by a very short time interval, letting the echo do most of the work.


I needed an atmosphere, so toned down the pinging sound of the other two tracks and created a background from another synth pad instrument. That had some very nice resonances in it.


Then I modified a synth texture to create a "thump" note and used them in pairs for a heartbeat. That went into one ear and a drum from the rock kit in the other ear. At this point some sort of a start to the piece came together:


To add some bass and melody I modified a bass guitar to make a muted twangy sound and used the track echo to create extra notes for me.


I needed more bass than that for more of a punch, so I used a different bass combined with a bass amplifier and some heavy filtering to get really deep pure notes. The lower of the two is actually two notes an octave apart:


Now I'm getting somewhere musical. But there is no lead and no emotion. After a lot of experimentation I got the sound I wanted: a twangy guitar sound from a synth. The lead is a modified synth lead that responded very well to the pitch blend wheel on my keyboard. The final trick was to add reverb to just that track.

I created two tracks separately, expecting to make one from parts of the two, but once I played them both together, realized that I could have a duet. Finally I created an end, worked on the beginning some more, adjusted the levels and panning, and tweaked everything.

I'm not sure how it stands up on its own. It would be good as part of a movie, an atmospheric background to a car journey in the rain or something like that. I will put it up on iCompositions with my other music.

Tags: Music

That is The Waiter. For The Cheater, The Zombie, and others, see this page on English Russia. Oh and there are also picked cell phones, bikes on top of cars, and more. Plenty of odd things and unusual photos if you dig around a little.

Tags: Russians, Fun, Photography, Interesting Stuff

Waffle is a blog that covers a multitude of geeky, webby, and Appley subjects. It's technical and meaty. But somehow never waffly.

Tags: Blogging, Cocoa, Apple, Interesting Stuff

Im getting reports of attempts to buy Get Your head Around Aperture 1.5 thwarted, at least temporarily, by a bug in WebKit introduced by Security Update 2007-009.

From what I can tell, if you are running 10.4.11 or Leopard and are on an Intel machine, and have installed the security update then clicking the Buy Now button will crash the browser. PowerPC machines are not affected. [Update: yes they are]. [Update2: Apple has now released version 1.1 of this update that fixes the problem].

Tags: Security, Updates, Get Your Head Around Aperture

Clamshell Bucket: 1/800s f/4.0 ISO100 170mm -0.3ev, Canon 30D, Canon EF 70-200 f/2.7L IS, adjusted

RapidWeaver, the application I use to create this site, now has the option to generate the sidebar using PHP. I plan on taking advantage of this feature so that sidebar modifications (which includes adding new pages) don't affect all the HTML on the site and require a complete upload, 1000+ files in my case.

But switching to PHP creates a problem. Although the links I publish, such as http://www.bagelturf.com, don't specify the file extension and so will be automatically redirected to the appropriate index file, there are many links out there on the web that specify .html and those files will no longer exist. An example is: http://www.bagelturf.com/aparticles/index.html. When I replace this file with http://www.bagelturf.com/aparticles/index.php, all the links to the index.html file will be broken.

The fix to this is to use the mod_rewrite facilities of Apache. mod_rewrite allows rules to be set up that can generate new URLs from those that match patterns. The goal here is to convert all requests for .html into requests to .php. I found a couple of good sites to help me with this, here and here.

I want to experiment with PHP and mod_rewrite on my computer before making any changes on my hosting service. As it ships, Tiger has PHP disabled. I'm still running Tiger, note. The changes are slightly different for Leopard. To turn on PHP, I fired up TextWrangler and selected File > Open File By Name... This lets me type in the Apache configuration file name I need to change: /etc/httpd/httpd.conf. This file needs root access to edit, so as soon as I start to edit it, TextWrangler asks me if I really mean to do this. When I save the file it requests my password. I prefer using TextWrangler since I don't need to mess with the terminal or sudo.

To enable PHP I remove the # from the following two lines in httpd.conf:

# LoadModule php4_module libexec/httpd/libphp4.so
# AddModule mod_php4.c

Then I start Apache. This is done from the Sharing preference pane by turning on Personal Web Sharing:

If I already had Apache running, then I would have had to stop it and restart it by unchecking and then checking the checkbox.

I can check that PHP is active this by creating a simple PHP file and accessing it in my Sites folder in my home folder. The file is called index.php and looks like this:

To access it I load the URL http://127.0.0.1/~steve/index.php in a browser and expect to see a page with Hello World appear. It does, so now PHP is working.

To use mod-rewrite I create rules and put them into a .htaccess file in my Sites folder. To create the file, I again use TextWrangler and type in the following:

Options +FollowSymlinks is needed or else the rule does not work. The RewriteBase line tells Apache that my web pages live in my home folder. Without this line the access will go to the default web page for the system, which is not what I want. The RewriteRule line matches all URLs that end with .html and replaces the extension with .php. The Item as the end of the line tells Apache to give a response code of 301 (Moved Permanently) and to reload the page. This reload replaces the URL in the browser with the actual one I am using, the one ending with .php. This will tell search engines where my .html pages have gone.

There is one more step to getting this work. As set up so far, Apache will not parse .htaccess files in my Sites folder because that feature is turned off. As well as processing the global httpd.conf file when started up, Apache also parses a file users/steve.conf and by default that is set to deny access to .htaccess files.

To fix this I use TextWrangler to edit the file /etc/httpd/users/steve.conf so that it looks like this:

The edit needed is to change AllowOverride from None to All. This file applies specifically to my Sites folder and to everything in subfolders below that.

I'm done. Now I can experiment with my site by enabling PHP sidebar generation and viewing the pages locally. That's turned on in the Page Inspector:

Tags: PHP, Apache, Leopard, RapidWeaver

Vector Magic is a web service at Stanford University that converts bit-mapped images into vector-images. Here is a rendering of an EPS generated by the service that was originally a photograph:

A close-up of the nose:

And here is the original photo:

To use the service, go to http://vectormagic.stanford.edu/ and upload an image of some sort. Answer the questions, make some color selections, and the computers do their stuff. The processing for the image I uploaded took about five seconds. Once the vectorization is complete you are given the opportunity to reprocess or edit the image before downloading it:

I can see this being very useful for creating new scalable artwork out of old bit-mapped logos and graphics. For photos it has a somewhat limited appeal, but could be used for artistic effect that goes beyond simple posterization.

Tags: Photography, Images, Vectorization

Great blog-- thanks!! I seem to have "misplaced" a master image. Not quite sure what happened. I opened it (twice) with an external editor and attempted to delete one version (using the 'Delete Version' option). I did not choose 'Delete Master and all Versions' option and Aperture never asked me to confirm this action. However, all traces of the photo now appear to be gone from the library. I drilled through using the 'Show page contents' tool and looked at previews. There is no folder in the project for this image. I have recently backed up my Vaults before editing. Is there any way I can recover a single master image from a vault? Thanks in advance for any suggestions!!

Yes, single images can be retrieved from vaults. By navigating down into the vault or by searching, the image can be located and copied out using the Finder. Once copied, it can be imported back into Aperture. This will lose all versions and adjustments, and any metadata that is not part of the original master file.

But first, check for the image in the trash. Images in Aperture that are deleted are put into the trash in a folder called Aperture. Inside that is another folder with the name of the project the image was in. Inside that is the images deleted from that project.

I'll find and restore a deleted image from a vault. The organization of a vault is very similar to that of the library, so delving into the vault is very similar to delving into the library. Since in this case I know that the name of the deleted image included the number 2486, I can search on that. First I open the vault using control-click and Show Package Contents:

Then by typing the part of the name I know into the Finder's search box, I can quickly locate the image:

I can use the slideshow and other features of the Finder window to examine my image. Once located, I option-drag the image out of the Finder window to copy it to the desktop, then drag it onto a project in Aperture to import it again.

If I had not already known part of the name of the image, then I would have had to do more work. By typing JPG into the search box (since I know that my master image was a JPG) I can find all the images and then browse through them:

This will of course work for other file name extensions such as CR2 or NEF. Selecting a image in the Finder window shows the full path at the bottom and double-clicking a folder in that list will open the folder for further examination. Control-click can be used to open projects that show up the path by selecting Show Package Contents. As before I can option-drag image masters out to copy them and restore them to Aperture.

If the deleted image is not in the trash and also not in the vault, there is one last place it may be. Images deleted from vaults by a vault update are not removed entirely, but they are not put into the trash. Instead the folder that holds the vault contains a folder with Deleted Images in its name. Inside that is a folder named for the date and time of the vault sync that removed the image from the vault. Inside that are folders for the deleted images and the masters:

My image is now available for reimporting into Aperture. The techniques I show here can also be used to find out if the image really was deleted from the Library in the first place.

Tags: Aperture, Q&A, Vaults, Deleting, Masters, Recover, Bone-Headedness

Air, a French band, makes some really great music to work to. Above is a live video: Talisman. I prefer the album versions because they are so much more polished. Be sure to hear La Femme D'Argent (album version set to the video of a sonogram or live), Biological, Another Day, and Alone in Kyoto. Lots more on You Tube.

Tags: Music, French

O'Reilly has posted another Inside Aperture podcast: Sal Soghoian talking about Leopard, Automation, and Aperture. Don't miss the previous shows listed in the sidebar, or simply subscribe to the podcast in iTunes.

Tags: Aperture, Podcast, Automation, Applescript, Interview, Leopard

Do you know how to reset all the metadata views back to their default designs?


The metadata view settings are kept in the user's Application Support folder. If you delete the file MetadataSets.plist, Aperture will create a new one with the default settings.

The Application Support folder in the Library which is inside the user's home folder. Aperture has its own folder. Mine looks like this:


This is also the home of many other settings for Aperture, including the keyword list, watermark images, and plug-ins. Sometimes these files are the cause of mysterious crashes on launch, so it can be a good test to rename the folder and relaunch Aperture to see if the problem goes away.

All these settings only apply to this user, note. There is another Application Support folder with an Aperture folder inside the Library on the boot disk. Here is mine:

BorderFX is here because it has an installer that put the plug-in in this central location. This gives access to the plug-in to all users of the machine. On my machine the Sample Projects folder is empty. That's because I trashed its contents after I had played with the images provided. It's worth checking to see if yours is wasting space and trashing the contents if it is.

Tags: Aperture, Q&A, Metadata, Metadata Views, Defaults, Plug-ins, Keywords

I attended a party celebrating SmugMug's 5th birthday tonight. Five years ago SmugMug was two people in an apartment. They had five customers sign up the first month. Today they are almost 30 people and support many customers. I use SmugMug to host my galleries and provide originals for many of the images I post on the blog.

They were taking pictures of people in costume too. Lots of fun as you can see:

Tags: SmugMug, Birthdays, Costumes

Stand out in the crowd with a Cocoa tee-shirt. I've a few more ideas that I will convert into products when I get a chance.

You can buy this one from Zazzle. It has white lettering with the code [self setNeedsDisplay:YES]; on the front and the back. You can pick any dark color shirt you like. I get a cut of the proceeds.

Tags: Cocoa, Tee Shirts, NSView, setNeedsDisplay, Fun, WWDC

First, quickly, I love your site, and thank you for the useful information you have on it. Quick question: I have an aperture library with referenced masters. My library is approx. 13000 images, totaling approx 25GB. I do not automatically create previews for the images, in fact I periodically select all images and choose to delete previews. I only have previews for about 200 images that I sync to my iPhone. I use keywords, but not overwhelmingly; I do have Blue and Gray folder organizational structure within Aperture. I have very few smart albums/lightables/etc. Mostly I have 7-8 Blue (top level folders) with each shoot being a separate project under one of the Blue folders. So the question is, why is my ApertureLibrary.aplibrary file over 7GB in size? Thank you in advance for your help.

For 13,000 images, that works out to 540k each, about right in my estimation. The space is used mainly by the thumbnails that Aperture stores for each version.

Here I have a small project with 13 images, all referenced. None of them have previews. To look inside, I open my library with control-click and select Show Package Contents, then navigate down to the project and open that the same way:

Pretty much everything is small except for the AP.Minis and AP.Thumbnails files. The former holds 256 pixel thumbnails at 16 bits per pixel, 128K per image. The latter holds 1024 pixel JPEGs, about 415k each. The whole project is 7.3MB, so those two thumbnail files account for about 95% of the space used. This also shows why vaults are smaller than libraries: they omit the thumbnails.

Creating high resolution previews for these images would add somewhere between 2MB and 5MB per image, depending on the size and fidelity of the JPEGs generated. That would boost the project size by between 26MB and 65MB, a significant increase over the current 7.3MB.

The library has some overhead beyond the projects it contains. By opening the library with control click and Show Package Contents I can see the files at the top level:

The biggest non-project item is the database file at 2.2MB Not particularly significant in this 7GB library.

To a very rough approximation the library size is given by:

(number of managed masters * master size) + (number of versions * 500k) + (number of previews * 3MB)

Tags: Aperture, Q&A, Size, Library, Thumbnails, Previews

There are diagrams, pie charts, venn diagrams and more at Jessica Hagy's site, Indexed. They cover many topics: car accidents, television, Thanksgiving, and GPS, just for a start. Some of them are available on tee-shirts. And there's a widget too.

Tags: Fun, Cartoons, GPS, Accidents, Television, Thanksgiving, Tee Shirts

Greg Newman has cheat sheets for Aperture and Lightroom on his site. His screen shots take you to Flickr, so don't go there.

What you really need is to look for the links under the images and download the ZIP files, two for Lightroom (Mac and Windows) and one for Aperture. After unzipping you'll find a large PNG image for on-screen use and a PDF for printing.

Tags: Aperture, Lightroom, Cheat Sheets, Tips And Tricks

A report that says iPhone browsing is approaching 0.1% market share has been causing a stir. It doesn't sound like a large amount, but the device has only been out for 5 months and that is a bigger share than a decade of Microsoft-based phones.

The stats for this blog show an even bigger percentage of mobile Safari users, close to that of Linux.

The yellow sliver is iPhone, and the blue sliver below it is iPod. Here are my numbers:

Macintosh	80.12%
Windows	17.97%
Linux	0.96%
iPhone	0.56%
iPod	0.22%
(not set)	0.12%

Here's the Wild Guess. Comparing my stats to those in the article, it is interesting to note that the ratio of Macintosh page views to the sum of iPhone and iPod page views is about the same: 100:1. So I conclude that roughly one in a hundred Mac owners have a mobile browser now. But with unit sales of Apple's mobile devices running something like 50% of Macs, I'd expect the 100:1 ratio to change dramatically over the next year: maybe to as much as 10:1.

Tags: iPhone, Linux, Microsoft, Apple, Browsers, Wild Guesses

Thomas Dolby (yes, that Thomas Dolby) is having a lifeboat delivered:

I’m going to sleep on it, but I think I’ve found my lifeboat. She’s on blocks on a farm in Berkshire, about as far from the sea as she could get, and still be on the British mainland. She’s somewhat neglected—in fact the owners are planning to burn her unless I buy her this week—but she has enormous potential. A lovely mahogany interior, and a wheelhouse to die for. I’m not going to tell you any more about her until I make up my mind, but let me just say this: she is a boat born out of necessity, and if I decide she’s the one for me, I will abandon myself to a whole new romance with a wonderful ship, the open sea, and my imagination a blank sheet of manuscript to fill with the soundtrack!

You can read all about it on his blog. And I thought it was submarines he was missing.

Tags: Thomas Dolby, Lifeboats, Music, Submarines

Jellyfish: 1/20s f/2.8 ISO1250 @55mm, Canon 30D, Canon EF-S 17-55mm f/2.8, adjusted, cropped

I've put together what I think is a comprehensive list of ways to speed up Aperture. Some are quick, some are cheap, some are neither.

Get A Faster CPU Or More CPUs
Up to a point more GHz and particularly more CPUs will speed up Aperture. I say up to a point because there are diminishing returns as processors are added. And because CPU speed is secondary to GPU speed. Which brings me to...

Get A Faster Graphics Card
Aperture is very GPU-intensive. If you are buying an iMac, get the fastest graphics option you can, and get the most VRAM you can. If you have a Mac Pro, then configure it with fastest graphics card option find with the most VRAM. When you have your card...

Plug The Graphics Card Into The Fastest Slot
That's going to be a 16x PCIe slot on most machines. Second best is an 8x slot. If you have two graphics cards then put the fastest one in the fastest slot. And to run two screens with Aperture...

Connect Both Screens To One Video Card
It's much faster to drive both screens from one card because the CPU only has to transfer the data once to the card to have it available on both screens. And also because that one card will be in the fastest slot. But even if you have two screens you can make things faster ...

Use The Smallest Screens That Are Useful
Yes a 30" Cinema display is very nice, but you will get more speed out of 23" simply because there will be fewer pixels to process. Another reason for smaller screens is that the larger the screen, the more VRAM is used, and so the less that is available for cached images and the slower the overall performance. Or if you don't need the second screen...

Use Just One Screen
One screen will be faster than two for all the reasons that apply to using a smaller screen.

Add More RAM To Your Mac
Running Aperture on a machine with less than 2G of DRAM is asking for slow. Consider 3G a minimum, particularly if using RAW.

Get A Faster Hard Drive Or Use Striped Hardware RAID
A faster hard drive will have some impact on the speed of Aperture, but not as much as you might expect. The fastest set-up will have internal or eSATA drives running in a striped arrangement so that data can be read from both drives simultaneously. Hardware RAID will ensure that writing is fast as well.

Make Sure You Have The Latest Version Of Aperture
Each release has run faster than the previous one, so be sure you are up to date. While you are at it...

Install Leopard
While Leopard does appear to have some odd problems for some Aperture users, it also runs faster and smoother. At some point Aperture will be optimized for Leopard, not just compatible with it and we'll see a big speed bump.

Set Processor Performance On Fastest
Older PPC machines and some laptops have a setting in the Energy Saver preferences to run the processor at different speeds. Select the Fastest setting.

Plug Your Laptop Into The Mains Power
I'm guessing here (since I don't have a laptop), but it is normal for laptops to run faster when plugged into mains power since they have no need to conserve power drain. Speed throttling when used on battery includes the GPU these days, so will have an impact on Aperture.

Turn Off Spotlight
If you have images on a drive or partition separate from your boot disk, disable Spotlight for that drive. This will prevent the OS from attempting to index and reindex the library and its images and will make things a little faster.

Reindex The Aperture Database
Each library has an SQLite database that exists to speed up access to all the images and metadata. Over time the index for this database gets fragmented and so is slower. So about every month or so, it is worth forcing that index to get rebuilt (see Applescript here). It takes a few minutes and can have dramatic results. It's much faster than if you...

Rebuild The Aperture Database
By starting Aperture with Option and Command held down, the database will be rebuilt. This can take a few hours because Aperture has to read all the files in the library to collect all the data and store it in a new database. But it can work miracles.

Turn Off Previews
Generation of high resolution previews can eat up a lot of processing capacity as well as disk space. If you don't need them, then turn them off and delete them. Thumbnails up to 1024 pixels are always generated, so there is nothing you can do about that.

Turn Off Sharing With iLife
Sharing previews with iLife uses an XML file that is regenerated when Aperture quits. This can take a long while if there are a lot of previews, so by turning off iLife sharing quitting can go faster. You will find the setting in Aperture's preferences.

Turn Off Anti-Virus
Anti-virus software is invasive and very resource-hungry. Turn it off for a dramatic improvement in speed.

Make Changes To The Keyword List With No Thumbnails Showing
In some circumstances changing the keyword list -- things like renaming or rearranging the keywords -- can go extremely slowly. These delays can be almost completely eliminated by ensuring that the browser is not showing any images when the keyword list is changed.

Use A Small Viewer
Since thumbnails are generated at 1024 pixels size, using a viewer that is equal to or smaller than that can give some speed up. The thumbnail is almost identical to the processed RAW image, so many decisions can be made immediately without having to wait for the full image to load.

Turn Off Automatic Version Generation For Adjustments
Aperture has a peculiar option in its preferences that make it generate a new version every time a slider is moved or a button clicked on the adjustments HUD. This makes things very slow since Aperture generates thumbnails for each of these versions. Turn that option off.

Use A Firewire Card Reader
Most card readers are USB and USB is not particularly fast. Firewire card readers can run at more than twice the speed, especially if using several of them at once.

When Adjusting, Crop First
That might seem like odd advice, but cropping first results in fewer pixels that must be calculated and displayed and hence faster operation. Since this is Aperture and the workflow is non-linear the crop can be adjusted at any time if you are not happy with it.

Turn Off All The RAW Fine Tuning Settings
The RAW Fine Tuning settings are all turned on by default. You may not actually need them, and if you turn them off you will find that RAW processing is quite a lot faster. You can do this by changing the settings on one image and then using lift and stamp on the others.

Don't Display The Histograms
Calculating the histograms takes time and computing resources. Turn them off if you don't need them, or hide the whole adjustments panel or HUD if they are not in use. The cog menu on the HUD gives control of the histograms.

Use Slow Adjustments Last
The Highlights, Shadows, Straighten, and Spot tools are notoriously slow. So after cropping first, do everything else except those next and finish up with the slow tools.

Don't Use Full Text Search
Aperture's full text search will do a linear search of all the text available, including captions. This makes it very slow for large libraries. Instead use a limited text search if you can. A limited text search only searches text that is indexed by the database, so is much faster. Change the setting by clicking the magnifying glass in the search box.

Don't Fill Disks To Capacity
A consequence of the constant rotational velocity of hard drives is that data close to the edge of the disk can be read and written at twice the speed of that close to the spindle. Disks are filled from the outside inwards because this gives the highest data rates for the first data written to the disk. As disks are filled to capacity, the data rate slows, so fill disks only to 50% to 75% capacity for best performance.

Keep Projects Small
Small projects are faster to work with in Aperture, probably because the opportunity for caching images and database information is greater. Less than 1000 images is a good rule of thumb. Use blue folders to combine small projects into larger groups for easier management.

Use JPEG Images
JPEG images are much faster to work with in Aperture than RAW or TIFF. Rather than use RAW for everything, use JPEG where you can get away with it. Either shoot JPEG or RAW+JPEG, or just get the levels right with RAW, export as JPEG and reimport for all the remaining operations.

Use Smaller Images
Smaller images are processed faster than larger images. So unless you need the pixels, don't put them into Aperture in the first place. Shoot at less than the camera's maximum resolution, or export and reimport JPEGs at a smaller size.

Delete Aperture's Preferences File
Some weird slow-downs and delays are cause by corrupted application preferences. you can rid yourself of these by removing the preferences file and restarting Aperture.

Did I miss any?

Tags: Aperture, Speed, Tips And Tricks

Cocoa Cheerleaders is brought to you by the team at PyrusMalus. It's a large collection of links to blogs, articles, books, code, and other information about Cocoa.

My interest piqued by the name, I discovered that PyrusMalus is the Latin name for the Domestic Apple tree. And there is a mystery application in the works looking for alpha testers called Atlantic.

Tags: Cocoa, Cheerleaders, Blogging, Programming, Books, Apple, Applications

Gruber has a short article that references a longer article on why the iPhone uses regular (gray-scale) anti-aliasing instead of the clever sub-pixel method used by OS X. He concludes that the pixel density is high enough that regular is good enough.

But there is a very simple reason that sub-pixel is not used on the iPhone: screen rotation. Sub-pixel anti-aliasing relies on the increased spacial density in the horizontal direction of the individual color bars (and on the pathetic color-resolution of eyes). Once you switch vertical and horizontal by rotating the screen, this no longer works and you have no option but to have a high-enough pixel resolution to make simple anti-aliasing work well. It also helps that sub-pixel anti-aliasing takes a lot more computation than simple, and you want to minimize that in a portable device.

The 160 dpi used on the iPhone is probably about the minimum you can get away with. The current 100 dpi of Cinema displays is about a factor of 2 better (100 * 3 = 300, just about 2 * 160 = 320) than the iPhone. And in Leopard in the places where sub-pixel anti-aliasing is not used, you can see the difference in the way the text looks and it is irritating.

Tags: Gruber, iPhone, Anti-Aliasing