# Presentation: 522637

## JPEG2000 Performance Result (so far...)

- A HiRISE-centric update by
- Myche McAuley
- 2005-08-31

**Notes:**
Only really considered the impacts of using JPEG2000 for HiRISE RDRs here.  More testing would be required to ensure efficacy with other, non-imaging, data types.

## JPEG2000 Testing

- Characteristics tested for:
- Lossless compression, does it really work?
- Attainable compression ratios?
- Affect of tile sizes on compression ratio?
- Timing characteristics of (de)compression?
- Not critical, but important as JPEG2000 format used for Web artifacts
- Data type support?
- Byte?
- Short?
- Float? (still TBD)
- Large image file support (> 500MB)?

## JPEG2000 Reference Software

- Used both Java and C reference implementations:
- Java: JJ2000
- _[http://jj2000.epfl.ch/](http://jj2000.epfl.ch/)_
- Caveat: compresses 8- and 16-bit data, but doesn’t seem to support decompression to 16-bit
- Didn’t test extensively due to this restriction, but will investigate further
- C: JasPer
- http://www.ece.uvic.ca/~mdadams/jasper/
- Compresses and decompresses 8- and 16-bit data
- Both implementations currently require netpbm formatted files for input (PGM here)

**Notes:**
The JasPer software has been included in the JPEG-2000 Part-5 standard (i.e., ISO/IEC 15444-5), as an official reference implementation of the JPEG-2000 Part-1 codec.
JJ2000 is the Java reference implementation (part 5) of JPEG 2000. This project was the result of a partnership between EPFL, Canon Research France and Ericsson. It ended in September 2001 with a complete implementation of the normative parts of the JPEG 2000 core coding system (part 1).
The reference software libraries would probably be useful in creating JPEG2000 software that would (de)compress JPEG2000 directly without having to use the netpbm intermediate format

## JPEG2000 Testing (cont.)

- Test images must be somewhat indicative of expected MRO HiRISE RDRs:
- Use MEX HRSC data.
- Two HRSC images used:
- h0068_0000_s22.img (~600MB)
- h0068_0009_s22.img (~55MB)
- 1MB == 1024*1024 bytes

## JPEG2000 Test Images

- Additional stresses for the JPEG2000:
- Pretend the HRSC header, binary header table and line prefixes are part of the image data.
- Basically, compress the whole kaboodle and see what happens
- Seeing how the algorithm performs in the face of this extra entropy should by interesting, especially since what we’re after is lossless compression.

## h0068_0000_s22.img

- 2618 x 119757
- Short data type
- Total size:
- 627047673 bytes
- Histogram range:
- With binary “noise”
- Full 16-bit dynamic range
- Image data only
- [67,308],  = 52.5

**Notes:**
Can’t really see much about the image.  Just a big noodle at this resolution

## h0068_0009_s22.img

- 2618 x 11013
- Short data type
- Total size:
- 57664088 bytes
- Histogram range:
- With binary “noise”
- Full 16-bit dynamic range
- Image data only
- [62,188],  = 9.2

**Notes:**
Can make out the binary line prefixes on the left side of image

## JPEG200 Tests - computing environments

- Used two platforms
- Linux
- AMD64, 2.2GHz CPU with 1GB RAM
- Mac OS X
- Dual G5 Mac, 2.5GHz, with 1.5GB RAM
- Only crucial for timing performance, but interesting nonetheless

## JPEG2000 Lossless Compression ratios

**Notes:**
Pretty remarkable to get > 2:1 compression ratios. Although the test images don’t exhibit a great deal of dynamic range.  For SIRTF (Spitzer), 2:1 ws the goal, but we get ~ 1.7 - 1.8
Compression worked in all cases above.  Doesn’t do much good if decompression fails though.

## JPEG2000 (de)compression processing times(times in seconds)

**Notes:**
Almost a zero sum game: smaller time sizes decrease the compression time but commensurately increase the decompression time
And even then, there a cases where decompression will fail with too small a size relative to the original input image size

## JPEG2000 Test Results

- Lossless compression achieved?
- Yes, quite.  Lossless compression ratios > 2:1 are impressive
- Tile size selection can have deleterious impact:
- Smaller tiles better for error containment and web serving, but decrease compression ratio and decompression performance (insignificant issue).  Pathological cases caused decompression to fail (not so insignificant).
- Seems that a tile size of around 256 is pretty good
- Large file size support?
- Yes, > 500MB.  2.3GB tests pending.

## Pending Tests

- Very large file support
- > 2GB (beyond 32-bit addressable range)
- Geometrically corrected and projected images (see next slide)
- Large “blank” border areas
- Images with much larger dynamic range
- Expectation that this will work, but just with lower compression ratios
- Floating point
- Appears to be included in Part 10 of the spec.

**Notes:**
Floating point support could be an issue
Code has lots of bells and whistles that might be useful and, therefore, would warrant further investigation.

## Images still to be tested

- As HiRISE archive will only use JPEG2000 for RDRs, it would follow that these might be map projected (or otherwise geometrically corrected) giving an image that has blank boundaries
- This is expected to compress very well.
- Performance impacts TBD

## Other References

- _[http://www.oreillynet.com/lpt/a/4370](http://www.oreillynet.com/lpt/a/4370%0Dhttp://aroundcny.com/technofile/texts/tec032104.html)_
- _[http://aroundcny.com/technofile/texts/tec032104.html](http://www.oreillynet.com/lpt/a/4370%0Dhttp://aroundcny.com/technofile/texts/tec032104.html)_
- _[http://www.](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)__[ee](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)__[.](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)__[unsw](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)__[.](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)__[edu](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)__[.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf](http://www.ee.unsw.edu.au/~taubman/seminars_files/IEEE_IEA_J2K.pdf)_
- http://www.dsp.toronto.edu/~dsp/JPEG2000/JPEG2000_51to100.pdf