Open derselbst opened 3 years ago
alexvanderberkel
commented
3 years ago Hi Tom,
thanks for reporting the issue. We have just released RC2 of v0.27.4 and are heading towards GM this or early next month. The latest branch to work with is the maintanence branch as you assumed correctly. There has been some work on new tags from Canon cameras within this release. The file which you need to look at is canonmn_int.cpp. That is where the Canon tags are being handled.
Cheers, Alex
hassec
commented
3 years ago Hi @derselbst, I thought I could help and quickly provide a fix since I did similar work recently for the nikon maker note....
However, for some reason the CanonAFInfo is being decoded differently from what I expected from my current exiv2 knowledge. There is a special TiffDecoder implemented in tiffvisitor_int.cpp just for this tag.
My current guess is that it maybe has something to do with the dynamic size of the AFInfo tag?
It's easy to quickly add a few lines to tiffvisitor_int.cpp that will lead to exiv2 printing the info, but I'm a little hesitant to just add code to a construct that I've not yet completely understood.
Hoping @clanmills knows more and can enlighten me :blush:
derselbst
commented
3 years ago @hassec Don't worry. I already had a look into the code and found it quite easy to do. Here's my branch. I'll need a few more days to test it. Not sure why it's handled differently. Probably due to it's dynamic size.
clanmills
commented
3 years ago Welcome back, Tom @derselbst I though we worked on something like this a couple of years ago. It's tag 0x0026. My brain is a little flattened from the effort to ship v0.27.4 RC2 yesterday.
Can you submit a PR to the 'main' branch which I will set up on Sunday morning. 'main' will be the development branch for v1.00 which is scheduled for 2021-12-15.
hassec
commented
3 years ago @hassec Don't worry. I already had a look into the code and found it quite easy to do. Here's my branch. I'll need a few more days to test it. Not sure why it's handled differently. Probably due to it's dynamic size.
Ok glad to hear that you are on it! That's exactly the change I did as well.
But I'm hesitant to continue to just add to the canon MakersNote construct without fully figuring out what's going on.
Because, I think we should include a bit of cleanup as well, since I think the tagListAf.. functions in canonmn_int.cpp are unused.
In any case, @clanmills suggestion is probably the best, and then we can continue development once there is a PR ;)
derselbst
commented
3 years ago Can you submit a PR to the 'main' branch which I will set up on Sunday morning.
Ok, I'll do. No hurry :)
I think we should include a bit of cleanup as well, since I think the tagListAf.. functions in canonmn_int.cpp are unused.
Yes, I've seen them. I'll think about how they can be integrated.
clanmills
commented
3 years ago I've set up branch 'main' and bumped the revision numbers. When PR #1545 merges, we're good to start on Exiv2 v1.00.
@derselbst Tom. I've invited you to join Team Exiv2 in order to collaborate on this issue. If you work in our repository, It's easier for us to review your changes. @hasssec and I can update your PR and this makes life easier when adding new scripts and images to the test suite. I hope you will continue to contribute to Exiv2, however it's fine if you ask me to "uninvite you" when this work is complete.
clanmills
commented
3 years ago I was working on my book and discovered I had written the following about 6 months ago:
This decoding function decodeCanonAFInfo() added to TiffMappingInfo manufactures the new tags. Normally, tags are processed by the binary tag decoder and that approach was taken in branch fix981_canonAf. #981 and #988 However, the binary tag decoder cannot deal with AFInfo because the size of some metadata arrays cannot be determined at compile time.
We should support decoding AFInfo in v1.00, however we should NOT auto-port this PR. We can avoid having to explicitly delete tags from the metadata before writing by adding a "read-only" flag to TagInfo. This would break the Exiv2 v0.27 API and has been avoided. There is an array in decodeCanonAFInfo() which lists the "manufactured" tags such as Exif.Canon.AFNumPoints. In the Exiv2 v1.00 architecture, a way might be designed to generate that data at run-time.
More work ahead. Worth the effort.
Hello,
I have noticed that Canon stores additional rotation information in the AFInfo chunk. Neither Exiv2 nor ExifTool currently seem to handle this information. I would like to share and document that information so we can add support for this.
Canon's AFInfo chunk contains a list of AF focus points that were used, selected, and in-focus when the image was taken. Depending on the camera in use, this may look like so:
Canon's software DPP supports rotating images by an arbitrary amount of degrees. [This is not be confused by the simple +- 90 degree rotation that you know from every other image editor!] If you rotate the image by that amount, it influences the AF Point mask. Here you see a picture of the same image rotated by 7.25 degrees in a mathematically negative (i.e. clockwise) manner:
I'm attaching a ZIP file that contains some example easter egg images. The applied (clockwise) rotation in degrees can be derived from the file name of the image. rotation.zip
When we search for the difference in those images, we will find that the very last two bytes of the AFInfo chunk differ between all the images.
Exiv2 already does a good job in parsing the AFInfo chunk and will tell you what's inside. However, the last 6 bytes are missing. While I still have no clue what the sequence
ff ff 00 00means, I can tell for sure that in this example the byte sequence3c 8cdefines the rotation. From my experiments with DPP4 I can tell, that this should be interpreted as little endian unsigned short. This yields a value of0x8C3C = 35900. Since we are dealing with image1.JPG(an image, that was rotated 1 deg clockwise), we receive a rotation of35900 / 100 = 359 degrees. This is the mathematically positive (i.e. anti-clockwise) rotation that should be applied to each and every individual AF rectangle, whose locations are defined by their coordinates reported byAFXPositionsandAFYPositions.If that rotation is not applied, the AF Mask might look very strange like:
So, it would be really great if Exiv2 could be expanded to report the correct rotation in degrees. I assume you guys are quite busy with other topics. If you let me know on with branch this should be implemented (I assume 0.27-maintenance?), I will try to get it working myself. (This may take some time though.)