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

[Matt Hanson]

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/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 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/
> ispgroup)
>
> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171013/5fd3e476/attachment-0001.html>