Skip to content
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
Open

image/jpeg: correct for EXIF orientation? #4341

bradfitz opened this issue Nov 4, 2012 · 18 comments
Labels
Milestone

Comments

@bradfitz
Copy link
Contributor

@bradfitz 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
Copy link

@gopherbot 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
Copy link
Contributor Author

@bradfitz 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
Copy link
Contributor

@rsc rsc commented Dec 30, 2012

Comment 3:

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

Status changed to Thinking.

@nigeltao
Copy link
Contributor

@nigeltao 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
Copy link
Contributor

@mewmew 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
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 6:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 7:

Labels changed: added feature.

@robpike
Copy link
Contributor

@robpike robpike commented Aug 19, 2013

Comment 8:

Not happening for 1.2.

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

@robpike
Copy link
Contributor

@robpike robpike commented Aug 20, 2013

Comment 9:

Labels changed: removed go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 10:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Nov 27, 2013

Comment 11:

Labels changed: removed feature.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 12:

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

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 13:

Labels changed: added repo-main.

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 14, 2014

Comment 14 by artem@volkhin.com:

Any update on this?
@nigeltao
Copy link
Contributor

@nigeltao nigeltao commented Oct 14, 2014

Comment 15:

No news to report.
@Macilias
Copy link

@Macilias 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
Copy link

@edwvee 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
Copy link

@edwvee 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
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants