After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 377548 - Rotate functionality corrupts EXIF data
Rotate functionality corrupts EXIF data
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: Metadata
0.2.2
Other All
: Normal normal
: 0.7.1
Assigned To: F-spot maintainers
F-spot maintainers
Depends on: f-spot-taglib
Blocks:
 
 
Reported: 2006-11-20 22:02 UTC by David I. Lehn
Modified: 2010-07-08 18:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
original unrotated image (61.77 KB, image/jpeg)
2006-11-20 22:05 UTC, David I. Lehn
Details
f-spot 0.2.2 rotated image (32.05 KB, image/jpeg)
2006-11-20 22:11 UTC, David I. Lehn
Details
diff of origianl and rotated EXIF data (11.07 KB, text/plain)
2006-11-20 22:13 UTC, David I. Lehn
Details

Description David I. Lehn 2006-11-20 22:02:21 UTC
Please describe the problem:
Using the rotate functionality causes image EXIF data to be corrupted.  Ideally, the applicaiton would offer a choice of _only_ editing the EXIF orientation flag, doing the rotation non-destructively (as requested in Bug#301819), or doing a full lossless image and thumbnail rotation.  Now it looks like it's just changing the rotation flag and along the way is corrupting other EXIF data.

This bug can be shown with images from a Nikon CoolPix 2500.  Rotating one of its images changes (using EXIF.py/exiftool field names):

- various EXIF offsets
- EXIF UserComment from nulls to "ASCII" and some nulls.  Why?
- Image DateTime to current image time.  This should arguably be done since the image is being updated but I would prefer the option to leave it alone.
- Image Orientation to the requested orientation.
- Image Software from, in this case, "E2500v1.0" to "f-spot version 0.2.2".  This is another field I think should be optionally changed.  I would prefer to keep the original camera data stored here.
- various MakerNote fields.  They all look corrupted with random crap.  This is _bad_.

- The image size also shrinks by ~30k for unknown reasons after a rotation.

Steps to reproduce:
1. Load image in f-spot
2. Click one of the rotate buttons
3. Examine EXIF data

Actual results:
Image is rotated via EXIF orientation flag, other EXIF data is modified or corrupted.

Expected results:
EXIF orientation flag changed, everything else left exactly the same.

Does this happen every time?
Yes

Other information:
Comment 1 David I. Lehn 2006-11-20 22:05:35 UTC
Created attachment 76944 [details]
original unrotated image
Comment 2 David I. Lehn 2006-11-20 22:11:14 UTC
Created attachment 76945 [details]
f-spot 0.2.2 rotated image

The rotated image is ~30k smaller, which for this example image is half size but larger 500-700k images also shrink a similar non-constant ~30k as well.
Comment 3 David I. Lehn 2006-11-20 22:13:23 UTC
Created attachment 76946 [details]
diff of origianl and rotated EXIF data

This EXIF diff is between output of exiftool -v on both images.
Comment 4 Larry Ewing 2006-11-28 17:05:13 UTC
other than the intentional changes (modification time, software) the problems result from libexif not understanding the makernote.  I'm working on replacement code for this. 
Comment 5 Tom Harris 2006-12-31 11:32:17 UTC
This is also reported by me in Ubuntu's launchpad, here - https://launchpad.net/products/f-spot/+bug/69577

I would suggest that no EXIF should be changed (including software and modification time). This is especially important given the promise stated on the "Features" page of the website: "Easily rotate, crop, resize, and adjust red eye and other color settings with a few simple clicks. Versioning ensures your originals are never altered."

Currently I have set all my photos to read-only to protect them from F-Spot. Surely the only tag that should be changed is the rotation tag, and even then that should be a new version, with "Original" preserving the default orientation as it was recorded by the camera.
Comment 6 Ruben Vermeersch 2010-05-23 15:39:59 UTC
This will probably be fixed by moving to Taglib#. Soon.
Comment 7 Ruben Vermeersch 2010-07-08 18:13:20 UTC
This should not happen anymore. Please re-open in case you still have problems.