export should apply flip

[elementaryBot]

export seems to just save EXIF data for flip instead of actually flipping. This is important when I need to use a photo online or somewhere the EXIF data won't be read

Launchpad Details: #LP1371826 Daniel Fore - 2014-09-19 23:39:41 +0000

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/61472756-export-should-apply-flip?utm_campaign=plugin&utm_content=tracker%2F60550306&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F60550306&utm_medium=issues&utm_source=github).

[elementaryBot]

This is a feature, not a bug. Using the orientation tag is non-destructive. Actually flipping the pixels is not.

Apps and sites which ignore the orientation tag are broken and should be fixed.

Launchpad Details: #LPC Alan Pater - 2015-03-15 23:47:58 +0000

[elementaryBot]

In an ideal world sure. Sadly this is not an ideal world. I don't think orientation changes are really "destructive" as it can be reverted quite easily.

Launchpad Details: #LPC Daniel Fore - 2015-03-16 02:19:06 +0000

[elementaryBot]

Sadly it is not. In an ideal world, pixels can be flipped non-destructively. In the real world, algorithms to do that may be imperfect. It may look to the human eye as if nothing has been lost, but that may not be the case.

The orientation tag seems safer.

Launchpad Details: #LPC Alan Pater - 2015-03-16 13:28:41 +0000

[elementaryBot]

This is a long-standing source of confusion with Shotwell. There are numerous issues involved.

First, Shotwell uses GDK Pixbuf to perform the rotate/flip operations in memory. Those operations are non-destructive and reversible.

Re-encoding a JPEG is destructive due to the lossy nature of JPEG compression. Older photo managers used generational editing, meaning they saved (re-encoded) the JPEG with each edit. This leads to loss of precision, detail, color, and more.

This is why Shotwell uses EXIF orientation whenever possible; by avoiding re-encoding the JPEG, we preserve the photo.

However, there is only one export case where Shotwell can use this technique: If the photo is being exported (a) at the same size (dimensions) as the original and (b) with no other transformations involved (cropping, red-eye, color adjustment, etc.) If either of these is not true, Shotwell must re-encode the JPEG, so it will go ahead and rotate the image along with the other transformations.

Note that there is a side-case as well: When metadata writing is turned on, Shotwell will write the Orientation out (along with keywords, titles, descriptions, etc.) This is a handy way to properly orient your master photos without re-encoding them (and losing the detail in the originals).

For most photo sharing services, the photo must be uploaded at a smaller size than the original, so the orientation issue is moot. For situations where the original is being uploaded (again, with no other transformations), then yes, only the EXIF Orientation is modified.

The problem with re-encoding every time is that we don't know the purpose of the export. If it's to share baby photos on Facebook or Instagram, then yeah, re-encoding is probably not a big deal. But if it's being exported for archival purposes (which some people use Flickr for), then we're needlessly removing detail from their photos. For some people, it's no big deal. For others, it's like we're repartitioning their hard drive.

Launchpad Details: #LPC Jim Nelson - 2015-03-16 19:33:27 +0000

[elementaryBot]

Gonna make the call here as I think Jim pointed out the distinction. We want to make sure to be as non-destructive as possible in the library. EXIF rotate makes the most sense inside of Photos.

However, since we can't predict external apps and whether or not they will respect this data, I think it makes sense that export should apply all changes (including rotate and flip) to the exported file.

Launchpad Details: #LPC Daniel Fore - 2015-03-18 21:32:28 +0000