New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image/jpeg: correct for EXIF orientation? #4341

Open
bradfitz opened this Issue Nov 4, 2012 · 18 comments

Comments

Projects
None yet
8 participants
@bradfitz
Member

bradfitz commented Nov 4, 2012

JPEG files can embed EXIF metadata specifying one of 8 mirroring+rotation options.  Only
2-3 of these are in common use, from people holding their phones sideways when taking
pictures.

It would be nice of the image/jpeg package could, perhaps optionally, correct for these.

Camlistore will be doing it on its own, but it seems like something the image/jpeg
package is in a good position to do automatically.

It's probably only safe to do the left-90 and right-90 ones automatically (and only when
width & height change), so users can detect whether the operation has already been
done and not apply the transformation again, as orientation-fixing code has to do anyway
(because you can't trust whether upstream software in the wild fixed the metadata for
you when it flipped-and-resaved the image, so you also have to check the before &
after dimensions).

If we want to do this in image/jpeg, I've attached a screenshot of the 8 modes and a
tarball of 16 JPEG files: 1 for each mode without EXIF, and 1 for each mode with the
Orientation field set to "fix" the image back to a lowercase eff letter.  The
f files are written on 8x8 pixel boundaries, so we can do pixel-wise compares in tests
safely.

Attachments:

  1. exif-orientations.png (22969 bytes)
  2. f.tar (30720 bytes)
@gopherbot

This comment has been minimized.

gopherbot commented Nov 6, 2012

Comment 1 by jsummers3456:

Did you intentionally put JFIF segments in your sample files? According to the JFIF
specification, JFIF files always use top-left orientation. So, the orientation of your
images seems to be ambiguous. I don't know whether there's a standard way to resolve it.
@bradfitz

This comment has been minimized.

Member

bradfitz commented Nov 8, 2012

Comment 2:

JFIF segments weren't intentional.  I made the original image in Gimp and made each flip
and mirror by hand (also in Gimp), saved them all, and then used the "exif" tool in
Debian to create the EXIF header and force the Orientation fields.
Both Nautilus and OS X render all the images in the same way, fwiw.
@rsc

This comment has been minimized.

Contributor

rsc commented Dec 30, 2012

Comment 3:

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

@nigeltao

This comment has been minimized.

Contributor

nigeltao commented Feb 18, 2013

Comment 4:

There is a larger concern of decoding all of a JPEG's EXIF metadata. The right API might
be for image/jpeg to provide EXIF data, and image/draw to provide 90-degree rotations.
This is analagous to jpeg decoding to an image.YCbCr; if you want an image.RGBA then it
is the caller's responsibility to explicitly perform the conversion (via image/draw). On
the other hand, single-pass decode-and-rotate can be more efficient.
I'm wary of adding new API so close to an API freeze. I'm marking this bug as out of
scope for the Go 1.1 timeframe.

Labels changed: removed go1.1maybe.

@mewmew

This comment has been minimized.

Contributor

mewmew commented Feb 20, 2013

Comment 5:

EXIF orientation is notably hard and it has been incorrectly implemented a number of
times. [1]
Just pointing it out so that it can be implemented correctly for Go, once and for all.
[1]: http://recursive-design.com/blog/2012/07/28/exif-orientation-handling-is-a-ghetto/
@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 6:

Labels changed: added go1.2maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 7:

Labels changed: added feature.

@robpike

This comment has been minimized.

Contributor

robpike commented Aug 19, 2013

Comment 8:

Not happening for 1.2.

Labels changed: added go1.3maybe, removed go1.2maybe.

@robpike

This comment has been minimized.

Contributor

robpike commented Aug 20, 2013

Comment 9:

Labels changed: removed go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 10:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 11:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 12:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 13:

Labels changed: added repo-main.

@gopherbot

This comment has been minimized.

gopherbot commented Oct 14, 2014

Comment 14 by artem@volkhin.com:

Any update on this?
@nigeltao

This comment has been minimized.

Contributor

nigeltao commented Oct 14, 2014

Comment 15:

No news to report.
@Macilias

This comment has been minimized.

Macilias commented Apr 9, 2018

Hi, had the same problem, fixed it by providing a function which replaces the original image with a copy of referenced image (jpg, png or gif). The replaced copy has all necessary operation, which are needed to reverse its orientation to 1, applied. The result is a image with corrected orientation and without exif data.
You can find it here:
https://github.com/Macilias/go-images-orientation

@edwvee

This comment has been minimized.

edwvee commented May 31, 2018

That's sad that there is nothing has been solved yet. Even no mentioning of that in official guides and etc.

@edwvee

This comment has been minimized.

edwvee commented Jun 2, 2018

Wrote image.Decode replacement handling EXIF orientation: https://github.com/edwvee/exiffix

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