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.

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.

Comment 3:

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

Status changed to Thinking.

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.

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/

Comment 6:

Labels changed: added go1.2maybe.

Comment 7:

Labels changed: added feature.

Comment 8:

Not happening for 1.2.

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

Comment 9:

Labels changed: removed go1.3maybe.

Comment 10:

Labels changed: added go1.3maybe.

Comment 11:

Labels changed: removed feature.

Comment 12:

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

Comment 13:

Labels changed: added repo-main.

Comment 14 by artem@volkhin.com:

Any update on this?

Comment 15:

No news to report.

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

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

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

Sorry, I know this isn't the spot for it, but if anyone needs a workaround -

package main

import (
	"github.com/disintegration/imaging"
	"github.com/rwcarlsen/goexif/exif"
	"github.com/rwcarlsen/goexif/tiff"
	imagego "image"
	_ "image/jpeg"
	"log"
	"os"
)

func main() {
	f, err := os.Open("test.jpg")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()

	x, err := exif.Decode(f)
	if err != nil {
		// EOF no exif
		log.Fatal(err)
	}

	tag, err := x.Get(exif.Orientation)
	if err != nil {
		// tag not present
		log.Fatal(err)
	}

	// reset for image decode
	off, err := f.Seek(0, 0)
	if err != nil {
		log.Fatal(err)
	}

	if off != 0 {
		log.Fatal("Not at beginning of file.")
	}

	img, _, err := imagego.Decode(f)
	if err != nil {
		log.Fatal(err)
	}

	if tag.Count == 1 && tag.Format() == tiff.IntVal {
		orientation, err := tag.Int(0)
		if err != nil {
			log.Fatal(err)
		}

		log.Println(orientation)

		switch orientation {
		case 3: // rotate 180
			img = imaging.Rotate180(img)
		case 6: // rotate 270
			img = imaging.Rotate270(img)
		case 8: //rotate 90
			img = imaging.Rotate90(img)
		}
	}
}

After 10 years and the issue is still there

We could have a little party Nov 4, 2022. 😆 Seriously, I saw some photos on my kids school website with the orientation wrong last week and thought "oh, they must have that EXIF bug." I would be surprised if that website was Go powered though. Seems like a common enough bug that it should really be snipped out.

Four days away from the big anniversary! 🎉🎊🥳 Arrived here fixing this bug for a photo upload / thumbnail service. Good to see that it has a long pedigree. While there was some initial reluctance to fix this because the exif decode complicates the interface, would it not be possible to handle rotation as a loss-less operation within the current interface?

Yeah, I think someone just needs to find a weekend to sit down a write a good patch.

I just ran into this "bug", and found this issue.
Hasn't been fixed yet, surprised 😭

The thing is how do you define the API with no compatibility breakages.
Do you just assume you're always supposed to rotate, period?

Yes, I think ignoring the EXIF rotation was always a bug, and no one ever wanted it.

But then everyone who is handling this after the fact (rotating the output after the decode) will be broken by the fix.

@TACIXAT since you are using imaging, how about simply calling imaging.Decode(f, imaging.AutoOrientation(true))?

I have come across another solution from @disintegration, which was written 7 years ago and can be found at https://github.com/disintegration/imageorient. It is unfortunate that many of the Go libraries related to image processing appear to be inactive. It would be beneficial to incorporate this type of solution into the standard library and ensure its maintenance.