Error parsing -M option arguments: Invalid key Xmp.GCamera.MotionPhoto #3016
Comments
|
I don't understand XMP or Adobe's XMPSDK. The exiv2 option -dX will totally remove the XMP, and that might be the solution to your needs. Your image contains the following XMP data: XMPSDK understands the data and can modify it. I have insufficient knowledge to explain this. I see that your image contains ExtendedXMP which is not supported by XMPSDK 5.4 embedded in exiv2. So the option Looking at your file with program tvisitor (which is thoroughly documented in my book), I see: Almost 50% of the file (from 3870002 onwards) is XMP, previews, and various APPn segments. As discussed in 3.1 of my book, you can remove that data with dd. I think this is what you want to save storage space. This could be added as a new option |
|
Thank you for the response! I believe I have tried removing the whole XMP section, and this has an unfortunate downside: the Ultra HDR data is also removed, as it is apparently stored in the XMP. Since this is important to me I decided against this approach. |
|
@arty-name. I attach foo.jpg. I think the XMP (and extended XMP) remains in the file. Is the "Ultra HDR" still present?
|
|
I don’t know what happened but Google Photos doesn’t recognize this file as having Ultra HDR and doesn’t display it with extra brightness |
|
Well, I threw away half the data in the file, so it must be in the stuff I removed. Here's the specification: for "Ultra HDR" https://developer.android.com/media/platform/hdr-image-format So, I'm not convinced this is a bug. It's an enhancement request to support ExtendedXMP and remove the Ultra HDR information. If you're happy with the I'm only offering to mentor and am not coming out of retirement to work on this. If you can't work on this, you'll have to wait to see if another engineer offers to help. |
|
I've put https://photos.app.goo.gl/3aWMWPbR62U2VYJq7 I like and use Google Photos. The 90,000 images on my website are stored in Google Photos. https://clanmills.com |
|
Progress. I've uploaded foo2.jpg to Google Photos. I figured out Apologies: @arty-name Tom: I'm on vacation with my family and can't spend more time on this. This is an interesting challenge. I hope somebody can find time to work on it. |
|
|
|
Thank you for your work, Robin! I have the utmost respect for people being able to handle these insane data structures. I didn’t intend, of course, to distract you from your vacation, not even mentioning the retirement. The view is very cozy! The colors with Ultra HDR are quite nice indeed. I found the technical approach there a bit of smart cheating: bumping up the OLED screen brightness. Nevertheless it’s nice to see screens finally competing not only on resolution and refresh rate. |
|
@arty-name. Tom: I'm happy to investigate this matter. I've been busy travelling, gardening, and performing music and should take time to investigate software puzzles. I was bored on Friday morning, and you presented an interesting issue. Thank You for bringing up this topic. Your file uses extended XMP and MPF segments, as shown in this drawing from https://developer.android.com/media/platform/hdr-image-format.
The 20230713_123442-CINEMATIC.1.mp4I didn't document MPF in my book and will investigate this when I get home in two weeks. The file The colours on my MBP are beautiful, and I look forward to seeing them on my ALOGIC touch-sensitive UHD desktop when I return from vacation. Progress in display and camera technology is excellent. Exiv2 has no code to manage MPF or Extended XMP and therefore the changes to Exiv2 involve architectural changes to Exiv2. Until this work can be undertaken, the solution to your issue is to use Phil's excellent |
|
I'm awake. The family are still asleep. Here's your video: 34.mp4
How did I figure out I've signed up for an August Google alert about the Pixel 9 Pro. I know what I'm going to get for Christmas. |
Oooh, exciting!
I’ve tried it out as well, and extracting data is relatively straightforward with it, but modification turned out to be too much of a challenge for me. |
|
Making progress. It's painful, I don't think I've written any C++ for a couple of years. When dumping Stonehenge.jpg, tvisitor shows: I've added a dictionary to understand MPF and the recursive dump shows: I hope to add the decoder to handle MPF.MPF.Photos tomorrow. No good news about the Pixel 9 Pro. Alison asked the killer question: "Will that work with your Samsung Watch?" |
|
This is difficult. Specifications: Challenges:
Dumping MPF.MPF.Photos: I'm not certain that this conforms with this drawing: |
|
I didn’t have to look at Android-related documentation often, nor too deep, but it was always a bad experience. I would not be surprised if the implementation does not 100% match the specification. Regarding the Samsung Watch, this depends on its generation. Recent versions switched away from Tizen OS and started using Google’s Wear OS, which supposedly should be better compatible. However even my old Tizen OS based Samsung Watch worked okay with Android phone. Not Pixel though, I cannot vouch for it. |
|
@arty-name Alison doesn't want a solution. My current Samsung Watch/Phone setup is working fine and will be upgraded eventually. I have a lot of confidence in Google Engineers. Can you confirm that I've been out for a walk and thought about this puzzle. Three useful conclusions:
MPF.nPhotos is: And we know the two images (greyscale image + movie) are located at: Only 98874 is correct. The other three numbers seem to be wrong. Next step. I'll inspect the files with exiftool debugging options. Here's the greyscale jpg |
|
I've had more thoughts about this. The MPF segment offset/length data is unsafe. When we rewrite the JPG, the segment order is unchanged, however the segment lengths can change, which implies that when a JPG is rewritten, the MPF segment data should be updated. Exiv2 does not support MPF. The exiv2 rewrite strategy to blindly copy after EOI is good because the additional images/movies will be preserved. That is to say, the additional images/movies are undamaged and lie in sequence after the primary image. Now that I understand your file, I return to the bug report concerning Your aim is to delete the embedded movie in the file (to save space). Let's suppose we had an option on the exiv2 command to "delete embedded movies". It would have to:
Exiv2 cannot delete embedded movies. May I ask you to close this issue? |
clanmills
added
enhancement
|
Thank you for looking into this, Robin! That’s fair, an unsupported feature is definitely not a bug. |
|
@arty-name Tom: Thank you for logging this interesting matter. I'm surprised to learn that JPG files may contain embedded movies and HDR Gain Maps. I'm going to update my book with this discovery. I'm going to put the book and utilities (tvisitor and dmpf) on GitHub. When I wrote it, the code was on the Exiv2 SVN repository which was abandoned when the exiv2.org server was rehosted. That code is useful for debugging files. One day somebody will discover and appreciate the value. AFIK, it's the only book ever written about how metadata is stored in images. |
|
This way of extending JPGs was a total surprise to me as well! It’s great to have a central place documenting data formats like these, especially when it’s kept up-to date. I vaguely remember the existence of tools for converting the SVN commit history into git. Such history could be quite valuable. |
|
All code going into Exiv2 on GitHub has to be reviewed/approved by other team members. I put the book into SVN to avoid that. When we changed the host for exiv2.org, the SVN repository didn't move. I'll open a new repository on github and put the book there. Image file formats are a software nightmare. Exiv2 and tvisitor support 18 different formats (TIFF, JPG, PNG etc). What's the difference? We've had several efforts to kill JPEG (for example: JP2000, WebP, JXL, HEIF). All different and none have displaced JPEG. Canon have three different RAW formats (CRW, CR2 and CR3). A JPEG file is a linked list of segments. Adobe added transparency to JPEG about 20 years ago using a clippath segment. Adding capability, by extension, seems better than inventing new formats. |
Describe the bug
My phone sometimes includes "Motion Photos" in the photos it takes. Sometimes I want to remove them to save on file size. I see them in the XMP section. When I try to delete these XMP tags I get an error that the key I provided is invalid. The same command with an EXIF tag works flawlessly.
To Reproduce
Steps to reproduce the behavior:
exiv2 -M"del Xmp.GCamera.MotionPhoto" test2.jpgorexiv2 -M"del Xmp.Container.Directory[3]/Container:Item/Item:Padding" test2.jpgExpected behavior
I expect the XMP tag to be deleted. Instead I get an error message like this:
Desktop (please complete the following information):
Additional context
Add any other information about the problem here.
The text was updated successfully, but these errors were encountered: