this is the best plausible reason for why the file size differs. I've also noticed some unepxected media restoration (thought I cropped/edited a video, it is still there in full length and resolution).

This also helps explain why my iPhone storage always seems to be at its limits, despite my obsessive management.

Anyway, we all know foss unix ftw :P

> thought I cropped/edited a video, it is still there in full length and resolution

It's been possible to create a clip from a video file that merely changes what parts of the video are displayed without effecting the data in the original since the Classic Mac OS days.

If you want to completely remove unwanted portions of a video to reduce the size without a loss of quality, there are many options. LosslessCut is a cross platform option that is both free and open source.

https://github.com/mifi/lossless-cut

> I think that all "photos" or "videos" are just a view of the underlying "photo or video object". If you crop a video, the full-size video will remain. Only if you export the video, it will be cropped and the smaller file size will manifest.

Yup, the Photos app keeps the unmodified original file, and then any edits/crops are stored separately. You can always revert to the original file and redo your edits. So they might be storing multiple copies of the same image, with and without edits.

Which API were you looking at for "file size"?

I was able to get the size data from Photos.app with the PhotoKit API [1]. I've only tested it with my library of ~26k items, but it was useful for getting an indicator of the biggest items. (Although I didn't think to check whether exporting a 1GB video caused my iCloud usage to drop by 1GB.)

[1]: https://alexwlchan.net/2023/finding-big-photos/

Ahh, I did consider PHAsset.fetchAssets but my understanding was that the method will download the file if not present locally - which wouldn't be acceptable for an app, I guess.

Do you know more? The introduction says "Retrieve asset metadata or request full asset content.", but I can't find clarification when it actually accesses full content.

Yeah, that was what I thought when I first worked with these APIs! But when you use PhotoKit, you have to explicitly opt-in to downloading files from iCloud.

AFAICT, PHAsset is only metadata. When I'm downloading the full-sized images, I use PHImageManager.requestImage() and pass in the PHAsset I'm looking at [1][2]. I know there's something similar for video, but I've never used it.

You can control the behaviour by passing a PHImageRequestOptions instance. This includes an isNetworkAccessAllowed bool which controls where Photos.app will download the file from iCloud if not present locally, and it defaults to false.

[1]: https://developer.apple.com/documentation/photokit/loading_a...

[2]: https://developer.apple.com/documentation/photokit/phimagema...

[3]: https://developer.apple.com/documentation/photokit/phimagere...

It’s (much) more complicated than that. HEIC format allows multiple “frames” to be stored in the container, each one derived from the source (or each other). So there may literally be just one file but it has (algorithmically) the definition for generating (losslessly) the other files, too. So there isn’t/wouldn’t be even a separate “smaller copy” at all as it is generated on-the-fly.

Since you're willing to write since code apparently: have you checked the internal databases? They're just sqlite, moderately understandable at a glance last time I looked.

Side note, been a while sense i looked, is there a sqlite db for the contacts table?

Yes

well the created_at/updated_at (these arnt the names of the colums, but still) are from when my macbook synced and not when the actual contact was created. useful, but not what i needed.

Looks promising - will look into it!

So it appears you can conveniently query the DB for filename (+directory), UUID, and (original) file size. But I can't find a good way of opening a Photo by filename or UUID.

After all, the file might not be present locally, so opening it should go through the Photos.app. But once you call AppleScript to open the file, you might as well use the AppleScript to comb through the database like the script I linked to earlier.

Check out this which I believe has that feature: https://github.com/RhetTbull/osxphotos

Yes, `osxphotos show UUID` will open the photo with UUID in the Photos app. (I'm the author of osxphotos)

>write since code

"since" -> "some". ugh. I had a bad swiping day apparently.

You might know this already but the Photos catalog/photiolibrary is just a folder. You can actually right click and “show package contents”. From there, you can use something like Daisy Disk to display all the files based on their size. A simple drag and drop has worked for me. Once you find the large file, you can search for the name in the photos app. I’ve deleted some quite large videos this way to clear up some space.

This only works for files saved locally though. Doesn’t help with large files on the iCloud server.

On top of that, something I still haven't looked into the details on: when you import RAW+JPG photos, the "original" can be set to either one. You can import and make some edits without realizing which is being used unless you go through the menus. So my freshly imported pic could be 5MB or 50MB despite just being a single thumbnail in the library.

https://github.com/RhetTbull/osxphotos will do this:

osxphotos query --min-size 100MB --add-to-album "Big Files"

Finds all photos, videos > 100MB and adds them to the album "Big files"

`osxphotos query --help` for more info or `osxphotos docs` to open docs in the browser.

Disclaimer: I'm the author.