Hello @DDoS,

You're right, libvips will print int, rational and srational EXIF tags as numbers, but it uses exif_entry_get_value() for all other types. This string is internationalised, so it'll vary with things like locale, annoyingly.

EXIF support in libvips hasn't really been touched since the 90s, and it was pretty poor then :( And making changes now would probably break some old code somewhere.

We've talked a few times about designing a better system, but no one's done the work yet. I think the most recent suggestion was to add a new metadata item called exif-data-json which would just be a simple dump of the parsed exif as a chunk of JSON. It could include both i18n values and raw values.

Let's tag this as an enhancement issue for a new EXIF system.

Any other suggestions for a new and better way to handle EXIF are very welcome, of course.

In the specific case of GPSAltitudeRef, it's an int8u according to exiftool, but libexif says its EXIF_FORMAT_BYTE. We could modify vips_exif_get_int() to detect these, but as you say this could easily break something else (maybe single-character string-like fields stored as byte?).

--- a/libvips/foreign/exif.c
+++ b/libvips/foreign/exif.c
@@ -244,6 +244,9 @@ vips_exif_get_int(ExifData *ed,
                *out = (int) exif_get_long(entry->data + offset, bo);
        else if (entry->format == EXIF_FORMAT_SLONG)
                *out = exif_get_slong(entry->data + offset, bo);
+       else if (entry->format == EXIF_FORMAT_BYTE &&
+               sizeof_component == 1)
+               *out = *(uint8_t *) entry->data + offset;
        else
                return -1;

Yes, exif has:

typedef enum {
        EXIF_FORMAT_BYTE       =  1,
        EXIF_FORMAT_ASCII      =  2,
        EXIF_FORMAT_SHORT      =  3,
        EXIF_FORMAT_LONG       =  4,
        EXIF_FORMAT_RATIONAL   =  5,
    EXIF_FORMAT_SBYTE      =  6,
        EXIF_FORMAT_UNDEFINED  =  7,
    EXIF_FORMAT_SSHORT     =  8,
        EXIF_FORMAT_SLONG      =  9,
        EXIF_FORMAT_SRATIONAL  = 10,
    EXIF_FORMAT_FLOAT      = 11,
    EXIF_FORMAT_DOUBLE     = 12
} ExifFormat;

So we could just switch on that, but it'd almost certainly break things :( I think we just need something better.

I think the most recent suggestion was to add a new metadata item called exif-data-json which would just be a simple dump of the parsed exif as a chunk of JSON. It could include both i18n values and raw values.

I like this idea, perhaps the i18n values should be a separate field though? Only downside I see is that it would require some users (mostly C and C++ projects) to take on a JSON library dependency to parse the output. But if the goal is to keep this as a string field, I still think it's a better outcome than using a custom format that has to be parsed manually.

Yes, exactly, you could have eg.:

{
  "exif": {
    "ifd0": {
      "Orientation": "1",
      "Orientation-i18n": "Top-left",
      "XResolution": "72000/1000",
      "XResolution-i18n": "72",
...

Or I suppose the i18n values could be in a separate ifd0-i18n tag. It probably doesn't matter much.