JPEG2000 Image Encoding & Decoding Open Source Options Presently the Robertson Library relies on the proprietary, closed-source Kakadu project for JPEG2000 image processing, both internally with our own collections, and as an implied dependency in the large image content models and solution packs which are released as part of the Islandora project. Islandora is not unique in so doing. The progress of open-source JPEG2000 codecs has been slow and hampered by poor performance and reliability issues. In March 2011 I undertook to review the situation with respect to open-source JPEG2000 encoding and decoding utilities to compare their performance and reliability.

Platform All processing was done on my MacBook Pro (OSX 1.6.6 / 2.8GHz Core 2 Due / 8GB at 1067 MHz). This is by no means scientific as, while I mostly tried to leave the machine idle during processing, I was using it intermittently for other purposes. I also did some encoding/decoding on an iMac running OSX 10.5.8 with 4GB ram and a 2.2GHz processor, as well as a machine running Ubuntu 10.04 server edition with an Athlon X2 64 4200+ (2.2GHz) chip and 6GB @ 800MHz and offer some comments about this below, but for benchmarking purposes only the results from the primary machine are included.

Utilities 1. Kakadu (bundled with Djatoka 1.1) 2. ImageMagick (6.6.7-8 compiled with homebrew) 3. GraphicsMagick (1.3.12 2010-03-08 compiled with homebrew) 4. OpenJpeg (compiled from svn with homebrew on 2011-03-05) ImageMagick and GraphicsMagick both were compiled with OpenMP (multi-threading) support, but despite experimenting with the OMP_NUM_THREADS environment variable I never saw a process utilize more than 100% CPU, or a single core for any process done during these tests. Additionally I did a comparison round of lossless LZW compressed TIFFs using GraphicsMagick (which, as we'll see below, significantly outperformed ImageMagick) as a comparison.

Images I processed 13 images in total, ranging from 23MB to 1.3GB. All images either started as, or were pre-converted to, 8-bit-per-channel RGB, uncompressed TIFFs. 1. IMG_9356.tif (23MB - random personal photograph) 2. 0168-33.5x23cm-lot59_61_eq.tif (36MB - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 3. 0220-69.5x31.5cm-lot48rd_eq.tif (99MB - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 4. IsldStJohn-Macnutt_eq.tif (132M - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 5. 0241-44.5x74cm-lot5_eq.tif (145M - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 6. 0124-128x41.5cm-lot59_eq.tif (235M - abbyy:/mnt/Digitization/Island_Imagined

1 of 8

2015-01-14, 12:37 PM

/mapsprocessed/ingested/) 7. PIA03231.tif (242M - pulled out of the production Island Imagined repository - PID unknown) 8. 0002-127x55.4cm-lot1.tif (382M - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 9. 0204-40x296cm-PriQuCoLine_eq.tif (551M - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 10. UPEI-lakemap-4_eq.tif (974MB - abbyy:/mnt/Digitization/Island_Imagined /mapsprocessed/ingested/) 11. world.200407.3x21600x21600.B1.tif (1.3GB - converted from PNG found @ http://visibleearth.nasa.gov) 12. world.200407.3x21600x21600.A1.tif (1.3GB - converted from PNG found @ http://visibleearth.nasa.gov) 13. world.200407.3x21600x21600.B2.tif (1.3GB - converted from PNG found @ http://visibleearth.nasa.gov)

Process For each source image, two rounds of encoding were used, one for lossless encoding and another for lossy. I borrowed our kakadu encoding pameters from ImageManipulation.inc in the Islandora package, then invented parameters for ImageMagick, GraphicsMagick and OpenJpeg to attempt to achieve similar results. ImageMagick & GraphicsMagick (IM & GM for short) rely on the Jasper project for J2K compression, whereas OpenJpeg does its own thing. IM & GM allow manual setting of certain Jasper J2K parameters, but not nearly to the extent which does Kakadu (e.g. multiple precinct dimensions). OpenJpeg accepts encoding parameters which more closely mimic Kakadu. Following compression, each tool was used to decompress each JP2-encoded image back to TIF. No combination of compressor and decompressor yielded a result which was a binary copy of the source, so another method had to be employed to test for losslessness. Graphicsmagick was used to create a diff composite image from source to each decompressed TIF; a textual histogram of each composite image was produced in order to compare the degree of deviation from start to finish. An output image was considered lossless if the composite diff was pure black. (Additionally, the degree of image degradation can be roughly measured by multiplying the number of changed pixels times the degree of change for each, and dividing by the total number of pixels.) The following suggests all results stemming from an input, for illustrative purposes. Input.tif input/kdu_lossless.jp2 input/kdu_lossless.seconds.txt input/kdu_lossless/kdu.tif input/kdu_lossless/kdu.seconds.txt input/kdu_lossless/kdu.hist.txt input/kdu_lossless/kdu.hist.png input/kdu_lossless/oj2k.tif input/kdu_lossless/oj2k.seconds.txt input/kdu_lossless/oj2k.hist.txt input/kdu_lossless/oj2k.hist.png input/kdu_lossless/im.tif input/kdu_lossless/im.seconds.txt input/kdu_lossless/im.hist.txt input/kdu_lossless/im.hist.png input/kdu_lossless/gm.tif input/kdu_lossless/gm.seconds.txt

2 of 8

2015-01-14, 12:37 PM

input/kdu_lossless/gm.hist.txt input/kdu_lossless/gm.hist.png input/kdu_lossy.jp2 ... input/oj2k_lossless.jp2 ... input/oj2k_lossy.jp2 ... input/im_lossless.jp2 ... input/im_lossy.jp2 ... input/gm_lossless.jp2 ... input/gm_lossy.jp2 ... input/lzw_lossless.tif input/lzw_lossless.seconds.txt input/lzw_lossless/gm.tif input/lzw_lossless/gm.seconds.txt input/lzw_lossless/gm.hist.txt input/lzw_lossless/gm.hist.png I'll refer to inputs, encoded images, and outputs. This is a lot of processing. I wanted to decode each encoded image with each decoder to measure the relative performance of decompressors, but also to see if the encoders created encoded images which played nice with other utilities.

Results Unsurprisingly, Kakadu was the clear performance winner for JP2 compression and decompression among all images. Kakadu's performance boost over the next-fastest JP2 compressor increased with input filesize. Put another way, the performance of other J2K tools dropped off markedly on inputs over 250MB. Failures: OpenJpeg failed on 0002-127x55.4cm-lot1.tif (382MB) and all images larger than that. In fact, it took some fenagling even to get it to compress a 241MB input. Additionally, OpenJpeg failed on smaller images on a machine with less RAM. OpenJpeg critical image size seems proportional to system RAM. ImageMagick/GraphicsMagick also failed to encode the largest images on a machine with less RAM. GraphicsMagick outperformed ImageMagick on virtually every operation I measured. The discrepancy between the two was greatest when JPEG2000-encoding the largest inputs. However... Early examination of output histograms revealed that GM consistently failed to produce lossless JP2 images (I tried a few configurations). The loss was typically minuscule, representing about 0.0034% change from source (compared to about 0.25% change for

3 of 8

2015-01-14, 12:37 PM

a 48x-compressed lossy image created with kakadu). Therefore, I ceased production of GM lossless images to speed up the process. Though it isn't represented in this document (which is looking mainly at encoding, OpenJpeg failed to decode some of the largest JP2 images, and the difference in speed between the FOSS tools and kakadu tended to take off with very large images.

Lossy For lossy images, Kakadu took on average 20% the amount of time of the next fastest encoder, which was almost always GM.

Comparing compression ratios among lossy encodings is pretty meaningless, as you generally specify an output bitrate or compression ratio at encode time. More interesting is a comparison of image deviation due to compression at a given bitrate from one utility to the next. This data is contained in the output histograms, but I have not yet processed it all.

Lossless For lossless images, Kakadu took on average 26% the amount of time of the next fastest JP2 encoder, which was typically IM (GM being disqualified for not-perfectly-lossless results).

4 of 8

2015-01-14, 12:37 PM

LZW Lossless Compression Throwing GM-based LZW tiff compression into the mix provides an illustrative counterpart. The best JP2 encoder (Kakadu) took on average 1.7x the amount of time as a simple LZW tiff compression, though this dropped off and reversed slightly with the largest (1.3TB) images. The compression rate for lossless JP2 was about 1.39x that of an LZW-encoded TIFF. In other words, we pay an encoding performance penalty of about 1.7x for a compression boost of about 1.39x by using J2K and Kakadu for archival-quality lossless preservation versus simply recoding those images using LZW compression.

5 of 8

2015-01-14, 12:37 PM

However, there's more to consider. Without additional processing, JP2 encoders throw away potentially significant EXIF data on compression. Following is an example of EXIF data for one of the test inputs:

http://support.vre.upei.ca/attachments/1304/UPEI-lakemap-4_eq.exif.txt

Update: See new section "Metadata" below This is not insignificant. Even simple data such as the image resolution (dpi) is lost. It is possible to convert EXIF to XML and embed this in JP2 images with kakadu, but to my knowledge we don't currently do this nor do we know how. It's unclear to me whether we could reliably map such metadata back to EXIF on decode even if we wanted to. To my knowledge, most (if not all) of our JP2-based large image content models actually retain both the original TIFF and a lossless JP2, though in some cases we may have deleted the TIFF. In the case where we have both, the lossless JP2 is both less accessible and less archival (due to lost metadata) than the TIFF.

Effect of Parallelism Kakadu's performance edge should be viewed with an asterisk. That being, Kakadu was the only utility I tested which achieved multi-threaded processing. As such, it was the only process which was able to make use of both my system's two cores. My understanding is that our production Drupal environments, where J2P compression would be performed on ingest, run in virtual machines which are allocated a single virtual core. In such an environment, I would expect Kakadu's performance edge over the FOSS JP2-encoding tools to be cut in half.

6 of 8

2015-01-14, 12:37 PM

Conclusions? GraphicsMagick is the best FOSS tool for creating lossy J2K. ImageMagick is the best FOSS tool for creating lossless J2K. I hold out hope for GM. GM's purpose is to be more stable, slower-moving, and standards-driven than IM. Until semi-recently, IM was also unable to produce truly lossless JP2. I expect GM will follow. I had high hopes for OpenJpeg once I realized how to configure it. Unfortunately, it really disappointed. To quote Petr Pridal (author of IIPImage): "[OpenJPEG] looks promising for the future." Kakadu still kicks the crap out of FOSS J2K tools by a long shot.

Recommendations Based on these tests, it seems like it would be a good idea to consider utilizing GM for conventional (non JP2) image processing versus IM which we currently require. I have not yet done the work to see if Djatoka can still be made to work without Kakadu. I recommend doing that work and, assuming it can be done, that we release this to the world and especially make use of it in our VirtualBox image. (We can still include a script of explicit instructions on how to get the real Djatoka after the VBox image is imported.) Personally I prefer LZW-encoded TIFFs with EXIF data intact over lossless JP2s. My reasons are thus: JP2 doesn't feel "steady" yet. It probably won't until there are FOSS tools which begin to catch up with the commercial ones. LZW is a safe, expired patent. 1 It's widely supported. LZW is faster to encode. A goodly amount of interesting data relative to our capture process is contained in EXIF. It doesn't seem smart to just throw that away. If we're really going to be librarians about the need to keep every pixel exactly as it was when it was captured, then I think we need to keep the EXIF, too. If, on the other hand, we're willing to throw away the EXIF, then I don't think we should be storing lossless images at all when a 48x-compressed JP2 is something like a quarter of a percent "different" than an original. That 0.25% is probably similar to the environmental uncertainty involved in capturing the images to begin with.

Resources Also attached are two additional files: jp2k.sqlite is an SQLite database which contains both compression and decompression stats. encoded.ods is a spreadsheet in which I did some calculations and made the graphs above.

References 1.

LZW Compression Encoding - Sustainability of Digital Formats, Planning for Library of Congress Collections

Updates! Metadata

7 of 8

2015-01-14, 12:37 PM

The testing routines above were based on the version of Kakadu which is packaged with Djatoka. Kakadu's executables don't seem to display versioning information, but the core library in that distribution is named v60. The version of the source received with our license is v6_4_1-01119N -- which compiles out to a library named v64. This newer version of kakadu seems to automatically retain an existing XMP metadata profile from the source image and embed this in compressed JP2s. Previous versions did not. I can also confirm that neither imagemagick, graphicsmagick nor openjpeg accomplishes this either. However, various procedures to extract image metadata and store it are detailed here: http://www.sno.phy.queensu.ca/~phil/exiftool/metafiles.html Screen_shot_2011-03-08_at_2.13.39_PM.png (78.1 KB)

Zac Howarth-Schueler, 03/08/2011 02:19 pm

Screen_shot_2011-03-08_at_2.13.56_PM.png (77.2 KB)

Zac Howarth-Schueler, 03/08/2011 02:19 pm

Screen_shot_2011-03-08_at_3.26.19_PM.png - Lossless Compression Rates (76.2 KB)

Zac Howarth-

Schueler, 03/08/2011 03:26 pm

UPEI-lakemap-4_eq.exif.txt

- Sample EXIF Data (3.97 KB)

encoded.ods - Figures on JP2 Encoded Images (93.2 KB)

Zac Howarth-Schueler, 03/08/2011 03:38 pm Zac Howarth-Schueler, 03/08/2011 04:04 pm

jp2k.sqlite - SQLite database of compression/decompression stats (117 KB)

Zac Howarth-Schueler,

03/08/2011 04:06 pm

testjp2.sh kdu.hist.txt

- My processing script (9.53 KB)

Zac Howarth-Schueler, 03/08/2011 04:34 pm

- Sample composite histogram (text). (746 KB)

kdu.hist.png - Sample composite histogram (PNG). (130 KB)

8 of 8

Zac Howarth-Schueler, 03/08/2011 04:57 pm Zac Howarth-Schueler, 03/08/2011 04:57 pm

2015-01-14, 12:37 PM

JPEG2000 Image Encoding & Decoding -

Jan 14, 2015 - parameters which more closely mimic Kakadu. Following compression, each tool was used to decompress each JP2-encoded image back to.

375KB Sizes 1 Downloads 363 Views

Recommend Documents

Visually Lossless Encoding For JPEG2000.pdf
Whoops! There was a problem loading more pages. Retrying... Whoops! There was a problem previewing this document. Retrying... Download. Connect more ...

Visually Lossless Encoding for JPEG2000 ieee.pdf
Each component is then independently transformed to. the wavelet domain by the DWT, and compression is achieved. via bit-plane coding of wavelet ...

Systematic encoding and decoding of chain reaction codes
Nov 17, 2011 - 690-697 (Oct. 1998). Paris, et al., “Ef?cient broadcasting protocols for video on demand”,. International Symposium on Modeling, Analysis and Simulation of. Computer and Telecommunication systems (MASCOTS), vol. 6, pp. 127-132 (Jul

Learning encoding and decoding filters for data representation with ...
Abstract—Data representation methods related to ICA and ... Helsinki Institute for Information Technology, Dept. of Computer Science,. University of Helsinki.

Systematic encoding and decoding of chain reaction codes
Nov 17, 2011 - Frojdh, et al., “File format sub-track selection and switching,” ISO/. IEC JTC1/SC29/WG11 MPEG2009 M16665, London UK., Jul. 2009, 14 pp. Gao, L. et al.: “Ef?cient Schemes for Broadcasting Popular Videos,”. Proc. Inter. Workshop

SOFTWARE ARCHITECTURES FOR JPEG2000 David ...
The paper is informed by the au- thor's own work on the ... JPEG2000 also supports .... transform involving finite support operators may be ob- tained by applying ...

SOFTWARE ARCHITECTURES FOR JPEG2000 David ...
The paper describes non-obvious implementation strategies, state machines, predictive algorithms and internal ..... The first collects statistics from code-blocks.

Geometric Encoding
troid and approximate length of the space is a. 85 summary parameter derived from the boundaries. 86. Thus, global geometric coding with respect to the. 87 principal axis would involve encoding the correct. 88 location during training as the location

Iterative Decoding vs. Viterbi Decoding: A Comparison
probability (APP). Even though soft decision is more powerful than hard decision decoders, many systems can not use soft decision algorithms, e.g. in GSM.

Hybrid Decoding: Decoding with Partial Hypotheses ...
Maximum a Posteriori (MAP) decoding. Several ... source span2 from multiple decoders, then results .... minimum source word set that all target words in both SK ...

Hybrid Decoding: Decoding with Partial Hypotheses ...
†School of Computer Science and Technology. Harbin Institute of .... obtained from the model training process, which is shown in ..... BLEU: a method for auto-.

pdf file encoding
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. pdf file encoding.

Phonics Encoding Decoding.pdf
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. Phonics ...

pdf change encoding
Loading… Whoops! There was a problem loading more pages. Retrying... Whoops! There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. pdf change encoding. pdf chan

Iterative Decoding vs. Viterbi Decoding: A Comparison
hard and soft decision Viterbi decoders (we use hard decision type decoders only, for the channel, where data is in the binary format only), and convert the hard ...

pdf encoding problem
Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. pdf encoding problem. pdf encoding problem. Open. Extract.

High-quality JPEG2000* software with enhanced server platform
Kakadu Software, a business of New South Innovations based at the University ... Software Development Kit (SDK)* is a comprehensive, heavily optimized, fully ...

Speech coding and decoding apparatus
May 30, 2000 - United States Patent. Akamine et al. ... (List continued on next page.) Issued: ... section, a prediction ?lter and a prediction parameter cal. [30].

Decoding the Digital Consumer - Rackcdn.com
consumption platform. Subscriptions are making some headway but churn looks set to become an important part of the digital .... of the world's most popular music app and to the fact that music video is a really important part of the digital music ...

Wiki - JPEG2000/Viewer Testing - Roblib Project ... -
14 Jan 2015 - All processing was done on my MacBook Pro (OSX 1.6.6 / 2.8GHz Core 2 Due / 8GB at 1067. MHz). ... on an iMac running OSX 10.5.8 with 4GB ram and a 2.2GHz processor, as well as a machine running ... Following compression, each tool was u

Narrow Bus Encoding for Low Power Systems
Abstract. High integration in integrated circuits often leads to the prob- lem of running out of pins. Narrow data buses can be used to alleviate this problem at the cost of performance degradation due to wait cycles. In this paper, we address bus co

Activity Guide - Encoding Color Images
the bits from this example. Step 2: 6-‐bit color. Tutorial Video: ​more bits per pixel for ... For example, to make a teal color (shown right) whose 12-bit value is: 001110101011 We can represent a 12-bit color in ... This is to avoid confusion w