-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for FocusPosition (Tag9402) in Sony RAW files (ARW) #582
Comments
I've copied your file here: http://exiv2.dyndns.org:8080/userContent/testfiles/582/ I wonder how Phil performs this trick! In this table: He shows Exif tag: 0x9206 | SubjectDistance which we also support. However that tag is not in your file! We'd report if were there! Is this urgent? We're about to go into code-freeze for Exiv2 v0.27 which is scheduled to be released on December 28. A puzzle for 2019. There's a discussion here which adds to the confusion in my mind. http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=7852.0 |
0.27.1 would be enough, but I would love to have support for it and add it in darktable so I have correct lens corrections. It looks like this is calculated by the FocusDistance2 and FocalLengthIn35mmFormat values. http://u88.n24.queensu.ca/exiftool/forum/index.php/topic,3688.0.html The last post has the formula. The first 1.5 is the crop factor for APS-C so it should not be used and FocalLengthIn35mmFormat should be used for the calculation. |
Andreas: I see Phil supports "Composite" Tags which are pseudo tags derived from other metadata: https://sno.phy.queensu.ca/~phil/exiftool/TagNames/Composite.html
I didn't see the formula to calculate this in the link you gave, however I did find this https://www.plymouth.ac.uk/uploads/production/document/path/3/3754/PlymouthUniversity_MathsandStats_outreach_lenses.pdf Exiv2 doesn't have "composite tags". Some metadata is protected and cannot be changed. For example the pixel row count Exif.Photo.PixelYDimension. So we could have "composite tags" which cannot be directly changed. However "cooking up" metadata is a bad idea. Lens recognition generates more queries than anything else. The metadata concerning a lens is usually an integer in the makernotes and the same number is often used for several lenses. So, we have to deduce the lens by inspecting other metadata. For Exiv2 v0.26, I added a file ~/.exiv2 to provide a simple lookup: http://dev.exiv2.org/projects/exiv2/wiki/Lens_Recognition_in_Exiv2_v026_(and_later)/ The lens recognition code is written in C++. I have a long standing ambition to embed a language interpreter (eg ChaiScript) to enable users to modify lens recognition. Exiv2 could fetch updates to the scripts from exiv2.org. I've never had time to undertake that work. We could generate "derived tags" with such a feature. I don't have good news for you. The plan for "dot" releases are security updates for the next couple of years. Exiv2 v0.28 will "modernise" the code to C++11 (or later). So we want to actively maintain Exiv2 v0.27 with security fixes while performing brain surgery on the code base. We want to write a new tiff parser to support BigTiff (64 bit tiff). The tiff parser is the heart of Exiv2 as Exif and Raw data are encoded in tiff format and embedded in the image. I'll be 68 next month, and after 10+ years of service to Exiv2, want to reduce my effort to provide time for other hobbies such as running, travelling and music. I've assigned this issue to Milestone "Exiv2 v0.28" and Team Exiv2 will decide how to handle your request. I know you will be disappointed in my reply, however I cannot commit other people to deal with this. The Open Source Community are engaged in a discussion about supporting Canon's new CR3 format. Canon have "stone walled" our requests for information. Canon cooperate with Adobe and others, however the Open Source Community will have to "reverse engineer" the format. As you know, the road of an open-source developer is long and winding! darktable-org/rawspeed#121 (comment) |
Quoting the JosR from the exiftool forums:
So this is calculated from the "FocusPosition" which seems to be a real tag. Which means if that is exposed, I could use this in darktable to do the calculation there :-) |
My guess would be it is "Sony Tag9402 Tags": https://sno.phy.queensu.ca/~phil/exiftool/TagNames/Sony.html |
So if I would get Exif.Sony.FocusDistance or whatever the tag would be, it could calculate it as:
|
Yes. I saw that message about 0x0020. We don't seem to know about that one. I'm up to my neck in debugging an ASAN issue on Ubuntu 14.04 with Clang 5.0.0 and I have three 32 bit issues to investigate for RC3 (which is scheduled for Friday). I promise to look at the 0x0020 business and see if I can safely get that into 0.27. If I get you the "raw" data and you finish the job, that's a great handshake. I'll give you an update later in the week. |
Awesome, thanks Robin!!! |
Good News. I've found/fixed the clang/ubuntu14.04 horror and to celebrate I'm looking at your stuff. I've made a little progress. I will meet with Luis (on Slack) this evening to talk about RC3. He might volunteer to look at your issue while I finish the 32 bit weirdos. I can find 0x2027 "FocusLocation":
What makes you think it's in tag 0x9402? When I recursively dump your file, I see:
I can extract the 400 bytes at offset 12098 with dd and format it with dmpf (my home-made od on steroids).
|
I think FocusLocation is where in the image the focus was set. The first two values look like the image size and then the position in the image. I've looked through the values of https://sno.phy.queensu.ca/~phil/exiftool/TagNames/Sony.html The Tag904* seem to be latest additions and that made me guess it is one of those for the Sony a7 cameras. However I'm no expert in that area ... The value in the RAW for FocusPosition is 140 (0x8c). Doesn't seem to be in that dump. |
Together we're going to solve this! What fun. We're both in the right place.
400 bytes What a coincidence? I don't think so. We're close. |
I've looked in Phil's code Sony.pm and the data is encrypted. Phil thanked David Coffin (dcraw), so I looked at his code, and found his decoder in C (I've pasted it below). I suspect that when we decrypt the 400 bytes, we'll discover it's an IFD (tiff dictionary). I added a print statement to Phil's code and I believe the key is 1144201745. However he's using this to decrypt 42836 bytes from SR2SubIFD. I'm lost. I don't know what's going on! Looking in the Exiv2 source, I don't see any evidence that this decoder is present. So, for now, this data appears to be hidden from Exiv2. I wrote a little command-line decoder. This doesn't generate the data that Phil shows in his We can't add this to Exiv2 as we're only a couple of days from code freeze for Exiv2 v0.27.
|
I thought this was easier to get but I understand if it needs much more changes that it needs to be postponed. Thanks for looking into it! |
The FocusPosition2 tag in the sample ILCE-7M3 file is in Sony tag 0x9402, which is enciphered using a simple substitution cipher that I uncovered (not encrypted using the algorithm mentioned that was uncovered by David Coffin). The decipher formula is simply out = (in * in * in) % 249 for each byte. Many other Sony tags use this same cipher. Once deciphered, the data is a straight binary structure (not an IFD). Some other models store FocusPosition metadata in tag 0x9404, which is enciphered in the same way. However, yet other models store the FocusPosition in tag 0x0020, which is not enciphered or encrypted, but for some models this is formatted in a proprietary directory structure which requires specialized decoding. Edit: Sorry, the formula I gave is for enciphering. Deciphering is the reverse. |
Thanks, Phil. I hope everything's good with you. We're on track for v0.27 on 28 December. And that's me finished with C++. I'm going to deal with users and releases and stuff going forward. Before I went hunting and found the DC code, I thought it was a simple lookup/substitution filter. It's not much more than that. Incidentally, I still haven't dealt with Exif > 64k in JPEGs and read your comments about that and noted them here. http://dev.exiv2.org/issues/1232 Do you have a sample JPEG that has > 64k Exif data? |
@cryptomilk This isn't going into Exiv2 v0.27 which will be released on 28 December 2018. I've implemented Phil's decoder as follows:
The encrypted data that I found in your file is exactly as reported by Phil and I believe I've decrypted it correctly:
Exiftool -v5 output:
|
Hi Robin, Your deciphered data is correct up to byte 100 or so, and after that is hasn't been deciphered. Here is a sample mult-segment EXIF file for you: http://130.15.24.88/~phil/tmp/multi-segment_exif.jpg |
I've fixed the code. I was read/writing And thank you for the test JPG with Exif data > 64k. I suspect implmentation will be easy. |
@cryptomilk I've done a lot of work this week on #646 and learned lots about the TiffReader. I'm confident that I know how to fix this issue in Exiv2 and assigned it to Milestone 0.27.1 (scheduled for 2019-03-31). Thank You very much for the work you have done on Exiv2 (and libssh). I'll update this issue report with progress on the implementation. |
Awesome, thanks! |
Is this still planned for 0.27.1? |
Unlikely, given Robin wants to release 0.27.1 it by the end of March and
no one actively working on this.
Andreas Schneider <notifications@github.com> writes:
… Is this still planned for 0.27.1?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#582 (comment)
|
Then you should change then milestone :-) |
Indeed, moved to the next one. |
Thanks @cryptomilk That's a splendid offer. We're in Scotland that weekend on family business that cannot be changed. I attended LGM in London in 2016 and gave a remote presentation in Rio in 2017. That's a real pity as I would very much like to meet you. Thanks @D4N. I'm going to focus on the release and website. Once that's working, I'll investigate patches for #646 and #582. You'll be really impressed with how this is achieved. Andreas Huggel's design of the TiffVisitor is ingenious. My aim is to stick to the schedule and release v0.27.1 at the end of March. #646 and #582 are lower priority and can be deferred. |
I feel for you Robin, and sympathize with your git frustration. |
@clanmills I can give you a guide through git (video chat), if you're interested :-) |
Phil: Yip, it's almost impossible to understand git on your own. I talked to the cat about it, but she doesn't get git either. @cryptomilk Thanks. I'd like to take up your offer and here's my suggestion. I fixed something yesterday for somebody and I'd like to submit a PR to branch 0.27-maintenance. It's a one line fix. Tomorrow, I'd like to update the test harness to block a regression. So, on Sunday evening could you "talk me down" (give me the commands)? I'll type them into the computer. I'd like to finish 0.27.1 RC1 early next week. So, if I understand your recipe, I can submit PRs for 3 or 4 matters which are to be fixed for 0.27.1 RC1. I've sent an invitation to join the Exiv2 Slack channel. Or we can chat on Skype, or Messenger or even the phone! Let me know. Thanks for offering to help me with this. |
Folks I've reduced git to 5 commands and wrote them on a little card. The weird brown marks were added by the cat (don't ask how). I hope to get the fix for this issue (FocusPositionARW) into v0.27.2 which is on-track to ship on 2019-06-30. I'll do the code for this in early June when I get back from Scotland. |
I've almost got this working and I will submit a PR which passes the test suite. I don't believe the decrypt is working correctly. I've successfully added the binary array handler. Decryption code
This isn't correct. When it decodes the data from test file, the decoded data is similar to Phil's. However it's not the same! Adding a binary array handler:
I hope we can get this fixed for Exiv2 v0.27.2 |
I'm looking forward to v0.27.2 |
Your formula is correct. Are you perhaps enciphering instead of deciphering? I think you need to reverse the direction of your cipher. |
@boardhead Thanks for your input. It must be something like that, however I haven't discovered my blunder yet! I want to release v0.27.2-RC1 today or tomorrow and spend more time on this puzzle next week. We're going to Normandy on Friday to run in the D-Day Half Marathon on Sunday. |
Try changing this line
to this
|
@boardhead You are a Genius. Looking forward to meeting in Canada in July 2020. Thank You very much.
And ExifTool reports:
|
@cryptomilk The code for this has been submitted to branches 'master' and '0.27-maintenance'. Could you test this, please? If you're happy, please close this issue. I've enjoyed working with you and @boardhead on this issue. I always enjoy working with @piponazo and @D4N. |
@cryptomilk Are you OK for me to close this? The fix will ship in 0.27.2 which is PR #940. I hope to release 0.27.2 today. |
Yes, I've already implemented support for it in darktable! :-) |
Thanks!!! |
Yes. I remember looking at your code in darktable that uses the macro Very pleased with how everything has worked out and how well we've all pulled together on this issue. |
Please add support for reading the FocusPositon from ARW files.
This should be in Tag9402
I can't read them with exiv2, it is needed to calculate the FocusDistance the correct vignetting for lensfun.
If you need an example file: https://xor.cryptomilk.org/darktable/ILCE-7M3/ColorCheckerSG/2018-10-17__7M34864.ARW
[UPDATE] Change from FocusDistance to FocusPosition which is a real tag.
The text was updated successfully, but these errors were encountered: