[gdal-dev] gdal_merge is very slow

[Leith Bade]

Unfortunately I can't afford a Kakadu license for personal use so I am using
the precompiled demo binaries. (
http://www.kakadusoftware.com/index.php?option=com_content&task=view&id=26&Itemid=22
)

As you can see they only have a 32-bit build (and it is not even compiled as
Large Address Aware
http://msdn.microsoft.com/en-us/library/wz223b1z%28VS.80%29.aspx - this
would allow 4GB)

Currently if you use them on a large image without setting flush_period
kdu_compress will continue to allocate memory until it reaches the magical
2GB limit at which point the program crashes with the message:
"This application has requested the Runtime to terminate it in an unusual
way."

This is annoying as to use flush_period you need to break the image into
sufficiently small tiles which has a very bad effect on the performance of
the viewer when zoomed out a lot.

I note that the ERDAS ECW SDK has no memory limitation issues and will
happily compress the image into 1 tile, but the quality of the result is not
as nice as kdu_compress.

Would be nice for them to compile the 32bit with the /LARGEADDRESSAWARE
linker flag, and also provide a 64bit version too. But then I am not paying
them for it...

Thanks,
Leith Bade
leith at leithalweapon.geek.nz



On 19 July 2010 05:58, Greg Coats <gregcoats at mac.com> wrote:

> On Jul 18, 2010, at 12:44 AM, Leith Bade wrote:
>
> kdu_compress also has a memory limit at 2 GB
>
>
> Not true. Based on your comment, I suspect that you are using a version of
> Kakadu that is more than 3 years old, or that was deliberately compiled for
> a 32 bit environment.
>
> Since version 6.0, released on 15 Aug 2007 (essentially 3 years ago),
> Kakadu has included makefiles for 32 and 64 bit environments. Since then, I
> compile Kakadu with Makefile-MAC-x86-64-gcc, and this builds 64 bit
> applications, that automatically support and use more than 2 GB RAM.
>
> I suggest that you use Kakadu version 6.4, compiled for 64 bits, because it
> adds to kdu_compress the -progress option, that allows the user to ask for a
> progress report, at a user specified interval. For example, every 1000 lines
> kdu_compress -i in.tif -o out.jp2 Creversible=yes -progress 1000
> Copying Geo  tag info, size =     387
>         Progress with current tile row = 20.000000%
>         Progress with current tile row = 40.000000%
>         Progress with current tile row = 60.000000%
>         Progress with current tile row = 80.000000%
>         Progress with current tile row = 100.000000%
>     Finished processing 1 of 1 tile rows
>     Initiating final codestream flush ...
> Generated 1 tile-part(s) for a total of 1 tile(s).
> Greg
> http://homepage.mac.com/gregcoats/jp2.html
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100719/0441b464/attachment.html