Hi Jukka, > To: [email protected] > From: [email protected] > Date: Fri, 21 Mar 2014 14:26:21 +0000 > Subject: Re: [gdal-dev] New compression library based on gdal design > > Aaron Boxer <boxerab <at> gmail.com> writes: > > > > > Hello, > > I recently started developing an open source jpeg2000 compression library > using opencl. > > I would like to base the library design on the very successful gdal > library design. > > Can anyone recomend any resources to help me to grok the high level design > of gdal? > > > > Thanks so much, > > Aaron > > Hi, > > I would like to see something that is open source and fast with JPEG2000. I > think that it would be OK to support only a subset of JPEG2000 standard if > the basic operations would be super fast. I took just a moment ago some > timings for another purpose but they may be interesting. I converted the > same 12000x12000 pixel image (432 MB uncompressed) with a few different > methods: > > GDAL (64-bit) from tiff to tiff: 3 seconds > GDAL (64-bit) ECWJP2 (SDK 5.0) from lossless JPEG2000 to tiff: 21 seconds > GDAL (64-bit) JP2KAK (SDK 7.3.2) from lossless JPEG2000 to tiff: 14 seconds > Kakadu 7.3.2 (64-bit) kdu_expand from lossless JPEG2000 to tiff: 7 seconds. > > The new library with opencl should be at least as fast as ECWJP2 with GDAL > but the faster the better. > > It is interesting to see that native Kakadu application was two times faster > than GDAL with JP2KAK driver of the same Kakadu version. Of course the use > case is very simple.
Your test image was in fact 12000x12000x3 (=432 MB). That might explains why, maybe the GDAL driver is dealing with one band at the time, requesting to run the decompression 2 times more than the other application. > > -Jukka Rahkonen- > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
