Adding conditions to an Exiftool script

[pacman]

I'm working on an Automator drag & drop script (Mac) where the exiftool command (issued on the UNIX command-line) looks like this:

$ touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal FILENAME.JPG` FILENAME.JPG

It works fine (looking up the DateTimeOriginal tag's date/time and overwriting the file's OSX file creation and modification dates because the latter gets messed up by Adobe Lightroom whenever keywords or other metadata is added and saved to the file).
In the Automator shell script section I've entered it as follows:

for f in "$@"
do
touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal "$f"` "$f"
done

But I also want to add a few conditions before letting it do its thing though I don't know how to actually go ahead with it...

1) is it a suitable file type (JPG, PNG, PSD or TIF)?

    if YES; move to step 2
    if NO; skip the file and move on to the next file (repeat step 1 with the next file)

I've found that exiftool can be used to determine the filetype as follows:

$ exiftool -s -s -s -tag "-Filetype" TESTFILE.PNG
PNG

2) is a "DateTimeOriginal" EXIF date tag found within the file?

    if YES; move on to step 3
    if NO; skip the file and move on to the next one (go to step 1 with the next file)

I'm a little stuck here as I believe a yes/no response is needed.

3) Is the date and time in "DateTimeOriginal" identical to that of the file's creation date?

    if YES; skip this file and move on to the next one
    if NO; proceed to touch the file (as in the command-line above) -go to step 1 with the next file

This determines the DateTimeOriginal tag's time/date, so maybe this could somehow be used as part of it?

$ exiftool -s -s -s -d "%Y%m%d%H%M.%S" -tag -DateTimeOriginal TESTFILE.PNG
201605022025.01

and the getfileinfo command can get a file's creation date as follows according to a forum thread:

$ getfileinfo -d TESTFILE.PNG
05/02/2016 20:25:01

The same forum thread also mentions using the "stat" command with one example:

$ stat -f%SB -t %Y%m%d%H%M TESTFILE.PNG
201605022025

.. or the mdls command:

$ mdls -name kMDItemFSCreationDate TESTFILE.PNG
kMDItemFSCreationDate = 2016-05-02 18:25:01 +0000

Can these conditions be added to the exiftool command or is it something which I have to do as part of the Automator script prior to issuing the exiftool command?

[Phil Harvey]

Ideally these conditions should be tested before ExifTool is run, and this could be done by running exiftool again:

Code Select Expand

#!/bin/sh
for f in "$@"
do
exiftool -q -if '$fileType =~ /^(JPEG|PNG|PSD|TIFF)$$/ and $dateTimeOriginal and substr($dateTimeOriginal,0,19) ne substr($MDItemFSCreationDate,0,19)' -aaa "$f"
if [ $? == 0 ]; then
touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal "$f"` "$f"
fi
done

The double "$$" in the first command is necessary to pass the "$" symbol through the exiftool parsing to get a single "$" in the regular expression (otherwise exiftool converts the "$/" to a newline).

- Phil

[pacman]

Thanks, but neither this or my original script won't work as expected and gives the same strange results (the files' creation dates are updated to the current date/time while the modification date is set to 28th March 2028).

I had problems getting the original exiftool command to work (in the OSX terminal) until someone here kindly pointed out that I should change the ' quote character to `. After doing that it worked.
So I'm wondering if Automator expects yet another syntax to work in the same way as on the UNIX command line.

Having that in mind I did a quick comparison test between issuing it in the OSX UNIX Terminal first as follows:

$ touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal FILENAME.JPG` FILENAME.JPG

... which worked as expected. Alas I don't yet know how to issue that command for all files in the folder in one go from the command line. Apparently, just replacing the filename with a dot like this doesn't cut it:

$ touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal .` .

... and interestingly I got the same erronous dating result (file creation date being updated to "now" and modification date becoming 28th March 2028) as with the Automator script. In addition several zero byte length files with dates in their filenames were created.

anyway, comparing with the first command (which worked in the Terminal) I ran the Automator script with these lines which didn't work, giving me those strange results as explained earlier.

Code Select Expand

export PATH="$PATH:/usr/local/bin"
for f in "$@"
do
touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal "$f"` "$f"
done

... and changing the `character to ' didn't work but gave me an error message about the syntax:

Run shell script failed - 1 error
touch: out of range or illegal time specification: [[CC]YY]MMDDhhmm[.SS] (1)

Changing the quote character further to " didn't do any more good but returned the same error message.

[Hayo Baan]

The common cause of problems with Automator is that it can't find exiftool. Though you seem to have made sure the path is set to include where Exiftool can be found. Hmm...
Can you put echo in front of the touch command and put 2>&1 >> /Users/you/Automator.out at the end of the same line(replace you with your shell user name)? That should give you a file in your home directory called Automator.out have a look at that after you run your Automator script and it post it here. It should give us a clue of what's going on.

Oh, and do the same thing, but now for a line with just the exiftool command (I.e., the part between the back quotes)

[pacman]

The common cause of problems with Automator is that it can't find exiftool. Though you seem to have made sure the path is set to include where Exiftool can be found. Hmm...

Yes, I've found this rather strange when the terminal can find it.

Can you put echo in front of the touch command and put 2>&1 >> /Users/you/Automator.out at the end of the same line(replace you with your shell user name)? That should give you a file in your home directory called Automator.out have a look at that after you run your Automator script and it post it here. It should give us a clue of what's going on.

Sure, here it is, tested with just 4 files (to make it shorter) and with the pathname anonymized:

touch -t ======== /Users/MYNAME/Desktop/TEST/TESTIMAGES/file_jpg_DATE.JPG 201502221457.46 ======== /Users/MYNAME/Desktop/TEST/TESTIMAGES/screensh_ff_jpg_NoDATE.jpg 201605022022.27 ======== /Users/MYNAME/Desktop/TEST/TESTIMAGES/screensh_ff_ping_NoDATE.png 201605022022.12 ======== /Users/MYNAME/Desktop/TEST/TESTIMAGES/screensh_osx_1_NoDATE.png 201605022021.08 1 directories scanned 4 image files read /Users/MYNAME/Desktop/TEST/TESTIMAGES

The strange thing is that adding this to the Automator script actually changed the result as well! Now the files have both the creation and modification dates changed to "now".

Oh, and do the same thing, but now for a line with just the exiftool command (I.e., the part between the back quotes)

I'm not sure if I've understood you correctly, but is this it (again with the user path anonymized here, but not in the real script of course)?

Code Select Expand

export PATH="$PATH:/usr/local/bin"
for f in "$@"
do
echo exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal "$f" 2>&1 >> /Users/MYNAME/Automator.out_2.txt
done

If so, here's the result:

exiftool -s -s -s -d %Y%m%d%H%M.%S -DateTimeOriginal /Users/MYNAME/Desktop/TEST/TESTIMAGES

[Hayo Baan]

Right, it's clear what is going on. You are running your Automator script on a directory but your script doesn't work on directories, only on individual files...

To make your script work on directories as well, would require some more coding. It can certainly be done but is a bit more complex...

[Phil Harvey]

Thanks, but neither this or my original script won't work as expected and gives the same strange results

That is odd.  I tested it here before I posted the script and it worked fine for the one file I tested (with the interesting caveat that it seemed as if I had to wait a few seconds for the "touch" changes to take effect, because if I ran the script twice quickly it would change the date both times, but if I did it slowly it wouldn't change the date the second time).

If I get a chance I'll do a bit more testing.

- Phil

[pacman]

Right, it's clear what is going on. You are running your Automator script on a directory but your script doesn't work on directories, only on individual files...

To make your script work on directories as well, would require some more coding. It can certainly be done but is a bit more complex...

Ah, I see.
But instead of changing the Exiftool command, could the problem actually be within my Automator file as I've used the "Get specified Finder items" action first, to pass on a pre-defined folder (with my test images inside) to the actual script ("Run shell script" action)?
Obviously the pre-defined folder is just there for now, while I'm working on the script. When all works well the idea is to have anything dragged and dropped to it handled by the script (it should be able to handle either image files or a folder with image files inside).
Should I use a different Automator action before the "Run shell script" action?

See screenshot attachement for how my Automator file looks like (there doesn't seem to be an option here for actually showing uploaded images -only images linked on the web), but basically it's built like this:

- "Get specified Finder items" (path to folder with test images inside -for testing purposes)
- "Run shell script" (the Exiftool command line which Phil posted here, including "Export PATH..." for it to locate Exiftool)
- "Run Applescript" (A display alert window explaining that the files have been processed)

[Hayo Baan]

Instead of the folder, just use a couple of image files in the get specified finder items. That should solve the issue.

[pacman]

Yes, it worked (more or less -see below)!
When the script has been tested to perfection, which Automator action should I replace "Get specified Finder items" with so that it'll accept files and folders dragged to it?

A few issues:

- one file had a slightly different time (both hours and minutes) than the original file (a camera JPG with already existing metadata including the date). Upon further inspection the script did the correct thing to use the date tag but the original source file obviously had a different file creation time (around 3 hours later than the metadata-date) though I don't know why... for now I think I'll just see it as a mistake in the file.

- the other files all received back their correct dates, but.... only if first having metadata saved to them in Lightroom. If I skipped running them through Lightroom first they got today's date/time after having been through the script which isn't correct. In my folder full of different test files it didn't affect JPG or PNG files, but MOV, AVI, DNG, BMP, Olympus RAW (ORF), Canon RAW (CR2), Adobe Digital Negative (DNG) and TIFF. I know that at least the TIFF and DNG had date tags, so this puzzles me.

- this is just a nitpicking issue, but the way "touch" works it changes both creation and modification dates to the metadata date. But perhaps the modification date should be changed to "now" instead. After all, the file has been processed, and I might want to find out which files have been "fixed" and which ones were skipped. Some quick testing shows that I could just run a "touch command again (but just "touch", not "touch -t") on those files that had their creation dates changed.

- is it possible to output the result (number of files/folders processed and skipped by Exiftool) in an OSX alert window?

[Hayo Baan]

Yes, it worked (more or less -see below)!
When the script has been tested to perfection, which Automator action should I replace "Get specified Finder items" with so that it'll accept files and folders dragged to it?

That's easy: none. That already is the default for (application) workflows.

- one file had a slightly different time (both hours and minutes) than the original file (a camera JPG with already existing metadata including the date). Upon further inspection the script did the correct thing to use the date tag but the original source file obviously had a different file creation time (around 3 hours later than the metadata-date) though I don't know why... for now I think I'll just see it as a mistake in the file.

Without knowledge of the files and their history, it is impossible to tell the reason.

- the other files all received back their correct dates, but.... only if first having metadata saved to them in Lightroom. If I skipped running them through Lightroom first they got today's date/time after having been through the script which isn't correct. In my folder full of different test files it didn't affect JPG or PNG files, but MOV, AVI, DNG, BMP, Olympus RAW (ORF), Canon RAW (CR2), Adobe Digital Negative (DNG) and TIFF. I know that at least the TIFF and DNG had date tags, so this puzzles me.

I don't quite follow. Your script only touches those files whose create date it different from the datetimeoriginal. It could very well be that editing the file in Lightroom caused a change in the file create date (if it writes a new file, the create date is set to when it was created).

- this is just a nitpicking issue, but the way "touch" works it changes both creation and modification dates to the metadata date. But perhaps the modification date should be changed to "now" instead. After all, the file has been processed, and I might want to find out which files have been "fixed" and which ones were skipped. Some quick testing shows that I could just run a "touch command again (but just "touch", not "touch -t") on those files that had their creation dates changed.

WARNING: Touch does NOT change the creation date of files, ONLY the modification date.
One exception: if the modification date is set to before the original creation date, the new create date will be set to that too.

To be honest, why would you bother with the file creation date at all? It is an unreliable source of information over which you have almost no control.

- is it possible to output the result (number of files/folders processed and skipped by Exiftool) in an OSX alert window?

No, sadly enough automator does not have a way to do this
The simplest option is to write the output to a file and look at that (you can e.g., open it from the script automatically too for instance by adding the line open -e OUTPUTFILE to it.).

Hope this helps,
Hayo

[pacman]

Yes, it worked (more or less -see below)!
When the script has been tested to perfection, which Automator action should I replace "Get specified Finder items" with so that it'll accept files and folders dragged to it?

That's easy: none. That already is the default for (application) workflows.

I'm a bit puzzled by this because "Get specified Finder items" has add and remove buttons for adding/removing files or folders, but instead of pre-defining a specific folder I want to be able to drag & drop any file or folder to it. So I tried it without that action and it worked!
Then I put "Get specified Finder items" at the top, but leaving it blank (i.e. not selecting any file or folder) and it still worked! So would it be most correct to leave it there (without defining any file/folder)?

An oddity: when dragging 20 test images/video files to the OSX script icon in the dock I would get the "File creation dates corrected" alert window, then after pressing the OK button it would continue and pop up that same alert window again. Perhaps this is due to it encountering errors and not being able to fix the dates of all files....
I took a closer look at this and it appears the first alert window pops up when all except the MOV, CR2, DNG, BMP, the Epson-scanned TIFF but also two JPG files. After pressing the alert window's [OK] button I see the rest of the files getting their dates fixed except for the two BMP files and that Epson-scanned TIFF. After that second popup I wouldn't see the alert window again.
NOTE: I tried all this after adding the additional file-types explained below (shown in bold red in the script code).

but the original source file obviously had a different file creation time (around 3 hours later than the metadata-date) though I don't know why... for now I think I'll just see it as a mistake in the file.

Without knowledge of the files and their history, it is impossible to tell the reason.

Yes, that makes sense of course.
I'm not particularly worried about that file because it seems to be an isolated case. I've collected numerous files in different formats for testing and they should all have a "clean" history (i.e. directly from a scanner, camera etc), but one might have slipped through having been messed around with.

- the other files all received back their correct dates, but.... only if first having metadata saved to them in Lightroom. If I skipped running them through Lightroom first they got today's date/time after having been through the script which isn't correct. In my folder full of different test files it didn't affect JPG or PNG files, but MOV, AVI, DNG, BMP, Olympus RAW (ORF), Canon RAW (CR2), Adobe Digital Negative (DNG) and TIFF. I know that at least the TIFF and DNG had date tags, so this puzzles me.

I don't quite follow. Your script only touches those files whose create date it different from the datetimeoriginal. It could very well be that editing the file in Lightroom caused a change in the file create date (if it writes a new file, the create date is set to when it was created).

It puzzled me too, so I did some further testing and made some new discoveries...

1) apparently the skipping of fixing the dates of a few files was mostly due to the filtering, so I added those file types to the script (additions show below in bold red) and with a few exceptions the mentioned skipped files were processed this time:

export PATH="$PATH:/usr/local/bin"
#!/bin/sh
for f in "$@"
do
exiftool -q -if '$fileType =~ /^(JPEG|PNG|PSD|TIFF|MOV|AVI|CR2|DNG|ORF|BMP)$$/ and $dateTimeOriginal and substr($dateTimeOriginal,0,19) ne substr($MDItemFSCreationDate,0,19)' -aaa "$f"
if [ $? == 0 ]; then
touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal "$f"` "$f"
fi
done


I suggested the file-filtering (is it a suitable file-type?) because I didn't want say text files, folders or whatever to be touched, but perhaps I'm mistaken and it's not needed because Exiftool understands which ones are image/video files.... I believe Phil mentioned that a while back. Considering that the list of supported files by Exiftool is quite long and that I'd need to add new formats later if/when it'll support additional formats, could either this condition be skipped (and instead rely on Exiftool's own ability to detect and skip non-supported files on its own), or use an "all Exiftool-supported files" type shortcut if there's one?


2) one of the TIFF files still wouldn't get its creation date fixed and I found the problem to be a lacking "DateTimeOriginal" tag which is strange considering I used the following command to read the existing file creation date and write multiple metadata date-tags:

Code Select Expand

exiftool -r "-AllDates<MDItemContentCreationDate" "-XMP-Exif:DateTimeDigitized<MDItemContentCreationDate" -P -if 'not $exif:AllDates' -overwrite_original_in_place .

Actually I found both the original file, and a copy of the same file (after running ith through the above command) to be lacking "DateTimeOriginal" though they both contained CreateDate, ModifyDate and MetadataDate. Shouldn't they also contain DateTimeDigitized after being run through the above command?
This is a scanned image taken with an Epson scanner which obviously does create metadata date-tags when scanning.

3) I assume BMP files just don't support metadata date-tags as they're not added using the above command.

- this is just a nitpicking issue, but the way "touch" works it changes both creation and modification dates to the metadata date. But perhaps the modification date should be changed to "now" instead. After all, the file has been processed, and I might want to find out which files have been "fixed" and which ones were skipped. Some quick testing shows that I could just run a "touch command again (but just "touch", not "touch -t") on those files that had their creation dates changed.

WARNING: Touch does NOT change the creation date of files, ONLY the modification date.
One exception: if the modification date is set to before the original creation date, the new create date will be set to that too.

Yes, I'm aware of this, which is why I figured that in this case I could use "touch" (already installed as part of OSX) instead of "setfile" (must be downloaded and installed separately).

To be honest, why would you bother with the file creation date at all? It is an unreliable source of information over which you have almost no control.

I know there's a lot of disagreement on the subject, but I prefer to rely on both the metadata and the file creation date -the latter as a secondary, but more convenient way of finding out about files in the Finder etc.

- is it possible to output the result (number of files/folders processed and skipped by Exiftool) in an OSX alert window?

No, sadly enough automator does not have a way to do this
The simplest option is to write the output to a file and look at that (you can e.g., open it from the script automatically too for instance by adding the line open -e OUTPUTFILE to it.).

Hmm.... that would be nice for a logfile, but if that's possible, could a terminal window be opened and the output passed on to it (as when running Exiftool directly from a Terminal window)?

[Phil Harvey]

use an "all Exiftool-supported files" type shortcut if there's one?

I thought this would be obvious, but ExifTool will only be able to extract DateTimeOriginal from supported files, so the condition is not useful if you want to process all supported file types.  The only information it can extract for non-supported files are system tags.

- Phil

[pacman]

Yes, in hindsight I see that it's obvious. I was more thinking of filtering for the "touch" command, but obviously the script won't touch anything unless Exiftool has done its thing.

Syntax-wise, if I want to remove the file-type filtering, would removing $fileType =~ /^(JPEG|PNG|PSD|TIFF)$$/ and be the right way to do it? Here's the whole script with file-filtering removed and added && touch "$f" in order to update the file modification dates for the files which have just had their dates restored:

Code Select Expand

#!/bin/sh
for f in "$@"
do
exiftool -q -if '$dateTimeOriginal and substr($dateTimeOriginal,0,19) ne substr($MDItemFSCreationDate,0,19)' -aaa "$f"
if [ $? == 0 ]; then
touch -t `exiftool -s -s -s -d "%Y%m%d%H%M.%S" -DateTimeOriginal "$f"` "$f" && touch "$f"
fi
done

[Phil Harvey]

Your new -if condition is fine, but I don't understand the && touch "$f" -- doesn't this completely undo the new time you set with the touch -t?

- Phil