Serial number reported in easy access function appears to be incorrect

[DougRogers]

In easy access function serialNumber, the number returned is either 45 or -212376298

IMG_1089.zip

[DougRogers]

The correct serial number is "2171204312" and is located in the key "Exif.Canon.SerialNumber" not the key "Exif.Photo.BodySerialNumber" which is examined first.

Also,
auto value = it->print(&exifData);
does not work, you must obtain it with
auto value = it->toString();
otherwise "Exif.Canon.SerialNumber" reports "816962168"

[norbertwg]

This case shows the limitations of easyaccess. The logic is to check several tags and the value of the first filled is returned. Unfortunately, the first hit has wrong data - which in general is impossible to detect. So I think, we cannot do something here.

It is strange, that in this case print (gives interpreted value) and toString (gives original value) are different, because the type of Exif.Canon.SerialNumber is Long. In the code I can see, that print uses for this tag some special logic, so there must be a reason for it. Do you have access to the hardware to see, which of the two numbers is correct?

[DougRogers]

Why not put Exif.Photo.BodySerialNumber last in the search list? If a serial number specific to a vendor is found, it will be returned first.

I do not have the camera anymore. I do have other examples that do the same thing, though.

[norbertwg]

I will check the impact to put Exif.Photo.BodySerialNumber last in the search list. It might happen, that we then have other wrong results. Will not be easy to judge what is correct, if changing sequence gives other results for other images.

In most cases easy access first looks for Exif.Photo or Exif.Image, but there are also cases, where maker tags are first in list. For me it is plausible to start with Exif.Photo and Exif.Image, because these tags are well defined in a standard. So we know, what we can expect. An other argument - which would fit to your example - could be, that manufacturers take more care to fill their own tags than filling standard tags.

Regarding the different result of print and toString: I opened your image with Canon Digital Photo Professional and the serial number shown there is the one exiv2 returns with toString. I checked some other images in my collection of test images and the result is the same. So either the conversion in print is wrong or the conversion is missing in Canon Digital Photo Professional. The history in GitHub shows, that this conversion was already in the oldest available version from Mar 7, 2004. The author who provided the file is no longer working on exiv2 and I have no hope that somebody else can remember, why this conversion is made. Perhaps this conversion was valid back almost 20 years ago and now Canon fills the tag without conversion. It could help, if somebody is able to compare the serial number on hardware with the tag value.

There is also a tag called Exif.Canon.SerialNumberFormat in the images. I thought, this tag might define how to convert the value, but in Canon Digital Photo Professional the two different values I found had no influence.

[DougRogers]

I am happy with the order you decide is best.
.
I no longer have the camera, but it is still registered to me. Here is a screenshot from the registration page.

[norbertwg]

Well, this is a convincing evidence, that print returns the wrong serial number. So I will prepare a pull request for this.

I also will check, how to deal with the order of tags for serial number in easy access. Hoping that changing the sequence does not make anything worse, I will prepare a pull request for that as well.

[norbertwg]

An owner of an EOS 5D Mark III confirmed, that the plain number (the output of toString) is the one written on the body. But: During preparing the pull request I executed all test cases and compared output with Canon Digital Photo Professional. There I found one image from a D30, where the value of print matches output of Canon Digital Photo Professional. So in some cases print is correct, but I do not know the rule and decided not continue with the pull request before I or somebody else found the rule.

[norbertwg]

I used Canon Digital Photo Professional to check the Canon sample images from ExifTool. From these images,

• 44 had an entry only in Exif.Canon.SerialNumber
• 77 had an entry only in Exif.Photo.BodySerialNumber
• 1 on them had an entry in both tags, Exif.Photo.BodySerialNumber contained the value from Exif.Canon.SerialNumber as hex.

With these images 120 Canon models were covered.

In general Canon Digital Photo Professional shows the value of Exif.Canon.SerialNumber just as number with leading zeros to fill up to 10 or 12 digits. Only for the image taken with a D30, serial number is shown like the current print function from exiv2.

There is one image, where Exif.Photo.BodySerialNumber contains "aaaaaaaaaaaa", which - according to my opinion - most likely was written manually. But I hope, that this is an exception. Otherwise the analysis might be wrong.

So based on these data, my conclusion is to continue as follows:

• For images from D30, we use the current print logic.
• In all other cases, just print the number. Filling up with leading zeros would be nice, but as it is not clear when to fill up to 10 or 12 digits and leading zeros are not essential, we do it without.

[DougRogers]

Did the image that I attached have the hex value in BodySerialNumber?

[norbertwg]

No, hex value would be 8169F2D8, but Exif.Photo.BodySerialNumber shows -212376298. I see no relationship between this and the 2171204312 in Exif.Canon.SerialNumber.