Hi,
OpenJPEG 2.5.3 has been released:
https://www.openjpeg.org/2024/12/09/OpenJPEG-2.5.3-released
This is mainly a bugfix release, as detailed in the Changelog hereunder,
with a few new features:
* Use TLM (Tile Length Marker) segments to optimize decoding:
https://github.com/uclouvain/
Hi,
OpenJPEG 2.5.2 is released:
https://github.com/uclouvain/openjpeg/releases/tag/v2.5.2
This is a bugfix-only release correcting an issue of 2.5.1 (openjpeg.h
no longer including opj_config.h), as detailed in the Changelog hereunder.
More info:
News: https://github.com/uclouvain/openjpeg/
Hi,
OpenJPEG 2.5.1 is released:
https://github.com/uclouvain/openjpeg/releases/tag/v2.5.1
Summary:
* No API/ABI break compared to v2.5.0
* CMake: drop support for cmake < 3.5
* Several bugfixes, including
https://github.com/uclouvain/openjpeg/pull/1509 for CVE-2021-3575
* Significant speed-u
Thanks, everyone.
On Wed, Feb 15, 2023 at 10:44 AM Even Rouault
wrote:
>
> > In theory, BUILD_SHARED_LIBS=ON could/should cascade to all dependencies
> > - you want static GDAL, good, we will assume you link it against
> > static OpenJPEG, etc.
>
> That's indeed just theory. No such thing is imp
In theory, BUILD_SHARED_LIBS=ON could/should cascade to all dependencies
- you want static GDAL, good, we will assume you link it against
static OpenJPEG, etc.
That's indeed just theory. No such thing is implemented (if that was
implemented, it should probably be more a CMake functionality t
On Wed, 15 Feb 2023 at 19:14, Simon Eves wrote:
>
> I am building OpenJPEG with SHARED_LIBS off, as we only need the static
> version for GDAL.
> GDAL itself builds default (SHARED_LIBS on) as we need static for our main
> product build,
I know nothing about OpenJPEG build configuration, but GD
Interesting. Thank you for that.
Note that it was OpenJPEG that I added fPIC to, not GDAL itself. I am
building OpenJPEG with SHARED_LIBS off, as we only need the static version
for GDAL. GDAL itself builds default (SHARED_LIBS on) as we need static for
our main product build, but also DSOs for th
On Wed, 15 Feb 2023 at 01:34, Simon Eves wrote:
>
> I tried adding -DCMAKE_CPP_FLAGS="-fPIC" -DCMAKE_CXX_FLAGS="-fPIC" to the
> OpenJPEG build CMake invocation, but that made no difference.
>
More CMake-idiomatic way is to use -DCMAKE_POSITION_INDEPENDENT_CODE=ON instead.
It used to be there
h
OK, I'm an idiot. It's *CMAKE_C_FLAGS* not *CMAKE_CPP_FLAGS*. It works now.
However, I am still surprised at the need to hack the *configure* script to
make the test work.
On Tue, Feb 14, 2023 at 4:33 PM Simon Eves wrote:
> I recreated the compile/link test that *configure* is doing, and it al
I recreated the compile/link test that *configure* is doing, and it also
fails outside.
I then determined I could make it work by also adding *-lm* and *-lpthread*
to the link.
I hacked GDAL *configure* script to also add those two to *$LIBS* when it
does the OpenJPEG link test, and now that pass
Is there some trick to enabling this driver with the old non-CMake build
env...? :)
I am building OpenJPEG 2.5.0 (from source) and it's building and installing
fine into the same include/lib tree as everything else, and then GDAL
configure (just adding *--with-openjpeg*, no path, right?) sees it a
On vendredi 17 février 2017 14:02:37 CET Aaron Boxer wrote:
> See https://github.com/uclouvain/openjpeg/issues/892 for further details.
>
> Since problems occur unpredictably for various image dimensions and
number
> of encoder decompositions, safest approach is to avoid using the codec for
> los
See https://github.com/uclouvain/openjpeg/issues/892 for further details.
Since problems occur unpredictably for various image dimensions and number
of encoder decompositions, safest approach is to avoid using the codec for
lossless until this issue is resolved.
Cheers,
Aaron
So, it turns out to be quite complicated to re-factor the wavelet transform
to only transform a sub-region
inside a single tile image.
I've got it working now for lossy decode, lossless decode also works but 4
units tests are broken at the moment.
And, I am seeing a massive increase in performanc
On Mon, Jan 18, 2016 at 5:14 PM, Even Rouault
wrote:
> Le lundi 18 janvier 2016 22:41:38, Aaron Boxer a écrit :
> > Hello,
> >
> > It looks like OpenJPEG tiled encoding is broken for non power of 2
> images.
> > This seems to be quite an old bug.
>
> I don't reproduce that. For example, the follo
Le lundi 18 janvier 2016 22:41:38, Aaron Boxer a écrit :
> Hello,
>
> It looks like OpenJPEG tiled encoding is broken for non power of 2 images.
> This seems to be quite an old bug.
I don't reproduce that. For example, the following works :
gdal_translate ../autotest/gdrivers/data/utm.tif out.jp
Hello,
It looks like OpenJPEG tiled encoding is broken for non power of 2 images.
This seems to be quite an old bug.
Does this type of encoding get used in GDAL ? Or are all images power of 2
dimensions.
Thanks,
Aaron
___
gdal-dev mailing list
gdal-dev
On Wed, Jan 13, 2016 at 2:40 PM, Even Rouault
wrote:
>
> > So, are you saying there are actual pixel differences between encoded
> file
> > and original?
>
> Yes
>
I see. So, this is repeatable every time you run the test suite? And you
can't reproduce
with opj_compress followed by opj_decompre
> So, are you saying there are actual pixel differences between encoded file
> and original?
Yes
> > oh, so how does one make a forward struct declaration to make gcc 4.4
> happy ?
Apparently it doesn't like to see "typedef struct foo { ... } bar"
(openjpeg.h) and "typedef struct foo bar" (reg
Hi Even,
Thanks so much for testing this.
...
On Wed, Jan 13, 2016 at 2:11 PM, Even Rouault
wrote:
> Le mercredi 13 janvier 2016 18:10:52, Aaron Boxer a écrit :
>
>
> Some feedback:
>
> I've just tested the decode_region branch against the test suite of the
> JP2OpenJPEG driver
> ( https://sv
Le mercredi 13 janvier 2016 18:10:52, Aaron Boxer a écrit :
> Dear GDAL users,
>
> As I've mentioned previously, there are big changes coming to the OpenJPEG
> library. Performance is going up and memory usage is going down, by
> significant amounts.
>
> To do all of this, we have had to make sig
Dear GDAL users,
As I've mentioned previously, there are big changes coming to the OpenJPEG
library. Performance is going up and memory usage is going down, by
significant amounts.
To do all of this, we have had to make significant changes to the core of
the library. So, even though all of our un
es one-time and long-term
maintenance costs (making sure it builds on all supported platforms, regularly
synchronization, etc...) which we tend to avoid unless necessary.
>
> Regards,
> Rutger
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6
> -- Forwarded message --
> From: Aaron Boxer
> Date: Tue, Jan 12, 2016 at 8:42 AM
> Subject: Re: [gdal-dev] OpenJPEG: The Slumbering Giant Awakens
> To: Rutger
>
>
>
>
> On Tue, Jan 12, 2016 at 2:52 AM, Rutger wrote:
>
>> Hey Aaron,
&
so many alternatives?
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-OpenJPEG-The-Slumbering-Giant-Awakens-tp5244550p5244643.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev
Hi Folks,
Thanks to everyone who showed their support for my pull request!
It looks like these changes will be going into the next release of the
library,
which should be happening soon.
Following Even's suggestion, I tried it out on a Sentinel2 data set.
Good news:
1) 14 tiles per second decod
Hello,
I am looking into reducing memory usage for OpenJPEG.(how I spent my
Christmas holidays :) )
So far, I have managed to halve memory usage for high bit rate decoding,
for example. 1920x1080 single tile lossy-compressed image at 9:1
compression.
And there is more low hanging fruit.
I
On Tue, Dec 22, 2015 at 9:01 AM, Even Rouault
wrote:
> Le mardi 22 décembre 2015 14:38:30, Aaron Boxer a écrit :
> > On Tue, Dec 22, 2015 at 4:34 AM, Jukka Rahkonen <
> >
> > jukka.rahko...@maanmittauslaitos.fi> wrote:
> > > Aaron Boxer gmail.com> writes:
> > > > This feature would be quite invo
Le mardi 22 décembre 2015 14:38:30, Aaron Boxer a écrit :
> On Tue, Dec 22, 2015 at 4:34 AM, Jukka Rahkonen <
>
> jukka.rahko...@maanmittauslaitos.fi> wrote:
> > Aaron Boxer gmail.com> writes:
> > > This feature would be quite involved: one would have to gather all of
> > > the
> >
> > layers fo
On Tue, Dec 22, 2015 at 4:34 AM, Jukka Rahkonen <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Aaron Boxer gmail.com> writes:
>
>
> > This feature would be quite involved: one would have to gather all of the
> layers for
> >
> > all of the code blocks in all of the precincts overlapping that
> s
Hi Jukka,
On Tue, Dec 22, 2015 at 4:34 AM, Jukka Rahkonen <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Aaron Boxer gmail.com> writes:
>
>
> > This feature would be quite involved: one would have to gather all of the
> layers for
> >
> > all of the code blocks in all of the precincts overlapp
Aaron Boxer gmail.com> writes:
> This feature would be quite involved: one would have to gather all of the
layers for
>
> all of the code blocks in all of the precincts overlapping that
sub-tile,plus the immediately surrounding precincts, run the inverse entropy
coder to get the wavelet coeffi
On Mon, Dec 21, 2015 at 5:35 PM, Even Rouault
wrote:
> Le lundi 21 décembre 2015 23:29:14, Aaron Boxer a écrit :
> > Hi Even,
> >
> > I was thinking about your request to decode only a sub-window inside of a
> > tile.
> >
> > I don't think this is possible. Because of the serial nature the j2k
>
Le lundi 21 décembre 2015 23:29:14, Aaron Boxer a écrit :
> Hi Even,
>
> I was thinking about your request to decode only a sub-window inside of a
> tile.
>
> I don't think this is possible. Because of the serial nature the j2k
> decoding,
> there is no performance gain to only looking at a sub-w
Hi Even,
I was thinking about your request to decode only a sub-window inside of a
tile.
I don't think this is possible. Because of the serial nature the j2k
decoding,
there is no performance gain to only looking at a sub-window - the whole
tile must be
decoded. The only small gain is in memory
Hi Aaron & Even,
Decoding at preccints level in OpenJPEG would definitely be a great
addition.
I believe OpenJPEG performance could also be improved if multi-threading
was managed directly inside the lib, since in the current situation
OpenJPEG is purely monothreaded.
From my experience, Kak
Aaron,
> I am working on some performance enhancements for OpenJPEG,
> and I am curious about people's experience using the OpenJPEG driver with
> GDAL:
>
> Does it have all the features you need, if not what is missing?
Being the developer of the driver, I believe it must be close to using the
I am working on some performance enhancements for OpenJPEG,
and I am curious about people's experience using the OpenJPEG driver with
GDAL:
Does it have all the features you need, if not what is missing?
Given that it is the slowest J2K library around, what would be acceptable
performance in the
Selon Guillaume Pasero :
> Hi Even,
>
> Le 19/05/2014 20:01, Even Rouault a écrit :
> > Guillaume,
> >
> >> I am using the OpenJPEG driver from GDAL and I noticed some differences
> >> with the behaviour of an other OpenJPEG "driver" that I used before in
> >> the library Orfeo ToolBox. The GDAL
SAVINAUD Mickaël c-s.fr> writes:
> > IMHO the test case seems to be a bit too artificial to justify any change,
> > unless there are real world cases where that would cause issues.
> >
> Yes it is not a real case but it is a conformance data which allow to
> define if a decoder is JPEG decodi
Mickaël,
> >
> >> * The size of the overview at level 'n' is computed as : ovr_size =
> >> raster_size / 2^n , whereas it should be ovr_size = ceil(
> >> raster_size / float(2^n) )
> >>
> >
> > Hum, any reason to particularly round to the upper value rather than
> > the lower
> > value ?
Hi Even,
Le 19/05/2014 20:01, Even Rouault a écrit :
Guillaume,
I am using the OpenJPEG driver from GDAL and I noticed some differences
with the behaviour of an other OpenJPEG "driver" that I used before in
the library Orfeo ToolBox. The GDAL driver fails to pass a conformance
test : using the
Hi Even,
Even Rouault a écrit :
Guillaume,
I am using the OpenJPEG driver from GDAL and I noticed some differences
with the behaviour of an other OpenJPEG "driver" that I used before in
the library Orfeo ToolBox. The GDAL driver fails to pass a conformance
test : using the input file "jpeg2
Guillaume,
>
> I am using the OpenJPEG driver from GDAL and I noticed some differences
> with the behaviour of an other OpenJPEG "driver" that I used before in
> the library Orfeo ToolBox. The GDAL driver fails to pass a conformance
> test : using the input file "jpeg2000_conf_p1_06.j2k"
Are yo
Hi everybody,
I am using the OpenJPEG driver from GDAL and I noticed some differences
with the behaviour of an other OpenJPEG "driver" that I used before in
the library Orfeo ToolBox. The GDAL driver fails to pass a conformance
test : using the input file "jpeg2000_conf_p1_06.j2k" , reading th
On 11/26/2012 05:44 PM, Even Rouault wrote:
Selon Jeff McKenna :
On 12-11-26 5:51 AM, Angelos Tzotsos wrote:
Thanks Even,
I have disabled openjpeg2 support until 1.10.
Cheers,
Angelos
Thanks Angelos/Even, I will do the same.
Just to be clear: if you have already packaged GDAL 1.9 with ope
Selon Jeff McKenna :
> On 12-11-26 5:51 AM, Angelos Tzotsos wrote:
> > Thanks Even,
> >
> > I have disabled openjpeg2 support until 1.10.
> >
> > Cheers,
> > Angelos
> >
>
> Thanks Angelos/Even, I will do the same.
Just to be clear: if you have already packaged GDAL 1.9 with openjpeg "old" v2
bra
On 12-11-26 5:51 AM, Angelos Tzotsos wrote:
> Thanks Even,
>
> I have disabled openjpeg2 support until 1.10.
>
> Cheers,
> Angelos
>
Thanks Angelos/Even, I will do the same.
-jeff
--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/
On 11/26/2012 10:29 AM, Even Rouault wrote:
Selon Angelos Tzotsos :
On 11/20/2012 09:23 PM, Even Rouault wrote:
Hi,
Just to inform you that the OpenJPEG project has just released OpenJPEG
2.0.0.
GDAL users of GDAL 1.10dev that need support for JPEG2000 can (must) now
rely
on a released ve
Selon Angelos Tzotsos :
> On 11/20/2012 09:23 PM, Even Rouault wrote:
> > Hi,
> >
> > Just to inform you that the OpenJPEG project has just released OpenJPEG
> 2.0.0.
> >
> > GDAL users of GDAL 1.10dev that need support for JPEG2000 can (must) now
> rely
> > on a released version, and no longer on
On 11/20/2012 09:23 PM, Even Rouault wrote:
Hi,
Just to inform you that the OpenJPEG project has just released OpenJPEG 2.0.0.
GDAL users of GDAL 1.10dev that need support for JPEG2000 can (must) now rely
on a released version, and no longer on the openjpeg SVN v2 branch (which has
been removed
Hi,
Just to inform you that the OpenJPEG project has just released OpenJPEG 2.0.0.
GDAL users of GDAL 1.10dev that need support for JPEG2000 can (must) now rely
on a released version, and no longer on the openjpeg SVN v2 branch (which has
been removed by the way)
Even
_
Le vendredi 27 janvier 2012 11:09:00, Jukka Rahkonen a écrit :
> Hi,
>
> Here is a link to JPEG2000 image that is created by ERDAS Imagine with
> default settings
>
> http://latuviitta.org/documents/openjump_jpeg2000_erdas.jp2 (30 MB)
>
> It is created with ECW JPEG 2000 SDK v4.2.0.64
> There is
Hi,
Here is a link to JPEG2000 image that is created by ERDAS Imagine with
default settings
http://latuviitta.org/documents/openjump_jpeg2000_erdas.jp2 (30 MB)
It is created with ECW JPEG 2000 SDK v4.2.0.64
There is nothing odd in the JPEG2000 parameters and Kakadu and a few other
program I trie
Selon Julien Michel :
Julien,
I've just diff'ed openjpeg.h of 1.3 and 1.4 and couldn't see much difference
between the 2. What make you believe that 1.4 supports tile access ? The
JP2OpenJPEG driver in particularly needs the opj_set_decode_area(),
opj_read_tile_header() and opj_decode_tile_data()
I hop on the thread since I am interested in openjpeg support too. It
seems than those lines you pointed out are quite outdated, because
openjpeg 1.4 released january 2011 provides tile-level reading. Is there
any chance to build the gdal driver with openjpeg 1.4 ?
Many thanks for your help,
Brian,
GDAL's JP2OpenJPEG driver is based on version 2 of OpenJPEG library.
http://www.gdal.org/frmt_jp2openjpeg.html
On Thu, Mar 17, 2011 at 9:06 PM, Brian Wilson wrote:
> I am trying to build 1.8.0 on Linux with openjpeg support.
> I can easily build and install openjpeg from source
> (oropen
Selon Brian Wilson :
Please read carefully the first lines of http://gdal.org/frmt_jp2openjpeg.html
for the explanation (and solution)
> I am trying to build 1.8.0 on Linux with openjpeg support.
> I can easily build and install openjpeg from source
> (oropenjpeg_v1_4_sources_r697) into /usr/loca
I am trying to build 1.8.0 on Linux with openjpeg support.
I can easily build and install openjpeg from source
(oropenjpeg_v1_4_sources_r697) into /usr/local
./configure --with-openjpeg
./configure --with-openjpeg=/usr/local
both result in
OpenJPEG support: no
I wiped my gdal-1.8.0 d
59 matches
Mail list logo
