OnOne photos lets you use smart-photos. They’re awesome. DxO Optics lets you work with raw photos with an exporter in Lightroom. I’m sure Photos will get there with those 2 programs.

The difference in Aperture is that the plugins I use save tiffs back to Aperture. The one I’ve used in Photos (Affinity Photo) saves back jpeg. I don’t know if this is Affinity’s choice or a limitation of Photos. If this is the case for all extensions and if using more than one extension will result in recompression each time, then my hopes for Photo extensions is gone.

Walter, do you happen to know if the app developer has the option to send a tiff back to Photos?

Has anyone noticed if it is possible for a Photos extension to gain access to the actual RAW bits of an image? Or does the extension only have access to the JPEG generated by Photos as input.

DxO Optics extension would be amazing IF if can handle the RAW conversion itself, ignore Apple’s lousy RAW processor.

TL;DR

No, the workflow using extensions is destructive. Moreover, it is actually destructive quality-wise since intermediate data is often saved as Jpeg.

Keep reading if you want to know more.

I have actually spent some time reading Apple’s docs and playing with Photos extensions. I have even written my own one to check if I am understanding everything right.

So, the key to the problem is described in here:

——

When a user chooses your extension for photo editing, Photos first asks if your extension can interpret the adjustment data from the most recent edit. If your extension supports the adjustment data, Photos provides the previous version of the asset as input for your editing session. After you read the adjustment data and reconstruct the edit it describes, your extension can allow the user to alter or revert the last edit or make further changes. (For example, an adjustment data may describe filters applied to a photo. Your extension reapplies those filters and allows the user to change filter parameters, add new filters, or remove filters.)

If your extension does not support an asset’s adjustment data, Photos provides the current version of the asset as input to your editing session. Because the current version contains the rendered output of all past edits, your extension can further edit the asset but cannot alter or revert the most recent edit.

——

renderedContentURL property

Read this property to find a URL for writing edited asset content. Then, if editing a photo asset, write the altered photo image to a file in JPEG format at this URL.

——

They are keeping just current and previous rendering and only current adjustments. Intermediate format is JPEG.

We could have stopped here, but I would like to give you some examples.

These shortenings will be used for convenience:
 PA  - adjustments made by Photos app
 EA  - adjustments made by Photos extension (can be EA1, EA2 to represent different extensions) 
[  ] - file type (RAW, jpeg)

1. Let’s say we have imported RAW file into Photos and performed PA

[RAW] -> PA = [RAW] + PA

So every time you are changing PA they will by applied to RAW file. This is the only non-desctuctive way of editing photos.

2. Now we want to edit my photo using EA1

[RAW] -> PA -> [ ? ] -> EA1

The intermediate format is going to be jpeg and the chain will look like:

[RAW] -> PA -> [jpeg] -> EA1 = [jpeg] + EA1

Every time you are changing something in EA1, it will be applied on jpeg file.

3. Then we decide to edit same photo using EA2

[RAW] -> PA -> [jpeg] -> EA1 -> [ ? ] -> EA2

It is going to be jpeg again and all further EA2 changes will be applied on this jpeg

[RAW] -> PA -> [jpeg] -> EA1 -> [jpeg] -> EA2 = [jpeg] + EA2

4. Finally we recall that we forgot to add one tiny adjustment in PA or EA1. I think you can guess by yourself what is going to happen:

[RAW] -> PA -> [jpeg] -> EA1 -> [jpeg] -> EA2 -> [jpeg] -> PA = [jpeg] + PA

Ouch.

If you ask me personally, as a developer, I think this design is just wrong (I admit however they may have reasons for that) :)

I wish I know someone with good UI coding skills for OSX to prove that there is a better way of doing this.

Thanks for attention,

Alex Hude

P.S. For every Aperture user who was patient enough to read to this point I have a little reward.

Entire Aperture adjustment core is actually still here with us as a part of OSX private frameworks. And it looks like Photos App is using it more and more… ;)