Equivalent of "maximum" quality export in Photos #1522
Replies: 2 comments 17 replies
-
|
Interesting analysis -- thanks for sharing. Currently osxphotos exports only the cached edited image stored in the library (unless the image is missing and you use It would definitely be useful to have a way to export the "Maximum" quality image as you noted. I have some code where I've been playing with the private Photos API (which I hope to eventually turn into a complete rewrite of osxphotos). I'll take a look and see if there are any clues to doing this. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the update! I'm pretty deep down the rabbit hole at this point 😅, so to claw back some sanity I put together a script to automate the comparison of different export strategies. Here are some tables output by the script: Image ID: 0CC54CB1-EE02-4230-80B1-D8CB8CF229CE
Image ID: 77758382-025A-446E-91C6-88A0BCAFDA91
Image ID: B60D9534-6ADE-4BD9-83EC-A95C8DEBFB8F
These results mostly show what we've seen before, with "fatter" files coming out of the GUI export, and multiple other export paths simply copying the cached edit file straight from the In the course of automating this, I wrote an AppleScript that manipulates the Photos export GUI dialog directly to get the full-quality edited files. I posted the AppleScript file and a TypeScript wrapper to a gist. Happy to share the whole comparison-generating script too, but it's in TypeScript, not Python, and kind of entangled in the rest of the stuff I'm working on. Anyway, it's a quick hack, it's slow, and I'm finding it tricky to deduplicate the logic in AppleScript code. But it's nice to have all the other export options available — resizing, color profile handling, and so forth. I also explored your (awesome) PhotoScript project, which definitely solves Photos-related AppleScript manipulation in a more robust way. I can contribute a PR integrating the export script if that's of interest, but honestly this approach is probably too brittle to be worth maintaining since it's just poking at the GUI instead of calling proper commands from the Photos automation dictionary. (Especially if the private APIs end up working instead!) Also FWIW, this round of testing confirmed that the "original" exports of unedited files are perfectly consistent across the range of export strategy. Not super surprising since it should just be a file copy, but at least there's nothing weird happening there. And finally after futzing with the Photo editing APIs, it seems like the promise of "lossless" editing across apps is elusive in practice, and the pipelines between Photos and other apps resemble a game of "bitmap potato" instead of thin stacks of constantly-recalculated adjustment metadata on top of the original image data. So far the only place I've ever seen an actual re-render of the edit stack kick in is through the Photos Export GUI... The main issue seems to be that the "edited" JPEGs Photos.app saves to the Library are pretty heavily compressed, but Photos treats that as good enough to be the "highest quality" version of the edited file available via the public PhotoKit APIs... The moral for me here was to avoid editing library photos across multiple apps, and definitely don't start a stack of edits in Photos. Photomator, for example, saves its edited bitmaps at a higher quality. So, in theory working from the original Photos.app file in a third-party app first, and then making some final tweaks in Photos.app second is less destructive than going the other direction. |
Beta Was this translation helpful? Give feedback.
-
|
I just noticed a not-so-fun caveat: The export menu item in Photos does not preserve the alpha channel. |
Beta Was this translation helpful? Give feedback.
-
I'm trying to use Instruments to debug another issue in Photos but I'm not very familiar with the tool. Any tips for how you configured it to see the calls that Photos was making? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Rhet, I'm far from an Instruments expert, but can share my approach. I made a quick screen recording to show the steps. Basically cue up the action you want to analyze in Photos, then start the recording in Instruments, take the action, then stop the recording and dig into the various datapoints captured. There's not a ton of symbolication, so lots of calls are just memory addresses. Photos.+.Instruments.mov |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Rhet, dusting off the project that had led to this thread earlier this year — everything's still working in Sequoia which is great. Just wanted to offer one more data point... I was curious if Jpeg XL support might open up an improved export pipeline in Photos.app on Sequoia, but FWIW I'm still seeing alpha channel deletion when exporting Jpeg XL images with transparency to PNG/ TIFF from the export menu. I'm not seeing any promising changes in the PhotoKit API diffs... any new insights from your end? |
Beta Was this translation helpful? Give feedback.
-
It seems like Photos.app implements some additional plumbing to re-render the stack of image adjustments at a higher quality when TIFF, PNG, or "Maximum" quality JPEG is requested via the export command GUI:
However, as far as I can find, all the available programmatic export techniques seem to top out at the equivalent of the "High" quality Photos.app JPEG export, sometimes resulting in non-trivial compression artifacts in the resulting images.
Seems like there's no way to specify export format or quality via AppleScript, and I tried writing a quick Swift app using PhotoKit directly to poke around and see if there were any options to request additional quality. I found none.
Interestingly PowerPhotos exposes additional export options (TIFF, "Maximum" quality JPEGs, etc.), but these don't seem to yield the same output as the equivalent options Photos.app. For example, a TIFF export comes with JPEG artifacts reminiscent of the "High" quality export from Photos.app.
I tested across a couple different export techniques for an image edited in Photos.app which was originally a 6MB jpeg out of the camera. The results are summarized below, with many landing at 497,748 bytes, suggesting the export is a straight copy from the edited JPEG stored in the Photos library filesystem:
I realize the relationship between file size and image quality is not guaranteed, but on inspection there are subtle but perceptible differences between the ~500K and ~5MB JPEG exports.
This is in no way the fault of osxphotos, and of course exporting the original image will preserve full quality regardless — but I'm curious if anyone else has noticed this discrepancy between "High" and "Maximum" quality exports of edited images, and if there's any sort of work around or option that can automate exports of a quality equivalent to that available in the (tragically cumbersome) Photos.app GUI.
Beta Was this translation helpful? Give feedback.
All reactions