Exif Metadata in JPEG2000: Request for Comments

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:

>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