Resolution not in expected header fields

Description

The format specification (15444-1annexi.pdf) defines two sets of header fields for storing an image's grid resolution: 'capture resolution' and 'default display resolution'. However, the description of the 'default display' fields is vague and open to multiple interpretations, whereas the definition of 'capture resolution' is partially incomplete. This has lead to the situation that the software of most vendors will only write to / read from the 'capture' fields, whereas some others (esp. Kakadu's kdu_compress and kdu_expand version 6.4 and earlier) only consider the 'default display' fields.

The standards committee is currently addressing this issue through an amendement to the existing standard (see below).

Risks

As these fields are handled differently by different encoders/decoders, this introduces the risk that future migrations may lead to loss of resolution information. In addition, hardcopy printouts may be printed at the wrong size, and some software products for optical character recognition may fail to process images because the underlying algorithms only work properly if accurate resolution information is available.

Assessment

Check if resolution box exists

Check if capture resolution box exists

Check if display resolution box exists

Resolution handling by popular JPEG 2000 implementations

The table below shows the default fields that are used by a number of widely-used encoder/decoder applications.

Encoder	Capture Resolution	Default Display Resolution
Kakadu kdu_compress (version 6 and before)
Kakadu kdu_compress (version 7 and later)
Aware JPEG 2000 SDK
Luratech command line tool
Adobe Photoshop CS4 with Adobe JPEG2000 plugin
ImageMagick
OpenJPEG

Source: http://www.dlib.org/dlib/may11/vanderknijff/05vanderknijff.html with additional (unpublished) tests by same author.

Recommendations

General

Formulate policy ('control policy') on storage of resolution in JP2s, taking into account existing workflows (including optical character recognition and possible future migrations). Note here that currently most encoders/decoders use the 'capture' fields.

Pre-ingest

Use Jpylyzer to establish if files conform to 'control policy'. Reject any files that do not pass this test.

Existing collections

• Use Jpylyzer to establish if files conform to 'control policy'.
• If files fail the above test, mark this in their associated in metadata. Document the issue and the associated risks.
• Normalisation may be considered. This could be as simple as changing the 'type' field of a 'default display' box to 'capture' (or vice versa). Nevertheless, this would require careful planning and risk assessment.

Additional information

Upcoming changes to the standard

An amendment to the standard (ISO/IEC 15444-1:2004/AMD6) is in preparation which will, among other things, include a more specific description of the resolution fields and their intended use. This should clear up most confusion about this in the future. See also the following blog post by Rob Buckley, and the August 2011 draft of the amendment.

Kakadu

From version 7.0 onward, Kakadu's kdu_compress tool will use the 'capture' fields when converting a TIFF to JP2. This change brings it in line with the amendment (see above) and the existing behaviour of most other encoders (Luratech, Aware, etc.).

References

Buckley, R. Color in JP2. Wellcome Library. April 2011
Van der Knijff, J.M. JPEG 2000 for Long-term Preservation: JP2 as a Preservation Format. D-Lib Magazine Volume 17, Number 5/6. May 2011
ISO/IEC 15444-1:2004/PDAM 6. Updated ICC profile support, bit depth and resolution clarifications. Draft, August 2011.