Resizing an image strips EXIF data about vip

[foresmac]

The problem is that the standard image library doesn't read (or write) any EXIF data, so none of the imaging libraries support it either. Looks like our best bet is to read the orientation field and rotate the image before resizing.

Rough sample code:

import "github.com/rwcarlsen/goexif/exif"

src := io.Reader(image)

x, err := exif.Decode(src)
    if err != nil {
        log.Fatal(err)
    }

orientation, err := x.Get(exif.Orientation)

switch orientation {
case: "90 CW":
    src.Rotate(90)
case "90 CCW":
    src.Rotate(-90)
}

[scottferg]

Makes sense. Looking that bug it's just waiting for somebody to pick it up and fix it.

[scottferg]

Make sure to measure performance before and after this change. I'm very wary of changes that negatively impact cold cache hits in Vip. If it causes a regression we should look into how it can be improved before distributing the change.

[foresmac]

It appears as though the orientation itself is actually recorded as an integer between 1–8. (Presumably 0 is "no rotation".) Most tools that display the value translate that integer into some human readable string like "90 Clockwise".

More data here, pp 30–35: http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf

[scottferg]

Check with the Android team. They're pros at this because samsung. @nick-fedesna dealt with EXIF orientation woes on dScout if I remember correctly.

[nick-fedesna]

That is correct, come see me if you have EXIF questions.

[foresmac]

@scottferg Well, I'm pretty sure it going to cost at most the time to do imaging.Rotate(). However, we should be able to add runtime.GOMAXPROCS(runtime.NumCPU()) and imaging will parallelize whatever processing it can.

Also note that imaging also claims to support GIF files now, but I don't think it makes any promises about animated GIFs.

[foresmac]

@nick-fedesna You have a reference that maps the orientation integers to rotation amounts/directions?

[foresmac]

This seems to be what I need:

[nick-fedesna]

https://github.com/vokalinteractive/Android-Utilities/blob/master/android-utilities/src/main/java/com/vokal/hardware/JpegDataSaver.java#L121

[scottferg]

Did imaging state that it works concurrently?

Regardless, the cost can be optimized. image.Image is a reader, so we can buffer. Measure the before and after and we'll move on from there.

[nick-fedesna]

also: https://developer.android.com/reference/android/media/ExifInterface.html#ORIENTATION_ROTATE_270
for the constants

[foresmac]

As noted by @nick-fedesna, We can probably safely ignore 1, 2, 4, 5, and 7. I'll map:

6 -> 90
3 -> 180
8 -> 270

All clockwise.

[scottferg]

@nick-fedesna: VIP contributor
On Nov 18, 2014 4:55 PM, "Nick Fedesna" [email protected] wrote:

also:
https://developer.android.com/reference/android/media/ExifInterface.html#ORIENTATION_ROTATE_270
for the constants

—
Reply to this email directly or view it on GitHub
#41 (comment).

[nick-fedesna]

Woohoo!

[foresmac]

@scottferg:

Imaging package uses parallel goroutines for faster image processing. To achieve maximum performance, make sure to allow Go to utilize all CPU cores.

https://github.com/disintegration/imaging#parallelization

[scottferg]

Cool cool, sometimes people look at GOMAXPROCS as a silver bullet. Important to make sure it's legit.

[brockboland]

Any movement on this one? I'll rotate images before upload if I need to.

[foresmac]

I'm working on this in conjunction with #46 since it requires using basically the same libraries on file ingress.