Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Lossless encoding

j2kdriver.exe –-set-input-image <imagefilename.tif> –-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 <outputfilename.jp2>

Notes on individual options:

  • “–set-input-image ” reads file into the encoder’s memory-buffer and auto-detects the input file format
  • “– set output-j2k-color-xform YES” 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.
  • “–set-output-j2k-error-resilience ALL” This function will take the following parameters, each explained below by Aware’s Alexis Tzannes.
    • SOP to enable Start of Packet markers
    • EPH to enable End of Packet Header markers
    • SEG to enable segmentation symbols
    • ALL to enable all of the above
    • NONE to disable all of the options
  • “–wavelet-transform R53” specifies use of the reversible “integer 5-3 filter” (compression) to produce a losslessly encoded JPEG2000 file.
  • “–set-output-j2k-bitrate 0” 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 […].”
  • “–progression-order RLCP” “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.
  • “–tile-size 1024 1024” 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.

Resynchronization markers

Start of Packet (SOP), End of Packet Headers (EPH). These are used to signal the beginning of each packet and the end of each packet header, and can be used to resynchronize in the case of missing or corrupted data. This allows the decoder to detect and discard entire corrupted packets. 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.

Segmentation symbols

This adds a special four symbol code to specific locations in the compressed data stream, enabling error resilient decoders to detect errors, if this symbol is corrupted. This allows the decoder to detect and discard corrupted bitplanes. 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.

Lossy encoding

j2kdriver.exe –-set-input-image-file <imagefilename.tif> –-set-output-j2k-color-xform YES –-set-output-j2k-error-resilience ALL –-wavelet-transform I97 –-set-output-j2k-progression-order RLCP –-set-output-j2k-psnr 46 –-tile-size 1024 1024 –output-file-type JP2 –-output-file-name <imagefilename.jp2>

“–wavelet-transform I97” specifies use of the “irreversible 9-7 filter” to produce a lossy encoded JPEG2000 file.

“–set-output-j2k-psnr 46” 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 method for dynamically resetting the db value if the file appears to have been too heavily compressed.

Creating a Windows batch file

If you would like to run your encoding script over a directory of TIFF images (for example), you can create a simple batch file.

Example

for %%f in (*.tif) do j2kdriver.exe –-set-input-image-file “%%f” –-set-output-j2k-error-resilience ALL –-set-output-j2k-progression-order RLCP –-set-output-j2k-ratio 8 –-tile-size 1024 1024 –-output-file-type JP2 –-output-file-name “%%~nf.jp2”

  • No labels