Filename %date variable not working correctly

[jmuc...@gmail.com]

When I set the filename to use the %date variable, it doesn't work correctly for me. 

Problem 1

For example, using "%filename - %time" as the template, a jpeg produces 

IMG_3664 - 01/18/46 PM.pto

I'd prefer periods instead of slashes and 24-hr time, but that at least is the correct original time as exiftool reports it. For the same file, if I use %date instead of %time, I get just

2019.pto

The filename preview in the prefs shows the slashes in the date (3/20/2021), so I wonder if somehow the save process is swallowing what it thinks is the entire path, which would include the part of the date string up to the last slash. If I reverse those two items in the template, I get the following, which is consistent with that idea:

2019 - IMG_3664.pto

Problem 2:

If I use a png I created from a heic file (which hugin doesn't seem to like) and to make sure it has all the date data that the original does (with exiftool -tagsfromfile), hugin uses the literal string "%date" in the filename. IOW it doesn't seem to read the date or time info at all. This despite the png also having date/time info in PNG tags.

Any help appreciated, but the first at least seems like a bug.

On MacOS 10.15.7, Hugin 2020.

[T. Modes]

jmuc...@gmail.com schrieb am Samstag, 20. März 2021 um 20:06:56 UTC+1:

Problem 1

For example, using "%filename - %time" as the template, a jpeg produces 

IMG_3664 - 01/18/46 PM.pto

<snip>

Hugin is using the system setting for the date/time formatting. On my system the date/time format does not contains a slash. So I havn't seen this before. I fixed this in the repository. Now the slashes are replaced by an underscore.

Also missing date/time value are now correctly handled.

Problem 2:

If I use a png I created from a heic file (which hugin doesn't seem to like) and to make sure it has all the date data that the original does (with exiftool -tagsfromfile), hugin uses the literal string "%date" in the filename. IOW it doesn't seem to read the date or time info at all. This despite the png also having date/time info in PNG tags.

Any help appreciated, but the first at least seems like a bug.

Hugin is using exiv2 to read the metadata, not exiftool. The displayed date/time is the EXIF DateTimeOriginal (Exif.Photo.DateTimeOriginal in exiv2 speech). PNG files have no EXIF data, the metadata are stored differently. So this is expected.

Can you provide a (small) sample png file, so I can have a look?

Thomas

[T. Modes]

T. Modes schrieb am Sonntag, 21. März 2021 um 10:13:33 UTC+1:

 The displayed date/time is the EXIF DateTimeOriginal (Exif.Photo.DateTimeOriginal in exiv2 speech). PNG files have no EXIF data, the metadata are stored differently. So this is expected.

I did some more digging. There is a newer standard for writing EXIF tags to PNG files. But for reading you need at least exiv2 0.27.4. Older version like the current stable 0.27.3 don't read EXIF data in PNG files.

Furthermore it seems exiv2 can't read the PNG CreationTime as written by Windows or exiftool.

[jmuc...@gmail.com]

Yes, png traditionally didn't have exif data. I'm no expert, but there are PNG tags, I believe. See here: https://exiftool.org/TagNames/PNG.html Could be these still aren't read by exiv2.

In any case, seems to me like a fallback to the file mofication date/time wouldn't be bad.

[T. Modes]

jmuc...@gmail.com schrieb am Sonntag, 21. März 2021 um 20:08:52 UTC+1:

Yes, png traditionally didn't have exif data. I'm no expert, but there are PNG tags, I believe. See here: https://exiftool.org/TagNames/PNG.html Could be these still aren't read by exiv2.

This is what I already wrote...

In any case, seems to me like a fallback to the file mofication date/time wouldn't be bad.

Okay,  I implemented the fallback to file creation date/time if no EXIF:DateTimeOriginal is found.

[jmuc...@gmail.com]

On Monday, 22 March 2021 at 13:21:31 UTC-4 T. Modes wrote:

jmuc...@gmail.com schrieb am Sonntag, 21. März 2021 um 20:08:52 UTC+1:

Yes, png traditionally didn't have exif data. I'm no expert, but there are PNG tags, I believe. See here: https://exiftool.org/TagNames/PNG.html Could be these still aren't read by exiv2.

This is what I already wrote...

Yes, Thanks for confirming.

 

In any case, seems to me like a fallback to the file mofication date/time wouldn't be bad.

Okay,  I implemented the fallback to file creation date/time if no EXIF:DateTimeOriginal is found.

Great.