An Android GPS extraction oddity

[Serenity]

I have a simple GPS coordinate extraction script that I've been using with my iPhone for quite some time. That looks like this:
----------------------
echo off | clip
for /f "delims=" %%A in ('C:\ExifTool\exiftool.exe -gpsposition -c %%+.8f -s3 %*') do set "var=%%A"
if "%var%" == "" goto empty
echo "%var%" | clip
exit

:empty
rem
rem
rem
rem     !! There are no GPS coordinates in this picture/video !!
rem     !!         Hit ANY key to close this window.          !!
rem
rem
rem
pause
----------------------

It works great. Here (for comparison purposes) is what gets coughed up with a full data extraction of one of my iPhone pictures:
GPS Position                    : 52 deg 47' 26.45" S, 71 deg 15' 36.25" W

So, for someone else, who has an Android phone, I tested one of those pics, and everything goes sideways.  Specifically, the script was generating nothing. On a whim, I added a 'pause' command, immediately after the 'for' statement above, i.e. where the coordinates are being extracted, and when tossing the Android picture to the script, it DID NOT pause, so clearly the "for" line is abending (i.e. crashing), and terminating the script.

When I do a full Exif dump of the Android jpg, this is the section where there IS what seems to be a legitimate GPS coordinate:
Focal Length                    : 4.4 mm (35 mm equivalent: 27.0 mm)
GPS Position                    : 47 deg 42' 44.13" N, 117 deg 28' 3.93" W
Hyperfocal Distance             : 2.28 m

Maybe I'm losing my mind, but it looks, structurally, identical to my iPhone coordinates, so I'm confused as to why exiftool appears to have "crashed" when trying to perform that GPS extraction.  On the possibility that some of the other GPS content (or non-GPS content?) is causing the crash, I'm attaching the entirety of the Exif extraction of this (Android) picture.  There IS other GPS content in the picture (as there always is in the iPhone photos as well), but I am ass-u-ming that the -gpsposition Exif option is targeting the line above.  And, just to be clear, the crash happens on any of the Android pics that I feed it, and not just this one.

Sorry to bother you with this.  Your thoughts/input is appreciated.  THX!

[Phil Harvey]

This is a .bat script?  My wild guess is that you're hitting some sort of buffer-length limitation in batch processing.  (After all, we're dealing with a command interpreter that has a command length limitation of 8k characters.)

- Phil

[Serenity]

At your leisure to respond.  I'm just trying to understand why this is going 'sideways'.  (And it is a *.cmd script)

I was simply trying to have my script "eat" Android stuff, like I was doing for my Apple stuff.  If I feed the script an Apple image (jpeg or mov), those all generate a lot more data, and they all work fine, either "pausing" to tell me there is no GPS data, or, I see the command prompt dialog pop up for a second or so (displaying some of the script content), and then disappear, and there is a GPS string in the clipboard.

This is the full data (with the -k %* script) from an android photo that I feed that same script "GPS script".  This content is actually considerably smaller that anything in my iPhone content, but when the script above "eats it", the command prompt opens, and closes almost instantly, regardless of whether I feed it an android photo with GPS content being present, or without it.  And if none is present, it definitely doesn't pause with that "not found" messaging.  Again, I do think it is abending, but I don't think it is a buffer size issue, as there's just not much data there.  I just keep thinking that there must be something in the content that is causing the issue, but I'm clueless as to what it is.

Again... I'd "like it" if I could make this work with those Android pics/vids, but the world won't end, if I can't.  It was something I was simply trying to do for someone else.  I just wanted to give you a bit more data to look at, in case something might jump out as a cause.  Sorry for the hassle.

Code Select Expand


ExifTool Version Number         : 12.57
File Name                       : (Coleen)imagejpeg_0.JPG
Directory                       : D:/BBS
File Size                       : 237 kB
Zone Identifier                 : Exists
File Modification Date/Time     : 2023:02:16 17:36:09-07:00
File Access Date/Time           : 2023:03:11 12:23:09-07:00
File Creation Date/Time         : 2023:02:16 17:36:08-07:00
File Permissions                : -rw-rw-rw-
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Exif Byte Order                 : Big-endian (Motorola, MM)
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Y Cb Cr Positioning             : Centered
Exif Version                    : 0221
Components Configuration        : Y, Cb, Cr, -
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 1024
Exif Image Height               : 771
Scene Capture Type              : Standard
Image Width                     : 1024
Image Height                    : 771
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Image Size                      : 1024x771
Megapixels                      : 0.790



[Serenity]

I have figured out the cause of this, but now realize that I'm going to have to take the simple script, and turn it into something far more complex, simply to augment the file name being fed to the script.  But, anyone else who might be using the drag/drop approach on these scripts needs to be aware of the problem.  Also note that on the most basic script, e.g. one that only has this single line, the problem below does not occur:
C:\ExifTool\exiftool.exe -k %*

It is only in more complex structures (again, my script in the beginning), where this all goes sideways in Windows.

I realized that on the few Android phone pic/vids that I received (from someone else, to test with), that I had put the person's name at the front of the filename, bound by parenthesis.  On a whim, I removed the parens, and the crashing problem went away.  The thing is, I have iPhone vid/pics whose names I modified with descriptive content, some with parens, and those were NOT causing the script to crash.  The iPhone and Android pics were in different directories, so I thought maybe it's a combination of the directory name, and the parens, that causes the Android files to crash the script, so I moved iPhone pics with parens, into the same directory with the Android pics (with parens), and when I drag/drop the iPhone pics on the script, the script works, and when I drag the Android pics, it (of course) still crashes.  But, again, bottom line, if there are no parens in the Android file name, then the "gps extraction" script shown above, works just fine.

So then I just got lucky.  I realized that the many (many) hundreds of iPhone pictures, whose file names I had modified to describe their content, did have quite a number of parenthetical comments, BUT ALL OF THOSE had at least one space, AT SOME SPOT around the parens.  To be more specific, on the failing Android photos, where there were parens, there were no spaces before, or after the parens.  I found that if I inserted ONLY ONE space, ANYWHERE in that parenthetical expression (i.e. before either of the parens, or after one of them), that one additional space eliminated the crash, when I dropped the image on my desktop shortcut.  If there is any parenthetical pair in a pic/vid name, and at least one of the parens isn't proceeded by, or followed by a space, then the resulting "file name" being passed to the script, in a drag/drop operation, will cause that script to abend.  (And to be clear, if the file name has two parenthetical pairs, with no spaces, and you ONLY add a space to one of those pairs, the script still functions.  (That part makes even LESS sense to me, but that's what I see in my testing.)

So, one simply fix, if you modify a picture name, is to never use parens, OR, to absolutely add a space around one of them.  The better (but more painful) solution is to wrote a new bit of code that precedes the main exiftool scripting, that escapes the parens, or does whatever is needed in the Windows scripting process to "make is happy", before feeding the file name to the exiftool portion of the scripting.

But either way, beware of parens in pic/vid renaming, as they are obviously nasty.

[Phil Harvey]

I didn't read your entire post, so I don't know if this is on point, but I seem to remember something about using "%*" (with quotes) instead of %* on the command line to get the shell to properly quote the expanded file names.

- Phil

[Serenity]

Hi.  Thx.

I did add double-quotes in some scripts, but there are some activities where exiftool wraps the file name in double-quotes automatically, so I obviously had to leave those as a naked %*

Anyway, it's closer now to where I wanted the scripts to be.  I know that I still have some places where parens in the file name cause problems, but the likelihood of those in the file names is limited enough that I'll just worry about them later.

Thanks again for listening, and for the input.  It was much appreciated.  Have a good week...

[StarGeek]

but I seem to remember something about using "%*" (with quotes) instead of %*

I'm pretty sure that any files passed with %* are properly quoted, at least when drag/dropping files onto a bat file.  You can't use "%*" because that would put quotes around the entire thing and would break in the case of multiple files, e.g. ""file with space.jpg" file2.jpg" .

Digging through some of my bat files (I really hate Windows batch commands), I think the best procedure is to use something like "%~a" (where a is the variable).  The tilde strips away any quotes around a variable and then they are added back in.  This is the site I have bookmarked for dealing with modifying Windows variables.

[Phil Harvey]

You can't use "%*" because that would put quotes around the entire thing and would break in the case of multiple files

Did you try it to be sure?  My recollection from my DOS days (~40 years ago) was that some magic was done here.  But of course it would be a minor miracle if my memory was correct.

- Phil

[StarGeek]

I was going off of some previous batch files where I went slightly mad trying to figure all this stuff out, but let me double check to see what happens.

Quicky test script

Code Select Expand

@echo on
echo Without quotes
echo %*
echo With quotes
echo "%*"
pause
Drag and drop 3 files, one with spaces in the name with these results

Code Select Expand

Y:\!temp\dddd>echo Without quotes
Without quotes

Y:\!temp\dddd>echo "Y:\!temp\dddd\Test3 - Copy.jpg" Y:\!temp\dddd\Test3.jpg Y:\!temp\dddd\Test4.jpg
"Y:\!temp\dddd\Test3 - Copy.jpg" Y:\!temp\dddd\Test3.jpg Y:\!temp\dddd\Test4.jpg

Y:\!temp\dddd>echo With quotes
With quotes

Y:\!temp\dddd>echo ""Y:\!temp\dddd\Test3 - Copy.jpg" Y:\!temp\dddd\Test3.jpg Y:\!temp\dddd\Test4.jpg"
""Y:\!temp\dddd\Test3 - Copy.jpg" Y:\!temp\dddd\Test3.jpg Y:\!temp\dddd\Test4.jpg"

Y:\!temp\dddd>pause
Press any key to continue . . .

[Phil Harvey]

Instead of echo, try ls %* and ls "%*" in a directory with files that have spaces in the names.  The echo outputs should be the same weather or not the spaces are between arguments or inside arguments.

- Phil

[StarGeek]

ls isn't a Windows command.

Code Select Expand

C:\>ls
'ls' is not recognized as an internal or external command,
operable program or batch file.
Ah, Powershell has ls as an alias for Get-ChildItem.  Which is really annoying because  it doesn't translate any options that ls has into Get-ChildItem options.  PS also does this with wget and curl, making them impossible to use in PS unless you figure out how to disable the alias.

I do have a copy of ls that is installed with msys2, which has ported linux utilities, and another port is included with Github Desktop.  But similar results.

[Phil Harvey]

Darnit.  I should have said "dir", not "ls".  (I forgot to think in DOS.)

But your tests show that quoting %* doesn't do what I thought.

- Phil