Exif Metadata in JPEG2000: Request for Comments

Discussion in 'Digital Cameras' started by Thomas Richter, Jan 9, 2008.

  1. Hi newsgroup, dear readers.

    The purpose of this post is to collect some impression on the needs of
    users and possible solutions. I'm looking for opinions on this from
    people with practical experience in the field and try to collect some

    Background: Exif is an image encoding standard, based on "traditional"
    JPEG that, along with the image, also carries meta-data as the exposure
    time, the white-point, the aperture and other camera specific settings.
    This data can be used for multiple purposes, for example to
    automatically or semi-automatically post-process images on a PC. Almost
    traditionally, the name "Exif" has been identified with the data and
    the binary container keeping it, however, Exif is really an image
    format: Traditional JPEG, with a TIFF-like container in one of its
    "comment" markers, keeping the Exif tags.

    JPEG2000, the follow-up of the traditional JPEG encoding, offers various
    methods how to integrate such meta-data. It's just that nobody has done
    that yet and there is not yet a standardized approach for it.

    The JPEG committee is aware of this problem, and tries to address it,
    but several options *how* this is to be done are possible, and I'm
    looking for opinions - what is in the market, what are user demands, etc.

    Question 1: I often hear the claim that "JPEG2000 has Exif issues".
    Would you believe that this is a serious market demand, and a serious
    problem why JPEG2000 did not gain a market penetration?

    Question 2: Currently, two solutions for the Exif problem are under
    discussion. Option 1) would be to use the same Exif container as in
    traditional JPEG, and pack it into JPEG2000, there as part of a file
    format structure called a "UUID-Box" which ensures unique identification
    of the structure. Option 2) would be to encode the same data set in XML,
    a human readable text format, using a recent ANSI specification.

    Drawback of the binary format is that it is, uhm, binary. Vendors kept
    adding vendor-specific tags to it, and data is not human-readable.
    Advantage is that there are well-established parsers for it, the specs
    are accepted and in the market. And binary is easier to create and read
    by the limited computation power found in the cameras.

    Drawback of the XML format is that it is relatively heavy, i.e. requires
    more space for encoding the same data, and requires more computation
    power to encode and decode it. It is also a relatively new spec which
    means that it currently has no penetration in the market whatsoever.
    There are of course XML parsers, but none that collect data specific for
    this set. The advantage is that it is human-readable, easily extensible,
    and a more orthogonal solution for the problem. It is also, from a
    technological p.o.v., the up to date approach for keeping the meta-data.

    Technologically, both data sets contain the *same* data (or hopefully
    will), i.e. provided an application supports both sets, the user would
    be able to do the same tasks, regardless of a binary Exif or an XML
    container. From this perspective, there is no difference (at least in an
    ideal situation where a 1:1 mapping between the Exif tags and the XML
    tags is given).

    As said, there is currently *not yet* a standardized approach for
    attacking the problem. Thus, the solution is not "take whatever will be
    standardized". This is rather the question.

    Thanks for comments,

    Thomas Richter, Jan 9, 2008
    1. Advertisements

  2. Thomas Richter:
    Yes, no.

    Yes, it's a demand now. With the kind of importance digital cameras
    have _today_, I understand that EXIF-type data has become an important
    feature and should be supported.

    No on the "why ... did not gain"; serious problems in the past were
    (and are)
    * patent issues,
    * the lack of a free implementation like IJG's was for JPEG,
    * the lack of a pressing need to switch formats, JPEG2000 had no
    overwhelming (!) advantage over JPEG (esp. with digital cameras which
    typically don't use the low bitrates where JPEG2000 really shines in
    As a developer, I really want to see that ugly IFD "follow this offset
    pointer to the next structure / to the actual value" system vanish:
    * It's error-prone (dangling pointers).
    * It enables implementations where random access is necessary in order
    to seek to locations before the current position in the input stream
    (cf. arbitrary PDF vs. linearized PDF). Having all the data grouped
    together instead of potentially spread over a file makes it possible
    to do reading with an InputStream and not a RandomAccessFile (in Java
    terminology). Sometimes, "only" the more simple InputStream kind of
    data source (reading, but no seeking) is available, e.g. in servlets
    or strict filter programs reading from stdin and writing to stdout.
    * It's a nightmare to update (necessity to memorize or compute the
    location of values larger than 32 bit before writing them).
    * It comes with that implicit 4 GB (in praxi: 2 GB) limitation because
    of 32 bit offset values.
    And so on. Makes me think of the network model for databases, which
    went the way of the dinosaur when something superior came along.

    XML overhead in terms of space and parsing is negligible already and
    becomes more so every year (even with embedded devices). There are XML
    parsers available for about any programming language under the sun,
    and querying and transformation can be done with languages more and
    more developers know (XPath, XSLT). Provide a big enough area for the
    XML metadata, and in-place editing of the metadata can be accomplished
    easily, avoiding the necessity to rewrite large files just to edit a
    single value.

    About the reuse issue: In the same way IFD parsers exist in current
    graphics software packages already, they probably come with XML
    support as well in order to read and write configuration files and do
    XMP editing (XMP is based on XML).

    Hopefully, someone defines an XMP namespace for EXIF values. According
    there already is a place for XMP data in JPEG2000:
    |JPEG 2000 - 'uuid' atom with UID of 0xBE7ACFCB97A942E89C71999491E3AFAC

    Marco Schmidt, Jan 9, 2008
    1. Advertisements

  3. Thomas Richter

    Bill Tuthill Guest

    The real problem with JPEG2K, from a camera manufacturer's perspective,
    is that it requires too much computing horsepower. Meanwhile I'm glad
    you are trying to solve the EXIF problem. I predict CPU power will
    increase in coming years, so JPEG2K might catch on. Or not.
    Do #1, because #2 is just stupid. XML might be the wave of the future,
    or it could just be a passing fad. There is nothing wrong with EXIF
    in current JPEG, and XML would not improve matters at all.
    Bill Tuthill, Jan 13, 2008
    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.