“Write only existing tags” without ALWAYS creating a temp file?

Started by Jan2, December 20, 2022, 11:04:17 AM

Previous topic - Next topic

Jan2

Hello,

with something like this:

% exiftool -wm w -XMP:GPSLatitude=48,51.69108796N -XMP:GPSLongitude=2,20.81508814E -overwrite_original_in_place /file.jpg
... I am changing the locations of multiple images, but do not add gps data if it is not already there.
Generally this works as expected, except for one annoyance:

This process creates a temp file, a copy of the image, EVERY time, even for images that remain unchanged.
In cases where the majority of the files remain unchanged, and especially when it comes to large photos or even videos, that seems a bit unnecessarily slow.

Is there a better way to do this? ... I am fairly new to all of this, so maybe there is something obvious I am missing?

(Otherwise I will have to add a read only preprocess phase to first check if the corresponding tags are available ... but this slows down the other cases ...)

Thanks a lot!

StarGeek

Add the -if option to check to see if the GPS tags already exist or not.

% exiftool -wm w -if 'not (defined $XMP:GPSLatitude and defined $XMP:GPSLongitude)' -XMP:GPSLatitude=48,51.69108796N -XMP:GPSLongitude=2,20.81508814E -overwrite_original_in_place /file.jpg

You didn't mention your OS, but I'm assuming Mac/Linux due to the leading %

Also take note that the -overwrite_original_in_place option is slower than the -overwrite_original option.  If your files have file system attributes you want to keep, such as xattr/MDItem on the Mac or ADS on Windows, then -overwrite_original_in_place is what you want.  But if your files don't have such extended attributes, you should use the -overwrite_original option.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype

Jan2

That did not work right away, but:

% exiftool -if '(defined $XMP:GPSLatitude and defined $XMP:GPSLongitude)' -XMP:GPSLatitude=48,51.69108796N -XMP:GPSLongitude=2,20.81508814E -overwrite_original_in_place /file.jpg
... seems to work as I had hoped. Great.


Quote from: StarGeek on December 20, 2022, 11:21:51 AMBut if your files don't have such extended attributes, you should use the -overwrite_original option.

Yes I am on a Mac.
Ideally, this will not only change my own photos, so accuracy is more important to me than speed.
Is that VERY much slower? In other words, would it be worth checking the files for these extended attributes beforehand in order to then decide which variant should be used?
I think I will test around with this a bit more ...

Thanks again!

Phil Harvey

-overwrite_original_in_place should be roughly half the speed of -overwrite_original because it has to write the file twice.

- 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 ($).

wywh

Quote from: StarGeek on December 20, 2022, 11:21:51 AMIf your files have file system attributes you want to keep, such as xattr/MDItem on the Mac or ADS on Windows, then -overwrite_original_in_place is what you want.  But if your files don't have such extended attributes, you should use the -overwrite_original option.

I have always used -overwrite_original_in_place because accuracy is more important to me than speed.

But now I finally tested -overwrite_original for a file with a Finder comment and Finder color tags which to my surprise were preserved as well as many other XAttr/MDItem tags (macOS 13.1 Ventura).

exiftool -overwrite_original '-ExifIFD:DateTimeOriginal=2000:01:01 12:00:00' image.jpg
    1 image files updated

exiftool -a -G1 -s -api RequestAll=2 image.jpg                                       
[ExifTool]      ExifToolVersion                 : 12.50
[MacOS]         MDItemFinderComment             : Finder comment
[MacOS]         MDItemUserTags                  : Red, Blue
[MacOS]         XAttrMDItemUserTags             : Red.6, Blue.4
[MacOS]         XAttrMDItemFinderComment        : Finder comment
[ExifIFD]       DateTimeOriginal                : 2000:01:01 12:00:00

- Matti

Jan2

Quote from: wywh on December 21, 2022, 04:33:46 AMBut now I finally tested -overwrite_original for a file with a Finder comment and Finder color tags which to my surprise were preserved as well as many other XAttr/MDItem tags (macOS 13.1 Ventura).

I also assumed "overwrite_original" would lose Finder tags and comments. The only "visible" thing I could find is a non-default "Open with Application" setting that gets lost. (I have to look more into "invisible" attributes.)

NOT overwriting at all feels weirder, actually: The "_orginal" backup file keeps the Finder tags as expected, but it loses the Finder comments, these are transferred to the modified file!? ... Is this the expected behavior?

One intriguing question remains: Is "overwrite_original_in_place" beneficial from a "filesystem / backup" perspective? Consider large videos: If it stays EXACTLY the same file, with mostly the same data, is it treated as a small delta-backup? Or is it always "new file", because the location of the data changed on the volume?

wywh

Quote from: Jan2 on December 21, 2022, 05:55:57 AM"filesystem / backup" perspective

I recently tested this when I noticed that a very small change in metadata did not seem to routinely backup. The author of the Carbon Copy Cloner app informed me that it routinely uses file size and modification date to determine if a file should be updated on the destination. I routinely use -P to preserve file modification date/time so sometimes very small edits might fail to change the file size.

And as CCC author advised, after I set "Advanced Settings > Find and replace corrupted files ON", THEN the file is successfully cloned because CCC then uses MD5 checksum to compare the source and target (which is a disk-intensive and time-consuming task). I used that setting to verify my master archive and it passed with 0 MB cloned so everything was correctly cloned even before that 2.5 hour check. I have another identical HDD clone but I then decided to just erase those images that were processed with exiftool (with potentially some minor metadata changes that might not previously been cloned) and let CCC do a regular clone which took only 20 minutes for that new 75 GB and the rest of the 300 GB unchanged data. With the routine setting it takes only a few seconds to clone that if there is no change in the source vs target.

Those old 3TB Seagate HDDs are way slower than new SSDs but I still have my main cold archives on them because I have heard that SSD might not be so reliable in "cold" powerless storage.

I'll try to more thoroughly test how -overwrite_original_in_place and -overwrite_original might differ.

https://exiftool.org/forum/index.php?topic=14278.0

Jan2

Quote from: wywh on December 21, 2022, 08:47:14 AMI recently tested this when I noticed that a very small change in metadata did not seem to routinely backup.

Oh thanks, important reminder!
I was actually thinking more of Time Machine (it is supposed to do real delta backups by now, isn't it?), but of course one should also consider these other types of backups.

So far I have only done complete time shifts. In these cases this is not a problem, since the file times usually change, even if they are synchronized with the Exif data.

But e.g. when only changing the GPS data this IS of course relevant ...