I needed help remembering when it was that we began making JPEG2000 images. I ran a search against the Harvard Library’s preservation digital repository, DRS, and it looks like we first deposited a JP2 image in 2004.
Over the intervening six years, we’ve refined and settled on a single recipe that we use to produce lossy-compressed images, and another that we use to produce losslessly-compressed JP2s. I’ll share these recipes with you below. My reasons for sharing are two:
1) Depending upon the software used, there are many encoding combinations to consider - many more than one would have to consider when cooking up the more familiar and less complex TIFF. My group uses the Aware JPEG2000 SDK encoder. Flipping through Aware’s 330 page manual (“AccuRad J2KSuite Developer’s Guide”), I count...152 different command line options. In sharing our recipes (the combination of options and parameters that we invoke ), I’d like to speed others along in developing their own encoding formulations and JP2 production workflows.
2) Not only are there many encoding options to consider, but some are complex and a bit intimidating. Honestly, I don’t know what the “--set-input-raw-channel-subsampling” or “--set-output-j2k-rd-slope” options do. I do think that I understand the options that we use, but I may hear from one of you that my understanding is flawed and that our recipe could be improved upon, or at least better understood and explained. Here you go.
Lossless encoding (Windows command line)
j2kdriver.exe --set-input-image --set-output-j2k-color-xform YES --set-output-j2k-error-resilience ALL --wavelet-transform R53 --set-output-j2k-bitrate 0 --set-output-j2k-progression-order RLCP --tile-size 1024 1024 --output-file-type JP2 --output-file-name
- I believe that one does not need to call this option explicitly; YES seems to be the default value. The transform referred to here is a colorspace transformation from RGB to YUV. This conversion is made prior to compressing the data. Applying compression to YUV data is more efficient, yielding smaller files than the same compression applied to the unconverted RGB data.
- This function will take the following parameters, each explained below by Aware’s Alexis Tzannes.
- So the SOP and EPH are basically tags that signal the beginning and end of a packet (a piece of coded data) in the file. If a packet gets corrupted the error resilient decoder can resync using the next SOP packet marker. The idea here is that if one packet in a file is bad, we don't lose everything that comes after it (as was the case with original JPEG). With JPEG 2000, you could lose a packet and have a small area of the image go bad, but the decoder can recover and keep on decoding.
- So this is similar, but less granular, as it operates at the bitplane level, each bitplane may include multiple packets. Overall, these features would be useful in noise prone environments or over unreliable networks.
- Quoting from the “AccuRad J2KSuite Developer’s Guide”: “Sets the output image bitrate, in bits per pixel. A bitrate of 0 indicates that all the quantized data should be included in the image. This creates lossless images if the R53 wavelet is chosen Sets the output image bitrate, in bits per pixel. A bitrate of 0 indicates that all the quantized data should be included in the image. This creates lossless images if the R53 wavelet is chosen [...].”
- “For a given tile, the packets contain data from a specific layer, a specific component, a specific resolution, and a specific precinct. The order in which these packets are interleaved is called the progression order. The interleaving of the packets can progress along four axes: layer, component, resolution and precinct.” [1] A progression order that begins with “R” (resolution) indicates that the data is organized so that low resolution information will be decoded first, followed and augmented by the remaining higher resolution data in the codestream.
- This tile size was prescribed, as it was said to be optimally matched to the software our library uses to dynamically generate and deliver JPEG files from stored JP2 masters.
- The pSNR function was selected because it effectively, although imperfectly, modulates the level of compression applied to each image based on the image's particular characteristics: the arrangement and variability of raster values. When we set the pSNR value to 46 db for the page-images that we create, we've come to expect a very high-quality encoded image. There are cases (certain kinds of photographs, illustrations with fine thin lines) where a 46 db setting would produce a too heavily compressed file. Too guard against over-compression, we have developed an effective (although a bit crude) method for dynamically resetting the db value if the file appears to have been too heavily compressed. This is a topic for another day.
No comments:
Post a Comment