Aaron, benchnmarking exercices are difficult in general, and even more with JPEG2000 and its trillions of possible variants. You would need to specify library versions, how the library was exercised exactly (gdal_translate or the XXX_decompress utilities of the library), use of multithreading, etc etc. For example, I've seen recently openjpeg to perform better than Kakadu on decompression of DIMAP 2 (2048x2048 tiling) products.
> 4. support for new Part 15 of the JPEG 2000 standard (HTJ2K) which promises > up to **10x** speedup Did you have a chance to test how the reality of performance compares with the promise :-) ? Anyway, this is secondary to my main concern. I should first say, I'm far from being objective, as I've been involved in OpenJPEG development. It seems you've done significant advances with Grok, and this is great to see, but this leaves me a bitter taste to see the scarce expertise of open source developers on JPEG2000, which is an extremely hard-to-master technology, to be split between 2 sister libraries (Grok was forked from OpenJPEG). And the consequence of that is now that GDAL would have to pay the price for the fork. Can you transparently tell us why Grok is AGPL licensed ? Do you sell commercial licenses for people who couldn't comply with the AGPL license ? Nothing at https://github.com/GrokImageCompression/grok indicates so, neither do I see mentions of copyright assignment to you for people that want to contribute to Grok that would enable you to do that. So what's the point of the license change ? If Grok was BSD licensed, provided that Grok indeed performs better than OpenJPEG in most situations we care about, then we'd might probably want to have just keep the JP2Grok driver and kill JP2OpenJPEG. Best regards, Even -- http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
