ExifTool Forum

Hi,

Regex Substitution
This tool was recommended to me and it certainly looks like it's capable of doing just about anything you can imagine with metadata. This is my first time using ExifTool because I wanted to make some specific  targeted edits to IPTC data in a folder of images.
I'm using the IPTC:SpecialInstructions field to store this data.

I want to replace a particular section of this TAG data when it is found to match the pattern: "&rf=<num>", where <num> is a sequence of 1 or more digits.

If this data was in Notepad++ it would be an easy task to do the replacement using a very simple regular expression... something like: "&rf=[0-9]*")
I'm not sure of the exact syntax for regex in ExifTool, however I think the following command will pretty much do the tag modification I need to do (minus the necessary regex):

Quoteexiftool -api "Filter=s/&rf=<num>/&rf=119703/" -tagsfromfile @ -iptc:SpecialInstructions *.jpg

All I need to do is work out what the correct syntax for the regex required where "<num>" is (assuming you can just plug in some regex here).
If someone can help me out with the syntax of the regex implementation in ExifTools, it would be greatly appreciated.

IPTC truncation
Here's where I've hit a brick-wall, because like many other EXIF and photo tools (including the Nikon ViewNX software), ExifTool truncates certain TAGS when they exceed a maximum length imposed by the IPTC specification.

QuoteWarning: [Minor] IPTC:SpecialInstructions exceeds length limit (truncated)

As this data is not for use in camera or photographic equipment, I'm not concerned by the fact that it's length (3-400 chars) exceeds the specification.
I can create and maintain this data in Ifrfanview (which is the only software I've discovered to date which does not enforce this character limit and truncate), however whenever I perform any operation on these images with other software (ViewNX, ExifTool), the IPTC data is truncated, which effectively corrupts my metadata.

EDIT: I should also mention that I tried an export/edit in Notepad++/import approach:

Quoteexiftool -ICCProfileName -all -csv *.jpg > FILENAME.csv
... edit ...
exiftool -ICCProfileName -all -csv+=FILENAME.csv *.jpg

but on import, the fields were once again truncated, and therefore (at least for my purpose) corrupted.

Is there any particular reason why ExifTool truncates? It seems to me that this is a limit that is probably based on some historical camera hardware limit, and is either no longer relevant, or would be automatically truncated iif necessary by the hardware in question if the hardware couldn't handle the extra length.
I have no problem with the issuing of a warning message, but IMO there's no value in actually truncating the data during editing, as the specified limit probably only matters when the image hits some actual hardware (like a camera) at which time it would almost certainly be automatically truncated by the hardware in any case.

I don't see the logic of truncating this data when it's stored on a computer, and may never actually end up on a camera/hardware device? Fine to warn about it, but IMO leave the truncation up to the hardware.

Is there currently a way around this truncation issue in ExifTool? ... some sort of override ... or is a software change required ?

Any thoughts ?

Quote from: chuft-captain on December 06, 2017, 12:05:38 PM
I'm not sure of the exact syntax for regex in ExifTool, however I think the following command will pretty much do the tag modification I need to do (minus the necessary regex):

Quoteexiftool -api "Filter=s/&rf=<num>/&rf=119703/" -tagsfromfile @ -iptc:SpecialInstructions *.jpg

All I need to do is work out what the correct syntax for the regex required where "<num>" is (assuming you can just plug in some regex here).

It looks like you pretty much nailed it.  To replace numbers, you can either use the same [0-9]* you used in notepad++ or a simple \d* (which also works in notepad++).

If you would like to know more (insert "Starship Troopers" meme here), you can search on Perl regex.  In the past I've found regular-expressions.info (https://www.regular-expressions.info/) to be a good regex tutorial site.

QuoteExifTool truncates certain TAGS when they exceed a maximum length imposed by the IPTC specification.

Add -m to tell exiftool to ignore this limitation.

QuoteIs there any particular reason why ExifTool truncates?

I would assume it's because that's what the standard calls for.  Phil has a pretty strong stand on keeping to the standards but is flexible enough to provide workarounds.  Exiftool will happily read any length and with the -m, write it as well.

QuoteIt seems to me that this is a limit that is probably based on some historical camera hardware limit, and is either no longer relevant, or would be automatically truncated iif necessary by the hardware in question if the hardware couldn't handle the extra length.

If I recall correctly, IPTC was developed in the early 1990s for use with news organizations.  Cameras probably weren't part of process, most likely the computers in use at the time had a bigger influence.  Even now, I don't think very many cameras deal with IPTC.  Even XMP doesn't appear in many camera images as far as I know.  EXIF is pretty much the camera standard.

StarGeek,

Thanks very much for your help. (The -m is a godsend!) ... it does appear that Phil has thought of every scenario and contingency!  :D

The final result:

Quoteexiftool -overwrite_original -m -api "Filter=s/&rf=\d+/&rf=119703/" -tagsfromfile @ -iptc:SpecialInstructions *.jpg

and this works a treat!

I realized I'll probably use this more than once, so the only other thing that I might do is automate it a little ... In the very small amount of research I've done so far I came across a technique which I think involves renaming the .EXE with selected switches in ()'s. eg.

Quoteexiftool(-k).exe

... which I guess might translate to something like the following for my scenario:

Quoteexiftool(-overwrite_original -m -api "Filter=s/&rf=\d+/&rf=119703/" -tagsfromfile @ -iptc:SpecialInstructions).exe

Please excuse my ignorance, as my experience of ExifTool is only hours old, so I'm not exactly sure how this paradigm works and what the limits are, but in any case I would probably replace the "&rf=119703" with a parameter, so that I can have the flexibility of varying the replacement string on different executions.

Or alternatively... just create a custom windows shortcut, and specify the switches, parameters and paths in the usual way in the TARGET field. I guess that would also work.

Cheers!
CC

See part ii of the Running in Windows (https://exiftool.org/index.html#running) section of the ExifTool home page for limitations of arguments in the .exe file.  Basically, you can include anything but these characters:  /\?*:|"<>

But you can get around this limitation with a Windows shortcut as you mentioned.

- Phil

Thanks Phil,

This looks like a very powerful (and potentially dangerous  ;D) tool.
I think I'll start using ExifTool to generate default TAG values for my images by writing a batch file containing something like:

Quoteexiftool.exe -overwrite_original -m -By-lineTitle="mysite.com" -CopyrightNotice="(C)2017 myname" -Caption-Abstract="Default Caption Text" -Author="mysite.com" -Copyright="(C)2017 myname" -Caption="Default Caption Text" %1

... which I can execute for example with:

Quoteiptc_init *.jpg

or

Quoteiptc_init .

I might even add in a "-r" switch.  ;D

A couple of other questions come to mind:
1. I thought it might be a good idea to have the caption field default to the filename prefix (eg. foo.jpg would get "foo" as a default caption.) ... How do you do this?
2. It seems that the code above would do a brute force overwrite of existing TAGS. I don't want to overwrite certain TAGS if they already have a non-null value. eg. the Caption TAG is one field for which I would not want to brutally overwrite it if I've already customized it's value on some images. (ie. overwrite it only if empty).

Sorry for the extra questions, I'm sure the answers are somewhere in the documentation, but there's just SO MUCH documentation for a newbie!  ;)

Regards
CC

Quote from: chuft-captain on December 07, 2017, 03:34:01 AM
2. It seems that the code above would do a brute force overwrite of existing TAGS. I don't want to overwrite certain TAGS if they already have a non-null value. eg. the Caption TAG is one field for which I would not want to brutally overwrite it if I've already customized it's value on some images. (ie. overwrite it only if empty).

Take a look at the -wm option (https://exiftool.org/exiftool_pod.html#wm-MODE--writeMode).  -wm cg is probably what you want.

Thanks StarGeek,

I'll give that a try. One caveat perhaps ---it looks like it's a global mode which will apply to all TAGs.
How do I restrict it to just certain tags ... will I have to call ExifTool in 2 passes (1st pass with "-wm cg" for selected fields, and then a 2nd pass for brute force overwrites of all other fields?)

Cheers
CC

OK,
so moving the caption field mods into a another batch file and running it as a second pass through the files works, although a little ugly.

I also found an apparent solution to getting the filename prefix as a caption, when I found the special config file here (http://www.sno.phy.queensu.ca/%7Ephil/exiftool/config.html)

After installing that, I then modified my caption batch file to be this:

Quoteecho off
SET filespec=%1
if (%filespec%)==() set filespec=.
echo. filespec: %filespec%

echo on
exiftool.exe -wm cg -overwrite_original -m "-Caption-Abstract<basename" "-Caption<basename" %filespec%

which worked perfectly until ....

... I realized that before running this new BAT file, I also wanted to clear out all the old "default captions" (which happened to be set as the string "Caption Text HERE", so I ran the following to try and clear them all out (without affecting any other customized captions).

Quoteecho off
SET filespec=%1
if (%filespec%)==() set filespec=.
echo. filespec: %filespec%

echo on
exiftool.exe -overwrite_original -m -api "Filter=s/Caption Text HERE//" -tagsfromfile @ -iptc:Caption-Abstract %filespec%

This clears them out alright, but the gotcha is that for some reason, the filename prefix script from above will no longer update those cleared out caption tags (I suspect because, although the caption tags are now empty, the "-wm cg" option somehow sees them as having been modified:

Quote1 directories scanned
    0 image files updated
  353 image files unchanged

CC

The problem is that you set Caption-abstract to an empty text instead of deleting it.  Since it exists, -wm cg won't write it.

You should have done this to delete the caption:

exiftool -caption-abstract-="Caption Text Here" FILE

But now that the caption-abstract is empty, use this to delete it:

exiftool -caption-abstract-= FILE

Then your other command should work.

- Phil

Thanks Phil,

I thought that was probably the reason!

I'm still finding my way around the syntactic and semantic conventions of your tool by trial and error a bit. There's quite a bit to it!!!

So in the spirit of trial  and error, my first idea was something like:
exiftool.exe -api "Filter=s/Caption Text HERE/$filename/" -tagsfromfile @ -iptc:Caption-Abstract %filespec%
... that didn't work, so next was:
exiftool.exe -api "Filter=s/Caption Text HERE/<basename/" -tagsfromfile @ -iptc:Caption-Abstract %filespec%
... and that didn't work.  :o

It was then, that I decided to replace with empty strings ... which got me into the strife with the -wm cg

The good news is that in the fulll knowledge that I'm a newbie and working definitely by the seat of my pants, I realized that there would be stuff ups, so while I'm learning I'm working only on a duplicate folder of the original images (I may be green with ExifTool, but I'm not THAT green!  ;D).
So in this case I decided just to restore from the originals and start from scratch again (no big deal), which enabled me to use your first suggestion:
exiftool -caption-abstract-="Caption Text Here" FILE

Wisdom in hindsight, I think it will be easier in the long run to just default the caption tag to some standard string such as "Caption Text Here" rather than the "basename" idea. This will make it easier to make bulk changes to that value if necessary, and defaulting the caption to the filename is not really that useful in any case.

Thanks for all the help. Very much appreciated.
CC

Thank you very much Phil and StarGeek for the advice.

Final version:

Quoteexiftool.exe -preserve -overwrite_original -m -api "Filter=s/&rf=\d*/&rf=%num1%/;s/&lm=\d*/&lm=%num2%/" -tagsfromfile @ -iptc:SpecialInstructions %filespec%

One question more: What if I want the filter to search for a certain pattern, but not replace it?

ie. List all images which contain a certain value in a specified tag (or perhaps any tag).

eg. Extract Caption-Abstract of all images where the Caption tag has the value: AUTHOR_BYLINE

I tried:

Quoteexiftool -P -Caption-Abstract -if "$Caption eq "AUTHOR_BYLINE"" .

and

Quoteexiftool -P -Caption-Abstract -if "$Caption eq AUTHOR_BYLINE" .

In each case:

Quote1 directories scanned
  353 files failed condition
    0 image files read

CC

Quote from: chuft-captain on December 09, 2017, 09:21:25 PM

One question more: What if I want the filter to search for a certain pattern, but not replace it?

ie. List all images which contain a certain value in a specified tag (or perhaps any tag).

To search for a value in a specific tag, using your SpecialInstructions example:
exiftool -if "$IPTC:SpecialInstructions=~/8675309/" -IPTC:SpecialInstructions FileOrDir[/tt]

I don't think it's possible to list only tags that contained a certain value. 

Ninja Edit!

In the case of Caption eq AUTHOR_BYLINE, that doesn't search part of a string, the whole thing has to exactly match.  Use the regex match as above.

For a case sensitive match (removed -P option since this is a read, not write operation)
exiftool -Caption-Abstract -if "$Caption=~/AUTHOR_BYLINE/" .

To make the search case insensitive, add an i after the last slash of the regex /AUTHOR_BYLINE/i

 ;D

Oops. I realized that the reason it's not working is because I was looking in the wrong tag. It should have been:

Quoteexiftool -if "$By-Line=~/AUTHOR_BYLINE/i" .

My bad!!!  :-\

BTW.
What's the difference between "eq" and "=~" operators?


Ninja Edit #2:

I noticed that the documentation  (https://exiftool.org/exiftool_pod.html#Processing-control)uses a combination of single and double quotes:

Quoteexiftool -shutterspeed -if '$make eq "Canon"' dir

I'm assuming the use of single quotes is a linux syntax, and that Windows uses double quotes instead.

Thanks once again for the help!  ;D

Quote from: chuft-captain on December 09, 2017, 10:34:12 PM
What's the difference between "eq" and "=~" operators?

'eq' is an exact match.  'a' equals 'a'.  It doesn't equal 'ab', 'aaa', 'á' or 'A'.  If they are not exactly the same, they don't match.

I tend to think of '=~' as the regex operator but technically it's called the Binding Operator (https://perldoc.perl.org/perlop.html#Binding-Operators) and can do a few other things.  In this case, it's being used for a regex match. 

Got it!

... and confirmed:

Quoteexiftool -if "$By-Line=~/AUTHOR*/i" .

and

Quoteexiftool -if "$By-Line=~/AUTHOR/i" .

give same result.

Quoteexiftool -if "$By-Line=/AUTHOR/i" .

does not give a match.

My knowledge of Perl syntax would probably be enhanced if I was Linux based instead of Windows based.
(That's my excuse anyway!  8))

Thanks for your patience.
Cheers.

Quote from: chuft-captain on December 09, 2017, 10:34:12 PM
I'm assuming the use of single quotes is a linux syntax, and Windows instead uses double quotes instead.

Yes, reverse single and double quotes on a Windows system.  So -if '$make eq "Canon" ' would be -if "$make eq 'Canon' " on Windows.  If you need to use double quotes as part of the statement inside of double quotes, you can try either (backslash)(double quote) \" or three double quotes """.  I've had success with a limited number of these but at a certain point Windows will choke on too many of them and you have to find some other way of doing it.

Quote from: chuft-captain on December 09, 2017, 11:05:23 PM

Quoteexiftool -if "$By-Line=~/AUTHOR*/i" .

and

Quoteexiftool -if "$By-Line=~/AUTHOR/i" .

give same result.

Here you have to be careful.  The asterisk has a special meaning in Regex and isn't a wildcard as you would think of in Windows.  It says that the previous character will appear 0 or more times.  So that first listing will match "AUTHOR", but it will also match "AUTHO" (match previous character R zero times) and "AUTHORRRRRRRRR" (or more).  If you use any of these characters .^$*+?()[{\| in a regex and you want an exact match, you must escape them by placing a backslash \ in front of them.

Good point.

I do understand very well the difference between * and + in regex, as I often do quite complex "search and destroy/replace" missions using regex in NotePad+, but thanks for the reminder.  :)

eg. AUTHOR+ would match "AUTHOR" but not "AUTHO"

CC

Just a quick question about your comment regarding -P above.

Because I don't like to mess with the sort order of my images (ie. I like to sort by date last modified), I tend to leave all the "safety" switches like -P on my EXIF commands (even when they're read commands). This is because I typically will use a read command to check I'm getting the right set of images according to the search criteria (as in the example we've been discussing), before doing the write command, and then, once satisfied, I'll convert the read command to a write command, like so...
exiftool -P -if "$By-Line=/AUTHOR_BYLINE/i" -api "Filter=s/AUTHOR_BYLINE/<something else>/" *.jpg

The reason to leave that switch on the read command is simply to avoid accidentally forgetting it when I do the write operation (which would mess with my file dates) ... especially as I also use the -overwrite_original switch!
It seems to me that although obviously unnecessary for read ops, a -P has no adverse affect if you leave it on.

CC

Yes, you're correct.  It's perfectly fine to leave it there if that's how your workflow... works.

One weird thing just happened when I tried this just now:

READ:
exiftool -P -m -overwite_original -By-Line -if "$By-Line=~/AUTHOR_BYLINE/" .

Quote1 directories scanned
352 files failed condition
   1 image files read

Now I'll try to selectively update ONLY the (single) image from above which satisfies the -IF condition...
WRITE:
exiftool -P -m -overwite_original -By-Line -if "$By-Line=~/AUTHOR_BYLINE/" -api "Filter=s/AUTHOR_BYLINE/<something else>/" -tagsfromfile @ .

QuoteIgnored superfluous tag names or invalid options: -overwite_original ...
    1 directories scanned
  353 files failed condition
    0 image files read

Criteria exactly the same, but this doesn't work. (When write actions added, 0 image files read, no change to the tag value.)

Any ideas what I'm doing wrong?

If I remove the -IF condition, it appears to do the substitution correctly on the 1 image, but pointlessly updates all 353 images, instead of just the one.
exiftool -P -m -overwite_original -By-Line -api "Filter=s/AUTHOR_BYLINE/<something else>/" -tagsfromfile @ .

Quote1 directories scanned
353 image files updated

Not sure why this message occurs either....but maybe doesn't matter:

QuoteIgnored superfluous tag names or invalid options: -overwite_original ...

PS.
Just noticed I'm now a "Jr. Member?". Yesterday I'm sure I was a "Newbie".
Why the sudden promotion? ... is it based on #posts?

Quote from: chuft-captain on December 10, 2017, 12:28:58 AM
Now I'll try to selectively update ONLY the (single) image from above which satisfies the -IF condition...
WRITE:
exiftool -P -m -overwite_original -By-Line -if "$By-Line=~/AUTHOR_BYLINE/" -api "Filter=s/AUTHOR_BYLINE/<something else>/" -tagsfromfile @ .

QuoteIgnored superfluous tag names or invalid options: -overwite_original ...
    1 directories scanned
  353 files failed condition
    0 image files read

Criteria exactly the same, but this doesn't work. (When write actions added, 0 image files read, no change to the tag value.)

Because you used the -api Filter option, the if condition is no longer satisfied.  When you check to see if By-Line matches AUTHOR_BYLINE, it has already been changed to <something else>.  Filter is a very power tool and affects tags globally.  If you wish to target a tag individually, it's best if you just process that tag. For example, copy the tag to itself with the changes: "-By-Line<${By-Line;s/AUTHOR_BYLINE/<something else>/}" or if you use the filter, -TagsFromFile @ -By-Line . 

When you use filter (or -d or similar options) and need to check against its original value, use the hashtag at the end of the tag (see the -n option (https://exiftool.org/exiftool_pod.html#n---printConv)).  This will disable the conversion for that tag.  So you could use -if "$By-Line#=~/AUTHOR_BYLINE/" or my favorite way of doing things with the Filter option, -if "$By-Line# ne $By-Line".  That last one compares the original non-converted version of the tag to the converted version.  This can be useful in cases where your regex gets extremely complex or if you throw in some straight perl into the Filter.

QuoteIf I remove the -IF condition, it appears to do the substitution correctly on the 1 image, but pointlessly updates all 353 images, instead of just the one.
exiftool -P -m -overwite_original -By-Line -api "Filter=s/AUTHOR_BYLINE/<something else>/" -tagsfromfile @ .

Quote1 directories scanned
353 image files updated

Now here's where you need to be very careful.  As I said, Filter affects tags globally.  It would have updated By-Line correctly, but what if you had AUTHOR_BYLINE in another tag, say in Keywords or Description.  Additionally, since you didn't list a specific tag after -TagsFromFile, it would copy the change for all the tags that it found AUTHOR_BYLINE in.  Which is fine if that's what you want, but it's something to keep in mind

And that's not all.  When you don't list a tag after -TagsFromFile, exiftool assumes you mean to copy -All.  -All will not directly copy tag to tag.  It copies from tag to its preferred location (EXIF, IPTC, and then XMP).  So if you have a tag in one group, it might end up in a different group if the tags have the same name.  As an example, if you had data in XMP:City, after such a copy, it would end up in IPTC:City, which may not be what you want.  To copy tags to the same location, you should use -All:All, though I feel that targeting a specific tag is best if that's what you are trying to change.

Quoteis it based on #posts?

I believe so, there's details around here somewhere.  Under "Help" I think.

Quote from: StarGeek on December 10, 2017, 02:12:20 AM

Quote from: chuft-captain on December 10, 2017, 12:28:58 AM
Now I'll try to selectively update ONLY the (single) image from above which satisfies the -IF condition...
WRITE:
exiftool -P -m -overwite_original -By-Line -if "$By-Line=~/AUTHOR_BYLINE/" -api "Filter=s/AUTHOR_BYLINE/<something else>/" -tagsfromfile @ .

QuoteIgnored superfluous tag names or invalid options: -overwite_original ...
    1 directories scanned
  353 files failed condition
    0 image files read

Criteria exactly the same, but this doesn't work. (When write actions added, 0 image files read, no change to the tag value.)

Because you used the -api Filter option, the if condition is no longer satisfied.  When you check to see if By-Line matches AUTHOR_BYLINE, it has already been changed to <something else>.  Filter is a very power tool and affects tags globally.  If you wish to target a tag individually, it's best if you just process that tag. For example, copy the tag to itself with the changes: "-By-Line<${By-Line;s/AUTHOR_BYLINE/<something else>/}" or if you use the filter, -TagsFromFile @ -By-Line . 

So basically what  you're saying is that to restrict it to the single field, I can either:
1. get rid of the "-IF" and just copy the tag to itself,
(I did this:
exiftool -P -m -overwite_original "-By-Line<${By-Line;s/AUTHOR_BYLINE/something else/}"
It made the change OK, but it still "updated" all 353 images -- I guess it's copying 352 unchanged images, and 1 changed image, then deleting temp copies.)
2. get rid of the "-IF" and continue to use the filter but restrict it to the field by appending -"By-Line" after the @. (I did have "-By-Line" earlier in the command which I thought would restrict it, but you're saying this has to come after the @ ?)

One other thing is a little confusing... you said: "it has already been changed to <something else>"(by the filter), which interfered with the "-IF" condition, but in this case I would still expect it to have changed, but I checked afterward, and it had not changed. Do you mean it gets changed "in memory" by the filter, the "IF" then fails, so the change made by the filter gets rolled back because of that?

Thanks for all the additional comments. It will take me a while to absorb all that, but will be very helpful I'm sure.


Thanks a lot!!

Quote from: chuft-captain on December 10, 2017, 03:00:09 AM
So basically what  you're saying is that to restrict it to the single field, I can either:
1. get rid of the "-IF" and just copy the tag to itself,
(I did this:
exiftool -P -m -overwite_original "-By-Line<${By-Line;s/AUTHOR_BYLINE/something else/}"
It made the change OK, but it still "updated" all 353 images -- I guess it's copying 352 unchanged images, and 1 changed image, then deleting temp copies.)

No, keep the -IF.  With out it, it's re-writing all those images that aren't changed by the regex.

Quote2. get rid of the "-IF" and continue to use the filter but restrict it to the field by appending -"By-Line" after the @. (I did have "-By-Line" earlier in the command which I thought would restrict it, but you're saying this has to come after the @ ?)

Again, keep the -IF, it helps prevent re-writing of images that don't need it.  And yes, directly from the second line of -TagsFromFile (https://exiftool.org/exiftool_pod.html#tagsFromFile-SRCFILE-or-FMT):
"Tag names on the command line after this option specify the tags to be copied"

QuoteDo you mean it gets changed "in memory" by the filter, the "IF" then fails, so the change made by the filter gets rolled back because of that?

Almost.  By-Line gets changed, the -IF fails because it no longer matches, so the file doesn't get changed.

Remember, "Filter" isn't just for changing tags for copying.  You can use it to change the output when just reading tags.  For example, maybe a tag has trailing spaces but you don't realize it at first.  You could then use something like exiftool -api "filter=s/ /_/g" -Description to detect them.

Example output:
C:\>exiftool -g1 -a -s -api "filter=s/ /_/g" -Description# -Description y:\!temp\Test3.jpg
---- XMP-xmp ----
Description                     : There are trailing spaces
Description                     : There_are_trailing_spaces___________
---- XMP-dc ----
Description                     : There are trailing spaces
Description                     : There_are_trailing_spaces___________

Quote from: StarGeek on December 10, 2017, 03:46:09 AM

Quote from: chuft-captain on December 10, 2017, 03:00:09 AM
So basically what  you're saying is that to restrict it to the single field, I can either:
1. get rid of the "-IF" and just copy the tag to itself,
(I did this:
exiftool -P -m -overwite_original "-By-Line<${By-Line;s/AUTHOR_BYLINE/something else/}"
It made the change OK, but it still "updated" all 353 images -- I guess it's copying 352 unchanged images, and 1 changed image, then deleting temp copies.)

No, keep the -IF.  With out it, it's re-writing all those images that aren't changed by the regex.

OK,
Changed it back with:
exiftool -P -m -overwite_original -if "$By-Line=~/something else/" "-By-Line<${By-Line;s/something else/AUTHOR_BYLINE/}" .
and this time, it only updated the 1 file:

Quote1 directories scanned
  352 files failed condition
    1 image files updated

Thanks for all your help. Don't think I'd get far without it!!  :D

CC

Ninja Edit:
I've found out why the message:

QuoteIgnored superfluous tag name or invalid option: -overwite_original

is happening. (I couldn't work out why this command was insisting on creating .jpg_original files.)
It seems that "overwite" should be spelt "overwrite".  ;D :P :-\
I wonder if a future version of EXIFTOOL might allow this to be abbreviated to perhaps "-o"  (It appears that "-o" has not been used yet) ... and I guess "-oip" for -overwrite_original_in_place.

-o is used to specify an output file name.  But I would prefer not to have a short form for a potentially dangerous option like -overwrite_original.

- Phil

Quote from: Phil Harvey on December 10, 2017, 08:02:14 AM
-o is used to specify an output file name.  But I would prefer not to have a short form for a potentially dangerous option like -overwrite_original.

Yep,

I 99% expected that response, and actually I totally agree.
I think I was just getting a bit sick of typing it (and mis-typing  :-\ it), so I thought I would throw that suggestion out there.
I'll get over it, and actually, I think your reticence is well justified.

:)

CC

PS. That reddit comment (https://www.reddit.com/r/linuxquestions/comments/2yiked/i_want_to_batch_extract_the_exif_datetime_from_10/): "... it is total fucking gibberish to me." is totally fucking priceless!  ;D

Quote from: chuft-captain on December 10, 2017, 12:42:19 PM
I think I was just getting a bit sick of typing it (and mis-typing  :-\ it)

There are two things I use to deal with this.  One is a text expansion program (see this old Lifehacker article (https://lifehacker.com/5611210/how-to-use-text-expansion-to-save-yourself-hours-of-typing-every-day)).  Even something like AutoHotKey or Autoit (if on Windows) can be used to reduce errors.  Another is a clipboard history program.  Anything recent I've copied into the clipboard, I can re-paste quickly.  Both can be especially useful when dealing with long, complex commands.

Quote from: chuft-captain on December 10, 2017, 12:42:19 PM
PS. That reddit comment (https://www.reddit.com/r/linuxquestions/comments/2yiked/i_want_to_batch_extract_the_exif_datetime_from_10/): "... it is total fucking gibberish to me." is totally fucking priceless!  ;D

Yeah.  I really liked that comment too. :)

- Phil