Conflicting target file tags (gps+orientation) when copying tags

Started by kana, September 08, 2020, 01:08:18 PM

Previous topic - Next topic

kana

tl;dr
When using "-tagsfromfile", the "-all:all" parameter corrupts the rotation tag orientation when played, if omitted, the gps data gets blown up so that Apple Photos doesn't recognize the location anymore.
Is there a way to get both things right?

**************************
UPDATE:
Important update: I noticed that -all:all actually correctly preserves the rotation tag of 90, nevertheless the file is played in the wrong direction. Only patching with the seemingly wrong value of 0 brings the desired result.
So I figure there ought to be yet another tag that controls the orientation, I can't figure out though wich it might be.

I'm using exiftool 12.05

**********************


Consider this use case:
I've got directories full of mov files that I had Handbrake transcode to HEVC mp4 files.
Unfortunately, Handbrake doesn't pertain the exif data, so in the transcoded files, important data like GPS coordinates is missing.

I was trying this command
exiftool -all= -tagsfromfile ./src/%f.mov -ext mp4 ./dest
and at first it looked good, but then I noticed that Apple Photos wouldn't recognize the GPS tags in the new file.

Then I found the recommendations in the FAQ (https://exiftool.org/faq.html#Q9) and added all:all which presumably keeps as much of the original tag structure and content as possible:
exiftool -all= -tagsfromfile ./src/%f.mov -ext mp4 -all:all ./dest
This actually solves my GPS issue, however, it causes another issue where the updated file is played with a wrong 90 degrees rotation (both Apple preview and the VLC do this).

I am actually able to patch this via
exiftool -rotation='0' file000494_withAllAll_rotation_patched_90.mp4
and get the wanted result where the file is played in correct orientation.
These observations, however, are in contrast to what Phil said in https://exiftool.org/forum/index.php?topic=6010.msg29546#msg29546

So my main questions are:
-Why is -all:all not capable of preserving the rotation data? Is rotation special to some extent?
-What is the command that correctly transfers as much as possible original information, especially gps and rotation information?

Side questions:
-From manually inspecting the tags, the gps information in the [Composite] group seems to be identical in *all* the files. Is there an issue in Apple Photos that gets confused by the other tags?
-Why is it possible to modify the resulting rotation although Phil said differently. I guess it's me who is overlooking something..
-Although I have read the Q9 section in the FAQ, I am not able to grasp how the mechanism described there leads to the creation of redundant information as seen in the destination files (see below, the original data gets sometimes blown up with ItemList and XMP-Exif group tags). Would anybody mind to explain this to me?


PS: Some detailed information I gathered via
exiftool -a -gps* -s -G1 -ee file000494*
I merged in the results of an additional
exiftool -a -rotation -s -G1 -ee file000494*
As I proved to myself above with the patch, rotation is the sufficient tag that is responsible for the orientation


This is from the original file *before* transcoding, the reference
======== file000494_org.mov
[UserData]      GPSCoordinates-deu              : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[Keys]          GPSCoordinates-deu-DE           : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[UserData]      GPSCoordinates                  : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[Composite]     GPSAltitude                     : 421.092 m
[Composite]     GPSAltitudeRef                  : Above Sea Level
[Composite]     GPSLatitude                     : 48 deg 38' 19.68" N
[Composite]     GPSLongitude                    : 9 deg 33' 55.80" E
[Composite]     GPSPosition                     : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E
[Composite]     Rotation                        : 90


This is from the first command with no "all" parameter whatsoever. non working location, right rotation,
======== file000494_noAllAll.mp4
[ItemList]      GPSCoordinates                  : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[ItemList]      GPSCoordinates-deu              : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[ItemList]      GPSCoordinates-deu-DE           : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[XMP-exif]      GPSAltitude                     : 421.092 m
[XMP-exif]      GPSAltitudeRef                  : Above Sea Level
[XMP-exif]      GPSLatitude                     : 48 deg 38' 19.68" N
[XMP-exif]      GPSLongitude                    : 9 deg 33' 55.80" E
[Composite]     GPSAltitude                     : 421 m Above Sea Level
[Composite]     GPSAltitude                     : 421.092 m
[Composite]     GPSAltitudeRef                  : Above Sea Level
[Composite]     GPSLatitude                     : 48 deg 38' 19.68" N
[Composite]     GPSLongitude                    : 9 deg 33' 55.80" E
[Composite]     GPSLatitudeRef                  : North
[Composite]     GPSLongitudeRef                 : East
[Composite]     GPSPosition                     : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E
[Composite]     Rotation                        : 0


That's the -all:all version that keeps the original groups. working location, wrong rotation
======== file000494_withAllAll.mp4
[UserData]      GPSCoordinates                  : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[UserData]      GPSCoordinates-deu              : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[Keys]          GPSCoordinates-deu-DE           : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[Composite]     GPSAltitude                     : 421.092 m
[Composite]     GPSAltitudeRef                  : Above Sea Level
[Composite]     GPSLatitude                     : 48 deg 38' 19.68" N
[Composite]     GPSLongitude                    : 9 deg 33' 55.80" E
[Composite]     GPSPosition                     : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E
[Composite]     Rotation                        : 90


I made an additional experiment with just -all parameter, non working location, right rotation
======== file000494_all.mp4
[ItemList]      GPSCoordinates                  : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[ItemList]      GPSCoordinates-deu              : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[ItemList]      GPSCoordinates-deu-DE           : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E, 421.092 m Above Sea Level
[XMP-exif]      GPSAltitude                     : 421.092 m
[XMP-exif]      GPSAltitudeRef                  : Above Sea Level
[XMP-exif]      GPSLatitude                     : 48 deg 38' 19.68" N
[XMP-exif]      GPSLongitude                    : 9 deg 33' 55.80" E
[Composite]     GPSAltitude                     : 421 m Above Sea Level
[Composite]     GPSAltitude                     : 421.092 m
[Composite]     GPSAltitudeRef                  : Above Sea Level
[Composite]     GPSLatitude                     : 48 deg 38' 19.68" N
[Composite]     GPSLongitude                    : 9 deg 33' 55.80" E
[Composite]     GPSLatitudeRef                  : North
[Composite]     GPSLongitudeRef                 : East
[Composite]     GPSPosition                     : 48 deg 38' 19.68" N, 9 deg 33' 55.80" E
[Composite]     Rotation                        : 0



Phil Harvey

I've seen this a couple of times recently where someone tries to copy all tags to a video and the rotation changes.  I think the thing to do is for me to make both Rotation and MatrixStructure protected when writing.  I'll do this in ExifTool 12.06.

Quote-Why is -all:all not capable of preserving the rotation data?

Presumably because the transcoded file is rotated differently.

Quote-From manually inspecting the tags, the gps information in the [Composite] group seems to be identical in *all* the files. Is there an issue in Apple Photos that gets confused by the other tags?

Composite tags don't exist in the file -- they are derived from the values of other tags.

Quote-Although I have read the Q9 section in the FAQ, I am not able to grasp how the mechanism described there leads to the creation of redundant information as seen in the destination files (see below, the original data gets sometimes blown up with ItemList and XMP-Exif group tags). Would anybody mind to explain this to me?

Video metadata is a mess, and there are numerous locations where it may be stored.  Use should use -all:all to preserve the original location if you are copying to the same type of file and want the information to go in the same location.  Otherwise ExifTool will copy it to the default location(s), which may be different.  See the second paragraph here for more information.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

kana


QuoteI think the thing to do is for me to make both Rotation and MatrixStructure protected when writing.  I'll do this in ExifTool 12.06.
For the time being, is there a workaround that works automatically, or would I have to, after the tag copy, identify the videos that got rotated and patch their rotation tag manually?

QuoteComposite tags don't exist in the file -- they are derived from the values of other tags.
If that is the case, I don't understand why was I able to successfully write the rotation tag?:

kana@Daniels-Mac RealTest % exiftool -a -rotation -s -G1 -ee file000494_withAllAll_rotation_patched_90.mp4
[Composite]     Rotation                        : 90
kana@Daniels-Mac RealTest % exiftool  -rotation=0 file000494_withAllAll_rotation_patched_90.mp4
    1 image files updated
kana@Daniels-Mac RealTest % exiftool -a -rotation -s -G1 -ee file000494_withAllAll_rotation_patched_90.mp4
[Composite]     Rotation                        : 0



QuoteVideo metadata is a mess, and there are numerous locations where it may be stored.  Use should use -all:all to preserve the original location if you are copying to the same type of file and want the information to go in the same location.  Otherwise ExifTool will copy it to the default location(s), which may be different.  See the second paragraph here for more information.
Hard stuff for a newbie  :o .  What I'm taking away is that -all:all is the point to start from 👍 :D

Phil Harvey

Quote from: kana on September 09, 2020, 06:14:14 AM
For the time being, is there a workaround that works automatically, or would I have to, after the tag copy, identify the videos that got rotated and patch their rotation tag manually?

Just add --rotation --matrixstructure to the command after the -tagsfromfile XXX option to prevent these from being copied.

Quote
QuoteComposite tags don't exist in the file -- they are derived from the values of other tags.
If that is the case, I don't understand why was I able to successfully write the rotation tag?:

Rotation is a writable Composite tag.  It writes back to the derived tags when written.  See here.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

kana

Quote from: Phil Harvey on September 09, 2020, 08:19:41 AM
Just add --rotation --matrixstructure to the command after the -tagsfromfile XXX option to prevent these from being copied.
That works like a charm, that's a fantastic tool, thanks you!