Exiv2

I have built Exiv2 v0.26 with VS 2017 and 2015 Community Editions. I believe the released .tar.gz will build. You can download pre-built libraries (with headers) to skip building the code from the buildserver: http://exiv2.dyndns.org:8080/userContent/builds/Latest/

I'm on vacation at the moment and don't have every version of MSVC on my laptop. I'll install VS 2017 Community Edition, check it out and give you an update.

You can't build master on GitHub.com Exiv2/exiv2 at the moment as we're making major changes to the build system concerning XMPsdk.

Thanks for your quick reply! I'm linking Exiv2.lib directly from the Release link you provided but I'm still getting the same errors. I'm trying to make minor updates (less than a dozen lines of code) to a personal project that is probably 6 or 8 years old when I think MSVC 9 was the current version. I think the Exiv2.lib had a date around March 1, 2010 at that time. I don't remember seeing an "External Dependencies" item in my updated VS2017 project containing a list of over 400 *.h *.hpp references back then as I see now, but rwllock.hpp is in that list and perhaps this is the source of my issue. It's been quite some time since I've used any version of Visual Studio so it could very well be a configuration issue on my side.

Good News. I have successfully built exiv2 v0.26 Release/32 "out of the box". Which build are you using 64/32? Debug/Release? DLL/static?

The code in include/exiv2/rwlock.hpp was contributed by a user about a year ago. It's classes to provide thread-safety locks for use with XMP. It is version sensitive as it sits over CRITICAL_SECTION and other M/S stuff that's changed over the years. Looking in our vcproj applications (such as exiv2, or exifprint), I don't see any references to rwlock.hpp, so I'm not sure what "External Dependencies" you've mentioned. Is this something in the MSVC conversion report?

Remarkably, in April, somebody reported a bug in rwlock.hpp when running on XP! I wondered at the time, if we shouldn't rip out most of the code in that file and only use the class based on CRITICAL_SECTION. So try throwing away everything except the code in lines 95-147.

You could try using exiv2 v0.25 as it predates the arrival of rwlock.hpp. Of course you'll miss out on all the goodness added in v0.26 while we figure out this 2017/v0.26 issue.

Where are you located? Perhaps we can talk/screen-share on Skype and get this fixed.

I'm on vacation in Scotland and about to go for a walk to where this photo was taken of the beautiful town of Largs in which I was born. The weather's perfect here today.

Quick responses (especially when you’re on vacation!) demonstrates commitment to the Exiv2 project and I thank you for that. When I think about it, my use of Exiv2 is quite trivial and it may give you a chuckle or two, but the backstory goes something like this:

I started shooting digital in early 2004, but it became apparent that names like IMG_1234.JPG or DSC_5678.JPG were of little use to me. I could see the “what” of a photo with its thumbnail but it told me nothing of the “when” unless I was in details mode of Windows Explorer. Was that taken in 2008 or 2009? Was it June or July? I organize my family photos in such a way that they are stored in a single “year” folder—I didn’t want the possibility of several dozen event folders inside that folder when some events might contain just a single photo. My way may make searching a tad more time consuming but I felt I could pick a year and quickly scroll to the time period in question. So, I took it upon myself to write a small MFC dialog application to rename those files in YYYY-MM-DD HH24.MM.SS.JPG format. I coded it so I could list several folders separated by semicolons and recurse through those folders. The result was I could rename hundreds of files in a matter of seconds. During my research of libraries that I could use, I came across Exiv2 and it was attractive because it was free and seemed to offer the most robust and extensive API if I ever wanted to write an Exif viewer/editor app that would do exactly as I wanted it to do without relying on commercial apps or libraries. That was something I never got around to doing. I had no intention of modifying the library in any way because it did what I needed it to do.

It was rare that I shot several photos where renaming one would cause an error because the file already existed. In those cases, I would edit by hand the handful of files in a hex editor, adjusting the seconds (and minutes, if necessary) and run that batch through my app again. In a later version of the app, I took advantage of Exiv2’s write capabilities to add or subtract an amount of hours to adjust the DateTime* values of the files if I forgot to adjust my camera’s date to account for daylight savings or different time zones. Some of the source files of my DatePics app are dated early December of 2005 and the last exiv2.lib I was using is dated March 1, 2010. All was good and the last changes I made to the app were in May of 2010. It is in no way thread dependent. All the time I was using the static release version of the library.

My daughter isn’t as picky about which photos she keeps and she can shoot several frames per second. So, in her quest to help her organize the thousands of photos she has, I installed VS2017 Community since I didn’t have any version of VS installed after rebuilding my system several months ago. There were many more files having renaming errors that made hand-editing more time consuming and problematic if the end of one batch overlapped the beginning of another. My thought was that I could append “.01” to the “seconds” value of the renamed file and increase that value for photos taken during a single second until the renaming error went away. It involved less than a dozen lines of code in the source file where I do all the work with the hope that all the renaming errors should disappear indefinitely. It was then that I found out that my project had errors (over 4,000!) when trying to build it. After fixing incompatible compiler options, “retargeting” the solution and a few other issues and again attempting to build with the static release version of Exiv2 0.26, I got it down to 7 unidentified variables pertaining to the “SRW” functions in rwlock.hpp.

It could be that Exiv2 0.25 would work well for me as it stands, but my thought process was that 0.26 exists that might offer bug fixes and/or performance improvements (even if it was in functionality I might never use), so why not use the latest version of the code? But I haven’t been able to get around the errors in rwlock.hpp and thus my reason for making use of the forums.

I’m in Calgary, Alberta, Canada, which is currently 7 hours behind Scotland. I’m more than happy to talk to you via Skype if I’m still having problems with the library but I won’t be able to talk about the technical details of Exiv2 beyond what I’ve described what I’m using it for. I’m not sure where the “External Dependencies” came from either—perhaps it was something I did in pointing to the wrong folder when I added an Include path because many of the thousands of errors I was getting had to do with not being able to find files like “string.h” and “stdio.h”. I think I’ll create a new solution, manually add my current source files and link with the static release of Exiv2 0.25. If I still come across any issues, I’ll let you know, but I’ll let you know if I’m successful as well.

Enjoy the rest of your vacation. Nice panorama, by the way!

Thanks very much for your kind words and thank you for the explanation about your use of Exiv2.

The code in rwlock.hpp was contributed by a user last year. It implements a class that uses underlying Windows code that depends on the version of Visual Studio. I see there's something about ATL and I wonder if that is causing a collision with MFC. I've simplified the code to only use CRITICAL_SECTION and attach a new version of that file. If that doesn't fix your build, pleased use v0.25. In terms of performance and functionality, I don't believe you'll notice any difference. I normally recommend everybody to use the latest version of Exiv2, however in your case, adopting v0.25 might be a quick fix.

If my modified rwlock.hpp doesn't fix matters, can you share your code with me? Zip your project and send it to me. I assure you that I won't share it with anybody. There are web services which provide a "one shot" service. You add the zip and ask to share it with robin@clanmills.com I get an email with a one-time key to download your code.

The Exif time specification is too simple. As you've discovered, It doesn't know about time-zones, day-light saving and has a resolution of 1 second. Many cameras have an additional tag: "Exif.Photo.SubSecTime" that provides millisecond accuracy. Perhaps you can take advantage of that to eliminate rename collisions.

I'm not suggesting that you modify your photo folder strategy. I have 60,000+ photos in my library, arranged into 1000+ folder "events". I also create a folder for every month. I put "one off shots" in the monthly folder if they don't obviously fit a real "event". http://clanmills.com/photos.shtml

I'm happy to report that your new rwlock.hpp made all the difference. After replacing the one in the latest Exiv2 include folder and rebuilding my code, everything compiled successfully. I did notice that the External Dependencies in my project was empty when I first opened the project but later contained all the 400+ include files it did before. I suspect this may be because the project sensed a new version of the rwlock.hpp file and updated its references.

When I first ran the executable, it complained it was missing exiv2, expat and zlib DLL files. I'm not sure why this happened as I added the lib files to the linker includes and previous versions of my app didn't need the DLLs. I may look into what changed later, but at this point, I'm thrilled that I was able to rename a folder containing close to 300 images in just a few seconds. If you're on Facebook, you may be familiar with the meme of a toddler in a green and white shirt and fist clenched with some slogan of victory. That's pretty much how I felt when my app ran like I expected it to! :)

I kept my own naming strategy in processing the files. I'm intrigued by SubSecTime but I think it would be a little confusing to have a bunch of file names ending in seemingly random numbers. We both know that most electronic devices don't keep exact NIST time anyway so even if I'm out a few seconds or even a couple minutes, it's still better than the default names that the camera uses. I know Exiv2 doesn't know anything about daylight savings or time zones, so that's why I added the ability to change DateTime values by a set amount of hours. It comes in handy when processing my daughter's photos from a recent trip to Vienna so that photos taken in late morning there don't reflect a timestamp filename that seems they were taken in the dead of night in Canada simply because she wouldn't have thought to change the camera time and the photos clearly indicate they were taken during a day of blazing sun! :)

I took a look at some of your photos. You are certainly more travelled than I am as I have been only to different parts of Canada and the US. My wife has been to New Zealand on an exchange program and Australia has always been on my bucket list.

Again, thank you so much for helping me with this, especially when code should be the farthest thing from your mind while on vacation. I know I would have racked my brain in frustration trying to solve a problem in code that I know so little about. I thought it was best to try the forums before going back to previous versions and it turns out I was right! It's nice to communicate with someone who knows what they're doing in matters like this! :)

I was very pleased to read your message this morning. Great start to the day.

Could the "missing dependencies" be source code for expat and zlib? You've added the DLLs, libs and modified the search path and that's a legitimate solution. msvc/exiv2.sln includes .vcproj files to build zlib and expat from source. Those should be installed parallel to the exiv2 code. This is documented in msvc/ReadMe.txt:

     Directory of c:\gnu\exiv2
     2010-12-05  10:05     <DIR>    trunk     <--- this tree
     2012-05-04  23:35     <DIR>    expat     <--- "vanilla" expat   2.1.0  source tree
     2012-05-04  23:35     <DIR>    zlib      <--- "vanilla" zlib    1.2.7  source tree

My solution contains only one project, that being my picture dater. Previous builds had the eviv2.hpp in my source code for declaration and a linker include for the static library for the definitions so the end result was just a single EXE with no DLL dependencies. I'm still not sure where the missing dependencies are coming from as I'm not compiling any the of Exiv2 code other than include files, but it's something I can look into, time permitting.

I also ran into a situation where some photos from various sources like my wife's old smartphone or my daughter's mini iPad would seemingly change the original filename to a "date", but the file name became something like "0008-00-00 1073741824.-82955175.1698724.15.JPG". It didn't seem to be consistent when this happened. I'll have to look through my code to see if there are any flaws in how I handle getting the date from the EXIF data such as not properly handling other date formats that Exiv2 can read besides the "YYYY-MM-DD HH24:MM:SS" that I've been using.

I'm not expecting any help in either of these matters, but I'll certainly try your suggestions if you have any. I'll consider this thread closed since I now have a working app but I'm more than happy to let you know my progress if you're interested. It's been quite some time since I've used Visual Studio and I'm sure that progress will include learning the nuances of the latest version.

Thanks for the update. I think this "missing dependency" matter is in your project and not the msvc/exiv2.sln and the .vcproj files. So, if you're moving, I'm happy and always pleased to hear from you (and all users). It's curious that photos from the iPad and Camera should throw up odd filenames. When I was in Largs last weekend, I took photos with my iPod and Nikon Camera. The date strings are the same:

535 rmills@rmillsmbp:~/Pictures/2017/Largs $ exiv2 -pa --grep date/i IMG_2984.jpg
Exif.Image.DateTime                          Ascii      20  2017:07:23 18:24:59
Exif.Photo.DateTimeOriginal                  Ascii      20  2017:07:23 18:24:59
Exif.Photo.DateTimeDigitized                 Ascii      20  2017:07:23 18:24:59
Exif.GPSInfo.GPSDateStamp                    Ascii      11  2017:07:23
536 rmills@rmillsmbp:~/Pictures/2017/Largs $ exiv2 -pa --grep date/i DSC_4735.jpg 
Exif.Image.DateTime                          Ascii      20  2017:07:24 12:36:06
Exif.Photo.DateTimeOriginal                  Ascii      20  2017:07:24 12:36:06
Exif.Photo.DateTimeDigitized                 Ascii      20  2017:07:24 12:36:06
Exif.NikonWt.DateDisplayFormat               Byte        1  Y/M/D
Exif.GPSInfo.GPSDateStamp                    Ascii      11  2017:07:24
537 rmills@rmillsmbp:~/Pictures/2017/Largs $ 

Anyway, very pleased to hear that you're rolling and out of trouble.

Having been a software developer, I certainly can appreciate having to maintain code for different platforms. Most recently, my efforts focused on compatibility with different browsers (Chrome, IE, Firefox, etc.) which can be a nightmare in itself.

I think the misnamed pics might have come from an iPod, but I thought nothing of it as I dumped all her photos into a single staging ground for renaming. I've never had any problems with "conventional" cameras from Nikon, Canon, Sony, etc. I'm going to start with a clean solution and build that—hopefully, the missing dependencies will disappear. It's likely a bug in my code and I'll let you know what I find out. It might be a good thing to know if someone else runs into the same problem.

Speaking of Nikon, What do you shoot with? I started with the original Canon Digital Rebel in 2004 but then moved to Nikon, having gotten a good deal on a D300 with an 18-200mm in 2007. Since then, it's been the D700, D800, and now the D810 that I usually have paired with the 28-300mm lens as my walk around setup. I would have loved to get into the D3, D4 and D5 series but they've always been too rich for my blood! :)

My first Digital SLR was a Canon Rebel in 2003. I have a Nikon D5300 which I purchased in 2014. It was the least expensive DSLR with GPS. I'm happy with it. The GPS was withdrawn on the D5400, so perhaps Nikon had second thoughts about this feature. For sure, the GPS doesn't track well if there's a tree anywhere nearby and I like taking the camera on hikes! However the built-in GPS is more convenient that merging GPX files from my Garmin Forerunner.

I get home on Wednesday afternoon (2 August). If you're having any trouble with this stuff, I'm happy to screen share and look at this with you on Skype (or Google Plus or FaceTime, or any other screen share/IM service you like).

I created a default MFC app in VS 2017 Community and clicked “Finish” as soon as I could. Upon compiling and running, I noticed the project had hundreds of “External Dependencies” as well. Perhaps there is an option in VS to turn this off, but since my app is not much bigger than it was before, I can live with that. I tried creating a new project and linking the static libs but it didn’t work for me for whatever reasons. Again, there may be some VS option that changes that, but I can live with that, too. I’ll just have to remember to include the DLLs in my own distribution.

I’m still not sure why I’m getting strange dates but I can get around that. I’m perplexed why Photoshop CC’s File Info shows XMP CreateDate and ModifyDate similar to “2017-03-26T03:45:24-06:00”, but there is no data in “Exiv2::XmpData” which is confirmed by Exiv2.exe included with the Exiv2 distribution. I’m thinking Photoshop is using the file system’s create and modify dates, but I don’t know where the “-6:00” time zone difference is coming from. Even the file’s properties don’t account for it, but I suppose in the absence of a date in any EXIF date I could just use the earlier of the create or modify dates if I really wanted all my files named as dates. Again, this is something I can live with.

Not knowing the Exiv2 API completely, I’m wondering if there’s a way to find out if a certain key exists. Currently, I’m iterating through the EXIF data to find “Exif.Image.DateTime” or “Exif.Photo.DateTimeDigitized”. I break the loop if I find the latter (which is almost always the case with digital cameras) but I can always fall back on the former if that one exists. In the absence of both, I currently inform the user that no date information could be found and leave the file name unchanged. I never thought of using “Exif.Photo.DateTimeOriginal” but, as mentioned, I could fall back on the file system’s dates if I don’t find that key either. It’s important that I use the date as close as possible to that when the photo was taken and not the date it may have been edited in Photoshop or Lightroom.

Speaking of GPS, I have the Nikon’s GP-1 for tagging, but I haven’t used it much because it’s never consistent in recording GPS data every time and it’s powered by the camera battery. That inconsistency may be why Nikon took it out of the D5400. Having internal GPS is certainly more convenient but it hasn’t been a critical thing for me. I could update my app to merge any GPX data recorded by my Garmin GPSMap 76CSx. It’s a lot more accurate than anything Nikon can offer anyway! Perhaps that’ll be a future project to keep my development skills in check.

Good to hear from you. And I think I have good news for you.

There are at least 2 date-time formats commonly used in metadata:

510 rmills@rmillsmbp:~/Pictures $ exiv2 -pa --grep date/i http://clanmills.com/Stonehenge.jpg
Exif.Image.DateTime                          Ascii      20  2015:07:16 20:25:28
Exif.Photo.DateTimeOriginal                  Ascii      20  2015:07:16 15:38:54
Exif.Photo.DateTimeDigitized                 Ascii      20  2015:07:16 15:38:54
Exif.NikonWt.DateDisplayFormat               Byte        1  Y/M/D
Exif.GPSInfo.GPSDateStamp                    Ascii      11  2015:07:16
Xmp.xmp.ModifyDate                           XmpText    25  2015-07-16T20:25:28+01:00
511 rmills@rmillsmbp:~/Pictures $ 

The API ExifData::findKey(...) searches ExifData for a key.

I've never noticed this "External Dependencies" feature of Visual Studio. You can avoid shipping the DLL if you build and link with the static library. This is fine for small stand-alone applications.

There is a sample application samples/geotag.cpp which reads GPX and updates images. There's a significant bug in the version in Exiv2 v0.26 which I've fixed. The code in v0.26.1 should be good. You might find that's all you need for your Garmin device. I originally wrote it in Python and converted it to C++ and put it into samples/geotag.cpp. The bug isn't harmful, just inconvenient. The truth is that I didn't finish the C++ version at the time and always intended to test it more. It's finished now and included in our test suite.

Please forgive my ignorance in using Exiv2 properly. Your help is genuinely appreciated.

I've attached a zip file of images illustrating some of my dilemmas. It contains the following files:

External.JPG: This is what I was referring to as External Dependencies in VS2017. It seems like it's including all the .H files because there are 11 more screens of this! It's not something I expect you to research for me. I would prefer to link just the static libraries to have just one EXE rather than including DLLs but I can look into that myself after I get added functionality working properly. My app was written mainly for myself and for friends and family who wanted to use it after I told them about it.
IMG_3534.JPG: This isn't an image I would necessarily want to rename as a date, but Photoshop's File Info shows the following related to XMP:

<xmp:CreateDate>2017-07-30T14:31:40-06:00</xmp:CreateDate>
<xmp:ModifyDate>2017-03-26T03:45:24-06:00</xmp:ModifyDate>
<xmp:MetadataDate>2017-03-26T03:45:24-06:00</xmp:MetadataDate>

xmp.JPG: I thought perhaps either of the two EXEs in dist\2015\Win32\dll\Release\bin would show me what I'm seeing in Photoshop's File Info for IMG_3534.JPG, but I assumed incorrectly or I'm using them incorrectly. Is there another console app I should be using instead?

It should have been obvious to me that an API using keys would have a find key function but thanks for pointing it out to me.

I'm not familiar with your build and test suite configuration. Could you point me to where I can find the updated geotag.cpp or is it already included in the "Download Source" on the Download page?

Nice image of Stonehenge! It's one of those places on my bucket list to see, even if I hear it's overrated and crowded with tourists. I'm surprised you got such a clean image in the middle of the afternoon. Was your update that evening using something like Photoshop's Photomerge to get rid of all the people? :)

David

The latest code for geotag.cpp is on 'master' on GitHub. I intend to publish Exiv2 v0.26.1 in September and it will include the fixed geotag.cpp (and binary builds).

Let's plan to talk on Skype 'clanmills' when I'm home. Saturday or Sunday morning your time (9:00am/4pm) is good for me.

I'm not sure I've understood what's in the zip. Here's what I see:

515 rmills@rmillsmbp:~/gnu/exiv2/0.26/src $ exiv2 -pa --grep date/i ~/Downloads/Images/*
/Users/rmills/Downloads/Images/External.jpg  Exif.Image.DateTime                          Ascii      20  2017:07:31 10:32:27
/Users/rmills/Downloads/Images/External.jpg  Xmp.xmp.CreateDate                           XmpText    25  2017-07-31T10:32:27-06:00
/Users/rmills/Downloads/Images/External.jpg  Xmp.xmp.MetadataDate                         XmpText    25  2017-07-31T10:32:27-06:00
/Users/rmills/Downloads/Images/External.jpg  Xmp.xmp.ModifyDate                           XmpText    25  2017-07-31T10:32:27-06:00
/Users/rmills/Downloads/Images/xmp.jpg  Exif.Image.DateTime                          Ascii      20  2017:07:31 10:45:59
/Users/rmills/Downloads/Images/xmp.jpg  Xmp.xmp.CreateDate                           XmpText    25  2017-07-31T10:45:59-06:00
/Users/rmills/Downloads/Images/xmp.jpg  Xmp.xmp.MetadataDate                         XmpText    25  2017-07-31T10:45:59-06:00
/Users/rmills/Downloads/Images/xmp.jpg  Xmp.xmp.ModifyDate                           XmpText    25  2017-07-31T10:45:59-06:00
516 rmills@rmillsmbp:~/gnu/exiv2/0.26/src $ 

I took the image of Stonehenge last year. The only change I made was to assign the Title "Classic View" in Picasa. Stonehenge is less than 1 hour from home and I often take overseas visitors. On this occasion my friend Tam and family. Tam and I worked together for Adobe in San Jose, CA. Stonehenge is usually "quite busy", however I've never seen it "very busy". More from that day: http://clanmills.com/2016/Stonehenge/

I apologize for the confusion over the files I sent. It comes from not properly explaining their intent and not fully understanding Exiv2's proper use and full potential. I hope I can clarify that here.

External.JPG is just a partial screen shot showing the External Dependencies section of my project similar to a a no-frills default MFC project that I also created for comparison which I'm seeing but you weren't familiar with. It contains 10 more screens of files from pressing Page Down and seems to include all the .h files from A to Z in the entire VS distribution! It has no real bearing on building my app but I still would like to figure out why it's there and contains hundreds of files. The exploration of this may also lead to why I can't link the static libraries at this point.

xmp.jpg is another screen shot of running the two console apps that I thought would show me XMP data, not realizing that Exiv2 would show me the dates I was interested in seeing if Exiv2 was given the proper actions/options to display them.

IMG_3534.JPG was included to illustrate that running Exiv2 on the file with no actions/options or with "-pa" does not show any XMP dates that Photoshop's File Info can see for the file. These are the three lines I show in my previous message. I'm curious why Exiv2 doesn't display any dates for this file.

Our exchange is gaining me a much better understanding of Exiv2 but if I'm having further difficulties I'm happy to do a Skype session. I'll let you know later in the week if that will be necessary and I'll be sure to have a list of questions if it comes to that. I also know where the invalid dates are coming from—a bug in my code that never manifested itself before because my current use of Exiv2 was always able to find the date info in files taken with all the digital cameras I've used my app with.

Ah, right. A couple of those image are screen shots. I understand. Now I understand what you're discussing when you talk about "dependencies". I suspect that is every header file that is accessed by the compiler. So, it will include all the MFC (afx) files, Exiv2 files and anything else you use when building your application.

There is no XMP metadata in IMG_3534.JPG! If PhotoShop is showing XMP data in this file, is it stored in an external "sidecar" file? For sure, it doesn't appear to be embedded in IMG_3534.JPG

The option -pS = print Structure.

528 rmills@rmillsmbp:~/Pictures $ exiv2 -pS ~/Downloads/Images/IMG_3534.JPG 
STRUCTURE OF JPEG FILE: /Users/rmills/Downloads/Images/IMG_3534.JPG
 address | marker       |  length | data
       0 | 0xffd8 SOI  
       2 | 0xffe1 APP1  |   12811 | Exif..MM.*......................
   12815 | 0xffed APP13 |      56 | Photoshop 3.0.8BIM........8BIM.%
   12873 | 0xffc0 SOF0  |      17 
   12892 | 0xffc4 DHT   |      31 
   12925 | 0xffc4 DHT   |     181 
   13108 | 0xffc4 DHT   |      31 
   13141 | 0xffc4 DHT   |     181 
   13324 | 0xffdb DQT   |      67 
   13393 | 0xffdb DQT   |      67 
   13462 | 0xffdd DRI   |       4 
   13468 | 0xffda SOS  

The option -pR = print Recursively. This is -pS AND dumps the data inside the structures. R = Recursive because some image data structures can embed more image data structures!

529 rmills@rmillsmbp:~/Pictures $ exiv2 -pR ~/Downloads/Images/IMG_3534.JPG 
STRUCTURE OF JPEG FILE: /Users/rmills/Downloads/Images/IMG_3534.JPG
 address | marker       |  length | data
       0 | 0xffd8 SOI  
       2 | 0xffe1 APP1  |   12811 | Exif..MM.*......................
  STRUCTURE OF TIFF FILE (MM): MemIo
   address |    tag                           |      type |    count |    offset | value
        10 | 0x0112 Orientation               |     SHORT |        1 |     65536 | 1
        22 | 0x011a XResolution               |  RATIONAL |        1 |        86 | 72/1
        34 | 0x011b YResolution               |  RATIONAL |        1 |        94 | 72/1
        46 | 0x0128 ResolutionUnit            |     SHORT |        1 |    131072 | 2
        58 | 0x0213 YCbCrPositioning          |     SHORT |        1 |     65536 | 1
        70 | 0x8769 ExifTag                   |      LONG |        1 |       102 | 102
    STRUCTURE OF TIFF FILE (MM): MemIo
     address |    tag                           |      type |    count |    offset | value
         104 | 0x9000 ExifVersion               | UNDEFINED |        4 | 808596017 | 0221
         116 | 0x9101 ComponentsConfiguration   | UNDEFINED |        4 |  16909056 | ...
         128 | 0xa000 FlashpixVersion           | UNDEFINED |        4 | 808529968 | 0100
         140 | 0xa001 ColorSpace                |     SHORT |        1 |     65536 | 1
         152 | 0xa002 PixelXDimension           |      LONG |        1 |       358 | 358
         164 | 0xa003 PixelYDimension           |      LONG |        1 |       480 | 480
         176 | 0xa406 SceneCaptureType          |     SHORT |        1 |         0 | 0
    END MemIo
       194 | 0x0103 Compression               |     SHORT |        1 |    393216 | 6
       206 | 0x011a XResolution               |  RATIONAL |        1 |       270 | 72/1
       218 | 0x011b YResolution               |  RATIONAL |        1 |       278 | 72/1
       230 | 0x0128 ResolutionUnit            |     SHORT |        1 |    131072 | 2
       242 | 0x0201 JPEGInterchangeFormat     |      LONG |        1 |       286 | 286
       254 | 0x0202 JPEGInterchangeFormatLeng |      LONG |        1 |     12515 | 12515
  END MemIo
   12815 | 0xffed APP13 |      56 | Photoshop 3.0.8BIM........8BIM.%
  Record | DataSet | Name                     | Length | Data
   12873 | 0xffc0 SOF0  |      17 
   12892 | 0xffc4 DHT   |      31 
   12925 | 0xffc4 DHT   |     181 
   13108 | 0xffc4 DHT   |      31 
   13141 | 0xffc4 DHT   |     181 
   13324 | 0xffdb DQT   |      67 
   13393 | 0xffdb DQT   |      67 
   13462 | 0xffdd DRI   |       4 
   13468 | 0xffda SOS  
530 rmills@rmillsmbp:~/Pictures $ 

There is no sidecar file for IMG_3434.JPG. I'm thinking that in the absence of date info, Photoshop uses the file system dates and times with the current time zone (-6 in my case). I'm curious if you were to open the file in Photoshop and get the File>File Info for it if the time stamps near the bottom would show a time zone relative to you. In any event, if the date info is missing in the Exif data, I use the earlier of file system create or modify date to rename the file as I like it. So all is good. Thanks again for all your help.

I don't have PhotoShop. I've got a 5 year old copy of Elements on a CD somewhere. I'll have a look at that. You can try changing the TimeZone on your computer and/or using the "touch" utility to change the file system time stamp. I think the dos COPY utility preserves time stamps and XCOPY does not.