# gThumb rotation issues (bug 343867)

I think a lot of the confusing in this bug is caused by the fact that we are dealing with multiple issue. I'll try to summarize all the problems and some of the proposed solutions.

For simplicity, I will assume that only jpeg images can have the exif orientation field. Once we have everything working, we can extend everything to TIFF images. Another reason is that some of the current exif code in gThumb is already written for jpeg images only.

## 1. Autorotation (for display)

When we are viewing images in gThumb, we have two options:

### 1.1 No autorotation before display

We can show the images unchanged (ignoring any exif orientation tag if present). What you see on the screen matches the layout of the pixels in the file. This is what gThumb (and any other exif-unaware application) does now.

#### Dealing with correctly tagged images

Many modern cameras have an orientation sensor and set the exif orientation tag to indicate that. Portrait mode is probably the most common. (Are there cameras known to do this wrong?) This information is now being ignored and you'll have to rotate all images manually (or automatically during import, see later).

### 1.2 Autorotation before display

We can also show the image after applying a transformation corresponding with the value of the exif orientation tag (if present). The original image is always left intact. This is what some other exif-aware applications (like f-spot) do.

#### Dealing with incorrectly tagged images

Previous versions of gThumb (and maybe some other broken applications) do not reset the exif orientation tag to top-left after a physical transformation of the image data. These leads to 'corrupt' images, that will show up with the wrong transformation applied.

I think that, regardless of our final decision here, this annoying bug should be fixed as soon as possible. We already have a patch for that, without any side-effects as far as I know. (Paolo or another gThumb developer, can you commit or at least take a look at patch 73884?) That is important, because we should not increase the number of 'corrupt' images any further. This issue already causes problems with other exif-aware programs like f-spot (see comment 3)!

If we implement this autorotation feature, some users will certainly have some of these 'corrupt' images. Therefore, it would be a very wise idea to warn the end user (e.g. show a dialog when activating the preference, on first use of the applicaton, or by some other means) and explain how to fix their images again. That could be done by providing some 'reset exif orientation tag to top-left' tool, a manual rotation or something else.

In my opinion this issue is not a good argument for not implementing this new autorotation feature.

### 1.3 Compatibilty with other applications

gThumb isn't the only gnome image viewer. For instance thumbnails are shared with other applications like nautilus and eog (as far as I know). Ideally they should all use the same method to view images and create thumbnails. See bug 335053 (nautilus) and bug 148400 (eog).

## 2. Rotation tool

When we are rotating images in gThumb, we have again two options:

### 2.1 Physical transformation of the image data

We can physically transform the image data (lossless for jpeg images). This is what gThumb (and any other exif-unaware application) does now.

#### Updating Exif tags

We need to take care to reset the exif orientation tag to top-left and adjust some other tags too (see comment 77). That means that without libexif support, we can't avoid corrupting images. Stripping all tags (if that can be done without libexif) is also not a good solution, because we'll lose all other (valid) information too.

### 2.2 Adjusting the exif orientation tag

We can adjust the exif orientation tag and leave the image data unchanged. This is what some other exif-aware applications (like f-spot) do.

This transform has the advantage that it's very simple and we do not have to worry about adjusting other tags, because they will remain valid at all time. Another (and maybe less important) advantage is that this transform is much faster, because no pixel data need to be changed.

#### Without libexif support?

Without libexif support, this type of transformation cannot be done and we should fallback to the physical transform (with the unavoidable problems of 'corrupt' images, already mentioned above).

#### Violation of the Exif standard?

Some question were raised whether this type of rotation is a violation of the Exif standard (see comment 82). Personnally, I don't think so (see comment 89).

#### Interaction with autorotation for display

Obviously you'll have to enable the "autorotation before display" to see the result of this type of rotation. I can imagine this will be confusing, when users do not see their changes in the viewer. The simple solution would be to offer this type of rotation only when the user also has the "autorotation before display" enabled. That could be done by re-using the same preference, or is that too simple? Consider the case where a user wants to enable autorotation for display, but prefers to do a physical transform. He could probably also enable the autorotation on import?

### 2.3 User interface issues

The initial preview image of the rotation dialog (and thus the initial rotation value) should always match the image in the main viewer, regardless of how the transformation will be performed.

With autorotation for display enabled, this is equivalent to always reading the exif orientation tag. Choosing additional transformations (using the buttons) starts from this initial value. A "Read photo orientation" checkbox (more on that later) should remain disabled in this case, because we are forcing to use that information.

With autorotation for display disabled, this is equivalent to force reading a top-left value. That means even if the user chooses no additional transformation, a transformation can be required. This case will probably need some more attention to do it right. Additional transformations (using the buttons) are also based on this initial value. A "Read photo orientation" checkbox (more on that later) can be used here to align the image with the exif orientation field.

From the last case above, it is clear that reading the exif orientation tag is usefull with autorotation for display disabled. The checkbox "Adjust photo orientation" does this job, but its label is very confusing. Renaming it to "Read photo orientation" (or something similar) would be much beter (see comment 63).

## 3. Autorotation (for import from camera)

We have again two options here. Either we leave the data unchanged (no transformation of any kind) or we physically transform the image data to match the exif orientation tag. There is already a (hidden) preference for this in gThumb. This is actually a simplified case of the rotation tool.