Odd behavior of Canon FileNumber when wrapping beyond 9999

[Martin B.]

Hi,

It appears the Canon FileIndex (and derived FileNumber) can go beyond 9999, so be aware that this may cause problems with your file names and indexing.

I found this odd behavior of the Canon FileNumber when reaching beyond FileIndex 9999. Depending on your camera settings, this "shutter count" may or may not be reset each time you change your memory card. I use the "continuous" setting, which means that "Even after you replace the card or create a new folder, the file numbering continues in sequence up to 9999." I just found out this is true for the name of the file recorded on the memory card, but the internal FileIndex doesn't exactly match.

See the following output:

Code Select Expand

>exiftool -datetimeoriginal -directoryindex -fileindex -filenumber _MG_9999.CR2 _MG_0001.CR2 _MG_0002.CR2
======== _MG_9999.CR2
Date/Time Original              : 2013:12:29 19:13:36
Directory Index                 : 100
File Index                      : 9999
File Number                     : 100-9999
======== _MG_0001.CR2
Date/Time Original              : 2013:12:29 19:14:45
Directory Index                 : 100
File Index                      : 10000
File Number                     : 100-10000
======== _MG_0002.CR2
Date/Time Original              : 2013:12:29 19:14:51
Directory Index                 : 101
File Index                      : 2
File Number                     : 101-0002
    3 image files read

>exiftool -ver -model _MG_0001.CR2
10.00
Camera Model Name               : Canon EOS DIGITAL REBEL XSi
Notice that the file name nicely wraps like this: 9999, 0001, 0002.
But the internal File Index goes like this: 9999, 10000, 0002.

The consequences are:
1. The FileIndex of one picture doesn't match the file name from the memory card.
2. The FileIndex can have 5 digits.
3. This confuses ExifTool when copying the FileNumber tag from one Canon file to another, but only if the target file doesn't contain a FileIndex before the copy.

See below for examples of item #3:

Code Select Expand

>exiftool -directoryindex -fileindex -filenumber _MG_0001.CR2 CanonRaw.cr2 other-photo.CR2
======== _MG_0001.CR2
Directory Index                 : 100
File Index                      : 10000
File Number                     : 100-10000
======== CanonRaw.cr2
File Number                     : 100-0024
======== other-photo.CR2
Directory Index                 : 100
File Index                      : 795
File Number                     : 100-0795
    3 image files read

>exiftool -tagsfromfile _MG_0001.CR2 -FileNumber CanonRaw.cr2
    1 image files updated

>exiftool -tagsfromfile _MG_0001.CR2 -FileNumber other-photo.CR2
    1 image files updated

>exiftool -directoryindex -fileindex -filenumber _MG_0001.CR2 CanonRaw.cr2 other-photo.CR2
======== _MG_0001.CR2
Directory Index                 : 100
File Index                      : 10000
File Number                     : 100-10000
======== CanonRaw.cr2
File Number                     : 1001-0000
======== other-photo.CR2
Directory Index                 : 100
File Index                      : 10000
File Number                     : 100-10000
    3 image files read
Notice that the DirectoryIndex and FileIndex are correctly copied to other-photo.CR2.

For CanonRAW.cr2, however, the FileIndex spilled over the DirectoryIndex part of the FileNumber, making the directory part 4 digits long.

CanonRaw.cr2 is a test file from the ExifTool distribution. The other two files are from my Canon XSi.
In other tests, writing to a JPG file yielded results similar to writing to CanonRaw.cr2.
Writing to a CR2 file from my Canon 70D yielded results similar to other-photo.CR2.

I'm not sure I'd qualify this as a bug, but I thought others might benefit from the information.

Martin

[Phil Harvey]

Hi Martin,

Thanks for reporting this.  I'll take a look and post back after I get a chance to investigate.

- Phil

[Phil Harvey]

Hi Martin,

There are a number of very similar values nearby in the metadata, and it may be that ExifTool is extracting the wrong ones for FileNumber and ImageNumber.  Could you email me the set of 3 images numbered 9999, 0001 and 0002 so I can take a close look at the metadata?  My email is philharvey66 at gmail.com

Thanks.

- Phil

[Phil Harvey]

Hi Martin,

I got the files, thanks.  I can't find any other metadata that better represents the file numbering scheme, so what I will do is apply a patch to the Composite:FileNumber tag so that NNN-10000 will be adjusted to MMM-0001 (where MMM = NNN + 1).

Thanks for pointing this out.

- Phil

Edit: In your email you mention the native Canon:FileNumber tag.  Have you also seen odd behaviour when this tag wraps?  The files you sent are from a REBEL XSi, which stores FileIndex and DirectoryIndex separately.  As you can see, ExifTool adds 1 to the stored value for FileIndex (and in most cases, although not for the XSi, subtracts 1 from DirectoryIndex).

So the stored directory/file index values for your 3 images are:

Image 9999:  100/9998
Image 0001:  100/9999
Image 0002:  101/0001

OK.  It is clear that the camera is storing the numbers for the previous image, then incrementing them in memory _after_ it writes the image.  Silly. 

Note that I think the very first image shot after the count is reset would be like this:

Image 0001:  100/0000

So both 0000 and 9999 represent an image number of 0001, but when the number is 9999 the DirectoryIndex should be incremented by 1.  This inconsistency makes things difficult.

Given that the mapping difficulties, I'm not sure that I can do much better than simply patching Composite:FileNumber like this:

        ValueConv => q{
            # fix the funny things that these numbers do when they wrap over 9999
            $val[1] = 1 and ++$val[0] if $val[1] == 10000;
            return sprintf("%.3d-%.4d",@val);
        },

[Martin B.]

Thanks Phil.

For completeness, NNN also wraps from 999 to 001, at the next picture after 999-9999. But that's 10 million pictures with the same camera body without a reset. I'm not sure anyone will ever reach this limit.

How about the FileIndex itself? If you only patch the Composite:FileNumber, then the FileIndex will still be displayed as 10000, when it should really be 0001.

Martin

[Phil Harvey]

Hi Martin,

Yes.  FileIndex will be 10000 for the first image after a wrap, which is an indication that DirectoryIndex is also wrong by 1.

The ideal solution would be to rename these to PreviousFileIndex and PreviousDirectoryIndex (and stop adding 1 to the number), because that is what they seem to be.  But this wouldn't be backward compatible for ExifTool users who are already using these tags.

- Phil

[Martin B.]

I think that not adding 1 to the indexes would be more confusing, since they would not match the name of the file on the camera.

So I prefer your solution.

Thanks again,

Martin

[TorC]

Unless you add the PreviousFileIndex and PreviousDirectoryIndex, along with, for that camera, CurrentFileIndex and CurrentDirectoryIndex with a note that the existing FileIndex and DirectoryIndex are deprecated for the camera?

Though I suppose that might pose challenges if writing to FileIndex or DirectoryIndex.

[Phil Harvey]

I wasn't seriously thinking about renaming these tags, so I think we are in agreement here.

There is a minor quirk in the FileIndex/Directory index both when reading and writing for the single image at the rollover, but the FileNumber should be consistent with this change.

- Phil