Bug 136958 - netpbm - optioin '-dumpexif' does not work
Summary: netpbm - optioin '-dumpexif' does not work
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: netpbm
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Ben Levenson
URL:
Whiteboard:
: 142340 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-23 23:22 UTC by Michal Jaegermann
Modified: 2013-07-02 23:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-30 06:45:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
sample jpeg picture with exif data (220.74 KB, image/jpeg)
2004-10-24 15:34 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2004-10-23 23:22:36 UTC
Description of problem:

'man jpegtopnm' says (minus really weird formatting):

   -dumpexif
          Print the interpreted contents of any Exif header in the
	  input file to  the  Standard  Error  file.  Similar to
	  the program jhead (not part of the Netpbm package).

On every file I tried it is actually producing that, both on x86
and x86_64:

jpegtopnm: WRITING PPM FILE
jpegtopnm: EXIF INFO:
jpegtopnm: Incorrect Exif header
Resolution   : 0 x 0
Color/bw     : Black and white
Flash used   : No

This is what actually 'jhead', recompiled on FC3test system, has
to say about the file used in this test:

File name    : 2004_0920_004.jpg
File size    : 1375379 bytes
File date    : 2004:09:19 23:19:10
Camera make  : FUJIFILM
Camera model : FinePix F700  
Date/Time    : 2004:09:20 07:19:11
Resolution   : 2832 x 2128
Flash used   : No
Focal length : 16.3mm  (35mm equivalent: 77mm)
CCD width    : 7.65mm
Exposure time: 0.0045 s  (1/220)
Aperture     : f/8.0
ISO equiv.   : 160
Metering Mode: matrix
Exposure     : program (auto)
Jpeg process : Baseline

Older version, like from netpbm-9.24-9.73 for example, print
with '-dumpexif' sometimes weird numbers but in generally something
recognizable.

Probably benign but it is hard to be sure that this "looking at
wrong places", if that what it is, cannot lead to security concerns
in some scenarios.

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

How reproducible:
100%

Comment 1 Jindrich Novy 2004-10-24 12:07:13 UTC
Could you please send here (as an attachment) some JPEG file you have
tested and jpegtopnm failed?

Comment 2 Michal Jaegermann 2004-10-24 15:34:15 UTC
Created attachment 105705 [details]
sample jpeg picture with exif data

What I described happens on every jpeg file with exif data I could find;
so any picture from a digital camera should do.  Here is one with a relatively
small file size.  Neither jhead nor gthumb have any problems with its exif data
but jpegtopnm behaves like detailed in the report.

An older version, i.e. from netpbm-9.24, of 'jpegtopnm -dumpexif ...' shows
for this picture:

jpegtopnm: EXIF INFO:
Camera make  : EASTMAN KODAK COMPANY
Camera model : KODAK DC4800 ZOOM DIGITAL CAMERA
Date/Time    : 2003:02:19 15:36:31
Resolution   : -1073752952 x 1073968572
Flash used   : No
Focal length :	5.9mm  (35mm equivalent: -2147483648mm)
CCD Width    :	nanmm
Exposure time: 0.003 s	(1/350)Aperture     : f/2.8
Focus Dist.  : 0.74m
ISO equiv.   :	9
Exposure     : program (auto)

This is also not so great but at least closer to desired results than
"Incorrect Exif header". :-)  It also looks fixable rather easily.

Comment 3 Jindrich Novy 2004-10-25 09:39:07 UTC
Ok, thanks, I'm having a look at it.

Comment 4 Jindrich Novy 2004-10-27 07:19:54 UTC
Michal, yes it looks like the interface bug to the jhead code. Bryan
told me he'll fix it upstream and will release a next stable release
in a few days so when netpbm-10.26 is released I build new netpbm and
close this UPSTREAM.

Thanks,
Jindrich

Comment 5 Jindrich Novy 2004-12-09 06:42:46 UTC
*** Bug 142340 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.