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 <[email protected]> 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 <[email protected]> > 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 <[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/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 [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/isp >> group) >> >> * 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 >> > > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Sean Gillies
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
