At an invitation-only media event earlier this month, Apple introduced Aperture, the company's new professional photo workflow application. Simultaneous with Apple pulling back the covers on Aperture, they posted pages of information, screenshots and slick QuickTime videos showing the software in action. The next day, Aperture was the star attraction of Apple's spacious booth at PhotoPlus Expo in New York, where marketing managers and code-crunchers alike were kept busy answering questions about what to expect from v1.0.
All this Aperture activity has resulted in a lot of solid data coming available about what the program will offer when it hits the streets sometime in November 2005. In fact, if you haven't perused the Aperture section of Apple's web site, it's well worth the trip. The Quick Tour movies in particular showcase what Apple intends Aperture to be, which is an all-in-one pro imaging application centred around storing, viewing and converting RAW files. For a first release, Aperture appears to be packed full of useful features. And those features are wrapped up in the first truly-beautiful interface we've seen in an application aimed at working photographers.
Given the potential for Aperture to really change the pro photography software landscape on the Mac platform, we've wanted more information. A lot more. Well, actually, what we want is to see the Aperture installer's progress bar jogging across the monitor connected to our G5 desktop. But since that isn't an option yet, staff writer Eamon Hickey and I have had to content ourselves with peppering Apple representatives with the many questions raised by Aperture's impressive feature set.
This article, which is co-authored by Eamon and me, is a compilation of the answers we've received during interviews conducted with Apple's Joe Schorr, Product Manager for Aperture, and Rob Schoeben, Vice President of Applications Marketing. It's not meant to be a complete look at Aperture, nor is it meant to duplicate all the information that Apple has put out. It is intended to shed some light on areas of Aperture that we think are important, and for which we haven't seen a lot of information elsewhere.
Going to the Library
Before you can do anything with your photos in Aperture, they have to be imported into its Library. This is where all original RAW files (and the many other picture formats the application recognizes), processing instructions, caption information and other metadata lives. Keeping track of what's where is Aperture's database, which also exists within the Library. The data inside the original RAW file, called the master, is never altered by Aperture, promises Apple. Aperture is really designed from the ground up to free the photographer from having to perform many of the basic tasks of file management, in a way that will be appealing to working shooters who struggle with organizing reams of photos into a logical structure.
Aperture full-screen view (Screenshot courtesy Apple)
The Aperture Library itself takes the form of a package. This is a Mac OS X construct in which files and folders are housed in a parent folder that appears to the user to be a single file. Packages are used both as application and document containers; try control- or right-clicking on most any OS X application and, If [Show Package Contents] is in the contextual menu, you've clicked on a package. Choosing that menu item will open the package and reveal the items lurking within. The same will be true with Aperture's Library - it will be possible to browse its contents through the Finder, though there will be little reason to do so. And, if we're understanding one bit of technical information relayed by an Apple engineer at PhotoPlus, Aperture may be doing a checksum or some other sort of verification of RAW and possibly other picture files to see if they've been altered outside the application.
Aperture's Library can, theoretically, hold an unlimited number of pictures. Apple has tested it with Libraries containing hundreds of thousands of pictures, we're told. But Aperture will support only a single instance of a Library at a time, and that Library can be no larger than the hard drive it's sitting on, so the number of pictures that can be stored is capped by drive capacity and not a hard limit established in the software. In other words, you can have accessible and searchable in Aperture only the photos (and their associated processing instructions, caption data and other information linked to a given picture file) that can fit on a single hard drive. Or, a set of drives configured to be one big virtual drive (a RAID 0 array, for example).
It's possible to export a subset of the Aperture Library, as any set of pictures and data assembled into a Project can be saved separate from the Library (a single Project is limited to 10,000 master photos, plus any versions). But once an Aperture Project has been saved - to another hard drive, CD, DVD or other media - and subsequently removed from the Aperture Library to make room for new photos on the Library's drive, there is no reference remaining to the saved Project, no way to browse those photos or search based on caption information. It's possible to reimport Projects at any time, and a reimported Project brings with it all the pictures and related data. But drive capacity will always be a limiting factor in how many pictures can be live within the Aperture environment at any one time.
There may be one or more workarounds for this, including creating a space-saving medium-resolution JPEG, complete with caption information, as a proxy for each RAW file that forms part of an exported Project, or perhaps having separate Aperture Libraries for each year or subject type or some other classification. And we may also see third-party tools emerge to manage around Aperture Library limitations, as was the case with iPhoto in its early days. But clearly, for Aperture to be able to properly manage the ever-growing collections of pictures that working photographers are assembling, it has to support spanning a single Library across multiple non-RAID drives as well as provide a smart mechanism for browsing and searching pictures that are offline.
It's also worth noting that Aperture is designed for the individual user. It's not possible for several photographers, or a photographer and an assistant, to be accessing the same Library at the same time. This won't affect our use of the application, but it may hamper Aperture's usefulness for some.
Apple has included the ability to backup an Aperture Library into a Vault. A Vault is an exact copy of an Aperture Library. Once a Vault is first created, any additions or changes to the Aperture Library are made to an associated Vault incrementally during the synchronization process. The program can backup a Library to one or more Vaults, with the incremental updating of multiple Vaults happening either all at the same time (if the volumes containing the Vaults are all mounted simultaneously) or separately (as might be the case if it isn't possible bring all the Vault media online at the same time). In the event that it's necessary to restore a Library from a Vault, issuing a single command does the job. We don't know yet whether it's possible to pull single files, Projects or other smaller groupings of pictures out of a Vault and into the working Library. And we believe, but aren't certain, that a large Library can be backed up across several smaller Vaults too.
Though Aperture is designed to do a lot with JPEG, TIFF, Photoshop (.PSD) and most any other QuickTime-supported still image file, it's really the viewing and processing of RAW files that is Aperture's reason for being. Like most RAW file applications from companies that don't make the cameras, Aperture is using its own interpolation algorithms and colour rendering methods, as opposed to relying on software development kits (SDKs) from Canon, Nikon and others to massage the RAW data into finished pixels.
For us, this news immediately put Aperture into a category of software called Not Another Raw Converter (this must be said out loud while groaning). We have a love-hate relationship with too-many third party RAW conversion tools, some of which excel at processing speed and workflow efficiency but produce lousy-looking conversions of the subjects we shoot most. There are exceptions of course, but Apple's own iPhoto isn't one of them. This statement is based on the colour quality of athlete portraits and night sports photos we've tried pushing through Apple's existing RAW conversion application. And Aperture's RAW processing and viewing capabilities are drawn from the same Mac OS well that iPhoto uses.
Two things have lifted us out of a gloomy funk regarding the potential quality of Aperture's RAW conversions:
First, Apple is promising that the conversions for certain cameras have been optimized, and have said as much as in the promotional materials for Aperture. The list of optimized cameras includes all Canon digital SLRs back to the D30, all Nikon digital SLRs back to the D1, plus the Olympus E1 and Konica Minolta Maxxum 7D.
Second, Apple has used as a reference for their own colour rendering the colour produced by the camera makers' RAW conversion software. In chatting with Apple's Schorr about this, he gave the specific example of comparing Nikon Capture's rendering of NEF files to Apple's rendering during Aperture's development phase. He also stressed that camera maker colour was not the end goal, but rather an important step along the way towards building what are promised to be good-quality colour conversions from Aperture. We like camera maker colour as a rule, and in some instances we love camera maker colour, so it was a pleasant surprise to hear the Apple thought it important to be at least partly guided by this in designing their new colour processing.
Schorr wasn't able to say precisely which conversion settings were used in the camera maker's applications when Apple was working up comparison images. And this is important since, for example, we like Color Mode II colour a lot more than Color Mode I in Nikon Capture, and we'll pick the Neutral Picture Style over Portrait in Canon Digital Photo Professional (DPP) every time. Ultimately, the only way to assess Aperture's RAW conversions is to use the application. At this point, however, we're cautiously optimistic that the colour rendering will be acceptable, and perhaps even really good.
The optimized conversion quality will be built right into the Mac OS and, while Apple representatives must refrain from commenting on software not yet announced (this is now not about Aperture but rather an unannounced update to the Mac OS itself), it's not much of a stretch to assume that the next incremental update to Mac OS X 10.4 will contain the fruits of Apple's colour optimization labours.
Update, October 31, 2005: OS X 10.4.3, which was released shortly after this article was first published, includes changes to "Core Graphics, Core Audio, Core Image, and RAW camera support".
Going forward, Apple plans to assess which emerging digital SLR models are worthy of their colour optimizing efforts and will roll the optimized colour for those models into the OS on an ongoing basis. Schorr's comments also suggest that few, if any, compact cameras' RAW files will be receiving a colour optimizing makeover, which makes sense given that Aperture is targeted at the digital SLR shooter.
Aperture does not incorporate a mechanism for tuning the default color and tone rendering of RAW files. There isn't anything in the software that's analogous to Picture Styles in Canon's DPP, Color Modes in Nikon Capture, or even the roll-your-own-colour-look approach that Adobe introduced when it built the Calibrate tab into later releases of Adobe Camera Raw. Aperture also lacks the capability to insert a custom camera profile directly into the colour rendering process, like Phase One's Capture One PRO. All of this will amount to much ado about nothing if the baseline colour rendering, combined with the colour and tone adjustment tools that Aperture does have, make it a quick process to produce great-looking conversions under a variety of circumstances. And, as stated earlier, we're hoping that's going to be the case.
Aperture light table view (Screenshot courtesy Apple)
We also asked why the camera manufacturers' SDKs for RAW conversion have not been used in Aperture. The answer was unequivocal: speed, or the lack of it, in what comes from Canon, Nikon and others. And this point is hard to argue, since the RAW conversion software produced by the camera manufacturers is almost universally the slowest at previewing and converting RAW files (though, as mentioned, the conversions themselves can be top-notch).
We don't know, as we haven't asked, about Apple's plans for RAW files from medium format digital backs. We did notice, however, that the Aperture profile of fashion photographer Richard Burbridge shows him shooting a Mamiya RZ67 with what appears to be the outline of a Phase One digital back attached.
For maximum flexibility during the import of photos into the Aperture Library, Apple is relying on its A Team: Aperture and Automator. On its own, Aperture can transfer all pictures, or a selection, from a camera card into the Aperture Library. It can also import folders of pictures, wherever they might reside, into the Library, optionally converting the folder structure to a matching hierarchical arrangement inside the Aperture interface. During the transfer, it's possible to populate Aperture's database with caption information for imported picture files; the interface for entering batch caption data is highly customizable. But, Aperture itself can't automatically create a backup of picture files to one or more locations outside the Aperture Library upon import, nor can it watch a folder and import files as they arrive from, for example, a camera linked up via Wi-Fi.
For these and other more sophisticated tasks, you'll have to call in the other half of the A Team: Automator. The user-friendly scripting environment that's part of Mac OS X 10.4.x is relied on heavily by Aperture to assist with the import and export process, and in fact Apple has developed several Automator Actions for this purpose (Automator in turn farms out some import-related duties to Image Capture). For a list of some of the Automator Actions for Aperture that Apple has prepped, as well as an example of a complete Automator Workflow (a Workflow is a series of linked Actions), see the Aperture section of the Automator site run by Apple's scripting maven Sal Soghoian.
Aperture is also AppleScriptable; Automator and AppleScript are close cousins. The range of functions exposed in the program's AppleScript dictionary relate almost exclusively to the import and export of photos, with the ability to query Aperture for lists of Projects and Albums within Projects but not individual files. All this probably means that the direct scriptability of the program will be fairly limited, and that third-party applications that may wish to interact with Aperture will have a fairly small set of things they can do in developing Aperture integration.
It's possible to import from multiple camera cards simultaneously and/or sequentially, but we're not clear if this multitasking also relies on Automator. We've used Automator a fair bit, mostly in conjunction with Ben Long's collection of Actions for Photoshop CS2, and it seems to be a sturdy way of automating tasks.
The Aperture application itself cannot control a tethered camera, Apple is expecting you to use another program to do that, and in most cases that will be the software supplied with the camera. As noted above, it will be possible through Automator to have a folder watched and pictures automatically brought into the Aperture environment, which should mean that it will be possible to cobble together a reasonable tethered workflow.
Aperture supports a single captioning standard: IPTC. As you add or edit IPTC metadata, Aperture stores the information in the working Library but does not embed it into your original RAW file (or other picture formats capable of accepting IPTC caption information, such as JPEG, TIFF and PSD). This is in keeping with Apple's firm philosophical decision to never alter an original image file in Aperture. Stored metadata can be embedded into a non-RAW image file (such as a JPEG, TIFF or PSD) on export. It's also possible to export images in their original RAW format, with the option of changing the name of the file from the one assigned by the camera (or whatever it was at the time of import into the Aperture Library) to one selected in Aperture. But when exporting RAW files, the IPTC metadata isn't exported as well. It's not embedded in the file, nor does Aperture export something like a companion XMP sidecar file.
If you read over what Camera Bits is planning for captioning functionality in the soon-to-be-released Photo Mechanic 4.4, you'll immediately see how underwhelming the Aperture captioning solution is. While the program appears to have a powerful keywording interface and numerous other captioning niceties, the fact that it's not possible to export caption data and the RAW file together from an Aperture Library means that all work to caption RAW files within Aperture stays within Aperture. We agree with Apple that the image data inside the RAW file shouldn't be altered, but we also think that a RAW file with no searchable metadata describing the content of the picture is, in the long term, only marginally more useful than no picture at all. And that embedding this metadata directly into the picture file in a safe manner, or at minimum exporting a linked sidecar file containing this information, is mandatory when the program is adding or updating caption metadata.
Apple's approach in Aperture 1.0 has the effect, unintended or otherwise, of keeping RAW images in Aperture and therefore keeping photographers using Aperture. That's because the option of exporting them for use in a different image management application in a few years will be made impractical by the fact that all the RAW files will need to be re-captioned. This alone means we won't use Aperture initially as our image management application, since the bulk of what we shoot is RAW CR2s and NEFs, though we're still excited about exploring the program's many other capabilities.
There will be workarounds, as there always are to such problems. For example, Aperture could be set to export an original RAW file plus a JPEG version with IPTC metadata embedded, and then Photo Mechanic 4.4 could sync the caption data between the two files. Or, a savvy developer outside of Apple may figure out how to interpret Aperture's database so as to extract a RAW file plus its IPTC metadata and marry the two up (this could well become a necessity if Apple were to cease development of Aperture some time in the future).
Update, November 9, 2005: In a follow-up interview, Apple's Schorr passed on some new information regarding how IPTC information is stored in the Aperture Library, information that he learned after we first published this article. In addition to existing as a record in the database document that sits at the root level of the Library, a picture's IPTC data also resides in a companion text file of metadata next to the picture file inside the Library's package structure. The program creates and stores a metadata file for each version of a picture that a user creates in Aperture, plus one for the original picture when it was imported into Aperture. Each metadata file contains the IPTC information associated with that iteration of the picture file, in addition to processing instructions and, in some or all cases, EXIF data too.
The metadata is ordered within a series of XML tags, much like the XMP sidecar file written by Adobe's Camera Raw plug-in for Photoshop, though the tag names themselves are not the same as those used in XMP sidecar files. This suggests that the caption data inside an Aperture metadata file is not stored in a manner that adheres to a particular XML-flavoured specification such as IPTC4XMP, though Apple was not able to confirm this quite yet. It also suggests that a photographer couldn't simply copy the RAW file and metadata file from a package and expect an XMP-aware application like Photoshop, Photo Mechanic or iView MediaPro would automatically be able to parse the caption information inside the metadata file.
Apple's approach within Aperture of storing the IPTC information in both its database and metadata files suggests it may be somewhat more practical - though not automatically more probable - that a third-party developer could extract IPTC data and RAW files together in some fashion, should the need arise. Also, Apple has published details of the XML schemas they've employed in other applications, including Final Cut Pro, Keynote and Pages, suggesting that it's possible that Apple might similarly document the XML structure used with an Aperture metadata file.
This new information is important to include when trying to paint a complete picture of the layout of an Aperture Library, which is the reason we've updated this article to include it. Armed with this new information, however, we feel no less certain about the point we make just ahead in this article. That is, early adopters of Aperture need to let Apple know that the program ought to provide a way of its own to export RAW files and IPTC data together. But we do hope that a third party developer thinking of providing this functionality, until such time as Apple sees fit to revise Aperture itself, will see this new information as adding up to it being somewhat less work to create RAW File and Caption Exporter 1.0 for Aperture. Unfortunately, the reality is that there probably aren't too many developers considering the creation of such a utility, since those that could do it properly may well be authors of applications that compete with Aperture. The bottom line: Apple needs to do it, and we hope that the company will be hearing from lots of photographers who think this is as important as we do. Now, back to the original article...
But, Apple really needs to fix what we consider to be a sigificant design flaw in the first iteration of Aperture, and to do so by ensuring that the option exists to have caption information inside key picture formats be updated whenever Aperture is used to change that caption information (as opposed to updating the information in the database only). They must also develop a solid way of linking caption information with all key picture formats, including RAW, upon export. Anything less is unacceptable. Aperture's design should mean that photographers will have to spend less time managing their pictures, which is a good thing. But the first version of the program has the effect of handcuffing the photographer to Aperture at the same time.
Aperture image management view (Screenshot courtesy Apple)
On a more positive note, Aperture's ability to send a rendered version of a RAW file to Photoshop (or another image editor, as this is configurable within Aperture) sounds well-implemented, mostly because how they've done it is so simple. When you want to work on a photo in Photoshop, Aperture will make a TIFF or PSD (which file format is also choosable) version from the master RAW file, place it within the Aperture Library's package structure, then send a command to Photoshop to open the photo. Once opened in Photoshop it can be adjusted as desired. Then, to save the adjustments back into the file and be seen by Aperture, it's just a matter of typing Command-S. Back in Aperture, the Photoshop-saved file will automatically be recognized as being a rendered version of the associated master file that has been round-tripped from Photoshop. Smart.
The Proof is in the Printing
Aperture looks to have a capable printing mode, one that is fully colour-managed and offers just enough flexibility that we might consider adding it to the short list of applications we'll dare try and print from (Photoshop and ImagePrint are the others).
The colours that flow through Aperture's colour managed printing pipeline to the printer driver are impacted by four things, beyond the colours in the picture itself: the profile selected, the rendering intent, black point compensation and gamma.
If this sounds a lot like printing out of Photoshop, well that's because it is. But there are some key differences: first, there is no choice of rendering intent in Aperture, it's always performing a relative colorimetric conversion. By comparison, Photoshop offers up to four rendering intents, which really translates into two or three in most printing scenarios. Relative colorimetric happens to be the rendering intent we choose almost always when printing from Photoshop, so the lack of choice in Aperture probably won't present a real world problem. But it does seem like an odd omission.
Black point compensation is a must, since almost without exception we've found that faithful printing of moody, shadowy photos to be all but impossible in Photoshop unless black point compensation is enabled (in Aperture it can be toggled on or off).
The gamma control, which is found in Aperture but not in Photoshop, is interesting. Its purpose is to compensate for your printer printing images at a different density than what you see on-screen. Of course, the whole idea behind colour management is to have the profile solve this problem, but in reality things often don't work as cleanly as that. So, the gamma control, which applies an additional tone compensating curve to the image data during the profile conversion, may well be a useful way to tame small density differences between screen and print.
We've edited countless printer profiles for clients on the training side of our business to introduce exactly this kind of change, and Aperture's gamma control appears to be akin to editing the printer profile on the fly. In other words, it's doing colour management wrong, but for the right reason: making better prints. We suspect that this will be a useful feature.
Aperture also enables a photo to be soft-proofed through a user-selected profile, using relative colorimetric as the rendering intent. It isn't possible, however, to have the soft-proof mode show the effect of black point compensation and any gamma tweak. This will almost certainly mean there'll be a disconnect between how a photo looks when soft-proofed and when it's printed, especially if the photo has significant shadow content.
We're nearing the end of our mini-preview of the less-publicized aspects of Aperture. Rounding out the article are a few things that didn't fit elsewhere:
Sharpening Aperture's primary or only sharpening tool is unsharp mask ,with sliders for amount and radius. It works on the RGB composite channel and this is not adjustable or configurable. Core Image, the OS component that is at the heart of many of Aperture's adjustment tools, includes a luminance-only sharpening Image Unit, but we're not clear on whether this is available in Aperture or even whether it's intended for sharpening high-resolution photos.
Web publishing The program includes numerous page templates for publishing images to the web – to post proofs of an assignment for client approval, for example. These templates are customizable - within fairly tight limits - in an elegant WYSIWYG user interface. There is no actual HTML editor within Aperture. Cascading style sheets are supported. Finished pages can be uploaded to a .Mac account directly from within Aperture; uploading to an FTP server must be done from a separate application. There doesn't appear to be any linkage to a web-based client viewing and print ordering system, as might be useful to wedding photographers.
Actions Aperture does not have a mechanism equivalent to Photoshop's Actions, though as noted earlier there is a measure of automation through Automator and AppleScript. The program itself is also designed to perform a number of different operations on either single images or groups of images.
Performance The program is built for speed, that's clear. But, how much of the program's promised peppiness depends on multiple G5 processors, a fast GPU on the video card, heaps of RAM and even fast hard drives we're not certain about. We have one computer that mostly meets Aperture's recommended system requirements, a 2003-vintage Power Mac G5/Dual 2.0GHz with 2.5GB RAM and an internal RAID 0 array. Its stock ATI Radeon 9600 Pro, however, is not among the video cards in Apple's recommended system listings, so we're guessing it may be a drag on at least some aspects of application performance. That's because so much of Aperture's processing is based on Core Image, and Core Image is all about the video card.
We have no intention of replacing this Mac with a newer one at this time, but we have decided to shell out a few hundred dollars to upgrade the video card. About the zoomiest one available for the AGP 8X Pro slot in this computer is the ATI Radeon X800 XT Mac Edition. While its specifications fall well short of the ultra-fast (and ultra-expensive) NVIDIA Quadro FX 4500 that is a build-to-order option with the newest Power Mac G5's, or even the less-pricey NVIDIA GeForce 7800 GT that will be the more-typical upgrade selection for an Aperture user looking at a new desktop Mac, we're hoping that the X800 XT will help make Aperture zip along as Apple intends, even on our aging G5 tower.
The competition Given how ambitious an effort Aperture appears to be, it's reasonable to wonder what will happen to competing software for the Mac that overlaps Aperture's feature set. The answer to this will depend on how good Aperture is, and how Apple grows the program to fill holes and expand its functionality. Assuming that v1.0 is pretty good (various image management weaknesses notwithstanding), then there are RAW converters, browsers and catalogers that are going to feel the pressure of Apple's entry into the pro imaging space.
Based on what we know so far about Aperture, its most direct competition would seem to be be Capture One PRO. There are many ways that the two programs are similar in design concept (though they of course look very different), and both contain a similar range of adjustment tools. Phase One's RAW conversion application does some things that Aperture doesn't, including offering tethered operation with certain camera models. Plus, it has the ability to use custom camera profiles. On the other hand, Aperture has image management and image output capabilities that don't exist in Capture One PRO, and Apple has done more to capitalize on the architecture in Mac computers for maximum speed of operation.
Since most of the RAW converters from the camera manufacturers are bundled with the cameras, and will presumably continue to offer features that are found mostly or only in the camera maker's software, such as access to Color Mode or Picture Style menus and the ability to save processing instructions back into the RAW file, there may be little impact by Aperture on the usage of these converters. The paid-for Nikon Capture may be harder hit, and since it's molasses-slow on the Mac platform in particular, it's poised for a spanking by a Mac-optimized Aperture.
Other applications are likely to be only lightly affected. Image catalogers like iView MediaPro and Extensis Portfolio can keep track of photos that are offline, while Aperture can't. That fact alone will make these and other image catalogers necessary in the workflow of plenty of shooters. Photo Mechanic, our preferred image browser, is really built for a type of photographer not directly targeted by Aperture: the working news, sports and wire service shooter, and other folks with the need for a similar workflow. In other words, Photo Mechanic and Aperture seem mostly not comparable. And in some areas of direct overlap - image import and RAW file captioning, for example - Photo Mechanic is the vastly superior of the two, especially as of the upcoming Photo Mechanic 4.4.
Photoshop should proceed without missing a beat. After all, it's Photoshop, the 800-pound gorilla of this category, and it's laden with useful image editing features that aren't in Aperture. Whether usage of the Camera Raw plug-in within Photoshop drops off with Aperture's release will depend in large part on the quality of Aperture's conversions.
How Aperture should impact Adobe, the camera makers and smaller developers alike is to spur them into revising their programs for pro shooters to be super-efficient, smooth in operation, photographer-friendly and show a deep understanding of the pro workflow. Simply put, all pro photography programs should be really pleasant to work in. Watching Aperture run, we couldn't help but think that we've put up with the poorly-designed interfaces of certain applications, and the seriously slow underpinnings of others, for far too long. Aperture appears to demonstrate that there is a better way to design certain aspects of applications for pro photographers.