The problem occurs when the following conditions are met:
The image has EXIF data containing the orientation tag (0x112)
The orientation tag for the image has a value other than 1 when xviewer reads the image
Since xviewer made the change the user has scrolled to another image (just scrolling back to this image doesn't fix the problem)
The image is saved - either explicitly or as a result of selecting Save when prompted when exiting xviewer
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?
Regarding tiff files, I have no opinion either way - is it useful? It's obvious why png/jpgs carry data, but doesn't the tiff format have a much narrower field of use?
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?