Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses issue #168
The problem occurs when the following conditions are met:
When xviewer rotates or flips an image it does so by actually modifying the image data, rather than (for files that have EXIF data) simply altering the setting of the tag EXIF_TAG_ORIENTATION (0x0112). As a result it has to set the orientation tag to a value of 1 (TopLeft) - it also updates the tags EXIF_TAG_PIXEL_X_DIMENSION and EXIF_TAG_PIXEL_Y_DIMENSION. These tags are updated in the copy of the EXIF data that xviewer holds for the image (image->priv->exif).
The problem occurs when the user scrolls to another image as the function xviewer_image_free_mem_private() is called to free up memory. Part of this processing involves unref'ing image->priv->exif thereby losing the changes. When the image is saved the original/unaltered EXIF data is read from the file and then saved without the changes. Programs that automatically orientate images based on the setting of the orientation tag then display the image not as the change made in xviewer intended.
The change made by this PR is to leave updating the copy of the EXIF data until the image is being saved (the orientation, width and height members of image->priv still hold the data that needs to be written). Since the update function is only called in xviewer-image-jpeg.c it has been moved there, from xviewer-image.c, and renamed appropriately (xviewer_image_jpeg_update_exif_data()).
The revised code has been tested with the sample images posted in #168 and the results are as the expected results that are shown in that issue.
Note that these changes do nothing to any thumbnail or associated orientation tag - but neither does the current code. Perhaps this is something that could/should be addressed?
As an aside xviewer neither reads nor writes EXIF data for tiff files (only jpeg and png) - perhaps this is also something that should be addressed - any views?