Research precedence order (i.e. modification date vs original date)

[ldexterldesign]

Hey,

Hope you're well

Thanks for software as always

I'm observing some strange behaviour today where the following Exif[f] seems to get higher precedence:

File Modification Date/Time     : 2017:04:02 03:13:53+02:00

... over the following Exif:

Date/Time Original              : 2012/03/02 11:56:41
Create Date                     : 2012/03/02 11:56:41

Inevitably, this results in incorrectly named files and folders (e.g. 2017-04-02_00-11-29-2012-03-02_12-56-42-imag0720.jpg)

Is this expected behaviour?:

If yes, why

If no, what do you need to debug this

If you have any issues (e.g. questions/queries) - happy to help

Hope this is clear/useful and to hear back

Keep up great work!

Yours faithfully

[f]

Last login: Sat Sep 15 01:33:22 on ttys001
Lewiss-MacBook-Pro:~ ldexterldesign$ exiftool /Applications/elodie/-2-destination/2017-04/HTC/Unknown\ camera\ model/UK\ -\ England\ -\ /2017-04-02_00-11-29-2012-03-02_12-56-42-imag0720.jpg
ExifTool Version Number         : 11.01
File Name                       : 2017-04-02_00-11-29-2012-03-02_12-56-42-imag0720.jpg
Directory                       : /Applications/elodie/-2-destination/2017-04/HTC/Unknown camera model/UK - England -
File Size                       : 810 kB
File Modification Date/Time     : 2017:04:02 03:13:53+02:00
File Access Date/Time           : 2018:09:15 01:33:14+02:00
File Inode Change Date/Time     : 2018:09:15 01:33:13+02:00
File Permissions                : rwxr-xr-x
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : HTC
Camera Model Name               : HTC Sensation Z710e
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Y Cb Cr Positioning             : Centered
ISO                             : 87
Exif Version                    : 0220
Date/Time Original              : 2012/03/02 11:56:41
Create Date                     : 2012/03/02 11:56:41
Components Configuration        : Y, Cb, Cr, -
Focal Length                    : 4.3 mm
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 1840
Exif Image Height               : 3264
Interoperability Index          : R98 - DCF basic file (sRGB)
Interoperability Version        : 0100
GPS Latitude Ref                : North
GPS Longitude Ref               : West
GPS Altitude Ref                : Above Sea Level
GPS Time Stamp                  : 11:56:30
GPS Processing Method           : ASCII
GPS Date Stamp                  : 2012:03:02
Compression                     : JPEG (old-style)
Thumbnail Offset                : 854
Thumbnail Length                : 13830
XMP Toolkit                     : Image::ExifTool 10.40
Original File Name              : 2012-03-02_12-56-42-imag0720.jpg
Image Width                     : 1840
Image Height                    : 3264
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
GPS Altitude                    : 0 m Above Sea Level
GPS Date/Time                   : 2012:03:02 11:56:30Z
GPS Latitude                    : 51 deg 28' 12.64" N
GPS Longitude                   : 2 deg 35' 39.97" W
GPS Position                    : 51 deg 28' 12.64" N, 2 deg 35' 39.97" W
Image Size                      : 1840x3264
Megapixels                      : 6.0
Thumbnail Image                 : (Binary data 13830 bytes, use -b option to extract)
Focal Length                    : 4.3 mm

[ldexterldesign]

For a moment I suspected this was connected to date formatting (hence issue title changes) but I'm also experiencing this behaviour with another file:

ExifTool Version Number         : 11.01
File Name                       : 2018-09-15_00-36-07-2008-11-03_23-02-38-tania zambabitchakdjan-harboursidebristol-oct2008 (5).jpg
Directory                       : /Applications/elodie/-2-destination/2018-09/SAMSUNG/Unknown camera model/Unknown Location
File Size                       : 123 kB
File Modification Date/Time     : 2017:04:02 02:41:38+02:00
File Access Date/Time           : 2018:09:15 02:52:34+02:00
File Inode Change Date/Time     : 2018:09:15 02:48:44+02:00
File Permissions                : rw-r--r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Resolution Unit                 : inches
X Resolution                    : 96
Y Resolution                    : 96
Exif Byte Order                 : Little-endian (Intel, II)
Make                            : SAMSUNG
Camera Model Name               : SGH-E260
Y Cb Cr Positioning             : Centered
Exif Version                    : 220
Date/Time Original              : 2008:103:03 19:46:10
Create Date                     : 2008:103:03 19:46:10
Components Configuration        : Y, Cb, Cr, -
Flashpix Version                : 100
Color Space                     : sRGB
Exif Image Width                : 1280
Exif Image Height               : 1024
XMP Toolkit                     : Image::ExifTool 10.40
Original File Name              : 2008-11-03_23-02-38-tania zambabitchakdjan-harboursidebristol-oct2008 (5).jpg
Image Width                     : 1280
Image Height                    : 1024
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                      : 1280x1024
Megapixels                      : 1.3

The following tags should take precedence here:

Date/Time Original              : 2008:103:03 19:46:10
Create Date                     : 2008:103:03 19:46:10

Regards

[jmathai]

Can you send me the file? You're correct that DateTimeOriginal should take precedence.

I think the format of the date string is the culprit. Here is the regex which it looks to parse. It looks for a 2 digit month but in yours it's 103. I'm not sure how python's time functions will handle 103. What month is that supposed to be?

To have it pass the regex validation you should change the line to the following.

 if(re.match('\d{4}(-|:)\d{2,}(-|:)\d{2}', exif[key]) is not None): # noqa

[ldexterldesign]

Thanks for reply

Can you send me the file?

https://drive.google.com/open?id=14lVsU72PYOVnmaeMLBJm9yYpJIAVtzH1 - you can grab the two photos here (one for each use case)

What month is that supposed to be?

Yea, I did spot the weird dates on the second use case too - it wasn't my (Samsung phone) camera so unfortunately can't do much research. The date should be 2008:10:03 but it's not clear (i.e. it could just as well be 2008:03:03 to the interpreter).

If I were elodie I would throw an error and leave the file in source, that way the user can go in and fix manually - what do you think?

If you have any issues (e.g. questions/queries) - happy to help

Hope this is clear/useful and to hear back

Cheers

[ldexterldesign]

If I were elodie I would throw an error and leave the file in source, that way the user can go in and fix manually - what do you think?

BUMP

[jmathai]

That's a good question and I'm not sure what the correct behavior would be as both have pros/cons.

Pros:

• Throwing an error lets you know something might be off and gives you a chance to fix it. Cons:
• Invalid strings in a field where the next field in priority contains a valid string will result in an error.
• Fiddling with EXIF is a pain and throwing an error means the photo will never be imported. This also makes it impossible to use the helper functions in Elodie itself to fix the dates.

For the moment I'm leaning against making a change to throw errors because I think it could be quite inconvenient. Also, the assumption used in Elodie is that EXIF data is usually correct but at times is not and when it's not there are easy ways to "fix" them.

[ldexterldesign]

If I were elodie I would throw an error

Apologies, although I said error I meant some kind of general exception

Assuming error means something that stops the CLI how about a warning (i.e. something that doesn't stop the CLI) - the warning could mention a lower priority piece of data was used because the top priority data was invalid?

My use case here is that if I'm inputing lots (e.g. 1000+) of files anything that takes an incorrect date gets buried in my output in the wrong folder structure. Until I I find the file later I have no idea it's there and actionable (i.e. needs correct Exif); by which point if I used the --trash option then I've just lost the original folder structure with naming potential that may have been useful to me in identifying and correcting the incorrectly dated file.

If you have any issues (e.g. questions/queries) happy to help

Hope this is clear/useful and to hear back

Yours faithfully

[jmathai]

That makes sense. We can output a warning in case the EXIF field is not empty but doesn't pass validation. Reopening.