Fix wrong Images orientation

[abdelrahmansd]

Photos taken with a smartphone or digital camera contain “Exif data,” all sorts of information about where the photo was taken, when it was taken, and even how the camera was oriented. When uploaded Images, this data is preserved, and that can often cause the orientation of the picture to be rotated. and Some images don't have the correct rotation
there are several solutions to fix the image orientation

• applying the Orientation instructions in the Exif metadata while ingesting process and this might change the Image ID
  
• add a rotate button on the image in the UI and add orientation metadata to the image to be applied while rendering the image in the UI

[paperboyo]

See also #403.

The solutions given aren’t exclusionary. We should combine them: we should read the metadata and automatically apply orientation while also providing manual controls for users for when things gone wrong (phone was disorientated about orientation, upstream apps were dumb while editing etc). This is how all editing apps work.

Problem for us is indeed well noted above: we don’t want to ever modify the original image.

I guess, the solution then is either to read the flags for all formats (once!) and then painstakingly make sure all renders (thumbnails, optimisedPng) and live views (imgops, crop) are always oriented explicitly when performing image operations and when requesting original image (imgops and cropping). The goal here would not be to ever miss a single point where this is needed, otherwise chaos ensues.

This is further complicated by the fact that orientation may also mean image flipping (not only rotation). Not sure if eg. nginx image_filter allows for image flipping. If it doesn’t we would either need to switch to something else or… go the hacky route: create a high quality flipped copy of the image whenever even just one of the many image operations/requests we do doesn’t support flipping. By which point we may think creating a copy even for simple rotation would be an acceptable compromise (although extra storage* of all images requiring rotation/flip smells of defeat, I guess it would simplify the engineering effort).

In general, this is not an unsurmountable problem by any stretch, just one that requires careful planning and looking at absolutely every place in the code where we perform image operations (or live requests to the original). Plus some UI work for the rotation button (this?) and, if we want to be completist, a second button for flip), in both Viewer and Browser (for batch apply).

*copies would need to be high quality as not all JPEGs can be rotated losslessly, let alone losslessly flipped

[paperboyo]

Since we’ve discussed making copies, the question arises how to compress them? Maybe we should use lossless jpegtran (available via im4java) with JPEGs which satisfy this requirement?

The other transformations operate rather oddly if the image dimensions are not a multiple of the iMCU size (usually 8 or 16 pixels), because they can only transform complete blocks of DCT coefficient data in the desired way.

A note that we would still be prone to #2066, but not sure if GM (or IM) deals with that automatically. Or if we would need to solve that with a generic solution (see issue).

I haven’t used it, so worth checking if normal, embedded ICC profiles survive transformations correctly (although images straight from devices tend to use DCF EXIF, at least for AdobeRGB).

cc @ochiengolanga