Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Batch Save - issue #168 #169

Merged
merged 1 commit into from
Jul 27, 2022
Merged

Fix Batch Save - issue #168 #169

merged 1 commit into from
Jul 27, 2022

Conversation

programmer-ceds
Copy link
Contributor

This PR addresses issue #168

The problem occurs when the following conditions are met:

  1. The image has EXIF data containing the orientation tag (0x112)
  2. The orientation tag for the image has a value other than 1 when xviewer reads the image
  3. Since xviewer made the change the user has scrolled to another image (just scrolling back to this image doesn't fix the problem)
  4. 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?

@mtwebster mtwebster merged commit 8f6f766 into linuxmint:master Jul 27, 2022
@mtwebster
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants