Running makelive results in a reduced file size image
Opened this issue · 8 comments
Before submitting a bug report, please ensure you are running the most recent version of osxphotos and that the bug is reproducible on the latest version
- If you installed with pipx:
pipx upgrade osxphotos
✅
Describe the bug
Importing images and videos using the new --auto-live command compress the size of the images.
Import an image IMG_4280.JPG directly into the photo app
Import IMG_4280.JPG + IMG_4280.mov by using osxphotos
The video size changes a little...
To Reproduce
Steps to reproduce the behavior:
- What' the full command line you used with osxphotos?
osxphotos import --auto-live "/Users/artem/Local folder/Live Photo"
Desktop (please complete the following information):
osxphotos, version 0.68.1
Python 3.12.3 (main, Apr 9 2024, 16:54:45) [Clang 14.0.0 (clang-1400.0.29.202)]
macOS 12.7.5, x86_64
The --auto-live feature rewrites the file because it must edit the metadata that Apple embeds in the photo and video to become a live photo. I will look at the code to ensure it's using the maximum quality settings but there's not much I can do besides that. There is no way to convert to a live photo without rewriting the file as the Live Photo requires the use of Apple proprietary metadata that tools like exiftool cannot write. I am using Apple's Core Graphics framework to write the image.
Interestingly, I ran makelive (which osxphotos uses for the --auto-live option) and the resulting jpeg was nearly identical in size:
Before live conversion:
After live conversion:
Running dssim to find differences in the resulting JPEGs resulted in a very small delta:
$ dssim test.jpeg tests/test.jpeg
0.00001462 tests/test.jpegThis means the files are nearly identical. (A value of 0.0 means the images are identical).
I'm not sure there's much more I can do to improve image quality during the "live conversion" but I will take a look to see what's possible.
I checked on another MacBook. I used makelive.
The result is similar:
Original photo - 7,4Mb
After processing - 4,7Mb
Can you try running dssim on the before and after files? I'm curious just how different they are. File size alone does not indicate that there is significant degradation. Unfortunately with any lossy image format like JPEG there will be some change anytime the file is re-encoded. I'll continue to look into the makelive code to ensure it is encoding with the best possible quality.
I've moved this issue to the makelive repo as that's really where the issue is. I tried creating a .pvt package per the convert2livephoto repo but this causes Photos to generate an error:
I figured out how to creata a .pvt package. This is just a package (a directory with an extension in macOS parlance) that contains a metadata.plist, a .jpeg or .heic, and a .mov. If the image and video both contain the ContentIdentifier maker note (which is what makelive adds to the images) then import the .pvt into Photos results in a live photo. However, if the image or the video do not contain the ContentIdentifier then Photos produces the error seen above. I'd hoped that packaging the images in the .pvt would remove the need to add the ContentIdentifier but this does not appear to be the case.
Can you try running dssim on the before and after files? I'm curious just how different they are. File size alone does not indicate that there is significant degradation. Unfortunately with any lossy image format like JPEG there will be some change anytime the file is re-encoded. I'll continue to look into the makelive code to ensure it is encoding with the best possible quality.
dssim IMG_420.JPG IMG_4200.JPG
0.00009796 IMG_4200.JPG
6,9Mb -> 4,8Mb
This means the files are almost identical (visually). I'll look into this when I have time but it may be the price of using live images as there is no way to make a live image without rewriting the image file which causes it to be re-encoded. This is an Apple design choice .