RhetTbull / osxphotos

Python app to work with pictures and associated metadata from Apple Photos on macOS. Also includes a package to provide programmatic access to the Photos library, pictures, and metadata.
MIT License
1.84k stars 94 forks source link

Somewhat strange Portrait photos #381

Open narensankar0529 opened 3 years ago

narensankar0529 commented 3 years ago

I have seen you deal with this issue before, but I have something strange going on -

I have a significant number of pictures which seem to be portrait photos but osxphotos does not seem to recognize them as portraits. And also when I look at the metadata via my iPhone with Metapho it shows the Image original as HEIC and with a FullSizeRender.jpg. But probing via python shows as follows -

photos = [p for p in PhotosDB().photos() if "AD05D755-505D-4A56-B362-706A32AA98FD" in p.uuid] for p in photos: ... print(p.path, p.path_edited, p.hasadjustments, p.portrait)

/Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/originals/A/AD05D755-505D-4A56-B362-706A32AA98FD.heic /Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/resources/renders/A/AD05D755-505D-4A56-B362-706A32AA98FD_1_201_a.heic True False

When I export via osxphotos the output file is a file with extension HEIC but it is actually a JPEG internally. So Exiftool complains whenever I try to update this file via the associated XMP sidecar.

But if I export via the Photos UI - the original is exported as HEIC and the JPEG is correctly exported with correct jpg extension.

So not sure why the render is saved as a jpeg with heic extension. But somehow exporting via Photos on macOS or iPhone works ok. But osxphotos is not able to handle this correctly.

RhetTbull commented 3 years ago

What does exiftool say this file type is: /Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/resources/renders/A/AD05D755-505D-4A56-B362-706A32AA98FD_1_201_a.heic

E.g. exiftool “/Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/resources/renders/A/AD05D755-505D-4A56-B362-706A32AA98FD_1_201_a.heic”

This is the path to the edited file and osxphotos only prints this if the file actually exists. This would seem to indicate that there’s an edited version of the image saved with .heic.

Portrait photos (internally to Photos called “depth effect”) always indicate they are edited as the depth effect seems to be done in post-processing. I’ve had to make several assumptions about identifying portraits and have had to make adjustments to the portrait code before (#203 ) so could be the same here.

Are you using —convert-to-jpeg? If so, it’s quite possible this is related as #366 and several other bugs related to this code. It has been surprisingly difficult to get this part of the code right. E.g. the image was converted to jpeg but the extension is incorrect.

Also, could you run this command and post or send me the data? The output will contain all the metadata of the photo in question so if sensitive (e.g. address information, person names, etc) you can sanitize it by editing the text file or email to me at rturnbull+git@gmail.com

osxphotos debug-dump --dump photos --uuid AD05D755-505D-4A56-B362-706A32AA98FD > debug.txt

narensankar0529 commented 3 years ago

Using another photos -

exiftool photo/2020/September/19/photo_n_200919_417CE6B7-6F93-4572-8C02-6A80028A0C0F_edited.heic outputs image as image/jpeg -

ExifTool Version Number : 12.16 File Name : photo_n_200919_417CE6B7-6F93-4572-8C02-6A80028A0C0F_edited.heic Directory : photo/2020/September/19 File Size : 3.0 MiB File Modification Date/Time : 2020:09:19 19:30:42+08:00 File Access Date/Time : 2021:02:17 00:27:52+08:00 File Inode Change Date/Time : 2021:02:16 12:41:34+08:00 File Permissions : rw-rw-r-- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg JFIF Version : 1.01 Exif Byte Order : Big-endian (Motorola, MM) Make : Apple Camera Model Name : iPhone XS Max

I am not using --convert-to-jpeg in this scenario

Will email the debug.txt to you

RhetTbull commented 3 years ago

This is very strange and I've not been able to replicate it. What's the full osxphotos command you're using?

Also, what's the output of: exiftool “/Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/resources/renders/A/AD05D755-505D-4A56-B362-706A32AA98FD_1_201_a.heic”

and

exiftool “/Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/resources/renders/4/417CE6B7-6F93-4572-8C02-6A80028A0C0F_1_201_a.heic”

RhetTbull commented 3 years ago

Thanks for sending the debug data. It appears the actual rendered file inside the Photos library is really a jpeg even though it has .heic extension:

File Name : F638A916-473E-4BEC-BB2A-F1A79805BC9C_1_201_a.heic
Directory : /Volumes/PhotoSync/nsankar/Photos Library.photoslibrary/resources/renders/F 
File Type : JPEG File Type Extension : jpg
MIME Type : image/jpeg

Is it possible this photo was edited in an external editor or plug-in? If so, do you know which one? You had a similar issue with luminar flex (https://github.com/RhetTbull/osxphotos/issues/322)

narensankar0529 commented 3 years ago

This image was not edited. I think this is a bug in Photos on how it is syncing from iOS to iCloud. I think the root cause is that for around a month last year Portraits from my iPhone were not synced up as Portraits to iCloud. So when downloaded to my Mac it seems that they got downloaded as rendered Jpegs with HEIC extensions.

So when I go to my iPhone and just open up the picture and edit it in any way - for example add a filter, then with the sync it seems to go through correctly and gets updated on my Mac with a HEIC in HEIC. I have filed a bug with Apple, but not sure if/when they might look at this.

For osxphotos perhaps there is a way to check on export if the extension matches the format when exporting and print an error?

I am using Imagemagick (identify) to probe and check in my Library and hence found these images. There were around a 100 like this. Not sure what was the reason for this issue though since this seems to be isolated to Portraits. Don't know if there is a python library that can allow you to do this easily.

And the other item I found is that some of these images now contains multiple images in the HEIC. One - full size and one reduced size. Again there doesn't seem to be any rhyme or reason for this. But when osxphotos exports the image it exports both images in a single HEIC. Not sure if there is a way to again detect/handle this. But less of an issue.

RhetTbull commented 3 years ago

For osxphotos perhaps there is a way to check on export if the extension matches the format when exporting and print an error?

This is similar to #322 which was also the result of Photos using the wrong extension for edited files. I've already created an issue (#336) to add a fix feature. It would be possible to also do this on export but there's not a reliable way to do this without an external dependency like Image Magick or exiftool, e.g. exiftool -FileTypeExtension file.heic. There are some libraries such as filetype to do this but they support a limited number of image types. E.g.

>>> import filetype
>>> filetype.guess("/users/Rhet/Desktop/export/IMG_1064.heic")
<filetype.types.image.Jpeg object at 0x7febcdb1c880>
>>>

And the other item I found is that some of these images now contains multiple images in the HEIC. One - full size and one reduced size.

This would be difficult to detect. osxphotos simply copies the photo out of the Photos library so if Photos so will copy whatever Photos has put in the file. There may be some way to post-process these with Image Magick, etc.

Not sure what was the reason for this issue though since this seems to be isolated to Portraits.

I think the issue with not detecting these as Portraits is the same issue as what caused the corrupted jpegs in the first place -- a Photos bug. The depthstate column in the database, which indicates Portrait photos shows these are not Portraits as far as Photos is concerned.

RhetTbull commented 3 years ago

Do the photos in question show up as Portrait in Photos (e.g. in the media types album under Portraits)

RhetTbull commented 3 years ago

I think the only reliable way to find the correct extension of the file is using exiftool. It handles the widest variety of formats. Unfortunately this means that for user to use a --fix-file-extension feature, they'd need to install exiftool (not a big deal) but it would also slow down export as exiftool would need to be called on every photo. The filetype library looked promising but it incorrectly guesses tif for all raw formats it doesn't recognize:

>>> photo.uti
'com.adobe.raw-image'
>>> photo.path
'/Users/rhet/Pictures/Test-10.16.0.1.photoslibrary/originals/D/D05A5FE3-15FB-49A1-A15D-AB3DA6F8B068.dng'
>>> filetype.guess(photo.path).extension
'tif'

whereas exiftool:

exiftool -FileTypeExtension '/Users/rhet/Pictures/Test-10.16.0.1.photoslibrary/originals/D/D05A5FE3-15FB-49A1-A15D-AB3DA6F8B068.dng'
File Type Extension             : dng