Canon AFInfo seems misinterpreted #981
Comments
|
Thanks for reporting this and providing a test file. I'll have to investigate this. There's something in the code for Canon.AFInfo: However we are reporting a long stream of 273 shorts: I'll investigate. I believe I can add a binary decoder to report values from fields in that binary stream. Something similar to this was reported in December concerning AFinfo on Nikon Cameras and the fix was released in Exiv2 v0.27.2 on 2019-07-29. So, I'm optimistic that I'll be able to fix this for you and get into a future "dot" later this year. #646 |
|
I should have explained that the 273 shorts are what's stored in the Exif tag 0x0026 in the file: However, in reality it's a binary record in the MakerNote. I'll have to add a decoder to report the fields in that data. |
|
Thx, looking forward to it. In case it helps understanding this issue, I'm also providing a test image from a EOS 500D: IMG_7600 |
|
Thanks. That's very helpful. Now there are 48 SHORTS version '96'. There were 273 SHORTS version 536. So I'll probably need two decoders with a selector. For sure the cameras have different firmware versions: Perhaps the 50D/Rebel 18-200mm lens has a lot less sensors/focal points. I don't speak camera/photography, I'm a software guy! You have raised this issue at a good time. I'm writing a book "Image Metadata and Exiv2 Architecture". I could use this as a case study concerning MakerNote processing. #911 While I hope to deal with this issue soon, this is quite complicated and will take some time. There's a dot release due at the end of September. If I can't complete the code by code freeze at the end of August, it'll be in the release at the end of December. |
clanmills
added
enhancement
Assuming you meant 546 rather than 536, these are not versions. This is the |
|
Here are some notes about this. I'll probably edit this several times while I figure what's going on! Phil's excellent documentation is: https://sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html#AFInfo2 Raw Data:
This doesn't look painful. I'll investigate the code required this evening. |
|
@derselbst Thanks for your comment about the size of the chunk. You can see that I realised that this morning. So while you were writing, I was figuring this out! This is looking straight forward. I'm taking my grand-kids to the park today as they are off school and their parents are working. I'll continue this evening. |
|
Making progress: #982 |
|
I've made progress with this today. The code now handles AfInfo and AfInfo2. However it's not populating the arrays in AfInfo2. I didn't write Exiv2, so I have to read/explore the code to know what already exists. It appears that the decoder expects a "static/fixed" structure of fields. AfInfo2 populates arrays whose dimension is in the metadata. I haven't found another structure with this layout. I've tried to dynamically create the structure at run-time and haven't yet got that to work. I'm going to take a break from this. |
|
I've fixed to work with any number of points. Very pleased. Great end to the week. It reports Exiv2.Canon.AFInfo as always (with unsigned shorts), however instead of creating a new group Exif.CanonAF.xxx, it extends Exif.Canon.AF* with entries such as Exif.Canon.AFMode and Exif.Canon.Exif.Canon.AFAreaWidths which is an array of SSHORT. I've submitted a new PR #985 and closed #982 I expect this to be released in v0.27.3 scheduled for 2019-09-30. Your feedback and comments are welcome. |
|
Here's an image which uses multiple AF focus points. It's too big for github. exiftool reports them to be: https://drive.google.com/open?id=1kgiEWPQJSSXsEI3OqsbOXEETaDp4-EgP |
|
Thanks for the test file. I'll only use that image if/when we modify the print function for AFPointsInFocus and AFPointsSelected. I wonder if we have the data in the wrong order here. 560 and -8192 look like bit-masks. 0 doesn't. Thanks for finding Phil's code. Maybe @boardhead could explain this magic. Couple of puzzles. What is |
|
Parsing of those AFPoints is currently incomplete. |
|
This team-work stuff really works. I don't know why nobody uses it in the office! |
|
$val{2} is the value of tag with id 2. ie) NumAFPoints In Perl, an expression like $var{key} is the value in a hash lookup for the specified key. All of the tables in ExifTool are hashes, and the keys are the tag ID's. |
|
To answer a few more questions, the format is an array of 16-bit signed integers. You get the higher bit numbers since the array may contain more than one element. The calculation for the size of the array is just to calculate the number of 16-bit integers required to store NumAFPoints bits. The "+15" is because you need 1 word to store 1 bit, and (1+15)/16 is 1. |
|
Thanks, Phil. I think we have this nailed and working well. @derselbst figured out what you've just explained. |
|
Fix submitted in #988 |
|
While testing #988 I also tried to figure out the meaning of In any case, thanks again guys! |
|
I've made (mostly made up/conjecture) a comment about "PrimaryPoint" here: #988 (comment) |
|
I would guess that PrimaryAFPoint is the point that the camera used to actually focus the image. |
|
That sounds right, Phil. I got a Digital Rebel about 2004 and I think you could change the a red dot in the view-finder. On the metadata here, AFPrimaryPoint is singular, yet it is a bitmask of points. We're left guessing! |
|
I figured it out! The number of actually usable AF points does not only depend on the minimum aperture of the lens, it also depends on the lens itself (at least, in the Canon world). This has to do with the beam path within the lens. Some Canon lenses may not use certain AF points by design. This is indeed documented in the manuals of the camera. Those unusable AF points are reported as Perhaps it would be worth to rename that field to something like |
|
Well done. Now it gets more challenging. What are ValidPoints and how can it be different from NumPoints? And PointsSelected. Is there a way to "select" points? |
|
Ok, a bit of documentation to hopefully clarify this mess. Feel free to share or embed it somewhere where it fits.
Depending on See the following examples that are based on the EOS 5D Mark IV: Example 1The standard use-case: You take a picture by looking through the viewfinder. There you can use up to 61 phase-AF points: You see, I've selected a single AF point, i.e. the 29'th point. The lens I used was a good one, so no AF-points were disabled ( Example 2Again you look through the viewfinder. But this time you've selected multiple points which the camera may use for focusing. As you see, only a subset of selected AF points are actually used by the camera to focus the picture ( Example 3You take a picture by using the live-view of the camera. In the live-view screen, you have a single small rectangle that you can move around and use for focusing the picture: The camera still stores 63 AF points, but given the live-view setting, there is only one AF point available. Ofc, this is point number zero, which is both, selected and used to focus the picture. All the other AF points in that array are (thankfully) zeroed out to avoid to contain some uninitialized garbage. Example 4Now it's getting interesting. Again live-view, but this time using multiple AF points and you let the camera decide which one(s) to use. Surprisingly the 5D Mark IV now uses 63 AF points rather than only 61 as before. All of them are selected (that means "considered") when focusing the picture, but only a few of them are finally used to focus the picture. |
|
Thanks, Tom. I'll add this to exiv2.org which is machine-generated. There are external references to bloggs discussing MakerNotes and other useful resources. I'll modify the makernote page to reference this discussion. https://exiv2.org/makernote.html This will get done in September when I'm working on Exiv2 v0.27.3 (scheduled for 2019-09-30). |
Describe the bug
Exif.Canon.AFInfois misinterpreted asunsigned short. It should besigned shortthough. From my understanding this applies to both AFInfo and AFInfo2, because the AF coordinates originate from the image center (0,0), thus some of them will be negative.To Reproduce
Steps to reproduce the behaviour:
Provide image with which you observed the issue:
Executing
exiv2 -PEkycv 62878860-3c552580-bd2a-11e9-94c0-cd4617d1af80.JPGyieldswith insanely high numbers > 60000 . They should be negative.
Expected behavior
Exiftool reports it correctly:
exiftool -a -u -g1 62878860-3c552580-bd2a-11e9-94c0-cd4617d1af80.JPGDesktop:
Linux 4.12.14-lp151.28.10-default x86_64Additional context
BTW: Exiftool also reports which focus point(s) was/were used:
I cannot find this information in exiv2. Am I missing smth.?
The text was updated successfully, but these errors were encountered: