Image Orientation in EXIF file formats

Theory: -

EXIF (Exchangeable image file format) is a protocol to store various meta-information about the images
taken by digital cameras. Exif are stored along with the actual image data. Some of the meta info in Exif
includes camera maker, shutter speed, focal length, orientation, shooting time etc. These meta info is
called tags and each tag has a specific tag number decided by the Exif format standard.

All the EXIF images (JPEG, TIFF, PNG, DCX... ) will have a field named Orientation, which determines the
orientation with which an image must be rendered. (There are censors which determine what was the
camera position when the image was captured)

Reasons for having Orientation in a tag is -

1 EXIF files store the data with some lossy (non-reversible) image data compression
techniques which gives pixels some values with a close approximation. Hence, due to
COMPRESSION, the file size of an EXIF is considerably small but due to LOSSY
COMPRESSION, the pixel colour/intensity is not accurate.
2 When images are photographed, digital cameras use orientation sensors to store an EXIF
orientation value for how the camera is held. While a digital camera may include an option
to "auto-rotate images" due to the camera's orientation, this is just a "virtual rotation". As
lossless image rotation is a compute-intensive operation, digital cameras are not likely to
include true lossless rotation after capturing the photo.

To minimize lossless transformation and reduce the dependency on the camera hardware, we need to
separate out image data with its representation in the image itself.

A flag is set to guide the viewing software which way to rotate the image before display, rather than
rotating the image data itself. (Image editing software should act on the image-file, rather than on the
image-content.)
There are 8 possible values (numbered 1 to 8) for anti-clockwise rotation of an image by 0, 90, 180, 270
and same 4 with mirroring option too.

EXIF Orientation Meaning

1 as is
2 rotation by 0, mirrored
3 rotation by 180
4 rotation by 180, mirrored
5 rotation by 90, mirrored
6 rotation by 90
7 rotation by 270, mirrored
8 rotation by 270

Problem with OIT: -

In OIT, we read the value of Orientation and we drop that information right there. OR We read the value
of Orientation but behave as if it is always 1 (1 is "as is").

So, the problem statement is - OIT should render/export its images as per the Orientation-field
provided in the input image file.

We might have to think about these complexities

1 Image type – we might have to understand JPEG/TIFF/PNG formats

2 Bits per pixel – 8-bit, 16-bit, 24-bit and 32-bit images...
3 Various exports – Exports in OIT like IX, PX, VW
4 Padding bytes – The WIDTH of an image is always a multiple of 4. The HEIGHT need not be a
multiple of 4. And if the width is not, then additional dummy padding bytes are inserted to
make it a multiple of 4. This creates a specific problem of understanding what is a Pixel and
what is a Padding byte. This problem further complicates in case of rotations with 90/270 as
the height and width gets swapped, and height (which may not be a multiple of 4 in the
original image) becomes width after transformation and should have padded bytes.
Similarly, width which was multiple of 4 after padding in Original image, now becomes
height and we must discard padding bytes.

(Customers will not be interested in what is the image type, BPP, dimensions of the image... and would
expect that to be rotated appropriately)
Potential solutions: -

There are 2 ways to solve the problem…

1 In Filter - we can make changes to the EXIF (JPEG/TIFF/PNG) filters, where we consider the
Orientation value in the filter itself and then update the image-data. We will have to
understand different image formats and change the image-data that way!

2 In core - we defer changing the image data till a point which is common between
IX/PX/VW/WV... and there we will change the data. We might have to make some changes
initially as right now; the Orientation value is not brought inside the core. We might have to
create a commonly accessible file which handles orientation and then call this separately
from core section for IX/PX/VW...

"Making changes to core" looks to be the winner...

Few bugs already raised on this (there are few more which are closed based on ER raised)

Sr No Bug# Title

1 31562116 Embedded JPG image in email file orientation rotated after PDF conversion

2 30380078 feature to have OIT rotate the images in JPG as per the orientation/EXIF data

3 29724358 pages of TIFF exported to PDF/HTML are in a different orientation

4 25841544 Orientation issue in TIFF file when view it in outside In viewer

5 18655517 FIDELITY: IMAGE ROTATION IS MISSING IN IX/HX: PPTX FILE FORMAT

6 18698381 IMAGE EXPORT FOR A THUMBAIL OF A ROTATED JPG LOOSES THE ROTATION

7 22242151 FIDELITY: INCORRECT ROTATION OF CYLINDER BARS

8 6294134 BETTER IMAGE METADATA SUPPORT (INCLUDING EXIF)

9 17766052 NEED THUMBNAIL IMAGE BASED ON USER ORIENTATION

10 18725769 OUTSIDEIN PDF EXPORT 8.4.1 DOES NOT CHANGE THE ORIENTATION OF THE IMAGE FILE

11 11737233 WORD 2007, INCORRECT JPG IMAGE ORIENTATION

12 7729874 PROCESS IMAGE: ALLOW PROCESS IMAGE ORIENTATION TO BE RELATED IN A "PE

13 25113336 OPEN IMAGE MENU DROPDOWNS RELOCATE RANDOMLY WHEN ORIENTATION IS CHANGED
Execution plan: -

Steps Task End goal Points

1 Basic understanding of the image file
formats. These EXIF file formats have a field
named Orientation, extracting information
from that. JPEG, TIFF… etc files have
different ways to store Orientation
information.
2 Implementation of remaining 7 orientation
values across image filters. Right now,
Orientation is not at all considered… OR it is
always treated as 1 (default; Rotated by 0,
no mirroring).
3 Implementation of Orientation in core area
for first 3 cases (case 2-4), where the image
data needs to be rotated/mirrored
appropriately. (average 4 per case, 3*4)
4 Implementation of Orientation in core area
for last 4 cases (case 5-8), where the image
data needs to be rotated/mirrored
appropriately. (average 6 per case, 4*6)
Understanding image file formats. The 13
data stored in it, what signifies the
orientation, pixel data. Impact of Sub-
Sampling, Compression, Encoding. Any
impact of GPS image directions.
Chunk dump showing Orientation values 8
in all cases across EXIF file formats.
Finding out the tag in input file under
which the orientation value is given will
be difficult.
Image (case 2-4) getting rotated. 12
(Rotation by 0-180)
Image (case 5-8) getting rotated. 24
(Rotation by 90-270)

Implementation Plan: -

1. Person-1, will deep dive into image formats, will try to investigate how to change. Step-1

2. Person-2, in the meantime will bring Orientation value to core. Step-2 (parallel to step-1)

3. Person-1 and 2 can parallelly work on Step3 and Step4.