Skip to content

Sony A580 family: camera settings block is byte oriented but parsed as shorts #9469

Open

Description

@hennikul

Summary

For the Sony A580 family, Exif.Sony2Cs.* values are wrong. The camera
settings block of these models is an array of bytes, but Exiv2 parses it as
an array of big endian unsigned shorts, so every element is read at twice its
offset and each reported value is two unrelated bytes glued together.

The aspect ratio dialed in on the camera is one casualty: it lives at byte
0x0a of that block and is not reachable at all, while Sony2Cs.AspectRatio
reports a value read from somewhere else entirely.

Reproduce

A CC0 sample is in the raw sample database, shot at 16:9:

https://raw.pixls.us/data/Sony/DSLR-A580/RAW_SONY_A580.ARW

$ exiv2 -pv RAW_SONY_A580.ARW | grep Sony2Cs | head -6
0x0004 Sony2Cs      DriveMode                   Short       1  4121
0x0006 Sony2Cs      WhiteBalanceFineTune        SShort      1  258
0x0010 Sony2Cs      FocusMode                   Short       1  258
0x0011 Sony2Cs      AFAreaMode                  Short       1  384
0x0015 Sony2Cs      MeteringMode                Short       1  257
0x0016 Sony2Cs      ISOSetting                  Short       1  4097

DriveMode 4121 is 0x1019. The block (makernote tag 0x0114, undef[1536])
begins:

68 38 38 80 10 02 13 01 10 19 08 02 01 02 02 10
                        ^^^^^ bytes 8 and 9

Exiv2's element 0x0004 is read as a big endian short at byte offset 8, which
is 0x10 0x19 = 4121. The reported value is literally bytes 8 and 9 of a
byte array concatenated. Every other element is wrong the same way.

Byte 0x0a of that block is 0x08. ExifTool decodes this block as
FORMAT => 'int8u' and reads that byte as AspectRatio = 8, meaning 16:9,
which matches how the picture was taken. Exiv2's Sony2Cs.AspectRatio is
element 0x0055, i.e. byte offset 170, and reports 0.

Cause

sony2CsCfg and sony2Cs2Cfg in src/tiffimage_int.cpp both declare
{0, ttUnsignedShort, 1} as the element type, and sony2CsSet offers only
those two variants to sonyCsSelector. There is no byte oriented variant, so
models whose camera settings block is byte oriented cannot be parsed
correctly by either.

ExifTool calls that layout CameraSettings3 and lists it for the A33, A35,
A55, A450, A500, A550, A560, A580, NEX-3, NEX-5, NEX-C3 and NEX-VG10E, so
this is not specific to the A580.

Suggested direction

A third configuration with ttUnsignedByte elements and its own definition
table, added to sony2CsSet and chosen by the selector for these models,
would follow the existing pattern. I have not written a patch because I do
not know how you would prefer the selector to distinguish them, and I only
have the one sample of the family to test against.

Reported 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.

Disclosure: this investigation was done with AI assistance (Claude Code with
Claude Opus 5). I have verified the byte level claims above myself against the
linked sample.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions