bad orientation tag causes gthumb to show strange value

Bug #178575 reported by Dmitriy Geels
8
Affects Status Importance Assigned to Milestone
ImageMagick
Fix Released
Undecided
Unassigned
libexif
Confirmed
Undecided
Unassigned
imagemagick (Debian)
Fix Released
Unknown
imagemagick (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: gthumb

see attached screenshot. gthumb shows part of my email message, which might be left after freeing memory by evolution.
orientation value for image = 0, orientation value for thumbnail is correct

opera shows orientation value correctly - 0

PS I'm not sure if this is really a security vulnerability, but should be so, if it allows to see something you are not intended to see.

ProblemType: Bug
Architecture: i386
Date: Tue Dec 25 15:26:45 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/gthumb
NonfreeKernelModules: nvidia
Package: gthumb 3:2.10.6-0ubuntu1
PackageArchitecture: i386
ProcCmdline: gthumb file:///home/dmig/shit1.jpg
ProcCwd: /home/dmig
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=ru_RU.UTF-8
 SHELL=/bin/bash
SourcePackage: gthumb
Uname: Linux dmig-desktop 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

Tags: apport-bug
Revision history for this message
Dmitriy Geels (dmig) wrote :
Revision history for this message
Dmitriy Geels (dmig) wrote :
Revision history for this message
Dmitriy Geels (dmig) wrote :
Revision history for this message
Dmitriy Geels (dmig) wrote :
Revision history for this message
Dmitriy Geels (dmig) wrote :

this bug is not in gthumb - exif utility also shows wrong value, so bug must be in libexif

see line "Ориентация|Project-Id-Version: ru"

Revision history for this message
Charlie Barnes (charliebarnes) wrote :

I'm seeing the same with my images in gthumb and EoG (from a DSC W-17 and Canon EOS 400d), see attached.

Changed in libexif:
status: New → Confirmed
Revision history for this message
mjc (mjc-avtechpulse) wrote :

The svn trunk version of gthumb uses exiv2 instead of libexif, and it seems to work better with these images (no garbage strings).

However, it seems clear that these images do not have correctly coded orientation tags. I don't know how a camera could mess that up. exiftool reports the orientation as "unknown" for the last sample image.

- Mike

Revision history for this message
Charlie Barnes (charliebarnes) wrote :

I have just found images from the same camera that have correct orientation tags. I have a feeling this may actually be due to some editing that has gone on and not preserved the tag. I will investigate further...

Revision history for this message
Charlie Barnes (charliebarnes) wrote :

The problem seems to come from 'convert', part of the imagemagick package.

Use the following command in the terminal with the attached file (2mb; good orientation tag) to produce a file with the bad orientation tag:

convert -quality 80 -resize 800x600 00001.jpg 00001-bad.jpg

Revision history for this message
Charlie Barnes (charliebarnes) wrote :

Using package version 7:6.3.7.9.dfsg1-2ubuntu1 on iBook G$ (PPC),
ImageMagick version 6.3.7 02/18/08 Q16

Revision history for this message
Charlie Barnes (charliebarnes) wrote :

This is maybe a duplicate of the imagemagick bug 247147 (mogrify or convert (imagemagick) delete exif orientation field)?

Revision history for this message
David Sterratt (david-c-sterratt) wrote :

I have exactly the same problem: In the exif file after using convert, the Orientation lines say:

Orientation |Project-Id-Version: libexif

I notice that there are two of these Orientation lines saying the same thing (though separated by lines of other info). This is also true in my source images - the camera seems to have duplicated the Orientation information. It also seems to have duplicated the Resolution information -- and this too seems to be corrupted. See the attached diff and the original exif information.

Revision history for this message
David Sterratt (david-c-sterratt) wrote :
Revision history for this message
David Sterratt (david-c-sterratt) wrote :

I agree, this may be a duplicate of #247147

Revision history for this message
David Sterratt (david-c-sterratt) wrote :

According to this debian bug report, the problem is fixed in version 6.4.0.1 of ImageMagick (Hardy is on 6.3.7.9):

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468692

Changed in imagemagick:
status: New → Fix Released
Revision history for this message
Tormod Volden (tormodvolden) wrote :

imagemagick 6.4 is only in Debian experimental, and is therefore not merged into Intrepid yet. The merge request is bug #188773.

Changed in imagemagick:
status: Unknown → Fix Released
Daniel T Chen (crimsun)
Changed in imagemagick:
status: New → Confirmed
Changed in imagemagick (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.