IIIF Community Call :: HTJ2K : High-Throughput JPEG2000

HTJ2K : High-Throughput JPEG2000
Encoding / Decoding Test Results

Ruven Pillay
IIPImage Maintainter / Imaging scientist, C2RMF
ruven@users.sourceforge.net

Objectives

The goal of these tests is to evaluate the performance of HTJ2K under typical IIIF usage scenarios and using the kinds of image content typically used by users for IIIF

IIIF is most commonly used for pan and zoom via a browser to display images from the cultural heritage sector

This typically requires the use of an IIIF-compatible image server

Pan and zoom usage requires the ability of the IIIF server to rapidly extract regions from a source image at a specific size.

Evaluating HTJ2K

Objectively measure the real performance of the format for our use case and compare to JPEG2000 Part 1 and to TIFF for both lossy and lossless encoding

HTJ2K Performance Metrics

Which performance metrics are useful to measure?

  1. Compression size
  2. Encoding speed
  3. Decoding speed

HTJ2K Implementations

How do different software implementations of HTJ2K compare?

  1. Kakadu
  2. OpenJPEG
  3. Grok
  4. For TIFF: Vips & libtiff

Test Environment

How does HTJ2K perform in a real production environment?

  1. ~1000 images from the Getty collection
  2. Linux (Ubuntu 20.04 LTS)
  3. Run natively on bare metal for these particular tests (no Docker etc)
  4. High-end production server: 16 core Intel(R) Xeon(R) CPU / RAID 10 disk array

Compressed File Size

All 1000 images compressed both lossy and losslessly using all the available codecs

  • TIFF encoded using vips
  • JPEG2000 Part 1 using OpenJPEG, Kakadu and Grok
  • HTJ2K using Kakadu and Grok (lossless only for Grok / OpenJPEG unable to encode)

→ 11 different output files for each of the 1000 Getty images

Tiled Pyramid TIFF

vips tiffsave input.tif output.tif --tile --pyramid --tile-width 256 --tile-height 256 -Q 90 --compression jpeg

OpenJPEG: JPEG2000 Part 1

opj_compress -i input.tif -o output.jp2 -r 8 -n 7 -c "[256,256],[256,256],[256,256],[256,256],[256,256],[256,256],[256,256],[128,128]" -b "64,64" -p RPCL -SOP -TP R -PLT -threads ALL_CPUS

Kakadu JPEG2000 Part 1 & HTJ2K

kdu_compress -i input.tif -o output.jp2 -rate 3 Clayers=1 Clevels=7 Cprecincts="{256,256},{256,256},{256,256},{256,256},{256,256},{256,256},{256,256},{128,128}" Corder=RPCL Cblk="{64,64}" Cuse_sop=yes ORGgen_plt=yes ORGtparts=R ORGgen_tlm=8 -quiet
kdu_compress -i input.tif -o output.jp2 -rate 3 Clayers=1 Clevels=7 Cmodes=HT Cplex="{6,EST,0.25,-1}" Cprecincts="{256,256},{256,256},{256,256},{256,256},{256,256},{256,256},{256,256},{128,128}" Corder=RPCL Cblk="{64,64}" Cuse_sop=yes ORGgen_plt=yes ORGtparts=R ORGgen_tlm=8 -quiet

Grok JPEG2000 Part 1 & HTJ2K

grk_compress -i input.tif -o output.jp2 -r 8 -n 7 -c "[256,256],[256,256],[256,256],[256,256],[256,256],[256,256],[256,256],[128,128]" -b "64,64" -p RPCL -S -tile_parts R
grk_compress -i input.tif -o output.jp2 -r 8 -n 7 -c "[256,256],[256,256],[256,256],[256,256],[256,256],[256,256],[256,256],[128,128]" -b "64,64" -p RPCL -S -tile_parts R -M 64

Size Results

JPEG2000 can achieve significantly better compression than TIFF lossy (JPEG) or lossless (deflate)

HTJ2K compressed files are slightly larger than for JPEG2000 Part 1

Different JPEG2000 codecs produce very similar output

Encoding Time

Each combination of format and codec compressed 3x with the times averaged

Encoding Time Results

Large differences between codecs

Kakadu significantly faster for all types

HTJ2K encoding faster than JPEG2000 Part 1 especially for lossless encoding

Lossless JPEG2000 encoding faster than lossy encoding for all codecs and JPEG2000 types

Decoding Time

For pan and zoom type use, decoding time is by far the most important criteria as encoding is only performed once offline

Essential processes that contribute to Latency during pan and zoom:

  1. User pan and zooms to region of image and browser requests tiles corresponding to this region
  2. IIIF server opens image file format and seeks to data corresponding to the image region
  3. Server decodes encoded data corresponding to this region
  4. Server transcodes this data into a format usable by the web browser
  5. Transcoded image in JPEG (or PNG or WebP etc) sent to browser

Methodology

Use most widely used and fastest IIIF server:
IIPImage (https://iipimage.sourceforge.io)

The IIPImage server provides precise (microsecond) timing information for each internal process

A set of random IIIF tile requests created on a subset (the 50 largest images) of the Getty images

100 random IIIF tile requests made at different locations and resolutions for each image, resulting in 5000 requests in total

The same 5000 IIIF requests used for all decoding tests

Decoding Results

Tiled pyramid TIFF is by far the fastest format for random tile access on large images

For JPEG2000, OpenJPEG remains significantly slower than Kakadu: 10x slower for lossy up to 15x slower for lossless

HTJ2K decoding is about 2x faster for lossy JPEG2000 and ~20% faster for lossless for both OpenJPEG and Kakadu

Conclusions

Tiled pyramid TIFF has a very optimized structure for random tile access, which is hard to compete with in terms of decode times

JPEG2000 capable of much better compression than TIFF

HTJ2K is both faster to encode and decode than JPEG2000 Part 1

HTJ2K files are slightly larger than JPEG2000 Part 1, but not by much

HTJ2K is compatible with current versions of both OpenJPEG and Kakadu

OpenJPEG remains, despite recent improvements, very slow with respect to Kakadu

IIIF servers such as IIPImage can decode HTJ2K without modification

https://github.com/IIIF/htj2k

Docker on AWS