Hi, I've just done changes in GDAL to be able to use the newly released openjpeg version: https://trac.osgeo.org/gdal/ticket/7074
For trunk, - for linux builds, autoconf now uses pkg-config to be able to support more easily the /usr/ include/openjpeg-2.X path pattern - for windows build, your option OPENJPEG_CFLAGS option now must point directly to the the include/openjpeg-2.X path For branches/2.2, I've just extended the previous painful pattern to handle openjpeg versions. (if you use GDAL 2.2.2 unmodified, you can just copy rename/symlink the include/ openjpeg-2.3 to include/openjpeg-2.2, and that will build fine as well) Even ---------- Forwarded Message ---------- Subject: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement Date: jeudi 5 octobre 2017, 02:42:41 CEST From: Antonin - OpenJPEG <[email protected]> To: [email protected] <[email protected]> Good news everyone ! OpenJPEG 2.3.0 is released today: https://github.com/uclouvain/openjpeg/releases/tag/v2.3.0 This new release finalizes the work made by Even Rouault and funded by several academic institutions and archival organizations to make OpenJPEG significantly faster and safer. In addition to what has been done in v2.2.0 (multithreading at decoding, speed optimizations, memory consumption reduction, etc, see http://www.openjpeg.org/ 2017/08/10/OpenJPEG-2.2.0-released for details), this release adds improvement to sub-tile decoding. Now when you handle a huge single tile image and only wants to decode a small part of it, only the window of interest is actually processed: sounds quite natural but I can ensure it wasn't that easy to implement. This leads to drastic speed and memory improvements as they now only depend on the size of the window and not on the original image size. This release also adds the ability to decode only a subset of components. Overall, if we compare performances of OpenJPEG before all Even's optimizations (v2.1.2) and the ones reached by the new v2.3.0 release, we observe a 55-60% speed improvement on a single thread whole image decoding (even more on big images like 10000x10000). Memory consumption is also drastically reduced on mega-image decoding: for example, for a full decoding of a single tile 8000x12000 image, it is reduced from 2 to 1.3 GB RAM. But more importantly, OpenJPEG is now a workable solution for workflows involving partial decoding. Benchmarks are hard to compare as there are many variables that can influence the results: so if you are an OpenJPEG user, please download and try this new release within your workflow ... And share your feedback, that would be highly appreciated. As indicated above and described in a previous post (https://groups.google.com/d/msg/ openjpeg/CltNQpbbwm4/jajpDKq0AAAJ), all this has been made possible thanks to a funding from academic institutions and archival organizations, namely: - Wellcome Library - Stanford University - Nationale Bibliotheek van Nederland (KBNL) - University of Michigan - University of California, Los Angeles (UCLA) … And logistic support from the International Image Interoperability Framework (IIIF), the Council on Library and Information Resources (CLIR), intoPIX, and of course the Image and Signal Processing Group (ISPGroup) from University of Louvain (UCL, Belgium) hosting the OpenJPEG project. Thanks to all of them ! Many thanks also to Even Rouault, the developper who actually implemented these improvements, and of course to all contributors having suggested fixes or enhancements. Enjoy, Antonin More info: News: https://github.com/uclouvain/openjpeg/blob/v2.2.0/NEWS.md Changelog: https://github.com/uclouvain/openjpeg/blob/v2.2.0/CHANGELOG.md Full Changelog: https://github.com/uclouvain/openjpeg/compare/v2.1.2...v2.2.0 -- You are subscribed to the mailing-list of the OpenJPEG project (www.openjpeg.org) To post: email to [email protected] To unsubscribe: email to [email protected] For more options: visit http://groups.google.com/group/openjpeg OpenJPEG is mainly supported by : * UCL Image and Signal Processing Group (http://sites.uclouvain.be/ispgroup) * IntoPIX (www.intopix.com) ----------------------------------------- -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
