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

Fri Oct 13 12:32:11 PDT 2017

Thanks guys, I got it to work from the 2.2 repo branch, which has the
change on it. I could not get it to work with trunk.

On Fri, Oct 13, 2017 at 2:06 PM, Sean Gillies <sean at mapbox.com> wrote:

> 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/7ae15147/attachment.html>