Bug 142340

Summary: jpegtopnm -dumpexif does not recognize standard Exif headers
Product: [Fedora] Fedora Reporter: Rudolph T. Maceyko <rm55>
Component: netpbmAssignee: Jindrich Novy <jnovy>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: pknirsch
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:07:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rudolph T. Maceyko 2004-12-09 01:47:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041112 Firefox/1.0

Description of problem:
jpegtopnm stopped recognizing standard Exif headers created by two
different Nikon cameras as of Fedora Core 2 (netpbm-progs-10.19-7). 
I've gone through my entire archive of digital photos and the later
jpegtopnms are no longer able to read that part of the file.

Details are below.

Version-Release number of selected component (if applicable):
netpbm-progs-10.25-2

How reproducible:
Always

Steps to Reproduce:
1. Copy image file directly from smart disk card
2. Run jpegtopnm -dumpexif on image file

    

Actual Results:  Fedora Core 3 (netpbm-progs-10.25-2):

$ jpegtopnm -dumpexif dsc_2229.jpg > /dev/null
jpegtopnm: WRITING PPM FILE
jpegtopnm: EXIF INFO:
jpegtopnm: Incorrect Exif header
Resolution   : 0 x 0
Color/bw     : Black and white
Flash used   : No

Fedora Core 2 (netpbm-progs-10.19-7):

$ jpegtopnm -dumpexif dsc_2229.jpg > /dev/null
jpegtopnm: WRITING PPM FILE
jpegtopnm: EXIF INFO:
jpegtopnm: Incorrect Exif header
Resolution   : 0 x 0
Color/bw     : Black and white
Flash used   : No

Expected Results:  Fedora Core 1 (netpbm-progs-9.24-12.1.1):

$ jpegtopnm -dumpexif dsc_2229.jpg >/dev/null
jpegtopnm: WRITING PPM FILE
jpegtopnm: EXIF INFO:
Camera make  : NIKON CORPORATION
Camera model : NIKON D70
Date/Time    : 2004:12:08 13:35:55
Resolution   : 65457 x 65456
Flash used   : No
Focal length : 18.0mm  (35mm equivalent: -2147483648mm)
CCD Width    : 0.00mm
Exposure time: 0.013 s  (1/80)Aperture     : f/11.0
Focus Dist.  : 0.00m
ISO equiv.   : 65469
Whitebalance : cloudy
Metering Mode: matrix
Exposure     : aperture priority (semi-auto)
JPG Quality  : fine


Red Hat 9 (netpbm-progs-9.24-10.90.3.legacy but also straight 9.24-10
& -10.90.1 from Red Hat):

$ jpegtopnm -dumpexif dsc_2229.jpg >/dev/null
jpegtopnm: WRITING PPM FILE
jpegtopnm: EXIF INFO:
Camera make  : NIKON CORPORATION
Camera model : NIKON D70
Date/Time    : 2004:12:08 13:35:55
Resolution   : 65457 x 65456
Flash used   : No
Focal length : 18.0mm  (35mm equivalent: -2147483648mm)
CCD Width    : 0.00mm
Exposure time: 0.013 s  (1/80)Aperture     : f/11.0
Focus Dist.  : 0.00m
ISO equiv.   : 65469
Whitebalance : cloudy
Metering Mode: matrix
Exposure     : aperture priority (semi-auto)
JPG Quality  : fine

Additional info:

jhead from http://www.sentex.net/~mwandel/jhead/ is able to read the
Exif data correctly and even gets some of the details correct that the
older jpegtopnm got wrong:

File name    : dsc_2229.jpg
File size    : 2699136 bytes
File date    : 2004:12:08 15:45:59
Camera make  : NIKON CORPORATION
Camera model : NIKON D70
Date/Time    : 2004:12:08 13:35:55
Resolution   : 3008 x 2000
Flash used   : No
Focal length : 18.0mm
Exposure time: 0.013 s  (1/80)
Aperture     : f/11.0
Whitebalance : cloudy
Metering Mode: matrix
Exposure     : aperture priority (semi-auto)
Jpeg process : Baseline

I have no other way at present to determine whether there really is
something wrong with the Exif data, but I'm inclined to believe that
something changed in jpegtopnm that simply causes it to no longer
recognize Exif data properly.

Comment 1 Jindrich Novy 2004-12-09 06:42:44 UTC
Rudolph, it's a known bug in recent netpbm (please see bug 136958),
it'll be fixed upstream soon.

*** This bug has been marked as a duplicate of 136958 ***

Comment 2 Red Hat Bugzilla 2006-02-21 19:07:37 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.