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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2

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 <[hidden email]>

To: [hidden email] <[hidden email]>

 

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 [hidden email]

To unsubscribe: email to [hidden email]

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement

Matt Hanson-2
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 \
    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 <[hidden email]> 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 <[hidden email]>

To: [hidden email] <[hidden email]>

 

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 [hidden email]

To unsubscribe: email to [hidden email]

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement

Even Rouault-2

On vendredi 13 octobre 2017 13:47:22 CEST Matt Hanson 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?

 

Matt,

 

I've changed the way autoconf detects openjpeg in GDAL trunk. It now requires the pkg-config info to be available.

Normally pkg-config should be able to find the info even with the /usr/local installation prefix

 

At least, that works on our Travis-CI platforms such as

ci/travis/precise_clang/before_install.sh

ci/travis/precise_clang/install.sh

 

You may try running GDAL configure with

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig set as env variable, in case that helps (which I doubt is needed)

 

Perhaps add a ldconfig after make install of openjpeg ?

 

You may have a look at config.log generated by GDAL configure to help debugging the issue.

 

For GDAL 2.2.2, the symlink trick should work too.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement

Sean Gillies-3
In reply to this post by Matt Hanson-2
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:


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


On Fri, Oct 13, 2017 at 11:47 AM, Matt Hanson <[hidden email]> 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 \
    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 <[hidden email]> 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 <[hidden email]>

To: [hidden email] <[hidden email]>

 

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 [hidden email]

To unsubscribe: email to [hidden email]

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Sean Gillies

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement

Matt Hanson-2
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 <[hidden email]> 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:


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


On Fri, Oct 13, 2017 at 11:47 AM, Matt Hanson <[hidden email]> 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 \
    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 <[hidden email]> 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 <[hidden email]>

To: [hidden email] <[hidden email]>

 

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 [hidden email]

To unsubscribe: email to [hidden email]

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev



--
Sean Gillies


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [OpenJPEG] OpenJPEG v2.3.0 is out: more speed and memory improvement

Even Rouault-2
On vendredi 13 octobre 2017 15:32:11 CEST Matt Hanson wrote:
> 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.

Is pkg-config installed in your Docker env ? Can you share your dockerfile ?

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev