Hey.
Gives an error when trying to read exif data from .avif format

Error: Invalid EXIF data: buffer should start with "Exif", "MM" or "II".

Does this library not support avif parsing?

Code

  const sharpImage = sharp(src, { animated: true });

  sharpImage.png({ quality: quality });

  sharpImage.withExif({
    IFD0: {
      Software: `sharp:${quality}`,
    },
  });

  sharpImage.keepMetadata();

  sharpImage.keepExif();

  const buffer = await sharpImage.toBuffer();

  const { exif } = await sharp(buffer).metadata();

  console.log(exif?.toString());

  try {
    if (exif !== undefined) {
      console.log(exif.toString().substring(0, 2) === "II");
      console.log(ExifReader.load(exif));
    }
  } catch (err) {
    console.log(err);
  }

Buffer to string

II↕☺♥☺☺→☺♣☺b☺♣☺(☺♥☺☻1☺☻ r‼☻♥☺☺i�♦☺|x2☻�♥x2☻�♥sharp:80♠�♦0210☺�♦☺☻♥�♦0100☺�♥☺��☻�♦☺�☻♥�♦☺ ♥

Exception

Error: Invalid EXIF data: buffer should start with "Exif", "MM" or "II".
    at module.exports (\node_modules\exif-reader\index.js:8:13)
    at test (\vite.config.ts:130:50)
    at async FSWatcher.<anonymous> (\vite.config.ts:102:5)

If you use this project with typescript, you have to create a declaration file every time to prevent this error:

Could not find a declaration file for module 'exif-reader'. '/home/Code/node_modules/exif-reader/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/exif-reader` if it exists or add a new declaration (.d.ts) file containing `declare module 'exif-reader';`

It will be easier to add type definitions directly to this project instead of maintaining a mirror in the already too large DefinetelyTyped (@types) project.

e.g the following top image contains EXIF metadata
http://www.w3.org/MarkUp/Test/xhtml-print/20050519/tests/A_2_1-BF-01.htm
but triggers an exception.

'Invalid EXIF data: buffer should start with "Exif".'

If Exif offsets happen to be random garbage - package tries to split at those random positions without validation. This will cause "Out Of Memory" error and process stop node itself.

I'd suggest as first command in readTag function add validation of abnormal valueOffset and numValues:

function readTag(buffer, offset, bigEndian) {
...
    // Prevent damaged Exif data to cause Out Of Memory
    if (valueOffset >= buffer.length || numValues > 1000000 || valueOffset + numValues * valueSize >= buffer.length)
      throw new Error("Damaged Exif data");

numValues > 1000000 (just assumed very large number) - but without this check - last comparsion may not always work - it can rollower.

Attached damaged header Exif information
damaged_header.zip

trying to read a buffer created using:
var exifreader = Npm.require('exif-reader');

var buf = Buffer.from(fileObj.blob, 'binary');
var meta = exifreader(buf);

Use standard Exif group and tag names generated from Exiv2 metatdata

Note: This is a RFC and not a real issue. My intention is to get
feedback about an idea I had when tried to solve my own issue #27 for better
Typescript support.

While working on this issue I noticed some things that made me scratch my head

• where could I find an official Exif spec?
• why are tags distributed into different groups?
• why do we have the same tag name for different tag ids?
• what are the correct types? Where are they specified?
• why are some tags missing and are accessible only by tag id?

So I spent some time looking at exiftool
which seems to be the original inspiration to this project.

Then I found the nice Exiv2 project with
a working link to the Exif spec and
a well structured list of all standard Exif tags together with type information.

When I realised that the exiv2 cli was already installed on my machine, I used it
to compare the ouptut of exiv2 and exif-reader with exiv2 -p e some.jpg.

IMHO the exiv2 project is trying to follow the spec one to one, while the exiftool project
diverges a bit. For example the tag 0x0132 is called DateTime in Exif and Exiv2, but ModifyDate
in exiftool and exif-reader. Exiftool lists tags that are not found in the specs.
The exiv2 project provides structured access to the data type of each tag, my
original motiviation for starting all this.

So my proposal is, can we just generate the tags.js file and the type definition index.d.ts
based on the metadata from eviv2? That would give us some benefits

• standard group and tagnames, reuse of the eviv2 documentation
• a more uptodate list of tags
• automatic generated typescript types

It also has some drawbacks:

• some tag names would change (e.g. ModifyDate to DateTime) so this
  is a breaking change tha needs a major (2.0) release
• non Exif tags (e.g. InkSet, InkNames or FaxRecvParams) now no longer have a tag name (but would
  still be accessible by tag id if they are actually inside a file)
• dependent project must apply changes when upgrading (easy with Typescript support)

I prepared a branch of my proposed change. Please have a look.

I think this change would align this project with the Exif Spec,
but I fully understand that this is a breaking change that will cause effort for users of this project.
In most cases it's just adjusting tag names. The following table of changed tag names
will help with that. Only if someone relied on the edge case, when a file really contains
different values for different tags with the same name (e.g. WhiteBalance),
they will experience a behavioural change.

Duplicate Tag Names

This is most probable a bug in exif-reader, as those tags would return wrong results if
they exist in the same file:

Changed Tag Names

New Tag Names

Non standard Tag Names (removed)

A sampling of those values on https://exiftool.org/TagNames/EXIF.html indicates that they are either
offsets to vendor specific IFDs or are not part of any IFD (basicly undocumented on exiftool)

According to the spec, exif only supports ASCII.

2 = ASCII An 8-bit byte containing one 7-bit ASCII code. The final byte is terminated with NULL.

Yet in practice, a lot of tools write UTF8 text into fields such as ImageDescription.

My suggestion would be to optionally support different charsets when decoding exif type 2.

If that's a change you're willing to accept, I'd gladly submit a PR.

Hi there!

I just ran into the same issue as #11 ("Buffer must start with Exif") when using exif-reader on the "exif data" from a PNG. I'm using sharp to extract the metadata (as per the example in that other thread)

const sharp = require('sharp');
const exifReader = require('exif-reader');

sharp('example.png')
  .metadata()
  .then(({ exif }) => {
    const exifProperties = exifReader(exif);
    console.log(exifProperties);
  });

is this supposed to work? Is exif-reader capable of reading the exif data coming from a PNG? I'm assuming the error is thrown because of the format differences between exif data in JPEGs vs "exif" data under metadata chunks in PNGs? 🤔

Having tested several node/js exif parsers there appears to be a bug in your implementation.

Certain Images report having an Orientation of 6 when all other readers report a value of 8. I'm not sure why this would be but I have been able to confirm that it is yours that is incorrect as transforming the resulting image based upon the your retrieved Orientation value shows an incorrectly rotated image.

Currently dates are always parsed in the local timezone, but since that changes it's unlikely to be what you'd actually want. Would you be willing to accept a PR for working with dates in UTC so it'd always serialise to the same time across timezones?

Relevant source code: https://github.com/devongovett/exif-reader/blob/master/index.js#L132-L149

Hi.

In the function parseDate, date.setUTCMonth() is called after new Date() (means current local time).
But, if the current date is 31st and the parsing value is like "2016:09:17 09:36:23",
then date.setUTCMonth('09'-1) cannot change the month to September but October since the day
has been set to 31st in the constructor. So, the parsed day is "Mon Oct 17 2016 18:36:23"

I think if the value date is initialized not new date(), but something fix day time like
new Date(2001,0,2,0,0,0,0); (Jan, 2nd 2001 00:00:00 in the local time),
this illegal value will not be occurred.

You can easily reproduce if new Date() changes to new Date(2016,11,31,23,59,59,0); for example.

The current export of the type definition in index.d.ts looks like this:

export default function exif(buffer: Buffer): Exif;

However, the current implementation in index.js does not export any default. The type definition should actually look like this (similar to the old type definitions):

declare function exif(buffer: Buffer): Exif;
export = exif;

or you need to adapt the exports in index.js appropriately.

When I import the library using import exifReader from 'exif-reader'; I will get following runtime error:

(0 , exif_reader_1.default) is not a function

It only works when I import and use it the following way:

import * as exifReader from 'exif-reader';

const metadata = await sharp(file).metadata();
 // @ts-ignore
const exif = exifReader(metadata.exif);

(I cannot set "esModuleInterop": true in tsconfig due to some other library.)

Hi,

great piece of code. Works well with images. however I was looking into getting exif data from video formats. Do you know anything about it? I would love to make that work.