Photo by Jakob Owens
The Ins and Outs of Non-destructive Editing in Photos for Mac and iOS
One of the near-magical features of Photos, and iPhoto before it, is the way it allows you to edit a photo with the assurance that those edits are non-destructive—you can always revert to the original version. That said, non-destructive editing brings with it some confusion, particularly for those working with RAW images or using Photos extensions to do the editing.
To shed light on the situation, I’ll first explain how non-destructive editing works in photo applications in general, using Photos as an example. Then I’ll go into detail about how non-destructive editing in Photos works with RAW image files, Photos extensions, and more. I will also identify some trouble spots.
To give you some background, I was the lead developer for Aperture, and I later led the team that developed the editing engine for the Mac version of Photos. Now I’m on my own, developing a Photos extension called RAW Power that uses the same RAW engine underlying Photos and Aperture. In this article, I will often use RAW Power as an example, though other Photos extensions work similarly. If you are unfamiliar with RAW, you may wish to read a separate article of mine that discusses the benefits of RAW as well as touching on Apple’s new HEIF image format.
Basics of Non-destructive Editing
Most applications directly modify your documents. For example, when you choose Save in Microsoft Word, it saves your changes directly to the document’s file, replacing the previous version of the file in the process. Some image-editing applications also modify image files directly, notably Adobe Photoshop and Apple’s Preview.
In contrast, most photo-editing applications work non-destructively and never modify the original photo. The application applies edits to an in-memory copy of the original to produce a real-time preview of the adjusted image.
The application may automatically save the edit instructions, or it may wait for you to hit Done or choose Save. From your standpoint, the image appears to be modified, but the original file remains untouched. While extremely useful, this non-destructive model can be confusing to users because it clashes with their expectations based on other applications.
Photos saves the edit instructions in a location separate from the original file and generates a full-size JPEG (and smaller thumbnail images) that contain the results of the edits. (Photos makes JPEGs for all file types, including RAWs and Apple’s new HEIC files. You cannot rely on the Info pane in the Mac version of Photos to tell you the file type you are editing because it always shows you the file type of the original.) After the edit is completed, this is what is stored on disk:
The full-size JPEG is an individual file on disk. The smaller thumbnails are stored in “container” files that hold multiple thumbnails at once. The edit instructions are stored in the photo library’s database, along with other information about the image.
If you want to continue editing the image at a later date, Photos reloads both the original and the edit instructions and then combines them to display the adjusted image.
Outside of editing mode, Photos hides the original photo from view, instead showing the full-size JPEG or smaller thumbnails at every point in the application. While this is clearly correct, hiding the original reinforces the perception that the original has been modified. This is the main point of confusion for people. Many users ask me how to copy or duplicate images before they edit them—they are convinced by Photos’ sleight of hand and believe they need to preserve their original before making any adjustments. (Some people duplicate images because they want to have both unadjusted and adjusted copies visible in the grid, but this is less common.)
Ironically, one reason non-destructive editing exists is because RAWs cannot be edited in place. It is not possible to make arbitrary edits to RAW sensor data, and from those edits, create RAW sensor data (it is possible to make a linearized DNG, but linearized DNGs are not RAW images). Photos never modifies the original RAW images.
Why go through all this trouble? Because non-destructive editors offer three important features:
- Instantly show the original image to allow for A/B comparisons
- Discard all the edits and thumbnails for an image, revealing the original
- Revise or remove individual edits without loss of quality
Photos always stores its editing instructions in the library’s database. Other applications may use a database or store them in separate “sidecar files,” typically using the same name with a different file extension. For example, for an image named IMG_0005.JPG, an application may store a sidecar titled IMG_0005.xmp or IMG_0005.dat in the same directory. Sandboxed apps may store the sidecar elsewhere.
Sidecars are general-purpose files, so they can also hold thumbnails and miscellaneous metadata such as ratings. Applications sometimes store the sidecar information inside the original file because most image formats can store miscellaneous data without modifying the pixels or impairing the ability of other applications to read the original pixel data. This ensures the editing information stays with the original file data but can lead to corruption or data loss if the application fails to insert the data into the original file properly. In addition, not all applications correctly retain sidecar data from other applications when they write their sidecar data into the original file. For these reasons, many photographers prefer the sidecars to be stored separately from originals.
Although we mostly think of non-destructive editing in the context of the native editing tools in Photos, that’s not the only place it’s used. Developers can create a type of plug-in called a “Photos extension” that gives Photos additional editing features. To access Photos extensions, start editing a photo and then click the Extensions (···) button at the top of the window.
Photos extensions do not add extra sliders to the Photos editing interface. Instead, they replace the standard Photos tools entirely.
As with normal editing in Photos, Photos extensions let you edit only one image at a time—you cannot use a Photos extension to correct white balance in a batch of ten images. When you select a Photos extension, Photos opens the extension and sends it the original file:
When you click the Save Changes button in the Photos extension interface, the Photos extension gives Photos back its editing instructions and a full-size JPEG, as shown here:
As a result, Photos extensions participate in the same non-destructive system that Photos uses for its own image editor. Photos stores the JPEG and extension’s editing instructions in the library. Then Photos creates thumbnails from the full-size JPEG and hides the original.
If you decide to edit the image again with the same Photos extension, Photos will pass the extension the original image, along with the extension’s editing instructions. Again, this is just like Photos does for its own editing system:
The Photos extension can show the original, as well as remove or adjust any previous edit made in that Photos extension. Even better, the Photos extension’s adjustment data is synced through iCloud Photos, allowing you to continue editing with that Photos extension on another device. That means you can edit with the RAW Power extension on a Mac and continue editing non-destructively on another Mac with the RAW Power extension, or in iOS with the RAW Power app.
This is also how the system works in iOS, with one important limitation. Photos extensions in iOS 12 are never passed a RAW image—they are always given a rendered JPEG. So don’t bother editing a RAW image with a Photos extension in iOS 12. I filed a bug about this some time ago; hopefully Apple will fix it in iOS 13.
A Fly in the Ointment
This approach works swimmingly as long as only one application or Photos extension edits an image. As soon as two editors enter into the mix, things go sideways. That’s because Photos can store the adjustment information for only one editor for any given image. As soon as the changes from a second editor are saved, the edit instructions from the first editor are discarded and cannot be recovered! The image data is preserved, but the option to make changes with the first editor is lost. This is another key point of confusion for customers.
To illustrate this problem, imagine that a user decides to use the Photos Auto Enhance feature on a RAW image and then use the RAW Power extension to apply a crop and vignette. Photos has a good auto enhance and, unlike the Photos Vignette tool, the RAW Power Vignette lets you pick the center of the vignette.
Step 1: The user clicks the Auto Enhance button and clicks Done. As described earlier, Photos stores a full-size JPEG and the adjustment parameters in the library (the original is present, but hidden):
Step 2: The user selects RAW Power from the Photos extensions menu. Here’s where we run into the first difference from the previous example: Photos sends the full-size JPEG (not the original RAW image) to the Photos extension. Photos sends a JPEG rather than the original because the user expects to see the auto-enhanced image in the Photos extension, not the unadjusted original. Since Apple does not publish its internal format for adjustments, nor does it provide access to the code for its adjustments, there is no way for a Photos extension to apply the auto enhance made in Photos. This is also true in reverse—if a user edits an image with a Photos extension, and then edits further in Photos, they are working in Photos with a rendered JPEG—Photos has no way to apply edits made by other companies’ extensions to the original file.
Step 3: The user applies Crop and Vignette in RAW Power and clicks Save Changes. This is what gets stored in the Photos library:
Notice that Photos has just discarded its own adjustment data! While everything may look fine, the Photos editing information has been lost, and the user is never informed of this. While the user can go back into the Photos extension and adjust the crop or vignette (or any other adjustment in the extension), they cannot go back a step and fine-tune the sliders in Photos. Further, the user cannot undo the step before they invoked the Photos extension—the only option available is Revert to Original because there is no Apple adjustment data left to revert to.
Note that there are also now two JPEGs stored in the library, one from Photos and one from the Photos extension. This is necessary to maintain some semblance of non-destructive editing. The first JPEG is the one created by Photos as a result of the Auto Enhance step and handed off to the Photos extension. Remember that for the user to re-edit an image with the same editor, the editor must receive the “starting image” along with its editing instructions. In this case, the “starting image” is the JPEG made after Auto Enhance was applied. Though there are two JPEGs, only the final JPEG is visible in the user interface. The auto-enhanced JPEG is hidden; it’s only stored in the library to enable re-editing with the Photos extension.
“But,” you may say, “I can edit in Photos, and then use a Photos extension, and go back to Photos and continue editing.” True, but you are adjusting the JPEG sent back from the Photos extension, not the original adjustments you made in Photos to the RAW file. Imagine that you make the edited image black-and-white. This is what is stored:
In other words, you are stacking Photos adjustments on top of the RAW Power adjustments (and losing the RAW Power adjustment data in the process).
Also note that this loss of adjustment data will occur if you edit in the Photos extension first and then edit in Photos, or if you don’t edit in Photos at all, but instead do all your editing with two Photos extensions. The order doesn’t matter—just the use of two or more editors on the same image.
A RAW-specific note: If you first edit a RAW in Photos and then send the image to RAW Power or another RAW-friendly Photos extension like DxO OpticsPro, not only are you working in the Photos extension with an 8-bit JPEG, rather than a 12- or 14-bit RAW, you lose access to the RAW processing features that RAW Power or DxO provide. This severe loss of quality happens for any edit done in Photos, even a simple rotate or flip.
This gotcha also rears its ugly head if you want to use two RAW-capable Photos extensions. In this situation, which Photos extension should you use first? RAW Power has strong RAW editing controls, based on the same engine that Photos uses. DxO has high-quality lens correction. I believe it’s best to start with RAW Power to access its RAW-only editing sliders, and then use DxO OpticsPro, because DxO’s lens correction works on both RAWs and JPEGs.
I wish Photos would warn users whenever quality is being degraded or adjustment data is being lost. Photo extensions cannot warn users of this problem because of the way Photos extensions communicate with Photos—they do not even know there is a RAW original. This is a warning only Photos can provide. If this happens to you (and you notice it in time), you should:
- Cancel the edit in the Photos extension
- Revert to Original in Photos
- Re-enter the extension
I Exported a TIFF from a What?
When saving edited RAWs for posterity, photographers prefer 16-bit TIFFs because they can store all of the richness of an edited RAW in a universal image format. For best results, exports should start with an image format whose quality is equal to or better than the destination file format. RAW is superior to TIFF, and TIFF is superior to JPEG. Accordingly, if you edit a RAW in Photos and later export a TIFF, you get excellent results because Photos will reload the RAW, apply the edit instructions to the RAW, and then generate the TIFF.
That’s not true for Photos extensions. As I mentioned earlier, extensions are required to send JPEGs back to Photos, rather than TIFFs. If you use Photos to export an image edited by an extension, Photos uses that JPEG as the source. I’ll repeat that: your 16-bit TIFF will be created from an 8-bit rendered JPEG, not by applying the adjustments to the original, as Photos does for images edited by its own tools. Photos uses a lower-quality source than the destination—your exported image is basically a JPEG decompressed into a TIFF.
There is a good, if unsatisfying, reason for this: Photos cannot go back to the extension and ask it for a rendered, full-size TIFF because the extension might have been uninstalled, or the image may have been synced to a device that lacks the extension. This is another case where Photos should warn users. It’s unreasonable to assume users understand that their 16-bit TIFF is being made from an 8-bit JPEG.
A word to the wise: there is no point in exporting a TIFF from Photos if you edited the image with an extension. I had to add a button in the RAW Power extension to export TIFFs, which is kind of crazy but necessary.
Support for multiple editors as well as TIFF export would be greatly improved if extensions could return TIFFs to Photos—and if Photos could send TIFFs to extensions. This could be an opt-in feature for extensions and users wanting the best quality.
Don’t Edit with “Edit With”
Photos has yet another way to work with third-party editors and, unfortunately, it is both prominently placed in the Image menu and produces inferior results in most cases.
This feature is intended to let users edit in applications that modify files directly, such as Photoshop and Preview, that do not have Photos extensions. However, any application that can edit images will appear, including some that don’t make much sense in this context. Confusingly, the list may also include apps that provide Photos extensions, if those apps can also edit images outside of Photos (as RAW Power does). The prominence of the command means it’s all too easy for customers to choose Edit With RAW Power instead of the RAW Power extension. Extensions, as you will see, integrate much better with Photos. (As a simple fix, Photos could filter out apps with Photos extensions from the Edit With list.)
Because Apple intended Edit With for use with destructive editors, Photos protects the original. Instead of sending the original file, Photos makes a copy in its library and sends the copy to the external editor. The editor modifies the copy, and non-destructive behavior is maintained. Sort of. Because the external editor is making destructive edits, all that Photos can do is maintain the ability to use Revert to Original. No editing information is stored in the Photos library (since there isn’t any), nor can the user revise edits afterward in Photos or the external editor. (It’s technically possible to have a more non-destructive workflow, but doing so requires storing the edits separately and managing them yourself. It demands great care and is highly error-prone.)
I mentioned that Photos starts by making a copy of the original. That’s not entirely accurate. If the original is a RAW, Photos sends a TIFF instead. Why? Because it must provide a file that the destructive editor can modify, and as I mentioned earlier, RAWs cannot be edited and rewritten. In addition, not all editors support RAWs.
Consequently, Edit With is a particularly bad choice for RAW editing. I field many questions from customers wondering why they are unable to edit their RAW with RAW Power. The reason is usually that they used Edit With instead of the RAW Power extension. It may be possible for external apps to hunt around the Photos library and locate the RAW, but that is sketchy and not recommended (sandboxed apps cannot do this anyway).
Conclusion: Non-destructive Editing Is Great, Most of the Time
Non-destructive editing provides users with valuable features like instant revert, A/B comparisons, and fine-grained control over the editing process. However, it establishes a significantly different interface paradigm that applications don’t communicate well to users. The non-destructive illusion leads many photographers to believe their originals are being modified when they are simply hidden. These photographers then protect their originals by duplicating images needlessly. While smart copying can minimize the disk cost, such duplication leads to complexity and visual noise due to extra images in the grid. Some education would reduce customer nervousness when editing prized photos.
In addition to its own editing tools, Photos provides a clean extensions interface that provides non-destructive editing and syncing through iCloud. It has some warts, including issues with multiple editor support, export, and the Edit With feature. However, with a few fixes, Apple could greatly improve the non-destructive workflow in Photos, both in quality and understandability. To that end, I have filed bugs with Apple with my suggestions. Hopefully, we will get some improvements in a future release of Photos for macOS and iOS.
Nik Bhatt, formerly Senior Director of Engineering at Apple, led the Aperture and iPhoto engineering teams for several years. Afterward, he led imaging teams for Apple’s photo applications, including the teams responsible for Core Image and Apple’s RAW Camera library. He is now the developer of RAW Power, an advanced photo editing app for Mac and iOS.
This is a fascinating article which makes it very clear just what a powerful tool Aperture 2.x was (3.x was a step backwards in terms of interface), doing almost all of this in real time and allowing easy export of sidecars.
Working with any RAW converter which doesn’t store sidecars is a kind of digital deathwish. Sooner or later the program won’t be supported or the files will be moved and one’s edits will be lost. Sidecars should always be stored with the original images, in the worst case in a subfolder.
The most reliable partner (and affordable) for one’s images in Iridient Developer, who does not try to to manage your images. The Finder can do most image management especially with Raw Right Away Quicklook plugin, $7 in the App store. For culling of images on ingest, just grab FastRawViewer which uses standard XMP sidecars to store rating data. Rating and throwing away all the unneeded outtakes is probably the most important part of image editing in this digital age with hundreds and thousands of images.
For more serious RAW development the tools get expensive. DxO PhotoLab and CaptureOne are the market leaders among software one can purchase. Adobe will never get a foot back on my computer as I will not rent desktop software. Plus when I installed a trial to do some testing for an article, uninstalling Adobe CC was so incredibly complicated. Adobe CC is basically full time spyware that spends most its time watching everything you do on your computer and sending data back to Adobe headquarters. DxO PhotoLab is the least invasive (CaptureOne wants a few more permissions than I want to give).
Affinity Photo offers great Photoshop level tools for very little money and even includes a RAW converter. While Affinity Photo is a great Photoshop replacement, the front end RAW converter is no great shakes (probably Apple Photos level).
It would be great if Apple would respect its pro users and not neglect and then cancel important projects like Aperture. The FCP Studio 3 abandonment was not much better. It was five years before FCPX was even partially ready to replace FCP Studio. These antics lost Apple the post-production pole position and giving it away to Adobe with its Premiere and After Effects. Based on the mediocre condition of Apple Photos, I’m surprised that Apple allowed Nik to walk away. Apple need all the expert help they can get, to create even a shadow of what Aperture was.
Now that Nik’s explained the internal workings of Apple Photos, I’m glad I only used it for a couple of test projects to see how it worked.
Again, this is one of the most interesting and in-depth articles I’ve enjoyed on TidBITS for the last couple of years. Great look behind the scenes.
Seems like the obvious solution would be for Nik to build his own DAM into RAW Power.
Waiting, hoping, that Apple will fix things in a logical and useful way, is a fool’s game. They just don’t work like that. If you don’t believe me, just ask iWork fans, or iBooks fans … or one that always makes me smile; Apple Mail on Mac and iOS. No Rules on iOS, so if mail is collected first on iOS, before the Mac, then the Rules aren’t applied on the Mac. Sigh. It’s been years.
I understand that catering to Photos is very enticing, because a gigantic number of users have their images in there, but equally, that gigantic number of users isn’t really Nik’s base, which surely starts at the enthusiast level and not casual users. I’m a professional photographer and I know what it’s like when you try to explain even rudimentary aspects of Photo editing to a non-enthusiast, which is precisely why there’s a ‘Magic Wand’. Those people aren’t interested in RAW/JPEG/Tiff and all they entail.
It seems that Apple have shown at WWDC, with iOS and MacOS being brought closer together and with the addition of iPadOS, that users might easily be able to enjoy the benefits of iCloud for more specialised apps like RAW Power, e.g. Cloud synchronisation of edits etc. So maybe dump the extension idea and build RAW Power into a full-blown Aperture replacement.
That was a useful and interesting piece. The inability to layer on edits with multiple extensions is an ongoing disappointment with Photos.
I loved Aperture, moved to Capture One after, which is also a wonderful app.
Iridient Developer is the best for detail however, it smartly works alongside Capture One and if I plan on large prints, I use it for Raw processing. You choose Edit With and Capture one creates a Tiff of your specification to hand over. But ID is smart enough to grab the Raw file instead, process it and save back out a Tiff overwriting the original generated one for C1 to do further edits.
So as Nik points out you have to stay on your toes.
Can’t recommend DXO at all, had terrible experience with them.
A nice article. I have not even tried Photos, because I use Lightroom. So it was interesting to see how Photos handles RAW files. Unlike Photos, Lightroom enables you to maintain the bit depth of the original photo on export, though you can lower the quality of a JPEG, if you like. JPEGs have always been scalable because they were so often used with e-mail, especially in the early days when bandwidth was limited—and AOL limited file sizes. It seems obvious to me that Photos is intended for casual users. Why any professional photographer would use it is beyond me.
Lightroom is also flexible when it comes to sidecar files. Generally they are kept as metadata in the Lightroom catalog. But you can direct Lightroom to keep the sidecar with the image. Which is a good idea if you plan to move them around, say from one computer to another.
As for price, Lightroom, before CC, was priced in the middle, well below Capture One. Now Affinity Photo is the best value in a Photo developer. Unfortunately, it cannot read Lightroom metadata or sidecars, so while it is easy to switch from Photoshop, I’m stuck with Lightroom. Fortunately, you can get both Lightroom Classic, Lightroom (for mobile) and Photoshop for $9 a month in Adobe’s Photo package. Affinity Designer is a decent, affordable, replacement for Illustrator. And Affinity Publisher will soon replace InDesign. I love iDesign, but cannot afford CC at $20 a month. Maybe the price will drop when Publisher comes out of beta. But I’m not holding my breath.
Anyway, thanks for the article.
I have become a big fan of Affinity Publisher after their beta. Really settled in on me even with InDesign sitting there on my Mac, albeit CS5.
For photoshop alternatives, we are lucky indeed with the options from Pixelmator Pro through Acorn to Affinity Photo. All are lesser apps than Photoshop but they all cover what I look for in a photo editor.
I’ve not had to subscribe yet to the Adobe world, can’t see myself doing it.
A number of years ago, I was embarking on a prestigious book project, which involved a lot of images to be taken using available light indoors, sometimes quite low-light (kitchen of the Ritz in Paris). Prior to starting, I wanted to make sure I was using the best RAW decoder/tool for this, so I spent an entire week, pixel peeping high-iso. Lr, Aperture, Iridient, Nikon’s own and a couple of others that were quickly discarded. What I found, was that it is very hard to reach conclusions, because the results can be very image dependant.
At the time, everything I read online said that Lr was tops for low-light/high-iso. This was actually the only thing that was conclusively wrong, as Aperture consistently produced far better output at high-iso. So that was the first surprise. I also found that Iridient did really well on some images and really badly on others. I didn’t own Aperture at that point, but ended up buying it for the project. Nikon’s own decoder produced excellent results too, with the nicest colour of all, but the difference compared with Aperture didn’t justify using an utterly horrible app.
One of the criticisms of Aperture was that it took so long for Apple to provide support for new cameras, but a couple of years later, I was told by a senior engineer at Leaf, that this was because Apple required a camera to be given to them for 2 months, so that they could produce high quality results. Adobe on the other hand … just added the camera’s name to the list of existing cameras and it was handled the same way as those other models (presumably until they could get hold of a camera). Terrific. I don’t know if this is still true, but I do know that Apple’s RAW decoder remains very good (and Nik’s RAW Power taps into it).
The images that I found to be the most useful for determining the quality of output from RAW, were anything with a mass of very similar textured detail (surprise!). The best was a large area of gravel (driveway of a house) and a recently tarmacked/resurfaced road, which had some quite large pieces of gravel (quite a rough surface). Shooting in both harsh and flat light tested these to the limit. Sometimes, a RAW processor would make the gravel almost completely disappear!! Interestingly, I re-ran some of these tests, using the Olympus OM1, when it was introuduced with pixel-shift. Using Olympus’s own software, could make the road texture disappear too! That was a surprise.
Regarding jeff5’s comment and exporting from Photos and bit depth …
I don’t use Photos, but I have seen on Nik’s twitter feed for RAW Power (his really excellent RAW decoding app that uses Apple’s built-in RAW processing) that with a significant change to Photos due with MacOS 10.15 Catalina, which will allow developers to access Photos database, he’s now looking into adding Aperture like DAM features to RAW Power. (Yes!!). So I spent a little while looking at Photos again and was quite surprised by some of what I saw and what this new access may mean. It’s actually potentially very interesting. Anyway … Photos Export dialog offers bit-depth choice for Tiff. If you’re working with JPEG, I can’t say I really see the point in working in 16bit. You’ve already made a lower quality choice.
Interesting. I always found Aperture’s ability to recover detail in highlights or shadows superior to LR. That probably explains why.
I use Iridient now primarily given my Fuji cameras, the developer has focussed on getting the best out of files from the X-Trans sensor.
Excellent article, really interesting. And a great reference for the future.
This makes me so happy. I’m still on Aperture, and pondering what I’m going to move to with 10.15 dropping support. Still not found anything as good for me with culling and managing photos. Would love to see RAW Power grow into the DAM side of things.
Thanks for all the discussion and info. I, also, have been clutching to Aperture in its death moments. After trying a few applications, including Lightroom (standalone) and On1, I bought Capture One based on all the positive comments and reviews. I do love the Affinity Apps for manipulation of images as well as On1, but will use Capture as my base.
As with many photographers, I still have a problem with changing my workflow and have not moved everything over to an external folder to browse with Capture One. I also want to make sure it imports my images from Aperture, but I really like Aperture’s workflow and will have to wrap my head around a new process.
Aperture makes it incredibly simple to ‘Move’, ‘Relocate’ or ‘Consolidate’ images. Moving ‘Managed’ originals, would let you try out Capture One for a large number of images. As long as Capture One is not actually altering the originals, then both apps can access the same images without any adverse consequences.
If you’re concerned about folder structure … you may want to rethink. Personally, I’ve always let Aperture do what it is designed for, which is to manage my images. All referenced images (in my case, all RAW files) are simply dumped at the root level of external disks. No folder structure at all. I use Aperture to organise using Libraries, Projects, Filters (Smart Albums) and Albums. Other file types (in my case Tiffs) are ‘Managed’ within Aperture. These tiffs are generally final images for client delivery or variations thereof.
The point is, to let the database front-end, handle the database and not try to use both the Finder and the Database do the same job … a recipe for problems. I do the same with Apple Mail. Everything just dumped in the In or Sent mailboxes and Smart Folders (permanent searches) to manage. (Most people don’t realise … but these can be And/Or)
Thanks for the informative article. I didn’t know that Photos keeps the originals but only stores editing information. Two questions:
If I genuinely want to delete original photos (to save space), is that even possible in Photos? For instance, I often crop photos and I have absolutely no use for the original.
Somewhat unrelated, I am confused by the iPhoto-xxx.migratedphotolibrary files which apparently use the same photo files as Photos-xxx.photoslibrary files. If they do not duplicate the actual photo files, why are they showing (roughly) the same file sizes? (I have two of these which are ~80GB each, so do I save anything if I delete the migratedphotolibrary version? Are the photos stored only in the photoslibrary file?).
Deleting photos will delete the original, editing information and thumbnails / full size JPEG. However, if you delete the original, you will also end up deleting the edited image (cropped in your case). That’s not what you want. The only way I can think of is to export the image to the Finder and then re-import it. Once you have done that, you can delete the original. Keep in mind that you will not be able to remove the crop, because it has been burned into the exported image (this is one of the main advantages of keeping the original).
To your second question, the migratedPhotoLibrary and photosLibrary share their originals, using a technology called “hard links”. The sizes are about the same because a hard link acts exactly like the original file so its file size is identical in both cases (this is different from soft links or aliases). There is only one copy of the file, but both libraries refer to it. The OS keeps track of the number of hard links to a file. When all links are deleted, the file is finally deleted. You can delete the migratedPhotoLibrary when you are certain you do not need it any more. The images will be still be accessible to Photos.
(You can confirm all of this by making a new library with one image in iPhoto or Aperture, and then going through the export/import, or the delete process and then checking to make sure everything is fine in Photos. The originals are stored in the library in a folder called Masters)
FWIW, I use Photoshop all the time, but almost never edit the original photo. With linked photos, smart objects, layers, masks and adjustments, you can achieve a huge number of transformations to photos without touching a pixel of the original. Since seeing Deke McClelland apply a camera raw smart filter to a smart object, another huge range of possibilities opened. PSD files are unquestionably large, and they don’t (to my knowledge) play well with Photos. But still, I prefer the control that Photoshop provides over the other editors I’ve encountered.
I like Iridient Developer as well, particularly for a quick one off file or for technical comparisons of lens transmission where it’s important to see the RAW data as is. Brian Griffith also offers a fair updates policy and wonderful support.
For serious work on high ISO files, where I’d like to retain colour and detail yet minimise chroma noise, nothing compares to DxO PhotoLab. Here it is head to head against C1 on a very challenging image (there’s a RAW file there which you can try in C1 yourself: if you have more success, let me know and send me your version, I’m happy to post a better C1 version).
That’s pretty thin material for a general damnation. Please explain.
Sorry Alec, no interest in a row on this, people have different experiences, their customer service was my issue. I’ve moved on, taken my losses, don’t expect to do more on it.
Thanks for a very informative article. I have one question that I’m not sure if you answered.
Does Photos make a full resolution jpg copy of every image or only the ones that are edited?
I ask because I am reluctant to edit many photos if that means the size will increase as a result and I have been unable to find an article that explains what actually happens
Thanks in advance,
@Nik_Bhatt can say more, but as I understand things, Photos has an original photo, whether in JPEG or HEIC, and then it layers edits on top algorithmically, which is why you can always revert to the original by stripping off those algorithmic changes. I don’t believe Photos still uses the iPhoto technique of duplicating images.
But regardless, I wouldn’t be concerned about size increases associated with editing photos unless you’re completely space-constrained (and at that point, I’d recommend solving the space constraint first). Denying yourself one of the core features of an app because it might use a little disk space seems counterproductive.
This article is so useful. I’ve been using RAW Power as an extension in Photos and have been puzzled about the behavior when I have “tweaked” the image in Photos (either before or after RAW Power). This article explains it!
I need to do the image editing ONLY in RAW Power!
I had been cropping in Photos, thinking erroneously that its crop tool was more convenient. Now that I’ve found the better crop tool in RAW Power, I don’t want to use the Photos crop tool anyway.
This should be a highlight section in the RAW Power documentation! Thank you!
This is a tremendously useful post, which has led me to trial RAW Power as I’m retooling my photo collection / workflow.
The Background (feel free to skip this paragraph to get to actual question):
I’m a former Aperture user who went to Lightroom but never felt satisfied. Photography has been a hobby of mine for years and I was originally happy-ish with Lightroom Classic. As work and family responsibilities increased (aka got married, had kids), the time I have for edits, curations, etc diminished. I started incorporating Lightroom Cloudy into my workflow to get the advantage of “everywhere sync”. However, I’ve increasingly became frustrated with glitches like being logged out of Lightroom, some photos never getting uploaded, etc. So, I’m trying to redo my workflow around Photos, to make device sync as seamless as possible, including maintaining all the extra Apple features which just work (especially for parents), e.g. Live Photos, Portraits mode, etc. Now, if Apple could just figure out a better (somewhat automated) approach to sharing full-resolution photos across spouses/partners …
Ok, the actual question:
If I understand correctly, RAW Power is currently for image-wide adjustments, and doesn’t have localized edit functionality. What’s the best workflow for when you want to edit a specific image locally, e.g. heal blemishes after doing broader photo-wide adjustments?
Is it Photos --> Use Raw Power for most edits --> Do localized edits in Photos/ another editor? Based on this article, the localized edits would be on the JPEG generated by RAW Power. Or is there a better workflow?
I’m confused. From the article:
But the article also says extensions only receive a JPG file from Photos even when the original master is RAW, and that the extension does not even know the original is RAW. If so, how can extensions like RAW Power or DxO use any RAW editing tools? If only Photos has access to the RAW file then only Photos can develop and edit in RAW, no?
The extension can only produce JPEGs for storage in the library (per Apple’s specification). If working on a JPEG is okay, then you can use another extension that has local adjustments / Photos for healing, or export the JPEG to the other app.
In addition, the extension has the ability to export TIFFs through the export button at the bottom of the interface. That image could be edited in another app and then imported back into Photos. That would maximize quality but is a few more steps.
If an image is unedited (by Photos or any extension), then Photos sends the original image to the extension (a RAW). However, once the image has been edited by Photos or another extension, then extensions are passed a JPEG, and they have no way to locate or use the original RAW image.
I guess none of this has been improved since the article was written?
Join the discussion in the TidBITS Discourse forum