[gdal-dev] New JPEG 2000 Driver

[Even Rouault]

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