OpenJPEG might be usable

You know about Jpeg2000 right? Wavelet compression, top notch work of the 90’s, an image compression format that promises better results than JPEG and can be lossless for some pixel types. Well it totally exists and commercial software uses it quite a bit. It has taken quite a hold of the satellite imaging sector as it allows image compression to 1/6th the size of a traditional TIFF. Unfortunately there doesn’t seem to be any good open source libraries available for everyone else. There’s Jasper, OpenJPEG, and CQJ2K but they were always a magnitude or more slower than the commercial product Kakadu.

OpenJPEG had an official 2.0.0 release on December 1st of last year and it is actually worth a glance. Unfortunately the current release of GDAL, version 1.9.2, doesn’t support this new release. It was designed for a prototype of OpenJPEG found at revision 2230 of OpenJPEG’s SVN repo. If you are willing though, the new OpenJPEG v2 release contains the executables opj_decompress and opj_compress for conversion of JP2 files to and from TIFF, PNG, and JPEG formats. Another alternative is also downloading the current development version of GDAL 1.10 which has support for the new OpenJPEG v2 library and can leverage it to read things like NTF. I performed some rough / unscientific tests of these configurations this weekend and my notes are below. My conclusion is that OpenJPEG 2.0.0 is decently nice and I can’t wait for the next release of GDAL so that I can roll it into Ames Stereo Pipeline.

Conversion times for 400 MB JP2 to 2 GB Tiled TIFF
Command Time Peak Memory
OJP r2230's j2k_to_image greater than 2 days ~1 MB
GDAL 1.9.2's gdal_translate w/ OJP r2230 greater than 2 days ~10 MB
OJP v2's opj_decompress 4 min ~2 GB
GDAL 1.10's gdal_translate w/ OJP v2 w/ GDAL_CACHEMAX=512 5 min ~600 MB

Interesting GDAL Usage Examples

Despite first appearances, GDAL is way more than an image I/O library. I routinely use it resize images, transcode images, and reproject images. But did you know that it can also draw contour lines, write kml, and orthorectify RPC images? Even if you did, I think it’s good to document here because I keep forgetting.

Render Contour Lines

Publishing DEM’s created by ASP is a tricky because it is easiest visualize height change through a color gradient. That loses its usefulness when publishing to a conference where they print in gray scale. A snazzier option would be a hill-shaded render of a DEM with contour lines plotted on top. You can see an example on right and the commands below:

gdaldem hillshade <DEM> output.tif -z 0.000012
gdal_contour -i 50 <DEM> contour
gdal_rasterize -burn 0 -l contour contour output.tif

The “-z” value on gdaldem hillshade requires some playing around to figure out what is best for your image. The “-i” value on gdal_contour is the interval between lines in units of height defined by the DEM (for ASP products, it’s meters).

KML Outline of a Cube File’s footprint

Rendering of KML outputEver wanted to provide context for your ISIS cube file image on Google Earth? These commands allow you visualize the image on right. The first two lines are ISIS commands.

footprintinit from=<ISIS Cube File>
isis2gml from=<ISIS Cube File> to=output.gml label=footprint
ogr2ogr -f KML output.kml output.gml

Orthorectify an RPC image on a DEM

This one doesn’t apply to planetary imagery, but most Earth images tend to have an RPC camera model attached to them. Download a DEM from USGS’s NED, and then with GDAL you can drape your source imagery over the DEM.

 gdalwarp -of GTiff -co TILED=yes -co COMPRESS=lzw -r cubicspline \
    -rpc -to RPC_DEM=<your DEM> <RPC image> output.tif -dstnodata 0