Project

General

Profile

Exif.CanonCs.FocusContinuous comes out as unsigned short

Added by Sridhar Boovaraghavan over 5 years ago

Hi,

This Exif.CanonCs.FocusContinuous value comes out as unsigned short and thus reports a value of 65535 when it should be reporting a -1 because it is a signed short type.

Now, I see that only 0 and 1 are defined values for this type. What does -1 signify? I see that there is a "8" defined as Manual in the exiftool documentation that could possibly be added to this list. I would also make -1 be treated as if it is 0.

I see evidence of this behaviour in exiv2's test files itself. Try exiv2\test\data\exiv2-test.out(Line #2697). See that it reports (65535) whereas it should be a -1.

Where is this going incorrect? I see that the definition of FocusContinuous in canonmn.cpp correctly as signedShort.

Thanks,
Sridhar
p.s. Windows 10 x64 with MSVC 2015 (exhibits the same behavior in x86/x64 builds)


Replies (7)

RE: Exif.CanonCs.FocusContinuous comes out as unsigned short - Added by Robin Mills over 5 years ago

You're right. It should be reporting -1. However it has been reporting 65535 since before I joined the project 8 years ago. I don't recall anybody complaining about this. I'm rather reluctant to change this as it may break somebody's script. For sure it will impact our test suite.

I can't say what 65535/-1 means. Exiv2 reports the data it finds in an image. If Canon choose to store 65535, 8, or 911, exiv2 will report it.

RE: Exif.CanonCs.FocusContinuous comes out as unsigned short - Added by Sridhar Boovaraghavan over 5 years ago

I think you should change it because it is a signedShort in your documentation (please see http://www.exiv2.org/tags-canon.html) and it is being interpreted as an unsignedShort in the code. 65535 is the unsigned short version of -1 (signedShort).

As I said in my original post, exiftool reports -1.

All indications are that this is a bug in exiv2. It not being raised in 8 years possibly just means that no one was interested in that tag till now.

As to what -1 actually means, that's a different question. I was proposing that we interpret -1 to mean Single (i.e. the same as zero).

I also propose that you add the value 8 to count as Manual (following exiftool).

Thanks,
Sridhar

RE: Exif.CanonCs.FocusContinuous comes out as unsigned short - Added by Robin Mills over 5 years ago

Please raise an issue on Redmine about this. Somebody might change it for you.

RE: Exif.CanonCs.FocusContinuous comes out as unsigned short - Added by Robin Mills over 5 years ago

We've split this matter into two issues. #1202 = 8/Manual #1203 = SShort/Short contradiction.

RE: Exif.CanonCs.FocusContinuous comes out as unsigned short - Added by Sridhar Boovaraghavan over 5 years ago

Hi Robin,

Please see my update to http://dev.exiv2.org/issues/1203

There are other tags such as Exif.CanonCs.ImageStabilization (returns 65535), Exif.CanonCs.SpotMeteringMode (returns 65535), Exif.CanonCs.Sharpness (returns 32767) that are also incorrect.

FocusContinuous is an obscure field, but I need values of ImageStabilization and SpotMeteringMode to be correct - i.e. I intend to use them much more often.

Please update the issue to say that all of these signedShort values are returned as short.

Thanks,
Sridhar

RE: Exif.CanonCs.FocusContinuous comes out as unsigned short - Added by Sridhar Boovaraghavan over 5 years ago

Hi Robin,

Sorry for the multiple updates.

I feel like I have more information now.

When I ask exiftool to report on such images (where I get 65535), those tags are not reported unless you pass along a "-v" switch.

This along with those values not being defined (i.e. there is no interpretation for -1), makes me feel that these are tags that are not "written" and thus contain default values.

This reinforces my earlier suggestion of creating a -1, but interpreting it as a new key that we introduce - say Unknown.

I can confirm (for ImageStabilization at least), the lens in question does not have it (and neither does the camera). So when exiv2 returns -1 for that image for this field, it should be interpreted as Unknown. If you can think of a better name for this, please do suggest.

Thanks,
Sridhar

    (1-7/7)