Hi Even, Thanks. You have certainly made remarkable improvements to OpenJPEG, especially considering the amount of time you were able to spend on the code.
Regarding benchmarking, I totally agree, there are many many different workflows and configurations. I chose lossless compression/decompression for my few tests because there is no quality vs. performance tradeoffs to worry about, and decoder's can't really "cheat" - they have to decode all the bits, so the numbers give a fairly good idea of how the core routines perform. I would be interested in looking at some DIMAP 2 images, if there are any freely available. For the promise of 10x improvement with HTJ2K, it's good to be skeptical :) I see around 2X speed up with current unoptimized OpenJPH implementation, which doesn't use SIMD or concurrency, so I don't think it will be hard to realize that promise. But, we'll have to see. As for the scarcity of open source expertise along with JPEG 2000, I also agree. But the bar to entry isn't as high as it used to be - we have high-quality open source implementations, so anyone who wants to spend a few months, (or years :) ) reading and re-reading the big blue JPEG 2000 book and looking through the code is welcome to do so -it's not that tough. They should then be able to contribute. if they have the time and interest. I chose AGPL in part because of my experience with OpenJPEG. The code was neglected for years under the current license, even by the project's sponsors, who had the resources and expertise to dramatically improve the code. I like AGPL because it enforces contributions back to the project. Although, to be honest, I've done 98% of the work on the library over the past 5 years. This is partly just the nature of open source, especially for maddeningly complex standards like JPEG 2000. Many have opinions but few are prepared to roll up their sleeves and do the work. I want to emphasize that this new driver would be completely optional - I have absolutely no plans or interest in replacing the OpenJPEG driver, or in changing the GDAL license, just for a single plugin. If even 20% of the GDAL user base can benefit from the better performance, I think it would be worthwhile. Of course, this would require time from a GDAL committer, so that's up to you or another committer to decide if it's worth the time. If this PR is approved I will probably get more involved with the project, because I like to work on performance optimization and geospatial work flows are challenging, so this is another reason perhaps to consider saying yes to the merge :) Cheers, Aaron
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev