Equivalent of "maximum" quality export in Photos #1522
Replies: 1 comment 14 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.
-
|
Interesting, yes I tried out requestimageforasset and am seeing the same results you are reporting, with a slightly larger file and stripped metadata. (I think the metadata loss is expected since it's not present in the NSImage representation, but my Cocoa is a bit rusty.) One other variable that's come to my attention is the color profile... it seems like any color profile change that triggers a reprocessing of the pixel data (e.g. a conversion instead of a simple profile assignment) will have a dramatic effect on the byte size of a "maximum" quality JPEG. Also, rethinking my testing protocol, since a lossless TIFF export is available in the Photos.app GUI, and since requestimageforasset is returning an NSImage, I'm saving that down to a TIFF as well to eliminate a potential JPEG compression pass. But still not getting equivalent output between the requestimageforasset and Photos.gui export versions. But the image returned from requestimageforasset also doesn't seem like an exact match for the cached edited image in the Photos library, suggesting that some processing or resampling of the edit stack is taking place, but I'm not 100% sure of this yet. Will keep trying permutations. |
Beta Was this translation helpful? Give feedback.
-
|
Digging into Photos.app a bit with Instruments, it seems to be calling a few methods of interest during the export process, things like:
I'm not seeing these same methods called when using the public PhotoKit image request methods. This vaguely supports the hypothesis that Photos.app is re-rendering the adjustment stack on export via the GUI in a way that doesn't quite match what we're getting from PhotoKit. I tried playing around with |
Beta Was this translation helpful? Give feedback.
-
|
Great detective work! I'm playing around with |
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.
-
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