-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged HEIC photos are not detected as HDR by Google Photos #2
Comments
|
Correction: If the XMP data contains the GCamera tags (MotionPhoto etc.), then Google Photos themself will stop looking for Apple HDR information. If you add any other tag (for example standard EXIF tags in XMP), then it works just fine (but cannot be recognized as Motion Photo). The reason is probably that the same GCamera namespace includes support for incompatible gain map HDR format. If you save the photo back to iPhone, it's still HDR. Sometimes, because GPhoto saves the photo in both JPG and HEIF format, HDR will not show even in photos app. In that case, edit the picture and immediately discard changes, HDR should show up then. Funnily enough, if you download the image to phone, kill GPhotos and launch it again, it'll usually show the image in HDR too - but it has to be saved locally on iPhone for that to work. The way to overcome this would theoretically be to remux the HDR information into google-specific ways... But unless someone can point me to some code, it's a very tall order... It also seems that the Google/Adobe gain map format only applies to JPG images... Links: |
Looking at AOSP source, I saw that namespace checking was not present, so I decided to try to fuzz it a bit to see if this could've helped (HDR code not seeing the tag and MotionPhoto seeing it). Unfortunately I must report that GPhoto server-side code is significantly better quality than Android, it works as it should (in case ns is incorrect, it is completely ignored, in case it is correct but unusual name, it works but turns off HDR) |
Thanks for looking into this on such deeper level. Just posting a reference where this discussion started. |
FYI, This should be soon available starting from Android 15 👍 |
Be careful about reading too much into the article - it never mentioned HEIC. The current libultrahdr does have some code for ISO HDR, but purely in JPG. The coveted compatibility is not that close IMO. I wish it was...
Muxing iPhone HDR JPGs may very well be possible now for all I know (possibly with some metadata fixing), but I personally have zero need for that. I'm not switching my camera to JPEGs :-) Additional note: See section "ISO 21496-1 Compatibility" at https://developer.android.com/media/platform/hdr-image-format. That 1) hints at the location in libultrahdr responsible for ISO gainmap and 2) confirms this is only for JPEGs for now. It also suggests that HDR JPEG MotionPhotos based on iPhone ISO-Gainmap JPEGs (e.g. iPhone 15+ iOS18+) should retain the HDR... I'll try to create such a test... The pictures based on Apple-Gainmap JPEGs seem to lose the HDR info in GPhotos. |
Ok, so even new iPhone JPGs are not detected as HDR... As soon as the GCamera structure appears, it seems it has to have the gainmap record to be recognized :-(. I've created issue #15 for it and will try to find some time to look into it. |
Confirmed, I was able to hand-craft a working MotionPhoto with HDR from iOS Live Photo. It has to have the android headers and HDR gainmap metadata, fortunately it is easy to copy it over from the ISO 21496-1 metadata. For older picture without the ISO values, I'm missing gamma adjustment that essentially covers the difference between colorspaces and between iOS and Android approaches. |
When merged photo is uploaded to GPhotos, it is not tagged as HDR.
Investigate if this can be caused by the XMP tag differences (the program tries to copy the HDR tags, but it does not create the same namespace alias, when it fails it does so silently etc.). If the problem cannot be tracked back to XMP changes of HEIF image, then it probably needs to reside in another place for Google/Samsung images :-(
The text was updated successfully, but these errors were encountered: