jimp icon indicating copy to clipboard operation
jimp copied to clipboard

Autorotate based on exif not working

Open rkcth opened this issue 5 years ago • 7 comments

Both in the browser and in node, Jimp is not autorotating based on exif. I'm using Jimp.read(buffer), does autorotate not work with buffers?

Here's the typescript code let image = await Jimp.read(buffer); let photo = await image.cover( 1920. 1920, Jimp.HORIZONTAL_ALIGN_CENTER | Jimp.VERTICAL_ALIGN_MIDDLE, ); buffer = await photo.getBufferAsync(Jimp.MIME_JPEG);

the buffer then contains an image with the rotation exif information stripped out, but not rotated properly. This also happened on 0.13.0.

rkcth avatar Jul 30 '20 21:07 rkcth

The behavior I'm seeing is that jimp is rotating the image but preserving the exif data that says the image is rotated.

NigelKibodeaux avatar Aug 06 '20 00:08 NigelKibodeaux

I can confirm the behavior described by Nigel.

I load a picture from a buffer and resize it (I want to make thumbnails). The thumbnail is saved with the proper orientation in the raw image data (the picture is rotated so that the up is up, etc in the raw image data) but it retains the EXIF metadata that say the picture should still be rotated. So my thumbnail ends up misoriented.

Here's the relevant code:

    this.imgJimp = await Jimp.read(this.image); // <= this.image is a Buffer
    // *snip* some stuff to get proper values for maxW and maxH *snip*
    return this.imgJimp
      .resize(maxW, maxH)
      .quality(this.THUMBNAIL_JPEG_QUALITY)
      .getBufferAsync(Jimp.MIME_JPEG);

My source image is 90° to the right, with EXIF data saying to put it straight. My thumbnail is straight... with EXIF data saying to put it 90° to the left

(my wanted result is a straight thumbnail with no EXIF rotation data)

ddernon avatar Aug 11 '20 13:08 ddernon

Actually, since OP mentioned it might be a Buffer-specific issue, I tried the following and still had the problem, so it's not Buffer-specific:

    const dummyPicPath = path.join('/', 'dummy4242.jpeg');
    fs.writeFileSync(dummyPicPath, this.image);
    this.imgJimp = await Jimp.read(dummyPicPath);
    fs.unlinkSync(dummyPicPath);
    // then same "return" as in my previous comment

ddernon avatar Aug 11 '20 14:08 ddernon

Has anyone figured out how to overcome this or have an estimated fix date? This is causing a lot of problems for me right now.

jdpagley avatar Oct 21 '20 13:10 jdpagley

You could probably implement a JS workaround using stuff like ts-exif-parser and/or this https://stackoverflow.com/questions/41490122/strip-exif-data-from-image-node-js-addressing-a-possible-bug-in-the-original-v

I ended up implementing my thumbnailing thing in Rust. It seemed the cleaner way to go and I liked the speed improvement.

ddernon avatar Oct 21 '20 13:10 ddernon

No exif data is sometimes better than wrong exif. The 'ugly patch' I've used is to clear out the internal exif buffer

(jimp.bitmap as any).exifBuffer = undefined;

Right before jimp.getBufferAsync.

turpault avatar Feb 12 '21 23:02 turpault

I have the same issue. And for me 'v0.10.3' is the latest version that auto rotate images (and resize). From a EXIF meta tag to actual pixels that are rotated. Rotating the pixels is what I would like to achieve.
Anyone a suggestion to get this working in a newer version. I'm using the following javascript code:

jimp.read(sourceFilePath)
.then(image => {

	image.resize(1000, jimp.AUTO);
	image.quality(80);

	image.write(targetFilePath, () => {
		process.stdout.write("≈");
		resolve(true);
	});

})
.catch(err => {
	console.error(err);
	resolve(false);
});

qdraw avatar Mar 17 '21 18:03 qdraw