TidBITS Issue #926

|

Apple Reports Record Q2 Financials

Apple posted record laptop sales in its second fiscal quarter of 2008, and nearly every other metric other than gross margin saw significant increases over Q2 2007. Notably, Apple retail stores are now averaging $7.1 million in sales.Show full article

Apple has released its Q2 2008 financial report, showing strong results pretty much across the board for the first three months of 2008. Quarterly revenues were $7.51 billion, leading to a net profit of $1.05 billion, or $1.16 per share. In comparison, the same quarter last year saw revenues of $5.26 billion and a profit of $770 million, or $0.87 per share. That works out to a 43 percent increase in revenues year over year, and a 36 percent increase in profit.

While revenue was high - down from the Q1 2008 holiday quarter that encompassed the last three months of 2007 but significantly above year-ago sales - it excludes an enormous amount of current iPhone revenue due to Apple's accounting practices. Apple chose to recognize iPhone revenue in its earnings more like a 24-month subscription than an outright purchase, as it accounts for Macs. Apple TV and AppleCare revenue is tracked the same way.

Apple further chose to defer all revenue for iPhones starting 06-Mar-08, the date they announced the iPhone SDK, until the iPhone 2.0 software ships. Their reasoning is that purchasers on and after that date bought their iPhones with the expectation of software that wasn't yet available. This is an extremely conservative method of deferring revenue, which now totals $3.8 billion for all money they're not yet counting. Some of that logjam will break in the next quarter as a result. (If you ever thought AppleCare was chicken feed, note that it has accumulated $1 billion in deferred revenue as of Q2 2008; that revenue is offset in part by the expense in fulfilling warranty repairs.)

Apple said in January 2008 that the iPod touch has all its revenue counted immediately, which was the justification for charging for a software update; the same will be true for the 2.0 software release for the iPod touch.

International sales accounted for 44 percent of revenues, slightly up from 43 percent in the year-ago quarter, but slightly down from 45 percent in Q1 2008. Japan showed the most strength, with a 49 percent increase in revenues from the year-ago quarter, compared to 45 percent for Europe and 46 percent for the Americas.

The strongest single segment growth, however, came from Apple's retail stores, which increased revenues by a whopping 74 percent over Q2 2007. The stores took in $1.5 billion, which averages $7.1 million each, calculated using the 205 stores open for most of the year. The year ended with 208 stores, and plans are to open 45 more in the 2008 fiscal year. In late 2006, one analyst figured that Apple was making far more per square foot than diamond retailer Tiffany and Co.; unless Tiffany has likewise experienced similar growth in sales, Apple now vastly outpaces all other retailers.

Apple's cash balance increased from $18.4 billion last quarter to $19.4 billion, giving the company more than enough working capital to introduce new products, or perhaps buy a small country. Microsoft, under pressure from shareholders, introduced the slightly-out-of-fashion idea of a quarterly cash dividend when sitting on a bit more than twice as much cash in 2003; Apple doesn't seem to have any truck with that idea.

Most compelling was the increase in Mac sales, up 51 percent in unit sales from the year-ago quarter and up 54 percent in revenue. As has become the trend, laptops led the charge, with 1,433,000 sold (up 61 percent), the most laptops sold in any quarter for the fourth quarter running, in comparison with 856,000 desktops (up 37 percent). Laptop sales even outpaced Q1 2008, which included the holiday season. Just two years ago, in Q2 2006, Apple sold only 498,000 laptops.

iPod sales were, of course, way down from holiday Q1's 22,121,000 units, with 10,644,000 sold in Q2, but showed only a slight 1 percent increase in unit sales. The iPod did post an 8 percent increase in revenue over the year-ago quarter, thanks to an increased volume of iPod touch sales. The iTunes Store (with iPod services and iPod accessories) accounted for $881 million in revenue, up 9 percent from Q1 and up 35 percent from the year-ago quarter.

Apple sold 1,703,000 iPhones, which is a drop of 26 percent from Q1, but interestingly, a 57 percent increase in revenue, which implies that Apple is making significantly more per iPhone, even though that excludes the deferred revenue noted earlier. The company has sold 5.7 million iPhones worldwide to date, and confirmed their forecast of a total of 10 million iPhones being sold by the end of 2008.

Peter Oppenheimer, Apple's CFO, said that the company expects to see revenues of about $7.2 billion and earnings per share of about $1.00 in Q3 2008. Meeting that goal would amount to about a 33 percent increase over Q3 2007.

The only notable negative in the report, other than the slowing growth in iPod sales, came from gross margins, or the percentage Apple earns from sales. For the current quarter they were 32.9 percent, down from 34.7 percent last quarter and 35.1 percent in Q2 2007.

Business Apps | 23 Apr 2008 | Listen

|

Microsoft Offers Online Storage, Sync through Live Mesh

by Glenn Fleishman

Live Mesh from Microsoft combines online storage, cloud computing, desktop folder synchronization, and remote access. But the real news about the technology preview is its reliance on well-used standards, and its notion of enabling developers to build whatever they want on Live Mesh's base.Show full article

Microsoft revealed its first truly new thing in a long while by discussing Live Mesh, a set of tools and services that enables users to synchronize data automatically from their desktop to a cloud service - Internet-based storage - while providing a framework for developers to create software that can offer the same kind of experience no matter where data is stored and no matter what kind of device is used.

Collaboration among multiple people for sharing information and keeping up to date on what others in a group are up to - personal or professional groups alike - is a key part of Live Mesh. And, yes, Mac support is planned and promised, not just loosely discussed, according to this blog entry by Live Mesh's product manager.

Live Mesh combines elements of services and software that are already extant, although it has the potential to be something more sophisticated. Apple's .Mac subscription service ($99.95 per year) lets Tiger and Leopard users synchronize data via iDisk, with Mac OS X automatically handling updates to files that are modified, added, or deleted. That's replication and synchronization, but apart from record-level support in a relatively small number of applications (mostly from Apple) like Address Book, iCal, and Yojimbo, .Mac's syncing isn't very granular. Nor does it offer particularly good performance for large quantities of data.

Part of the Live Mesh preview shows how someone could choose to add specific folders on any device to Live Mesh, and then manage which of those folders appear on which other devices. These folders can be shared with other users, too. Here Live Mesh goes far beyond .Mac and most other online-file-sharing services by revealing on the desktop which other users are accessing the folder. That's part of a general "news feed" attached to each folder that also reveals changes and other information, and which can be extended by third parties. (I've long wanted better controls even in Leopard when I'm sharing folders via AFP as to who is connected to a given folder and for how long; that's typically a server feature.)

The system also allows remote desktop access, a la Timbuktu Pro, GoToMyPC, or, dare I say, it, Back to My Mac. I am reluctant to mention Back to My Mac only because of the many, many stories I have heard from readers of TidBITS about their difficulties in getting it to work (see "Punching a Hole for Back to My Mac," 2007-11-07).

Microsoft is initially giving 10,000 developers access to Live Mesh's underlying technology; user access is some time away. Many different product managers and high-level folks at Microsoft have said at its introduction that Live Mesh is a platform, not a monolithic service. All the components of Live Mesh should be available to developers, meaning that programmers and companies can build software that lives on top of the Live Mesh system, integrating its features without having to build them from scratch themselves. I also invite brickbats when I point out that Live Mesh can be used with standard, well-understood programming languages (including flavor-of-the-year Ruby on Rails) and delivers information via standard, non-proprietary protocols. Even Apple's Cocoa programming framework is listed among the technologies that will interoperate with Live Mesh.

This is an awfully popular concept, all of a sudden, offering a cloud of computational service and storage on which to build rich applications that can run on devices ranging from desktop computers to smartphones and other handhelds, scaling capabilities and complexity to each platform.

Amazon's cloud computing services - S3 for storage, EC2 for on-demand virtual machines, and SimpleDB for a form of database storage - is one instance of this trend. Google App Engine, launched last week, is another. Even Adobe AIR fits partly into this category, by providing a cross-platform way to access the same underlying data no matter where it's stored, while displaying an interface appropriate for the device you're using.

Live Mesh appears to be the first major effort led from idea to implementation by Microsoft Chief Software Architect Ray Ozzie since he accepted this role two years ago. Ozzie was promoted to one of Bill Gates's former job titles to reinvigorate Microsoft's applications and platforms; he's been involved with creating or shaping some of the most important business and collaboration software over a nearly 30-year career, notably Lotus Notes. (I said important, not best-loved.)

Ozzie's full memo to Microsoft employees about Live Mesh is instructive because it lays out his, and presumably Microsoft's, overarching view: the future of Microsoft and the Internet is about turning to the Web as a hub of social and mobile device interaction in which information must be accessible easily in many ways with little lock-in or proprietary complexity.

Is it a new day at Microsoft? The company has certainly upped the ante, and introduced a platform that has the potential to attract an entirely new audience, and shed their image as a slow-moving organization tied to proprietary specifications where the applications and operating system constrain what's possible. Live Mesh implies a flowering of interoperability, simplicity, and openness. We'll see if Microsoft can deliver on that promise, or if the cash cows of Windows and Office cause too much drag for Live Mesh to overcome.

Inside TidBITS | 25 Apr 2008 | Listen

|

Take Control News: iPhone Ebook Now Covers iPhone 1.1.4

Taking advantage of our freedom from print, we've released an update to Ted Landau's "Take Control of Your iPhone" that makes it unique among books in covering the iPhone 1.1.4 software.Show full article

Inside TidBITS | 28 Apr 2008 | Listen

|

Dutch and Japanese Translators Wanted!

If you can read English and write in either Dutch or Japanese, we need your help in translating TidBITS!Show full article

Inside TidBITS | 28 Apr 2008 | Listen

|

DealBITS Drawing: Win a Copy of HoudahGeo

If you've ever wanted to geocode your photos, check out this DealBITS drawing for HoudahGeo, which provides a variety of automatic and manual ways of assigning geographic coordinates to images and can help you share your photos via Flickr or Google Earth.Show full article

Media Creation | 25 Apr 2008 | Listen

|

Hand Coding HTML Is Still in Vogue

by Glenn Fleishman

Graphical Web design tools are all well and good, but most sites with any substantial amount of regularly updated content still code by hand - including TidBITS and the venerable New York Times.Show full article

Back in 1994, when I first learned to write HTML code for display in NCSA Mosaic, I thought, "There's got to be a better way." After all, I was coming off nearly a decade of typesetting and working with desktop publishing, starting with a Mac Plus and PageMaker 1.0 at my high school's newspaper. The code never bothered me; I had also learned in high school how to code on a Compugraphic typesetting system that used a similar method of embedded tags for formatting. But this was 1994! Surely, a graphical editor existed that would put a nice wrapper around HTML's intricacies.

It's therefore rather amusing to recognize that after 14 years of such editors - FrontPage, PageMill, GoLive, Dreamweaver, and many others, with few surviving the hecatomb - hand coding still rises to the top as the preferred method of building pages. Khoi Vinh, design director at The New York Times, noted in a recent reader Q&A segment on the Web site, "It's our preference to use a text editor, like HomeSite, TextPad or TextMate, to 'hand code' everything, rather than to use a wysiwyg (what you see is what you get) HTML and CSS authoring program, like Dreamweaver. We just find it yields better and faster results." (GoLive, by the way, bit the dust today.)

Vinh isn't really dissing Dreamweaver here; rather he's pointing out something that I've seen develop organically over the last 14 years: graphical tools don't work well with the template-based systems that drive most Web sites of any scale, including TidBITS and The New York Times.

Most Web sites aren't built from static pages, but are collections of widgets, server-side scripts, IFrames (for embedded content drawn from other servers), and placeholders that insert information built in a content management system (CMS). These tend to be highly idiosyncratic. Even when purchased as a commercial system, the customization often makes it impossible for a graphical Web tool to provide proper editing and previewing.

In these systems, a template defines how a page is built when a particular request comes in. When you ask db.tidbits.com for "/article/9569," for instance, that's not a static page in an article directory. Our system breaks that request down into a query for an article with a GetBITS number of 9569. The system pulls in data from several tables in a database, and plops the results into a template that also references a variety of dynamic elements that need to be inserted, such as ads and links to TidBITS Talk discussions. That's what's fed out to you as a Web page.

This kind of hand coding isn't precisely the same as writing each page of HTML by hand; rather, it's more like handcrafting a prototype, such as a sculpture or machine part, which is the reference used to create mass-produced objects. A small imperfection in the prototype mars all the copies.

We built a CMS behind TidBITS to help manage the flow of content, and to make ourselves at least a little more agile. If you're a long-time reader, you'll note that we produce more content on a regular basis than we used to because the CMS streamlines a hunk of the process we had before. (We're still working to further streamline and extend our TidBITS Publishing System so we can have a better blog posting system, more translated articles, a way to display short items more effectively, and other improvements; see "Designing a Modern Web Site for TidBITS," 2007-09-10.)

In the late 1990s, I was building pages using scripts to dump thousands of static pages with some homebrew templates. But I was also working with designers on sites of hundreds of pages where GoLive, FrontPage, or Dreamweaver managed recurring components. The move to templates coincided with the rise of content management systems that actually worked. Content could be centrally stored and fielded, so you could rapidly update a story and publish it in different ways in many places. A headline might be updated on the home page, the story's main page could change, and a blurb from the story could appear elsewhere, all while bringing the RSS feed into sync.

As designers of larger sites have grown accustomed to hand coding, the graphical tools have improved so that even inexperienced users can design and deploy good-looking sites with relatively little effort. I'm fairly impressed with Apple's latest release of iWeb, which ditched a lot of bad code and bad ideas from its previous version, and seems to produce more than passable cross-platform HTML and JavaScript. Likewise, I've tested an online-only editor called Easy WebContent that has remarkably powerful tools for a Web-based editor. (I reviewed Easy WebContent for PC World, although it's platform agnostic.)

And Dreamweaver, as I say, doesn't need to be dissed. Its CS3 release is the easiest version I've ever used. I manage my personal site, glennf.com, in Dreamweaver and am perfectly happy with its range of control.

It's somewhat ironic that a display language like HTML, which initially had a high bar of entry, requiring people with some understanding of structured text or programming to figure out how to write code that appeared properly, now has a different but similar bar. To build rich, complex sites with ever-changing and expanding content, you almost certainly need to get under the hood and get your fingers dirty with some sort of templating system.

Safe Computing | 23 Apr 2008 | Listen

|

QuickTime Security Enhanced with Anti-Exploitation Technologies

by Rich Mogull

QuickTime 7.4.5 offers more than just specific security fixes - in it, Apple started activating anti-exploitation technologies to protect users even when there are software vulnerabilities. But when will we see these technologies fully implemented in QuickTime, or even Leopard itself?Show full article

Apple did more than merely patch a few (okay, 11) vulnerabilities with the recent release of QuickTime 7.4.5. According to a report from eWeek this update also included a series of improvements, for both Mac OS X and Windows Vista, designed to improve QuickTime's fundamental security by making vulnerabilities harder for attackers to exploit. To understand why these are so significant we need to take a moment to review a little bit about how bad guys attack computers, and why QuickTime is particularly difficult to secure.

As I discussed in my preview of Leopard security (see How Leopard Will Improve Your Security, 2007-10-22), a group of software bugs called "buffer overflows" are the favorite target of attackers. Buffer overflows are a vulnerability where an attack enters more data into an input than expected; if the programmer who wrote the software forgot to limit that input field, the data can flow past the expected limit and overwrite other parts of memory. Since memory on most of our computers is just a big stack of commands mixed with data, if you know exactly how much extra data to put in, you can trick the computer into running an arbitrary command by overwriting a spot where it expects a legitimate instruction with your malicious instruction. Done correctly, it gives an attacker complete control over your computer.

QuickTime, like many media players, is plagued by these vulnerabilities due to how it's built, and the unique demands of software that's expected to deal with real-time audio and video files in dozens of formats.

When you install QuickTime it includes extensions programmed in Java, which is a high-level language. A low-level language, like C, requires programmers to manipulate memory and the CPU almost directly. C is the foundation for nearly all of our software, even other programming languages, but is notoriously difficult to program and debug. It's like building a home with only hand tools, where more often than not you need to carve your own two-by-fours. High-level languages like Java make life easier for programmers by removing many tedious tasks, like managing memory. Java is also interesting because it's designed to let programmers write software once, then run it on any operating system that supports Java. In reality it's seldom that simple, but for the most part if you write a Java program for Mac OS X, it doesn't take much to enable it to run on Windows or Linux.

Because programmers don't directly manipulate your computer's memory in Java, it's nearly immune to buffer overflow vulnerabilities. In theory, this makes those Java extensions extremely secure. The problem is that Java isn't very good at things like audio or video that require really high performance, and we find ourselves going back to C. In the case of QuickTime the main program and all the plug-ins that play those media files on your computer are written in C code, making them potential targets for buffer overflows. Even worse, the very complexity of handling large media files increases the odds of a buffer overflow, since it isn't like the programmer looking at a video of unknown size can just impose a 140-character limit on an input field.

The way QuickTime works is that the main code processes the audio and video, then sends it to a plug-in (often called a codec, for "compressor-decompressor") that understands that file format and turns all those zeros and ones into high definition video with surround sound. It's hard for QuickTime to validate all this data, and the processes of handing things off between parts of the program itself are extremely complex. On top of that, the Java extensions add an additional layer of complexity, are nearly always available to an attacker, and expose parts of the QuickTime program that aren't normally accessible through a Web browser. The result is that attackers take advantage of this extra exposure and these complex handoffs to all the other bits and plug-ins programmed in C.

It turns out these Java extensions are one of the top three sources of security vulnerabilities in QuickTime. The next major source is the processing of all those different types of media files with all those different codecs; attackers craft malicious audio or video files that crash the player and create buffer overflows. The last problem also relates to supporting all those media types; attackers exploit vulnerabilities in the part of QuickTime that's responsible for first figuring out just what kind of file it is and what codec to use. They modify the file headers and exploit QuickTime before the file's contents ever get sent to the codec. QuickTime is thus difficult to secure because it has to be all things to all media files, and is written using multiple programming languages. QuickTime's main body and Java extensions are never really sure of what kind of data we're sending along, and must shovel data down to the C parts for processing. These interactions increase the odds of a buffer overflow somewhere along the way, or even in the process of the different bits talking to each other. QuickTime also supports random third-party plug-ins for new media types, which it has no way of protecting.

One way to reduce the chances of a successful buffer overflow attack is to protect the way the software interacts with memory. That's why we call this "anti-exploitation" - even if the software is vulnerable to a buffer overflow, such technologies make it harder for the attacker to turn that into a successful exploit of your system.

One example of this is the Address Space Layout Randomization (ASLR) technique used in Windows Vista. For the attacker to do anything specific on your system after they overflow the buffer, they need to "point" to operating system commands in memory with the instruction they insert. Vista moves all these commands around randomly every time it runs, so the attacker never knows where to point. With QuickTime 7.4.5, Apple added ASLR support to QuickTime, also moving around many of the QuickTime commands every time it runs. This keeps the attacker from being able to point back to any QuickTime commands and using that to take over the computer. Apple didn't enable this for all of QuickTime's commands, so QuickTime is still a little vulnerable, but it's a major step forward.

Apple included their own version of ASLR in Mac OS X 10.5 Leopard, but it doesn't work quite as well as Vista's. Called Library Randomization, it doesn't rearrange all the core system commands, and in particular it leaves fixed in place something called a dynamic linker that an attacker can still use to exploit the Mac. We're hoping Apple will fix this in a future update.

Apple also enhanced QuickTime for Mac OS X with two other ways of preventing a successful buffer overflow by protecting memory: stack protection and data execution protection.

In particular, stack protection could completely eliminate the possibility of an exploitable buffer overflow to the stack part of memory. Even if the attacker overflows the stack (where most user input and programming commands are held), stack protection should detect this and stop any of the attacker's commands from working. There's still another entire category of memory, called the heap, that's vulnerable, but exploiting heap vulnerabilities is considered more difficult than attacking stack vulnerabilities.

Data execution protection takes advantage of special hardware settings on Intel CPUs (and thus only works on Intel-based Macs). It enables programmers to set memory locations that will hold only data, and never execute commands, thus providing another way to foil a buffer overflow attack.

One area that will always present a potential problem for QuickTime is third-party plug-ins for new media types. Since Apple doesn't write or distribute these, there are no guarantees the programmers of said plug-ins will take the same precautions as Apple's engineers. It's one reason you want to be careful about installing third-party plug-ins.

The addition of ASLR, stack protection, and data execution protection doesn't make QuickTime immune to attack - buffer overflows are just one kind of vulnerability and Apple hasn't blocked every avenue of attack. In fact, just before publishing this article, eWeek reported a zero-day attack on QuickTime running in Windows Vista.

That said, the combination of all these changes is an excellent start with practical security benefits for any QuickTime user, which equates to nearly every Mac user (and an ever-increasing number of Windows users). Now that Apple has taken these steps with QuickTime, they need to work harder to extend similar technologies to Mac OS X in general.

Media Creation | 16 Apr 2008 | Listen

|

Cataloging Photos and Storing Them on the Computer

by Charles Maurer

Digital photography lets us shoot thousands of images, but keeping track of them is a growing concern. Charles Maurer looks at programs that enable you to apply keywords and other metadata to your photos so you can find them easily later.Show full article

Anyone who has ever heard me speak French will be surprised that there is something I do even worse: file papers. If the appropriate destination is obvious, I will usually put them away eventually, but I seem to be saddled with an unclear mind, for rarely do I find the destination obvious. For example, in front of me is an article on colour organs - 19th-century organs that projected colours while playing music. Do I file this under music, musical instruments, organs, colour, vision, or synaesthesia (the mixing of senses)?

My solution to such conundrums used to be to leave papers wherever I finished reading them until my wife got fed up with the mess and threw everything in a box. To find a paper - well, if it was still lying about and I had been noshing while I read it, I might try asking the dog to sniff out crumbs, but usually all I could do was hope to locate one paper by accident while searching for another. Only in the last few years have I come up with a sensible approach. Now I save them all on my computer in a folder called "papers" and search for the contents using CTM Development's FoxTrot (Tiger) or Spotlight (Leopard).

Pictures are different, though. There is no way to index images. To find pictures by their content requires (1) describing the content in words and (2) attaching descriptions to images. Both requisites sound simpler than I have found either of them to be.

Describing Picture Content -- Keywords are supposed to make it easy to find a photo. Computers can handle lots of keywords, so applying enough of them ought to let me find anything. Unfortunately, I can think up an impractical number of descriptors for every picture and I can never decide which of them not to include. For example, here are the keywords I came up with for this photograph:

workman, tradesman, builder, carpenter, sawyer, frame, framer, framing, saw, wood_saw, bowsaw, bucksaw, workplace, safety, workplace_safety, building, home_building, house, construction, house_construction, industrial_photography, portrait, industrial_portrait, travel_photography, travel_photograph, monsoon, clouds, monsoon_clouds, cloudy, barefoot, rural, China, Yunan, rural_China, rural_Yunan

In the hope of finding a sensible way to select keywords I consulted a professional photo cataloguer, Marcia Tiede, then at the University of Arizona's Center for Creative Photography. Tiede told me that if I wanted to identify a photo of a workman, one cataloguing convention would have me enter "workmen" instead. Ditto for 16 other words on my list - tradesmen, builders, carpenters, sawyers, etc. Beyond that, however, she could not make the job any more straightforward. She also suggested five more keywords: men, labourers, occupations, equipment, and tools.

Tiede explained that there is no standard set of descriptors. The U.S. Library of Congress publishes a two-part Thesaurus of Graphic Materials that some U.S. libraries use as a de facto standard but it is continually changing, so that the descriptor of a subject used yesterday or tomorrow may not be the same as its equivalent today. Also, the thesaurus is unwieldy, 830 pages and growing. On the other hand, despite its size, Tiede still finds it to be missing appropriate descriptors. If I were using it, this would be the list of keywords for that picture:

carpenters, saw, crosscut_saws, sawing_wood, safety, hazard, construction, houses, wooden_buildings, construction_industry, portrait_photographs, travel, equipment, tools, men, labourers, occupations, equipment, tools.

I took a long time to extract that list from the thesaurus. Tiede has been cataloguing photos daily for decades, so she is much more efficient. Still, she told me that it typically takes her about five minutes per picture, "often less but sometimes more." Describing pictures is so time-consuming that a bunch of museum administrators are trying to develop a catalogue formed by the public like a wiki, and - apparently Tom Sawyer is alive and resides in California - Google Image Labeler is trying to induce the public to identify pictures in Google's index by turning keywording into a game.

While talking with Tiede, it struck me that an index of keywords could be useful for particular, delimited circumstances but in most cases, their selection must be so limited and haphazard that searching might be no less efficient if keywords were not used at all, if a richly descriptive caption were used instead, a stream of text that would flow more easily from the mind. Tiede agreed. She told me that this is being tried in library circles, often with the addition of syntactical markers that form an extension of the World Wide Web called the Semantic Web.

Linking Photos and Descriptions -- Attaching this information to photos presents more problems. No organization maintains a standard for the EXIF information supplied by the camera - it is an ad hoc convention of camera manufacturers - and the IPTC (International Press Telecommunications Council) standard for storing textual metadata within image files has been evolving over the years. Indeed, the latest version is extensible, to allow for further change. The standards and practices are sufficiently chaotic that not all applications recognize the same fields and the same field may appear with different labels in different applications. Some applications permit you to enhance this confusion by defining fields of your own, which may or may not be in a format that another application will recognize. Finally, to read and edit the metadata of an image, an application needs to read and save the entire image file - perhaps 100 megabytes to change 1 kilobyte.

(If your pictures are smaller - if they are closer to 1 MB - then your pictures are compressed as JPEGs. This compression loses information, so serious photographers usually save pictures in an uncompressed format and convert them to JPEG only to put them on the Web or to send them by email. Uncompressed photos run in the tens of megabytes. When working in Photoshop, it is normal to duplicate the photo into a different layer and work on it, then to repeat this process several times. In this way a final image can easily become hundreds of megabytes.)

To show you a selection of photographs, any application needs to display small versions of the original and make available any metadata attached to them. There are only a few ways to do this and each has limitations:

Read all the information from disk every time it's needed, and generate a small preview image whenever one is required. With uncompressed pictures this takes so much time that it is sensible only when cataloguing folders that change often, like the contents of memory cards.
Generate a preview image the first time it is required, and keep the small image and the metadata in a cache. This works with more pictures than the previous method but becomes awkward with large numbers.
Generate a preview image and put that preview plus the metadata into a permanent, efficient database. This approach can handle any number of pictures, but the database and the original files must be synchronized after any change to either. This kind of synchronization is easily mucked up, leading to confusion and lost work.
Generate a preview then put the preview and metadata into a permanent, efficient database, and move the original image there too. This prevents damage from improper synchronization but presents a long-term liability. All of the technology involving digital pictures is evolving rapidly, including the databases for storing them. A few years from now you may prefer to store your photographs differently and want to export them. However, it is one thing to export text from a database and it is another thing to export 100 MB images, especially if you have a lot of them. Finding the time and drive space to do this might be difficult.

Simple Tools -- My personal approach to organizing pictures is almost as haphazard as my approach to organizing papers. I lack the self-discipline to label them, but if I care about them I put them into folders labelled by the journey I shot them on or the subject's name. To find them, I negotiate those folders then root rapidly through thumbnail images and small previews. The Finder is almost sufficient for this task, but every time it needs a preview image, it draws a fresh one. On our computers, Finder's preview of a 100 MB image typically takes 6 or 7 seconds to appear. (This is on both a 2 GHz dual-processor Power Mac G5 with 8 GB of RAM and a dual-core Intel-based iMac with 2 GB of RAM.) This takes so long as to make rooting through folders of large images impractical.

The next step up from this is Adobe Bridge, part of Creative Suite 3 and Photoshop Elements 6. Bridge builds previews and caches them. It offers a rough equivalent of the preview mode in older versions of Elements or the browser in GraphicConverter. Since I own Adobe Bridge, I tried it for awhile, but I found that, although an improvement over the Finder, it is still sluggish. Also, it will not let me edit one string of text that I often need to, the date and time that the photograph was taken. I rarely remember to change these in my camera while crossing time zones, and a couple of times I have set a camera to the wrong day or year, so I often find myself needing to correct the date or time in the image file.

Aperture and iPhoto -- At this point I decided to try Apple's Aperture. This is the big brother of iPhoto that is aimed at advanced amateurs and pros. Aperture offers many more tools than iPhoto for identifying, selecting, and manipulating pictures but iPhoto '08 has been changed to work much like Aperture under the hood, so my comments on Aperture apply to iPhoto as well, except as noted.

Aperture generates its own database, importing original photos into a proprietary data structure, and generating copies of each for quick previewing. This provides the advantages and disadvantages I mentioned above: speed and safety for the nonce with a long-term liability if - or, more probably, when - the time comes to store your photographs differently. However, when I tried importing files that contained descriptive metadata, I saw some of my information but not my captions or keywords. Aperture keeps all the metadata separate from the photos and will embed the metadata only if you export a picture.

Besides storing photos, Aperture can edit them. Aperture's editing tools are far more numerous and sophisticated than iPhoto's but they are still meagre. I would find it essential to augment them with some third-party plug-ins Apple just announced but even with those there are still some huge lacunae: no way to control perspective, correct distortion, or reduce optical blurring (as in Photoshop's smart sharpening controls). (See "Aperture 2.1 Adds Plug-in Capability to Edit Photos," 2007-09-07.) Also, there is no way in Aperture to select only part of an image and have either Aperture or a plug-in modify only that part.

Aperture's editing tools also generate a long-term liability. When you edit a photo either with an external editor or with a plug-in, Aperture duplicates it first and sends out the duplicate for alteration, but Aperture's built-in editing tools work differently. Those do not change the original image; they are mathematical instructions that are effected only when writing to the screen, printing, or exporting a file. The instructions fill little disk space and they can be changed or reordered at any time. However, if Apple ever changes an algorithm in a future release of Aperture, then at a stroke, all of the photographs that you painstakingly modified will be changed. Of course Apple is aware of this, and in a telephone briefing, a product manager assured Adam and me that Apple would always leave the original code in place so that users' photographs would remain unchanged, but "always" is a very long time for a company to maintain outdated code. To know that your editing is saved permanently, you need to create a copy of the file by opening it with a plug-in or an external editor, or you need to export the image.

Aperture displays a JPEG of the last state of every image, and attaches your keywords to that JPEG. Thus, if you ever cannot access your pictures through Aperture, you will still find a set of labelled, edited photos buried in Aperture's data package. (A package is a folder that looks like a file but can be opened in the Finder like any other folder by selecting it, Control-clicking, then choosing Show Package Contents in the contextual menu that appears.) They will only be JPEGs, not TIFFs or raw images, but at least you will have a complete set of pictures and metadata in some format. (iPhoto maintains comparable JPEGs in its iPhoto Library package but does not attach any metadata to them, so if you ever lose access to your iPhoto database, your keywords will be gone. However, unlike earlier versions, iPhoto '08 does attach your keywords to photos if you export the images.)

Aperture's user interface is much improved in the current version, and most of its icons and controls are labelled clearly in English, but it still uses close to two dozen hieroglyphical characters. They may be called icons but they are hardly iconic. I find them difficult to interpret and even difficult to make out with my monitor at the back of my desk. On top of that, their explanatory tooltips are not Apple's standard black on yellow but white on black, which makes them difficult to read. It is no accident that books are printed in black ink on white paper, or that black on white won out over reverse video in word processors. For optical and other reasons, black text on a white background is more legible than white on black. Apple's use of white text on black is a fatuous triumph of fashion over function.

Apple permits a choice of background behind your photographs, a choice running from black to white with a middling grey as the default. Grey is easiest on the eyes and black makes pictures look the best, but white gives the closest indication of how the pictures will look when printed. Since the primary purpose of Aperture is to sort pictures for printing, I want to use a white background - but I cannot. Aperture makes this impractical because to indicate a selection, it surrounds pictures with a white frame, not with a contrasting tone or a colour.

Apple's user interface guidelines eschew gibberish in menus, but Aperture sports Show Inspector HUD, Show Keywords HUD, and Show Lift & Stamp HUD. "HUD" stands for "heads-up display," which is Apple's new jargon for a floating window. Each of these floating windows uses small type in white on black, which makes them hard to read and annoying to use.

Despite these problems with the user interface, Aperture 2 is much improved over previous versions. In other respects it is now a competent application. However, it is not an application that I want to use, irrespective of the interface. I want my metadata stored with my original photographs, and I have seen too much change in the computer world to want to tie my pictures to a vector-based editor, even if that editor could do all that I would want it to.

Expression Media and Extensis Portfolio -- At this point I looked at other photo organizers. I tried all I could find, including, among others, Extensis Portfolio, Microsoft Expression Media (formerly iView MediaPro), Adobe Photoshop Lightroom, MediaDex (the single-user version of Canto Cumulus), and QPict. I found the first two of them to be worth a close look, Portfolio and Expression Media. Both of them use the third structure on my list: they maintain structured databases of text information and previews but will synchronize their databases with the original files. Both of them work quickly, are reasonably reliable at synchronizing, and are reasonably robust. Expression Media can also edit pictures but its editing tools are rudimentary.

Of these two packages, Expression Media ought to be preferable - just about ideal, in fact. It has virtually every feature I might ever want and the next version, currently in beta, has the missing one: hierarchical keywords. If I ever define keywords, some of them will fit into categories, so a hierarchical display will make them easier to find:

format: vertical horizontal square portraits: friends relatives personal commercial

Aperture also offers hierarchical keywords, and iPhoto does through Keyword Manager, but Portfolio does not, and Portfolio has fewer bells and whistles as well.

However despite Expression Media's capabilities, I cannot stand the product, because of its user interface. I don't want to mouse through menus for every command and I can remember few keyboard shortcuts, so I want to use toolbars most of the time, but I find Expression Media's toolbar to be virtually useless. Instead of meaningful icons, it is filled with indecipherable hieroglyphs, hieroglyphs that are not labelled in English and contain no colour to help tell them apart. Moreover, half of the hieroglyphs are for commands that I never use, so that they add nothing but confusion, and the toolbar cannot be modified to remove them. Only the pop-up tooltips make the hieroglyphs interpretable, so for all intents and purposes, the toolbar functions as a menu that displays its items one at a time after a one-second delay. I tried changing some of the keyboard shortcuts to a set that I might remember, but some of the menu items would not change and adding a shortcut to one command did not remove it from another.

Expression Media's predecessor, iView MediaPro, was identical to the current version of Expression Media, except that its toolbar was better. The hieroglyphics in iView's toolbar were in colour and contained some interpretable icons scattered among them. This made iView's toolbar useable, and a useable toolbar made iView a useable product. I used it happily and would use it still, if Microsoft were still maintaining it. However, the toolbar in Expression Media drove me to Extensis Portfolio. Although Portfolio does not offer quite all of the features I would like, it has enough features to do the job and it has a nice Cocoa interface that I can configure to be comfortable and convenient. I prefer fewer features that I can find easily to more features that I need to search for.

With Portfolio, I have found satisfactory if not excellent ways to have it do everything I want, with two exceptions: it cannot change the date and time a photograph was taken, and it cannot create hierarchical lists of keywords. However, I found a free application that will let me change dates, Jim Merkel's PhotoInfo, and I suspect that before I learn to be assiduous about applying keywords, Portfolio's developers will have been prodded by their competition to add hierarchism.

Both Expression Media and Portfolio maintain a separate database for metadata but, unlike Aperture, they will also write metadata to the original files. This strikes me as a valuable feature. Nothing in the computer world lasts forever. Eventually you are going to need to or want to move your photographs out of Aperture. When that happens, to extract your metadata, you will need to export all of your photographs. That will require as much additional drive space as your photographs are occupying. An active photographer's files can easily grow into the terabytes, so duplicating them is not finding a space to park your car, it's finding the space to park an 18-wheeler. With Expression Media and Portfolio you can leave your pictures parked exactly where they are and merely change the program that catalogues them. All you need to do is make sure your metadata are saved to the image files.

Making the Choice -- My own assessment of Aperture is that its long-term liabilities leave it suitable less for professionals than for serious amateurs who just want an enhanced iPhoto with better editing capabilities. They are more likely to be filling it with JPEGs, not raw files and TIFFs, so the eventual exporting problem will be reduced by orders of magnitude. They are also more likely to find Aperture's editing tools sufficient.

Moreover, both Portfolio and Expression Media are better suited to the business world. Unlike Aperture, both of these products are available for Windows as well as Macs, and both Extensis and Microsoft supply free readers for both platforms, to allow professionals to send out databases on CDs. In addition, Portfolio is available in a multi-user version that will permit colleagues to share images over a network.

The choice between Expression Media and Portfolio is the choice between two sets of chefs' knives in a kitchen: a dozen stored in a knife block with the blades buried or six hanging openly on a rack. The first set has an ideal knife for every purpose but you need to pull out several to find the one you want. With the second set you may not find the perfect knife for a job, but you can find a knife that's good enough and find it instantly. I have found the difference between the applications to be most pronounced when choosing subtle variations on a theme - slightly different smiles in a portrait, for example. Each program will enlarge its small preview images to fill the screen, and will switch among full-sized previews instantly, but when images are very similar I want to compare them side-by-side, not sequentially. Expression Media will let me do this but Portfolio will not. With Portfolio I need to open the images I want to compare in Photoshop. This requires but a click on the toolbar, but the originals are much larger than the previews, so they take longer to open.

All in all, the difference between Expression Media and Portfolio is less a matter of function than of taste. I prefer Portfolio but that is a personal preference, not a recommendation. What I recommend is that you try them both side by side. Both are available as full-featured demos with 30 days of unrestricted use.

[If you found Charles Maurer's thoughts about photo cataloguing helpful, he asks that you make a donation to Save the Children. See the bottom of the page for links to the organization in different countries.]

Tech News | 25 Apr 2008 | Listen