[gdal-dev] New JPEG 2000 Driver

Aaron Boxer boxerab at gmail.com
Sun Feb 28 06:10:08 PST 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210228/f31b6a1c/attachment.html>


More information about the gdal-dev mailing list