JPEG2000 Encoding with CUDA

For the last few days we have been struggling to efficiently write out very large JPEG-2000 files. In all their wisdom Erdas decided to supply only a 32-bit version of the ECW compressor. It seems to have trouble allocating memory for large JPEG-2000 files, is single threaded and dead-slow. Somewhere in the Ermapper install directory there is also the Kakadu core dll. So I decided to have a look at other methods of creating JPEG-2000, possibly faster and more scalable options. Kakadu seems to only supply an SDK and we can test the speed of compression with the SDK. GDAL also supports building against the Kakadu SDK and would be handy for creating the large mosaics we have been struggling with. It seems with modern hardware that is not the fastest option.

After some trial with Kakadu and a bit of reading I came across a few CUDA based implementations - CUJ2K and JPEG2K.  I decided to port the most recently maintained CUDA based JPEG-2000 implementation, claiming to be the fastest on commodity hardware to windows. The CMake based build system makes things easier. The code however was written for a POSIX based systems so I was missing a bunch of headers. I had to hack away at it and move variables around to cope with lack of C99 compliance in the MSVC C-Compiler or I am forced to used the /TP flag to upgrade the C-files to C++ files and allow variable declaration anywhere. Lots of moving variables around later, everything worked fine.

The compression library is built against FreeImage which functions as an I/O driver for the encoder/decoder. However only writing to the J2K profile is supported, a wrapper for the JP2 mode will be required to add-in all the projection metadata GIS Rasters typically require. To make this library more useful for GIS purposes we will need to add an I/O handler for GDAL instead of FreeImage to allow faster compression/decompression.

I have tested the JP2ECW, JP2OpenJPEG and JP2Kakadu drivers on a small file (26MB in .bmp format, since the Kakadu demo binary does not support LZW .tif I have lying around). The times averaged over a few runs on an i7-3930K @ 3.2GHz are shown below:

• LibECW - 0.8s
• Kakadu (1 Thread) - 1.5s
• Kakadu (8 Threads) - 0.5s
• OpenJPEG - 2s

Compared to these the CUDA library on the GTX580 on the same machine runs at 1.2s (with compression taking 0.75s, rest is I/O).  The logical next step is hooking up the compressor to GDAL for data-block I/O and building a JP2 wrapper in addition to the J2K profile which it currently uses. The Affero GPL licence also needs to be sorted out.

For those interested in the windows build, here is the SVN Diff against rev 84 and the pre-built release binaries against CUDA 5.5.

Building Liblas for Win x64 with GDAL and Geotiff

Some things are obvious to even the most oblivious, how to get liblas from OSGeo4W is one of them. However you quickly run into trouble as images, dem files and las files get bigger and the 32 bit osgeo builds start causing issues. There have been some discussions regarding a 64 bit version of Osgeo4W but getting builders for all the packages probably hasn't been achieved yet. I will see if I can step in and fill my drive with source trees and wield my MSVC 2010 license for good rather than evil. It is now up on the OSGeo GSOC ideas page, may be someone will take it up and make GIS toolchain deployment easier.

Liblas install for OSGeo4W set-up

Anyway here is how to built Liblas, assuming you are reasonably familiar with downloading sources and clicking a few buttons in CMake GUI. Grab LibLAS 1.7.0 sources. Since we want to add image support, grab GDAL 64 bit builds with headers from GISInternals. Build Geotiff 64 bit by hand using the handy CMake system, pointing it to proj and tiff obtained from the GDAL build above. Grab Boost from the handy distribution in PCL, you can get it somewhere else but PCL was my last port of call for boost. The final Liblas config page in CMake should look something like below.

CMake Liblas config

Change CMakeLists.txt for LibLAS to include the boost chrono library, there are linker errors otherwise.

find_package(Boost 1.38 COMPONENTS program_options thread chrono REQUIRED)

MSVC 2010 Liblas project

Configure and build away. I use MSVC 2010 Professional, running the bigfile_test after building has finished creates a 4GB+ dummy .las file and is nice for checking the x64 version. Put all the dependency DLL's in place after the build has finished using the handy Dependency walker.

Dependency walker check for libraries

Most windows users do not have a compiler installed and the inability to get a GIS toolchain on windows which can handle large datasets beyond 32bit restrictions is a major stumbling block in the wider adoption of the OSGeo toolchain. You can grab my Liblas binaries here and if you are interested student looking to package for 64bit let  OSGeo know.