The February 2008 issues of the Notices of AMS includes a three-page article by David Austin, professor of mathematics at Grand Valley State University, that explains how JPEG and JPEG2000 (J2K) compress image data. Austin also wrote an article in 2007 about JPEG entitled “Image Compression: Seeing What’s Not There.” Both article contain many formulas and are not for the mathematically challenged. Anyone, though, can glean useful information especially towards the end of each article, when he returns to looking at the big picture (no pun intended).
In talking about J2K, Austin notes that its "principal advantage lies in providing a much more flexible format for working with images in environments where the increased complexity [of the format] is not problematic." In other words, he is saying that one should not automatically choose J2K over JPEG. According to him, each have their advantages.
Thanks to Peter E. Murray for pointing out current article.
Technorati tag: JPEG2000
1 comment:
In commenting on your post, I would first transform the author's comment to the following more controversial one: "... principal advantage lies in providing a much more flexible format for working with images in environments where the increased complexity of the archiving system can become problematic."
Having generalized the issue of archival element complexity to the full archival system - with Producers on one end and Consumers on the other, I would then note how and where complexity comes and goes based on archival system functions. At this point, the definition of an archival information management system become interesting. If one reads the actual OAIS specification regarding how Dissemination Information Packages (DIPs) are generated for Consumers/end-users (p. 4-15 – 4-16), archival system operations that would create, package, and deliver images tuned to end-user requirements within the archive are introduced as one of several possible types of "special processing."
Issues arise as to which formats can support this operation in its specified place within the OAIS functional model. "Traditional" digital library practices - TIFF & derivative based - does not support this function very well, and have led to overall system designs that remove on-demand image quality delivery possibilities entirely from the archive model. The reasons offered for this are usually based on the fact that TIFF-type master images be scaled (spatial/tonal) for delivery.
System designers must then either reduce end-user quality options upfront (only certain sizes/quality levels are available from some locations outside the archive), and/or in some cases, systems just unload the full-quality image to the end-user. One can argue that the "Generate DIP" function was placed within the OAIS specifically to allow that system to serve "Consumers" without a dependency on other IT systems - a goal described in the OAIS document.
If you consider that (a.) the OAIS spec as an enumeration of necessary functions that could and are executed anywhere system designers please, and (b.) the functions are usefully gathered in one "place" in the spec to show how to reduce overall complexity of the archival system, then
* Exporting the "Generate DIP" (for image content) from the tightly defined OAIS to - wherever local system designers put it - increases the complexity of the OAIS.
* Instead of a specified and standalone operational OAIS, one encounters instead a OAIS + System A's Generate DIP + plus System A's Deliver Response complex. If multiple organizations submit to the same archive, our definition of that specified OAIS' functionality must include all of the Producer's respective Generate DIP + Deliver Response(s).
Seen in terms of the OAIS model as specified in the ISO document, the above sounds like a design tradeoff where overall system complexity is increased in order to retain file format simplicity.
Before the advent of formats like JPEG 2000, system designers had no choice but to accept this tradeoff. Now they do have a choice - but becoming aware of possibilities that new imaging formats provide for critical OAIS functions is a first, necessary, step.
Ref.: OAIS document http://public.ccsds.org/publications/archive/650x0b1.pdf
Post a Comment