sony: read the A580 family camera settings block as bytes - #9470
Open
hennikul wants to merge 1 commit into
Open
Conversation
Fixes Exiv2#9469. The camera settings block of the A33/A55/A450/A580/NEX family is an array of bytes, but sonyCsSelector had no byte oriented variant to offer, so these models fell through to the short based sonyCsCfg. Every Exif.Sony2Cs value for them is two unrelated bytes glued together: on a DSLR-A580, Sony2Cs.DriveMode reports 4121, which is bytes 8 and 9 of the array read as a big endian short. Add a third configuration whose elements are bytes, select it by model, and name AspectRatio in it, which sits at byte 0x0a and was not reachable at all before. The remaining elements are now reported with their correct values under Exif.Sony2Cs3, awaiting names from anyone with the samples to verify them; ExifTool documents the rest of the layout as CameraSettings3. The model list is matched in full rather than by substring, because "NEX-5" would otherwise catch the NEX-5N, NEX-5R and NEX-5T, which are a different layout again and are parsed correctly today. Checked against CC0 samples from raw.pixls.us. AspectRatio now agrees with ExifTool on all nine of the affected models available there: DSLR-A450, A500, A560, A580, NEX-5, NEX-C3, SLT-A33, A35 and A55, the A580 being the one shot at 16:9 and the rest at 3:2. Output for DSLR-A200, A330, A380, A700, A900, NEX-5N, NEX-5R and ILCE-7M3 is byte for byte unchanged. DSLR-A550, NEX-3 and NEX-VG10E are in the model list on ExifTool's authority but I had no sample to confirm them with. AI disclosure: written with AI assistance (Claude Code with Claude Opus 5). I have reviewed it and take responsibility for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #9469.
The problem
The camera settings block of the A33/A55/A450/A580/NEX family is an array of
bytes, but
sonyCsSelectorhas no byte oriented variant to offer, so thesemodels fall through to the short based
sonyCsCfg. EveryExif.Sony2Csvalue for them is two unrelated bytes glued together.
On a DSLR-A580,
Sony2Cs.DriveModereports 4121. The block begins68 38 38 80 10 02 13 01 10 19 08 ..., and 4121 is0x1019, bytes 8 and 9read as a big endian short.
AspectRatioreally lives at byte0x0aand isnot reachable at all today.
The change
sony2Cs3Cfg, a third configuration whose default element isttUnsignedByte, added tosony2CsSetsonyCsSelectorselects it by modelExif.Sony2Cs3group namingAspectRatioat byte0x0aOnly
AspectRatiois named, because it is the only tag I could verify. Therest of the block is now reported with correct values under
Sony2Cs3andcan be named by anyone with the samples to check them; ExifTool documents the
layout as
CameraSettings3.The model list is matched in full, not by substring.
contains(model, "NEX-5")would also catch the NEX-5N, NEX-5R and NEX-5T, which are adifferent layout again and are parsed correctly today.
Testing
CC0 samples from raw.pixls.us, comparing a pristine build of
mainagainstthis branch.
AspectRationow agrees with ExifTool on all nine affected models availablethere:
Before this change none of them reported an aspect ratio, and every other
Sony2Csvalue was wrong.Output is byte for byte unchanged for DSLR-A200, A330, A380, A700, A900,
NEX-5N, NEX-5R and ILCE-7M3. NEX-5N is the only model of any of these that
appears in
test/data/test_reference_files, and it is deliberately not inthe list, so no reference output should move.
DSLR-A550, NEX-3 and NEX-VG10E are in the list on ExifTool's authority; I had
no sample to confirm them. They are currently misparsed either way, so
including them cannot be worse than leaving them out, but I am happy to drop
them if you would rather only ship what is verified.
Found while trying to read the in-camera aspect ratio for darktable, where
Canon and Olympus both work through Exiv2 and Sony was the odd one out.
I can add a test if you point me at a suitable sample to use.
Disclosure: written with AI assistance (Claude Code with Claude Opus 5). I
have reviewed it and take responsibility for it.