[gdal-dev] Fwd: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement

Fri Oct 13 11:06:40 PDT 2017

Matt,

I've been able to build GDAL with OpenJPEG 2.3.0 by using
the changeset_40330.diff patch (from the GDAL Trac) and no args for
--with-openjpeg:

https://github.com/sgillies/frs-wheel-builds/blob/master/Dockerfile.wheels#L105-L144

These GDAL builds are in the rasterio 1.0a10 wheels on PyPI.

On Fri, Oct 13, 2017 at 11:47 AM, Matt Hanson <matt.a.hanson at gmail.com>
wrote:

> Hi Even,
>
> Great work with OpenJPEG! I'm trying to get GDAL trunk compiled with
> support for it, but I can't get configuration to find it properly.  On an
> Amazon base linux image my simplified Dockerfile is like this:
>
> ```
> RUN \
>     wget https://github.com/uclouvain/openjpeg/archive/v2.3.0.tar.gz; \
>     tar xvf v2.3.0.tar.gz; \
>     cd openjpeg-2.3.0; mkdir build; cd build; \
>     cmake .. -DCMAKE_BUILT_TYPE=Release; \
>     make; make install; make clean;
>     #cd ../..; rm -rf openjpeg-* v2.3.0.tar.gz;
>
> RUN \
>     git clone https://github.com/OSGeo/gdal.git; cd gdal/gdal; \
>     ./configure --with-openjpeg
> ```
>
> Even though it appears that --with-openjpeg doesn't take any arguments, I
> tried anyway with:
> --with-openjpeg=/usr/local
> --with-openjpeg=yes
> --with-openjpeg=/usr/local/include/openjpeg-2.3,/usr/local/lib
>
> I also tried with GDAL 2.2.2 and creating the symlink from
> /usr/local/include/openjpeg-2.2 to /usr/local/include/openjpeg-2.3
>
> I've not been able to get configure to turn on openjpeg support.
>
> Are there additional dependencies I'm missing, or is this a problem on
> trunk?
>
> Thanks so much in advance!
>
> Matthew Hanson
>
>
>
> On Thu, Oct 5, 2017 at 9:49 AM, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> 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 <info at openjpeg.org>
>>
>> To: openjpeg at googlegroups.com <openjpeg at googlegroups.com>
>>
>>
>>
>> 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/o
>> penjpeg/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 openjpeg at googlegroups.com
>>
>> To unsubscribe: email to openjpeg+unsubscribe at googlegroups.com
>>
>> 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/isp
>> group)
>>
>> * IntoPIX (www.intopix.com)
>>
>>
>>
>> -----------------------------------------
>>
>> --
>>
>> Spatialys - Geospatial professional services
>>
>> http://www.spatialys.com
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171013/ddff8bed/attachment-0001.html>