Reading JPEG header information

Discussion in 'Digital Photography' started by Z, Nov 11, 2005.

  1. Z

    Z Guest

    I need to be able to interpret the header information in a JPEG image file.

    I've been poking through Google hits, but am pretty much lost ... should
    I be looking at the EXIF, JFIF or JIF specifications? Or maybe some
    other, more global specification document that includes the others?

    Can anyone here direct me to a comprehensive specification document with
    field and byte layouts for JPEG files?

    Right now, I just need to be able to read the dimensions of the image.
     
    Z, Nov 11, 2005
    #1
    1. Advertisements

  2. Z

    Jim Townsend Guest

    This pdf document has details on the structure of the header:

    http://www.w3.org/Graphics/JPEG/jfif3.pdf

    This site contains essentially the same information
    with a little different spin:

    http://netghost.narod.ru/gff/graphics/summary/jfif.htm
     
    Jim Townsend, Nov 11, 2005
    #2
    1. Advertisements

  3. Z

    Paul Allen Guest

    When I wanted to reset EXIF timestamps on a batch of images, Google took
    me straight to what I needed. Later on I discovered that the
    functionality I needed had already been implemented as open source
    several times. For the header stuff (not the image itself) check out
    libexif. It might save you a lot of time.

    Paul Allen
     
    Paul Allen, Nov 11, 2005
    #3
  4. Z

    Z Guest

    I found libexif and played a bit, but my target o/s is VMS and because
    of the makefiles it's going to take a huge effort to build that code on
    any o/s other than Unix/Linux.

    I only need a very specific set of data: just the height and width in
    pixels (and I'm not sure it's in the EXIF section), so I think my path
    of least resistance is to decode the correct header myself.
     
    Z, Nov 12, 2005
    #4
  5. Z

    Z Guest

    Thanks.

    In that document I see Xdensity and Ydensity but that can't be height
    and width ... I have 2 JPGs, one 200x200 and another 400x400 (a resized
    version of the 200x200 image) and both have the same Xdensity and
    Ydensity fields within the JFIF header.

    200x200:
    FF D8 FF E0 10 4A 46 49 46 00
    01 01 00 00 01 00 01 00 00 FF E1 1C 86 45 78 69 66 00
    ( ver 1.1, units = 0, Xdensity = 00 01, Ydensity = 00 01 )

    400x400:
    FF D8 FF E0 10 4A 46 49 46 00
    01 01 00 00 01 00 01 00 00 ff E1 1C 86 45 78 69 66 00
    ( ver 1.1, units = 0, Xdensity = 00 01, Ydensity = 00 01 )

    How do I convert the densities (actually the pixel aspect ratio, since
    the units byte is 00) to number-of-pixels?
     
    Z, Nov 12, 2005
    #5
  6. Grabbing any given bits of information from the EXIF headers is
    fairly easy to do (like everything else, once you figure out
    how), and can be done with Standard C that will compile on
    virtually any platform.

    A while back I was fooling around with a short program to read
    EXIF headers from Nikon NEF formatted files, and more or less on
    a whim also added the ability to read JPEG files. I was only
    really interested in NEF files though, and while I researched
    that to the bottom of the stack, I only looked into JPEG EXIF
    headers enough to pull out a few things. I don't recall having
    found any really good information on JPEG headers, and mostly
    just reverse engineered the format from examples generated by
    the particular (Nikon D1) camera that I was interested in at the
    time. I've also tested it on JPEGs produced by a Canon 5D,
    where the only information that appears to be correct is the
    camera, the date, and the image size. :)

    The program is strictly ANSI, and uses stdio.h, stdlib.h,
    and strings.h only. No system/platform specific headers at all.
    And nothing other than libc is linked.

    My code obviously has 100 times more clutter than you need, but
    if it would be any help, point me at a URL that has an example
    JPEG file you want information from, and I'll post the shortest
    most basic example code I can come up with to extract the size
    in pixels from it. It might save you a little thrashing...
     
    Floyd Davidson, Nov 12, 2005
    #6
  7. Z

    Paul Allen Guest

    I did that myself before I stumbled over libexif and the various things
    on top of it. I've got some code that parses the internal structures of
    a JPEG file. I built it to increment the datestamps on a whole bunch of
    images, but that logic is up in the main program. The underlying exif.c
    logic knows all about things like the tags containing the image
    dimensions. It does have a Makefile, but that's not really needed.
    It definitely does not use autoconf and does not have a configure
    script.

    If you're interested, I can put it up on my web site. It's been a
    really long time (20 years, in fact) since I touched VMS. Can you
    handle a gzipped tarfile? A plain tar archive? Plain newline-delimited
    ASCII text files? I once warped the GNU C compiler on an Ultrix VAX
    into a cross-compiler for Minix running on a 386, so I guess VAXen have
    the same byte-sex as PC's.

    Paul Allen
     
    Paul Allen, Nov 12, 2005
    #7
  8. Z

    Z Guest

    Z, Nov 12, 2005
    #8
  9. Z

    Father Kodak Guest

    VMS as in DEC? An 11/780 in your home office?

    Actually, I remember someone telling me that (around 1985) about one
    quarter of the VAXen in use were running some version of UNIX instead
    of VMS.
     
    Father Kodak, Dec 18, 2005
    #9
  10. Try the Perl package Image::ExifTool. It's pure Perl, and Perl runs
    everywhere.
    Decoding the width and height from the JPEG header is rather easy.
    ITU T81 is the document you want for reference.
     
    =?iso-8859-1?q?M=E5ns_Rullg=E5rd?=, Dec 18, 2005
    #10
  11. Z

    Paul Allen Guest

    [/QUOTE]
    Back in the mid-80's, we had a pair of 11/780's at work. They faced
    each other in a raised-floor machine room that they filled. One ran
    VMS and the other ran Ultrix, DEC's flavor of BSD Unix. They were
    fantastically expensive to operate and had an aggregate total of 2
    whole MIPs of processing power. I don't think any of the researchers
    used them for image procesing. Ah! The joy of waiting half a day
    for the RA-80 disks to fsck after a crash! These kids today with
    their journalled terabytes of RAID don't know what they're missing!

    DEC's been gone for a while, but VMS lives on:

    http://h71000.www7.hp.com/

    OpenVMS apparently runs on Alpha hardware, which is definitely suited
    for image processing. Why one would saddle oneself with VMS when
    Linux runs on the same hardware is beyond me, but I notice that I have
    not yet been declared Captain of the Universe either. :)

    Paul Allen
     
    Paul Allen, Dec 18, 2005
    #11
  12. Z

    Father Kodak Guest

    I used to work with Fortune Systems UNIX on an 11/780. (long since
    gone Fortune Systems, as in Fortune 32:16, one of the JAWS crowd in
    the mid-80s.)
    From what I can tell, mostly they don't even want to hear about it.
    Or any of my stories about dropping an entirely full 80-column punch
    card box, with some massive Fortran routines, without sequence numbers
    in cols 73-80.
    I agree, but then why is your target os VMS and not
    UNIX/Linux/Solaris.?
     
    Father Kodak, Dec 19, 2005
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.