Rename Photos - Precedence of File Creation Date/Time vs. Capture Date/Time

[ravi]

Hi,

(PM5 Build 18895 running on a Win10 Pro Build 14393 system)

I'm using the Rename Photos command to organize a large number of old JPGs with the following parameters: {datesort}-{timesort}-M

I've noticed that some images are ending up with new filenames that do not match the actual capture date/time. For example, one image was renamed with a filename indicating a date from last week, but shows an event that clearly is from last winter.

Upon examining the EXIF data, I noticed that the camera capture date/time fields are blank in every one of the files with incorrect filenames. The filename matches the file creation date/time data however.

After looking through the PM help file, it seems this behavior is working as designed since the {datesort} variable provides the "Capture date of photo according to camera or file creation time." My guess is that PM looks for the camera capture date/time first, and if that is missing it defaults to file creation date/time? Am I understanding correctly?

My concern is that unless I go through each image manually to look at the EXIF data (and there are thousands of files), it will be difficult to tell which files were missing CAPTURE date/time data and therefore now have a potentially inaccurate filename based on the file creation time.

Are any of these solutions possible? If so, what settings do I need to use? Option 1 is preferred.

• Use different variables in the rename command to force using only CAPTURE date and CAPTURE time. I'm trying to end up with a filename formatted like YYYYMMDD-HHMMSS when capture data is available, and all blank (except for a file collision suffix) when capture data is missing
• Force PM during renaming to add a text prefix or suffix to files that defaulted to FILE CREATION date/time because the CAPTURE date/time data was missing.
• Force PM to skip files that are missing CAPTURE date/time data during the batch rename.

Thanks - Ravi

[Kirk Baker]

Ravi,

(PM5 Build 18895 running on a Win10 Pro Build 14393 system)

I'm using the Rename Photos command to organize a large number of old JPGs with the following parameters: {datesort}-{timesort}-M

I've noticed that some images are ending up with new filenames that do not match the actual capture date/time. For example, one image was renamed with a filename indicating a date from last week, but shows an event that clearly is from last winter.

Upon examining the EXIF data, I noticed that the camera capture date/time fields are blank in every one of the files with incorrect filenames. The filename matches the file creation date/time data however.

After looking through the PM help file, it seems this behavior is working as designed since the {datesort} variable provides the "Capture date of photo according to camera or file creation time." My guess is that PM looks for the camera capture date/time first, and if that is missing it defaults to file creation date/time? Am I understanding correctly?

That is correct.

My concern is that unless I go through each image manually to look at the EXIF data (and there are thousands of files), it will be difficult to tell which files were missing CAPTURE date/time data and therefore now have a potentially inaccurate filename based on the file creation time.

Are any of these solutions possible? If so, what settings do I need to use? Option 1 is preferred.

• Use different variables in the rename command to force using only CAPTURE date and CAPTURE time. I'm trying to end up with a filename formatted like YYYYMMDD-HHMMSS when capture data is available, and all blank (except for a file collision suffix) when capture data is missing
• Force PM during renaming to add a text prefix or suffix to files that defaulted to FILE CREATION date/time because the CAPTURE date/time data was missing.
• Force PM to skip files that are missing CAPTURE date/time data during the batch rename.

None of those options is possible.  If capture time data is not available then PM uses the creation date of the file as the capture time (this usually works out fine for images produced by cameras but does not work well for scans of slides/prints.)

There are no variables related to capture time that do not have this fallback behavior.

The only suggestion I have is for you to use something like ExifTool to insert capture time data that matches the time/date that you know the image to have been captured.  But this will be a largely manual process.

-Kirk

[ravi]

Thanks for the speedy reply Kirk.

At least I know for certain there was no easy automated solution that I overlooked before going through a manual verification process!   

[Odd Skjaeveland]

At least I know for certain there was no easy automated solution that I overlooked...

With reference to your own anticipation and Kirk's answer, changing the file timestamp may perhaps be a way out. Depending on circumstances, that may be simpler, or not. Most variants of unix-like operating systems come with the "touch" utility. I belive it has been ported to Winodws.