Float Lensid tags?

[PSS]

Maybe this is in some FAQ, but can't find any.

I have a problem with Canon RF LensID tags (among others). They should be in float, but I get only int out from exiftool (latest, centos, command line).

So, instead of 44 different 61182.X ids I get one same LensID all over again: 61182

https://exiftool.org/TagNames/Canon.html

Is there a solution to this? I use command exiftool -g2 -j -n -m -H /path

[Phil Harvey]

From the documentation:

Decimal values have been added to differentiate lenses which would otherwise have the same LensType, and are used by the Composite LensID tag when attempting to identify the specific lens model.

By this I meant that many lenses have the same LensType number (integer).  The decimal has been added only for internal purposes to be able to address the separate lenses.

- Phil

[PSS]

Thanks.

Internal purposes means "in documentation", right?

So it looks like there is no way to get the "internal purposes Composite LensID" tag out from exiftool, as it rounds up to same integer?

Too bad, that means the lensid is useless for guessing RF lenses.

PS. Thanks for this wonderful tool and all the work you do for it!

[Phil Harvey]

Internal purposes means "in documentation", right?

No.  Internally the LensType table is a hash lookup, and you can't have multiple entries with the same hash key, so I had to add something to make them unique.  Internally, ExifTool ignores this number and just cycles through all LensType values with the same integer part, comparing the strings against the stored lens parameters to determine the most likely Composite LensID to report.

- Phil

[PSS]

Internal purposes means "in documentation", right?

No.  Internally the LensType table is a hash lookup, and you can't have multiple entries with the same hash key, so I had to add something to make them unique.  Internally, ExifTool ignores this number and just cycles through all LensType values with the same integer part, comparing the strings against the stored lens parameters to determine the most likely Composite LensID to report.

- Phil

Sorry for being thick, but if the internal process "determines the most likely Composite LensID to report" the why doesn't exiftool return 61182.40 or 61182.26 as LensID (or even as some other tag like "DeductedLensid", but returns 61182 for all (which helps nothing)? My site software can now detect RF's by name and other things, but I had to made it ignore lensid value 61182 in deduction process, which is sort of counter-intuitive as the value IS there.
 

[Phil Harvey]

The actual lens is determined after converting the numerical LensType to a string by looking at the focal length and aperture values in the string and comparing to the other lens parameters upon which the Composite tag is based.  If you just ask for the numerical LensID then this is done before the conversion.  The important thing is the string (ie. lens model name).  I don't see why you would want to use the number.

- Phil

[PSS]

I don't see why you would want to use the number.

And yet it is there I match to items in database, so I use all I can get.

So, you find and store lensid 61182, then determine what the lens actually is by string match etc. and when matched to your internal list, find it to be 61182.24. Why not change the previously stored 61182 to 61182.24 after it has been established to be so, and make the lensid value useful?

Not a big issue, though. Have a nice week.

[Phil Harvey]

So, you find and store lensid 61182, then determine what the lens actually is by string match etc. and when matched to your internal list, find it to be 61182.24.

The first thing that ExifTool does is make a list of possible lens models.  61182 is used to narrow down this list, but the list isn't necessarily constrained only to those models in the lookup table.  The decimal LensType is already lost when the list is generated.  It would be difficult to store the decimal numbers and return them if the final lens model corresponds to one of these values.  There are so many exceptions, edge cases, and different logic for other makes that it would be a real headache to implement this.

- Phil