GNOME Bugzilla – Bug 517077
After croping an image the exif data is not adjusted to reflect the new size
Last modified: 2008-10-30 20:09:42 UTC
Please describe the problem: Cropping an image and the saving it still keeps the old dimensions in the EXIF data. Cahnging (scaling) the image seems to remove the size information Steps to reproduce: 1. Open any file containing size info in the exif data (Tags 0x0100 & 0x0101) 2. Crop a portion out 3. Save Actual results: Expected results: Have the correct size info in the file Does this happen every time? Yes Other information:
Could you please attach an image that can be used to reproduce the problem?
The image seems to big to upload as an attachment. So you can download it at http://www.drozilla.ch/705a71a4.jpg Please let me know, when you're done, so I can remove the link. By teh way, this is running on an uptodate Fedora 8 System
Two questions: What tool are you using to tell you what is in the exif info? And what version of libexif is installed on your system?
This can be easily reproduced using the exif tool that comes with libexif version 0.6.15.
Yeah, well, this is confusing stuff. According to the EXIF specification, we are not supposed to set those tags for jpeg files, because the information is included in the jpeg marker. Instead, the dimensions are supposed to go into the mandatory PixelXDimension and PixelYDimension fields (tags A002 and A003), which we do set correctly when we save an image, as far as I know. Still, it's hard to see what harm it could do for us to set them. Reference: http://www.exif.org/Exif2-2.PDF , pp 54-55.
The reason I confirmed this bug is that PixelXDimension and PixelYDimension fields are not updated correctly. For the other fields, we should of course adhere to the Exif specification.
Ugh. The code was using the wrong IFD -- this has obviously been wrong forever. Fixed now in trunk and gimp-2-4. 2008-02-19 Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/jpeg/jpeg-exif.c: correctly record dimensions when saving an image. Fixes bug #517077. Serge, thanks for the bug report.