Comment 4 for bug 158435

This is to note two things: (1) how to test that we have the right spatial resolution information stored, and (2) that we plan to put in exif data anyway, even though we'll have the resolution stored in a standard way.

(1) Testing the spatial resolution:
If you run the jhove program (http://en.wikipedia.org/wiki/JHOVE for a description; home page http://hul.harvard.edu/jhove/), in the form:
   jhove my_file.jp2
it will report a lot of metadata. If the jp2 box for the capture resolution is filled, part of this data will appear in
   JPEG2000Metadata > Codestreams > Codestream > NisoImageMetadata
in the fields SamplingFrequencyUnit, XSamplingFrequency, YSamplingFrequency.

For example, the sampling frequency unit might be centimeters, and the frequencies would in this case be in dots per centimeter.

If the jp2 box for the capture resolution is not filled, you won't see this. If the resolution is put in some other box, such as display resolution, you'll see something, but not the specific resolution numbers you put in.

The exif tool will also show the capture resolution info, but the "identify -verbose" command does not show this (ImageMagick version 6.2.4).

(Note that use of the capture box is called for in the National Digital Newspaper Program jpeg 2000 profile.)

(2) Now, even though we've already rigged up the software to do this (for color images, but grayscale will call the same functions i think), we still plan on inserting exif data for compatibility with existing tools (and the data we put in the header will still be a tiny, tiny percentage of the total file size).

[As usual, if anybody has any suggestions, advice, cautions, etc, please let me know, and thanks in advance.]