[gdal-dev] write JPEG2000 with codek KAKADU without .tif

Even Rouault even.rouault at mines-paris.org
Thu Aug 16 05:20:57 PDT 2012


Selon Evgeniy Borovenskiy <eborovenskiy at scanex.ru>:

> No, at the moment I use the variant in which the file '.tif' with the use of
> the driver GTiffDataset is created. And then through CreateCopy() JPEG2000 is
> created.
> I'd like to create a JPEG2000 file straigh away because the size of images
> are very big and the intermediate file '.tif' can be more than 20GB. In one
> of the examples of KAKADU compressor it said that it's possible to record not
> the whole picture at once but to record the pictures in parts. Am I write or
> it's impossible to record the pictures in parts?

The Kakadu API allows that, but not the GDAL JP2KAK driver. Well, internally to
the CreateCopy() method, it does actually rely on the capability to write the
picture by pieces. It is just that it is not exposed, because there might be
restrictions that would not respect the contract of Create(), which allows
random writes of blocks, and even re-write of them. Perhaps that GDAL could have
a relaxed Create(), which would advertize restricted write capability, that
would at least allow sequential write of the data, but that doesn't exist
currently.

>
> Is it possible to write the function 'create' for KAKADU that will create the
> driver for the direct record of JPEG2000 for the buffer (it's desirable to
> record the picture in parts)?

One option that could satisfy your need is to take inspiration of what is done
in the gdaldem utility to make the color-relief option works even with drivers
that have only CreateCopy() capability. See the GDALColorReliefDataset and
GDALColorReliefRasterBand classes in
http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdaldem.cpp . Basically you
must create a intermediate dataset class and rasterband class, the later
implementing IReadBlock(), and you would pass the intermediate dataset as the
source dataset to the CreateCopy() of the JP2KAK driver. The IReadBlock() will
be called by JP2KAKCreateCopy() each time it needs data, which would allow you
to generate it on-the-fly from whatever data you have.

It is certainly less flexible that the full random write capabilities offered by
Create(), but that's the only method I can see that doesn't require extending
the JP2KAK driver.


More information about the gdal-dev mailing list