Search code examples
exifandroid-camerax

'Corrupt' Exif data on Android Camera-X

I've been testing a migration to Android's new Camera X library and checking the EXIF data with exif $FILE. Some of the attributes are displayed, but the amount of values seems truncated & it displays an error:

Corrupt data
The data provided does not follow the specification.
ExifEntry: The tag 'ExifVersion' contains data of an invalid format ('ASCII', expected 'Undefined').

Photos from the same device using the Camera 2 API would show all the values and list the Exif Version as:

Exif Version | Exif Version 2.2

I thought that this was a bug with Camera X corrupting the data, but I just tried to read it with exiftool and it displays all fields correctly. On both Camera libraries (CameraX/Camera2), the Exif Version gets displayed as:

Exif Version : 0220

This is happening for me on multiple devices, both e.g. a Samsung Galaxy A01 CORE SM-A013M and a Nokia 8.1

Tried Googling for the error message from exif about invalid formats but couldn't find anything.

Is this a bug with Camera X, Exif or both? Or is it something I can safely ignore? (Assuming though that I do need valid Exif data :) )

Solution

  • The error message is correct: tag 0x9000 "ExifVersion" may only use the type UNDEFINED as per

    But any consumer can still support other datatypes, such as ASCII - if exiftool does not yield an error then it is most likely for your convenience, while at the same time you're unaware of that a violation to the standard has been encountered.

    The writer produces this bug: if following the standard UNDEFINED as datatype must be used, nothing else. One key difference between both datatypes is: one comes with a terminating byte, the other doesn't. Likewise using ASCII without a terminating byte is a bug, too - and on the field "ExifVersion" it's impossible to write the literal 0220 with the needed terminating byte when the field length is defined as exactly 4 bytes already.

    Effectively the difference hardly matters:

    • either I interpret the binary 0x30 0x32 0x32 0x30 as 4 bytes (as per datatype UNDEFINED) or
    • the literal 0220 (with or without a terminating 0x00, as per dataype ASCII).

    Even if I as consumer am still able to read it despite following the standard it should not pass by unnoticed. It's somehow like crossing a street while the traffic lights are red for you: it may work under certain conditions, but that doesn't make it okay.