Benchmarks for JPEG2000 encoders on CPU and GPU
Updated:
These benchmarks compare the Fastvideo GPU JPEG2000 encoder with open-source and CPU-based J2K encoders on the same images. On the GPU, Fastvideo J2K encoding runs many times faster than CPU codecs — the full results for 2K, 4K, and higher resolutions are listed below.
The results on this page are measured against CPU JPEG2000 codecs. For the comparison with the free NVIDIA library on the same GPU, see Fastvideo JPEG2000 vs nvJPEG2000 on RTX 4090 — the full procedure, both sides of the result and the raw logs.
Detailed benchmark data. Measured results are published on our benchmark pages: JPEG2000 decoder benchmarks, DWT / wavelet benchmarks, all benchmarks.
Approaches for JPEG2000 performance measurements
There are two standard approaches to performance measurements of JPEG2000 codecs, which utilize GPU. They correspond to the two most common use cases for J2K encoders and decoders.
1. Single image mode consists in processing of single image and could be called "latency-oriented" or "low latency" approach. In that case the time interval (latency) between availability of original image in RAM and availability of the processed image in RAM is measured. It means that software cannot expect that any additional images will be processed at the same time and therefore cannot take advantage of multiple image encoding or decoding. Overlapping of current image processing with other activities is undesirable because it would increase total latency. We need single image mode almost in all camera applications. You can get more info from our Image & Video Processing SDK.
2. Batch mode consists in processing of batch of images and could be called "throughput-oriented" or "maximum performance". In that case frame rate becomes more important than latency. It is calculated via division of the total time of processing by the number of processed images. Some JPEG2000 codecs are optimized for this use case, meaning that exploiting of task parallelism leads to better frame rate (throughput) at the expense of increased processing time for separate images. It is possible, because we actually have three devices (CPU, GPU and bus interface between them), which can be used simultaneously in that mode, whereas at single image mode these devices are used sequentially for different stages of JPEG2000 algorithm. Moreover, GPU can process several images simultaneously to increase frame rate even more, if each image is too small to load a multitude of GPU cores (especially at Tier-1 stage). Important limitation for simultaneous processing of several images is imposed by amount of free GPU memory. Batch mode is a must for streaming applications when the pipeline contains J2K encoder or decoder. For more complicated workflow it could be better to utilize single image mode, though fps will be reduced.
Briefly, JPEG2000 batch mode can take into account specific methods of task parallelism, based on the following:
- both upload to GPU and download from GPU could overlap with JPEG2000 processing on GPU (CUDA Streams)
- Tier-1 and Tier-2 could be done in parallel: Tier-1 on GPU and multithreaded Tier-2 on CPU at the same time (this is also possible at single image mode)
- multiple (batch) JPEG2000 processing to increase general GPU occupancy
- multiple JPEG2000 processing at Tier-1 to improve GPU occupancy for that particular stage
CPU-based J2K applications have no explicit implementation of batch mode, because all processing stages are done on CPU and complete loading of available CPU cores can be achieved by simply running multiple decoders in separate processes. Multithreaded mode of CPU-based JPEG2000 decoders decreases latency of single image processing, so we can consider this mode as single image mode.
At the moment we don't consider here the following possible modes for J2K encoding on GPU:
- multiple GPU mode
- multiple tile mode for big images
- fast parallel J2K processing with RESET, RESTART, CAUSAL and BYPASS modes
Results for all modes will be published as soon as their implementations are ready.
We don't hide anything concerning benchmarking procedures and achieved results. Thus, everyone can always reproduce our benchmarks, because we publish not only timing and performance, we supply full info about hardware, JPEG2000 parameters, test images and testing modes.
J2K encoder benchmarks
We've carried out time and performance measurements for JPEG2000 encoding for 24-bit images with 2K and 4K resolutions. All results don't include any host I/O latency (image loading to RAM from HDD/SSD and saving back) and we've also excluded host-to-device transfer time. We've done such an assumption to reproduce J2K encoder usage in our conventional image processing pipeline, when initial data reside in GPU memory. Results for GPU-based J2K encoder software also include Tier-2 time on CPU, because this stage in our implementation is performed on CPU. In the tables below, you can find averaged measurements results for the best series of 1000 encoded frames.
JPEG2000 encoding parameters
- File format – JP2
- Algorithm 1 – lossy JPEG 2000 compression with CDF 9/7 wavelet
- Algorithm 2 – lossless JPEG 2000 compression with CDF 5/3 wavelet
- Compression ratio (for lossy encoding) ~ 12.0 which corresponds to visually lossless encoding
- Subsampling mode – 4:4:4
- Number of DWT resolutions – 7
- Codeblock size – 32×32
- MCT – on
- PCRD – off
- Tiling – off
- Window – off
- Quality layers – one
- Progression order – LRCP (L = layer, R = resolution, C = component, P = position)
- Modes of operation – single or batch
- 2K test image (24-bit) – 2k_wild.ppm
- 4K test image (24-bit) – 4k_wild.ppm
Hardware and software
- CPU AMD Ryzen9 7950X (16 cores, 4.5–5.7 GHz)
- GPU NVIDIA GeForce RTX 4090 (Ada Lovelace, 128 SMMs, 16384 cores, 2.2–2.5 GHz)
- OS Windows 11 Pro (x64), version 23H2
- CUDA Toolkit 12.6
JPEG2000 Encoders for comparison
- OpenJPEG 2.5.2
- Jasper 2.0.16
- Kakadu JPEG2000 7.10.2
- CUJ2K 1.1
- Fastvideo JPEG2000 (SDK version 0.22.0.0)
JPEG2000 lossy encoding at single image mode for 2K image: 2k_wild.ppm (1920×1080, 4:4:4, 24-bit)
| JPEG2000 encoders | Average encoding time | Performance MB/s | Frames per second | PSNR (dB) | MSE | Compression ratio | Hardware |
| OpenJPEG (single thread) | 126 ms | 47 MB/s | 7.9 fps | 39.54 | 7.23 | 12.00 | CPU |
| OpenJPEG (multiple threads) | 45 ms | 132 MB/s | 22.2 fps | 39.54 | 7.23 | 12.00 | CPU |
| Jasper | 255 ms | 23 MB/s | 3.9 fps | 39.53 | 7.24 | 12.00 | CPU |
| Kakadu 7.10.2 (single thread) | 59 ms | 101 MB/s | 16.9 fps | 39.44 | 7.39 | 12.00 | CPU |
| Kakadu 7.10.2 (32 threads) | 13 ms | 456 MB/s | 76.9 fps | 39.44 | 7.39 | 12.00 | CPU |
| CUJ2K Encoder | 67 ms | 89 MB/s | 14.9 fps | 35.60 | 17.9 | 12.00 | GPU + CPU |
| Fastvideo JPEG2000 Encoder | 2.23 ms | 2660 MB/s | 448 fps | 39.50 | 7.29 | 12.01 | GPU + CPU |
JPEG2000 lossy encoding at single image mode for 4K image: 4k_wild.ppm (3840×2160, 4:4:4, 24-bit)
| JPEG2000 encoders | Average encoding time | Performance | Frames per second | PSNR (dB) | MSE | Compression ratio | Hardware |
| OpenJPEG (single thread) | 520 ms | 46 MB/s | 1.9 fps | 45.10 | 2.01 | 12.02 | CPU |
| OpenJPEG (multiple threads) | 157 ms | 151 MB/s | 6.4 fps | 45.10 | 2.01 | 12.02 | CPU |
| Jasper | 1069 ms | 22 MB/s | 0.9 fps | 45.09 | 2.02 | 12.02 | CPU |
| Kakadu 7.10.2 (single thread) | 220 ms | 108 MB/s | 4.5 fps | 44.78 | 2.16 | 12.00 | CPU |
| Kakadu 7.10.2 (32 threads) | 36 ms | 659 MB/s | 27.8 fps | 44.78 | 2.16 | 12.00 | CPU |
| CUJ2K Encoder | 123 ms | 193 MB/s | 8.1 fps | 41.42 | 4.69 | 12.05 | GPU + CPU |
| Fastvideo JPEG2000 Encoder | 5.7 ms | 4163 MB/s | 175 fps | 45.08 | 2.02 | 12.04 | GPU + CPU |
MB/s – MegaBytes per second
Fig.1: Fastvideo J2K encoder benchmarks on GeForce RTX 4090 (lossy encoding, single image mode)
From the above figure we can see the encoding speed (JPEG 2000 performance for lossy compression) as a function of image size for Fastvideo J2K encoder at single image mode. Maximum J2K encoder performance could be achieved with codeblock size 32×32 in most cases. For images with frame size more than 6 MB, preferred codeblock size is 32×32 at single image mode. It could also be seen that there is a performance saturation, which is dependent on image size for different codeblocks. This is the key point to get better results at batch mode. For 8K image compression with visually lossless parameters, performance saturation is reached for any codeblock size at single image mode.
Figure 1 shows that on NVIDIA GeForce RTX 4090 it's possible to achieve important milestones at single image mode for visually lossless J2K encoding. For codeblocks 16×16 one can reach 2800 MB/s performance, for codeblocks 32×32 maximum performance exceeds 5200 MB/s, for codeblocks 64×64 maximum performance could reach 4600 MB/s. Performance saturation for codeblocks 16×16 occurs at 4K resolution for visually lossless compression.
Fig.2: Fastvideo J2K encoder performance as a function of compression ratio (lossy encoding, single image mode)
Figure 2 shows Fastvideo JPEG 2000 encoder performance as a function of compression ratio for different image resolutions for lossy compression at single image mode at standard testing conditions as stated above.
Lossless JPEG2000 encoding at single image mode for 2K image: 2k_wild.ppm (1920×1080, 4:4:4, 24-bit)
| JPEG2000 encoders | Average encoding time | Performance | Frames per second | Compression ratio | Hardware |
| OpenJPEG (single thread) | 356 ms | 17 MB/s | 2.8 fps | 2.097 | CPU |
| OpenJPEG (multiple thread) | 61 ms | 97 MB/s | 16 fps | 2.097 | CPU |
| Jasper | 373 ms | 16 MB/s | 2.7 fps | 2.097 | CPU |
| Kakadu 7.10.2 (single thread) | 202 ms | 29 MB/s | 5.0 fps | 2.097 | CPU |
| Kakadu 7.10.2 (32 threads) | 20 ms | 297 MB/s | 50 fps | 2.097 | CPU |
| CUJ2K encoder | 76 ms | 78 MB/s | 13 fps | 2.095 | GPU + CPU |
| Fastvideo JPEG2000 encoder | 3.15 ms | 1883 MB/s | 318 fps | 2.098 | GPU + CPU |
Lossless JPEG2000 encoding at single image mode for 4K image: 4k_wild.ppm (3840×2160, 4:4:4, 24-bit)
| JPEG2000 encoders | Average encoding time | Performance | Frames per second | Compression ratio | Hardware |
| OpenJPEG (single thread) | 1138 ms | 21 MB/s | 0.9 fps | 2.776 | CPU |
| OpenJPEG (multiple threads) | 185 ms | 128 MB/s | 5.4 fps | 2.776 | CPU |
| Jasper | 1331 ms | 18 MB/s | 0.8 fps | 2.776 | CPU |
| Kakadu 7.10.2 (single thread) | 649 ms | 37 MB/s | 1.5 fps | 2.776 | CPU |
| Kakadu 7.10.2 (32 threads) | 53 ms | 448 MB/s | 18.9 fps | 2.776 | CPU |
| CUJ2K Encoder | 147 ms | 161 MB/s | 6.8 fps | 2.773 | GPU + CPU |
| Fastvideo JPEG2000 Encoder | 7.4 ms | 3220 MB/s | 136 fps | 2.776 | GPU + CPU |
J2K encoder performance at batch multithreaded mode
For the multithreaded batch mode we've carried out performance measurements for JPEG 2000 encoding exactly with the same parameters as we used at the single image mode. All results don't include host I/O latency (image loading to RAM from HDD/SSD and saving back). In the table below, one can find averaged measurement results for the best series of frames (each lasting 10 seconds).
| JPEG2000 encoding parameters | Lossy | Lossless |
| 2K image, 24-bit, cb 32×32 | 2108 fps | 1238 fps |
| 4K image, 24-bit, cb 32×32 | 732 fps | 425 fps |
The tables above compare the Fastvideo J2K encoder with OpenJPEG, Jasper, Kakadu and CUJ2K at the same compression ratio and on the same test images, both for single image mode and for batch mode. To make it transparent and simple, we have published all info concerning time measurements, together with sample images, JPEG2000 parameters and hardware specifications to offer everyone an opportunity to reproduce our results and to check performance measurements of other J2K encoders at the same testing conditions. Our demo GPU J2K encoder for Windows could be downloaded from our download page. This is the link to Fastvideo J2K decoder benchmarks.
Further reading
- Benchmarks for J2K decoders on CPU and GPU — the same comparison for decoding
- JPEG2000 on GPU: Fastvideo JPEG2000 and nvJPEG2000 on RTX 4090 — open comparison with the free NVIDIA library: the method, both sides of the result, raw logs
- Fast JPEG2000 Codec on GPU: CUDA Encoder and Decoder — features, licensing and support
- Benchmark methodology and test environment — how we measure
About the author
Fyodor Serzhenko, PhD, is the founder and CEO of Fastvideo. He earned his PhD at the Moscow Institute of Physics and Technology (MIPT) in 1993. Since 2009 he has led the development of Fastvideo’s GPU-accelerated image codecs and ISP modules, including the Fastvideo SDK. Connect on LinkedIn.
Why you can trust these results
Fastvideo has built GPU-accelerated image processing software since 2009. Our codecs comply with the standards they implement — JPEG (ITU-T T.81 / ISO IEC 10918) and JPEG2000 (ITU-T T.800 / ISO IEC 15444) — and our tools are open source on GitHub. Every performance figure we publish is reproducible: see our benchmark methodology, download the Fastvideo SDK benchmark report (PDF), and measure it on your own GPU.