> 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.)
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.
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.
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/