The lead article in the September/October issue of D-Lib Magazine release yesterday is on djatoka, the open source JPEG2000 Image Server from Los Alamos National Laboratory. The authors, Ryan Chute and Herbert Van de Sompel describe their effort in the article abstract:

The ISO-standardized JPEG 2000 image format has started to attract significant attention. Support for the format is emerging in major consumer applications, and the cultural heritage community seriously considers it a viable format for digital preservation. So far, only commercial image servers with JPEG 2000 support have been available. They come with significant license fees and typically provide the customers with limited extensibility capabilities. Here, we introduce djatoka, an open source JPEG 2000 image server with an attractive basic feature set, and extensibility under control of the community of implementers. We describe djatoka, and point at demonstrations that feature digitized images of marvelous historical manuscripts from the collections of the British Library and the University of Ghent. We also call upon the community to engage in further development of djatoka.

The article is very easy to read and is a great overview of how they built the djatoka image server. LANL has a demonstration site with images of the Magna Carta from the British Library. The University of Ghent has also deployed a djatoka installation with some digitized pages of a Gregorian choir book. (The text of the site is in Dutch, I think, but you can click on the square boxes to the right of “Fol.” to bring up the images.) LANL has also put together a screencast demonstration of djatoka, included below.

djatoka is available under the GNU Lesser General Public License. The software has a site on SourceForge with forums for discussion. It runs as a Java servlet, so it is pretty much cross-platform. In the image server is the Kakadu JPEG2000 toolkit and the IIPImage JavaScript Viewer toolkit. One other key piece is a fascinating use of an OpenURL ContextObject to carry the service request information from the browser through the image server to the caching and rendering pieces.

Congratulations and kudos to Ryan, Herbert, and the team at LANL for putting together this great piece of software and releasing it as open source.Ryan Chute, Herbert Van de Sompel (2008). Introducing djatoka: A Reuse Friendly, Open Source JPEG 2000 Image Server D-Lib Magazine, 14 (9/10) DOI: 10.1045/september2008-chute

This posting used to have the tag “– Except for Grayscale?” appended to the end of the title. That is no longer needed; see the bottom of the post for an explanation. We have been implementing University of Michigan’s DLXS software, and DLXS uses JPEG2000 for its image masters. We have been investigating reports of perceived changes in images in the conversion from our old media server to DLXS, and along the way I discovered an important fact: the default parameters for two popular JPEG2000 codecs results in an irreversible transformation. Here is how to address that.

Testing For Equivalence

• On a pixel-by-pixel basis, at high magnification, we looked for differences in the RGB and CMYK values between the source TIFF and the converted JPEG2000 image.
• Comparison by copying and pasting the JP2 on top of the TIF image and selecting “Difference” blending mode between the layers. We then look at the histogram of the resulting image. It should be all black, which shows as a black bar on the far left of the histogram view with the mean, median and standard deviation values all exactly 0.
• Using “Images > Calculations…” with 100% opacity difference blending between source images (the TIFF and the JP2) with the results put into a new document shows in a completely black image. (This is likely equivalent to the test above, but we do it just to be sure).

Another test uses geoimgcmp, which is part of GeoJasPer version 1.3.2. This command should return “0″:

geoimgcmp -f source.tif -F destination.jp2 -m rmse

Jasper via ImageMagick

convert source.tif -o destination.jp2

I ran though the tests, though, and it would appear Jasper/ImageMagick is not using the reversible (integer) wavelet transform.

Kakadu

kdu_compress -i source.tif -o destination.jp2

A colleague did offer some help in the form of parameters that he uses to achieve truly lossless compression:

kdu_compress -i source.tif -o destination.jp2 \
       Creversible=yes -rate -,1,0.5,0.25 Clevels=5

The parameters mean this (from the Kakadu usage documentation):

Creversible=yes

Reversible compression?

-rate -,1,0.5,0.25

One or more bit-rates, expressed in terms of the ratio between the total number of compressed bits (including headers) and the product of the largest horizontal and vertical image component dimensions. A dash, “-”, may be used in place of the first bit-rate in the list to indicate that the final quality layer should include all compressed bits. Specifying a very large rate target is fundamentally different to using the dash, “-”, because the former approach may cause the incremental rate allocator to discard terminal coding passes which do not lie on the rate-distortion convex hull. This means that reversible compression might not yield a truly lossless representation if you specify `-rate’ without a dash for the first rate target, no matter how large the largest rate target is.

Clevels=5

Number of wavelet decomposition levels, or stages.

Note that this implies this important default as well.

Corder=LRCP

Default progression order. The four character identifiers have the following interpretation: L=layer; R=resolution; C=component; P=position. The first character in the identifier refers to the index which progresses most slowly, while the last refers to the index which progresses most quickly.

Conclusions

1. Although one might expect the default options for image conversion programs to be lossless, ImageMagick’s ‘convert’ and Kakadu’s ‘kdu_compress’ commands do result in lossy transformations.
2. For our sample images, using the Kakadu command line options “Creversible=yes -rate -,1,0.5,0.25 Clevels=5” do appear to result in lossless transformations for source TIFF images.

Thanks go out to Rob Buckley, Ron Murray, Kevin DeVorsey, Greg Coats, and David Taubman for their help in figuring this out.

4-May-2007 Update

In response to the question of the lossy settings as a default, Dr. Taubman also notes “that quality is somewhat better (particularly at reduced resolutions) when viewing lossy compressed images using the irreversible options rather than the reversible.” There are reasons for this, primarily due with what I understand as the elimination of image signal noise through through the act of lossly compression, but they are too complicated to address in this already-too-large correction text.

The text was modified to update a link from http://wordnet.princeton.edu/perl/webwn?s=red+herring to http://wordnetweb.princeton.edu/perl/webwn?o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&s=red+herring&i=1&h=1000#c on January 20th, 2011.

The discussion has died down on Jack Nack’s blog posting about the future of JPEG2000 support in Photoshop. Since I last updated my own commentary on the issue, there have been a few more comments, including one by Erich Kesse from the University of Florida. Jack has added a few follow-ups to comments left on his blog, including this one at the bottom of Erich’s comment:

[Thanks for the detailed feedback. I would note that regardless of what Adobe does with JPEG 2000, other developers can create JPEG 2000 reading/writing plug-ins for the app. --J.]

A good point, but I think we’d all like to see Adobe remain committed to JPEG2000, and improve support for the image format across their entire product line. There haven’t been any other public statements on Adobe’s part that I have seen. If you run across one, let us know about it in the comments.

Update (20070515T1703): has done exactly that with a free plugin download for Photoshop that uses the Kakadu engine.

OhioLINK was excited and privileged to participate in the second annual Google Summer of Code — a program to inspire young developers and provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer, and to support existing open source projects and organizations. This is the first of three posts summarizing the efforts of three students; this one details the work of Juan Pablo Garcia Ortiz, a Ph.D. candidate at the University of Almeria in Spain, to build a JPEG2000 JPIP Streaming Server and Client Browser Viewer Applet. This is an edited version of his final report.

The final applications are the ‘jpip_server‘ and the ‘J2KViewer‘ — both of which can be found in the OhioLINK subversion repository. Please note that both are built atop the Kakadu JPEG2000 code library, only a portion of which is included in the OhioLINK subversion repository. ¹

JPIP Streaming Server

The multi-threaded mechanism is implemented with the Linux ‘pthread’ library and uses one thread for each client socket. The source code is written in C++, using the STL library to simplify the code, making it more legible, and orienting it to the object oriented programming philisophy. The different modules of the program are:

• report.cpp (report.h): For the class ‘report’, used to generate the applications logs.
• sock.cpp (sock.h): For the class ‘sock’, used to simplify the sockets work in Linux.
• j2k.cpp (j2k.h): Contains the class ‘j2k_image_file’, used to abstract the work with J2K images. It also contains the necessary code to initialize the Kakadu message handling system.
• jpip.cpp (jpip.h): Contains several classes to support a basic version of the JPIP protocol, over the Kakadu library.
• jpip_server.cpp: The main module.

It is recommended to start from a freshly unpacked (but not yet build) version of the Kakadu library source code (version 5.1). To build this JPIP, follow these steps:

1. At the top level of the Kakadu source directory, checkout the ‘jpip_server’ directory from the OhioLINK Subversion respository. The Subversion URI is https://drc-dev.ohiolink.edu/svn/jpip_server/
2. Change the current directory into ‘jpip_server’ and call the script ‘kakadu_rebuild‘. The script will create the Kakadu directory structure, apply some necessary patches, and build the Kakadu libraries. Please note that this script was written for Kakadu version 5.1 and the patches may not be required in subsequent versions.
3. Run ‘make’ (inside the jpip_server directory)

The accepted parameters by the server can be seen executing ‘jpip_server -u’. The images served by the server must be, by default, in the same directory. The command line option ‘-ipath’ allows you to define a base path for all the requested images. This server can be tested with the ‘kdu_show’ application of the Kakadu package. (kdu_show is a Windows application, but can be executed in Linux with WINE without problems.)

JPIP Browser Applet

1. Checkout of the ‘J2KViewer’ directory from the OhioLINK Subversion respository. The Subversion URI is https://drc-dev.ohiolink.edu/svn/J2KViewer/.
2. From within the J2KViewer directory, run ‘make’.

The build process creates a JAR file containing the viewer applet. It’s correct use would be to sign it with a official signature and include it into the appropriate Web page as an applet. The applet accepts the following parameters:

• “Image“: required, specifies the JPEG2000 image to view. If it’s a local image (not typical), this would be a path name (for example ‘/home/jportiz/image.jp2‘). If it’s a remote image (the typical usage) through the JPIP server, it would be a JPIP URI (for example, ‘jpip://server:9000/image.jp2‘). Do not include any JPIP parameters in this URI.
• “MiniViewWidth“: optional, specifies the width, in pixels, of the mini-view.
• “MiniViewHeight“: optional, specifies the height, in pixels, of the mini-view. The final mini-view size will be the maximum multiple by 2 size of the image that can be included within the specified mini-view size. By default, the mini-view size is 250×250.

To be able to test easily the applet, you can run ‘make test‘ to create a ‘test.html’ file and a ‘test’ script. This script launches the applet viewer with the ‘test.html’ page. It is necessary to modify the ‘Image’ parameter of this HTML page to set the appropriate image location.

To test the applet within a web browser, you can run ‘make test-signed‘ to create a signed JAR file, then open ‘test-signed.html’ with a Java compatible browser. Before opening the HTML page, it is necessary to modify the ‘Image’ parameter within the page to set the appropriate image location.

The viewer has a simple UI. It has a toolbar with two buttons, one to select the interaction mode (zoom or pan) and another one to show the mini-view window. There is a status bar where is showed the real image
size and the current scale, and in the right side, the current number of bytes read. In the center panel is the image — initially scaled by 2 fo fit it in the applet size. This behaviour can be modified easily in the code.

The mini-view window can be moved to any part of the main window. If it’s closed, it can be showed again with the associated button of the toolbar. The mini-view contains a red rectangle outlining the actual view of the main window. This red rectangle can be moved by dragging it and the corresponding view in the main window will be updated.

The applet requires that the Kakadu JNI library is stored in the user home directory (‘C:\Document And Settings\User’ in Windows and ‘/home/user’ in Linux). The applet detects if this library exists and if it is not found the applet allows it to be download automatically from the OhioLINK repository and stored it in the user home directory.

This is a brief description of the implemented classes:

• ChunkedInputStream: An InputStream derived class to decode HTTP chunked messages.
• HTTPMessage: The base class of all the HTTP message classes.
• HTTPRequest: Identifies a HTTP request.
• HTTPResponse: Identifies a HTTP response.
• HTTPSocket: Derives from Socket and allows HTTP messages to be sent and received in an easy way. In only supports send HTTP requests and receive HTTP responses (a client socket).
• ImagePanel: A GUI panel that can be included in any image browser. This panel has the necessary methods to load images and control its visualization. It supports the display of a mini-view of the image. All of the image navigation is controlled directly within this panel.
• ImageWindow: An interface to implement all the parent windows that include an ImagePanel obejct.
• J2KCache: A wrapper class for the Kdu_cache Kakadu class. This encapsulation allows another J2K engine to be used while avoiding the need to modify the design and code of the applet.
• J2KEngine: Contains all the necessary code to initialize the J2K engine. In our case, the Kakadu J2K engine.
• J2KException: A Exception derived class to identify the exceptions generated by the J2K code.
• J2KImage: This class contains all the necessary code to work with J2K images, local files as well as remote URIs. If the image is local, the Kakadu library functions are used to open it. If the image is remote, a J2KReader object is used to retreive the content.
• J2KImageView: Defines an image view, renderable on the screen. This image view is defined by its coordenates, size and resolution level.
• J2KReader: An implementation of a basic JPIP client to read the necessary data of a specific image view.
• J2KRender: Implements the rendering thread of the image browser. This thread is always generating the current image view. It stops when this view is rendered and the image content is completed (if the image is remote, this means that all of the required image codestream blocks have been received).
• J2KViewer: The main class of the application.
• JpipConstants: Defines several global constants related to the JPIP protocol.
• JpipDataInputStream: An InputStream-derived class to extract JPIP data segments from an input.
• JpipDataSegment: Contains the information of a JPIP data segment, which can be either an EOR message or a data-bin segment.
• Mutex: A simple mutex implementation in Java, used to avoid threads conflicts when accessing to the image data.
• StringInputStream: An InputStream-derived class to extract strings from inputs without buffering. Useful to decode HTTP headers and chunks lengths.

The viewer follows the JPIP philosophy in the code structure, especially with remote images. That is, when it is displaying a remote image, there are three threads running in parallel: one for the main GUI, a second for the JPIP comunication that is making the requests and filling the cache with the received data, and a third to render the cache content on the user’s display.

The Java JPIP viewer has been tested in Windows and in Linux. In Windows it has been used the Sun JVM/JRE 1.5 without problems. However, in Linux, this JVM/JRE version seems quite unstable, requiring the previous version, 1.4.2. In Linux the Blackdown JVM 1.4.2 as well as the Sun JVM 1.4.2 have been tested with succesful results.

Future Development Goals

Another feature that was part of the original design but was not completed due to time pressures was to integrate the JPIP server and client into the FEDORA digital object repository system. There is also room for a lot of more features: support of the HTTP-TCPtransport protocol, allow for the display of the image metadata, more GUI utilities like the ability to save the image as a local file for image processing, increase the set of supported JPIP parameters, etc.

Gratitude and Acknowledgements

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/jpip_server/ on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/J2KViewer/ on January 13th, 2011.

The text was modified to remove a link to http://drc-dev.ohiolink.edu/browser/jpip_server/kakadu_rebuild on January 13th, 2011.

Footnotes

1. Editorial comment: although not released with an open source license, the Kakadu JPEG2000 code library is available at a very reasonable cost. Juan Pablo’s efforts initially started with one of the open source JPEG2000 libraries, but it was quickly determined that the Kakadu library was required to meet the demands of the project proposal.