[gdal-dev] gdal_translate making NITF-JPEG2000 : memory exhausted?

[Even Rouault]

Le jeudi 03 février 2011 21:19:08, Jay Jennings a écrit :
> In fact, we do have a Kakadu license here... but I see in NITFCreateCopy()
> that JP2ECW and JasPer are the only two JPEG-2000 options currently
> supported. Any idea how difficult it would be if I tried to implement
> JP2KAK
> as an additional option for NITF creation ?

Actually, I just see that JP2KAK should be supported, but it is a very recent 
addition in GDAL trunk (1.9.0dev) that is not in 1.8. See 
http://trac.osgeo.org/gdal/changeset/21534

> 
> -----Original Message-----
> From: gdal-dev-bounces at lists.osgeo.org
> [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam
> Sent: Wednesday, February 02, 2011 5:29 PM
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] gdal_translate making NITF-JPEG2000 : memory
> exhausted?
> 
> On 11-02-02 05:20 PM, Jennings Jay wrote:
> > I have recently built GDAL including the optional JasPer library for
> > JPEG-2000 support. Using gdal_translate, I am able to convert smaller
> > GeoTIFFs into NITFs with JPEG-2000 this way. The first two attempts
> > (both color uncompressed GeoTiff less than 200 MB) worked fine, with
> > lossless compression and reduced in size by 67% and 59% respectively.
> > 
> > The problem came when I tried the same command on a bigger (950 MB)
> > GeoTIFF: gdal_translate apparently sucked up all available memory (as
> > indicated by Physical Memory Free = 0 in Task Manager) then the app
> > crashed.
> > 
> > Are there any workarounds in such a case ? It looks like the "-multi" and
> > "-wm" parameters aren't available in gdal_translate.
> > 
> > PS This is a Windows 7 64-bit machine with 8 GB RAM.
> 
> Jay,
> 
> This is a limitation of the JasPer based driver which is "whole image in
> RAM at once" oriented due to the way the JasPer library is structured.
> You could use the Kakadu or ECW based encoder though these have somewhat
> involved licensing issues.  In theory we should be able to use the
> OpenJPEG jpeg2000 implementation for this but I'm not aware of it having
> been tested in the JPEG2000 in NITF case yet, and it may also not support
> setting the jpeg2000 creation options to be truely NITF compliant.
> 
> Best regards,