Exif Metadata in JPEG2000: Request for Comments

Discussion in 'Digital Photography' 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
    advice.

    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
     
    Thomas Richter, Jan 9, 2008
    #1
    1. Advertising

  2. Thomas Richter:

    >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?


    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
    comparison).

    >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.


    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
    to
    <http://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Location_in_File_Types>,
    there already is a place for XMP data in JPEG2000:
    |JPEG 2000 - 'uuid' atom with UID of 0xBE7ACFCB97A942E89C71999491E3AFAC

    Regards,
    Marco
     
    Marco Schmidt, Jan 9, 2008
    #2
    1. Advertising

  3. Thomas Richter

    Alfred Molon Guest

    In article <fm2caa$bpe$-stuttgart.de>, -
    berlin.de says...

    > 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?


    Obviuosly a format which has exif issues is not going to be accepted by
    the photographic community. But the main issue is that JPEG is the
    standard and JPEG2000 does not offer significant advantages.

    It may be much better at high compression levels, but at low compression
    levels (1:10 or better) typical of digital photography it is not better
    than JPEG (better in terms of image artifacts).

    > 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.


    xmp would be better.

    > 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,


    That is less relevant today because memory is very cheap.

    > and requires more computation
    > power to encode and decode it.


    Also irrelevant because most devices have sufficient processing power.
    --

    Alfred Molon
    ------------------------------
    Olympus 50X0, 8080, E3X0, E4X0, E5X0 and E3 forum at
    http://tech.groups.yahoo.com/group/MyOlympus/
    http://myolympus.org/ photo sharing site
     
    Alfred Molon, Jan 9, 2008
    #3
  4. Thomas Richter

    Bill Tuthill Guest

    Thomas Richter wrote:
    > 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?


    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.

    > 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.


    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
    #4
  5. Thomas Richter

    Alfred Molon Guest

    In article <4789b691$>, says...

    > > 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.

    >
    > 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.


    The advantage of XML is that it's a human readable format, which is why
    it would be better. And since JPEG2000 is an entirely new format, it's
    not clear why it should use the old EXIF format of JPEG. There is really
    no advantage in doing so.
    --

    Alfred Molon
    ------------------------------
    Olympus 50X0, 8080, E3X0, E4X0, E5X0 and E3 forum at
    http://tech.groups.yahoo.com/group/MyOlympus/
    http://myolympus.org/ photo sharing site
     
    Alfred Molon, Jan 13, 2008
    #5
  6. Thomas Richter

    Roy G Guest

    "John H. Guillory" <> wrote in message
    news:...
    > On Sun, 13 Jan 2008 09:47:09 +0100, Alfred Molon
    > <> wrote:
    >


    YAWN !
     
    Roy G, Jul 25, 2008
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bob Smith

    new jpeg2000 format

    Bob Smith, Apr 8, 2004, in forum: Digital Photography
    Replies:
    4
    Views:
    596
    Michael Schnell
    Apr 8, 2004
  2. AWolf
    Replies:
    0
    Views:
    706
    AWolf
    Nov 2, 2004
  3. David Remley Photography

    Best freeware windows program to harvest all Exif metadata

    David Remley Photography, Jul 3, 2008, in forum: Digital Photography
    Replies:
    2
    Views:
    462
    Susan
    Jul 3, 2008
  4. Giuen
    Replies:
    0
    Views:
    1,010
    Giuen
    Sep 12, 2008
  5. Valerian Kadyshev
    Replies:
    5
    Views:
    835
    John Turco
    Aug 18, 2011
Loading...

Share This Page