Hi Folks,
Grok JPEG 2000 library v9.7.2 has just been released.
This open source project is now significantly faster
than the closed source proprietary Kakadu library v8.05
in a number of workflows involving large single and multi tiled images.
You can check out the benchmarks here:
https://githu
read from disk at
all.
There's no reason why JP2Grok can't match the library utilities in
performance, once I support
the above features in the driver.
> What about single threaded usage ?
>
I can certainly benchmark this.
Aaron
> Le 03/05/2021 à 16:59, Aaron Boxer a é
ility could be harmed if we release GDAL with a
> JP2 driver that writes JPEG 2000 files that the main open source JP2 driver
> can't read. Would it make sense to add compatibility to OpenJPEG before the
> PR gets merged? Or are we already in a state of inoperability between
>
Hi Jean-Roc,
Good question - unfortunately OpenJPEG doesn't currently support HTJ2K,
it only supports JPEG 2000 Part 1. I am sure that this will eventually be
integrated,
but it isn't there at the moment.
Cheers,
Aaron
On Mon, May 3, 2021 at 12:05 PM Jean-Roc Morreale (ml) <
jrmorreale...@enoreth.
Hi Folks,
I would like to draw people's attention once again to the pending JPEG 2000
driver PR
https://github.com/OSGeo/gdal/pull/3449
which was opened 3 months ago. Since I last posted, the driver now has an
autotest script courtesy of Frank Warmerdam, and all tests are passing.
In a nutshell,
nales
> hay infinitos pensamientos irracionales.
>
>
>
> On Mon, 29 Mar 2021 at 19:59, Aaron Boxer wrote:
>
>> On Mon, Mar 29, 2021 at 12:12 PM Marty J. Sullivan <
>> marty.sulli...@cornell.edu> wrote:
>>
>>> Just my two cents, I have very littl
te decode each time you view it.
>
>
> Marty
>
>
>
> *From: *gdal-dev on behalf of Aaron
> Boxer
> *Date: *Monday, March 29, 2021 at 10:22 AM
> *To: *gdal dev
> *Subject: *[gdal-dev] Long Term Prognosis for JPEG 2000
>
>
>
> Hello There,
>
>
Hello There,
I'm curious what folks here think about the future of JPEG 2000 in
geospatial?
I was having a little discussion about this over here:
https://github.com/USGS-Astrogeology/ISIS3/issues/4237
To me, the features that made JP2 unique amongst the many codecs were:
0. royalty free
1. suppo
Hi Jukka,
Thanks, makes a lot of sense. My comments about removing proprietary drivers
weren't meant as a provocation, I'm sorry you received it that way. Just a
thought experiment
to explore possible inconsistency of keeping proprietary drivers while
pushing back
on GPL drivers. But your explana
Hi Brad,
Definitely makes for an interesting discussion.
A few questions to ponder:
Is it GDAL's mandate to encourage projects with permissive licenses and to,
shall we say,
discourage those with copy-left licenses ? This is how Google and Apple
operate,
but they are for-profit corporations who
Hi Nyall,
Well, my point is that it's not terribly difficult to make a contribution,
but it does require some hard work,
which few are willing to expend. But, this isn't specific to JPEG 2000 -
it's the case for any FLOSS
project. The JPEG 2000 standard is difficult, but it can be grokked, if I
ma
Hi Even,
Thanks. You have certainly made remarkable improvements to OpenJPEG,
especially
considering the amount of time you were able to spend on the code.
Regarding benchmarking, I totally agree, there are many many different
workflows and configurations.
I chose lossless compression/decompressio
On Sat, Feb 27, 2021 at 1:18 PM Kurt Schwehr wrote:
> I can't touch grok... GNU Affero General Public License
>
No problem, this driver will be optional. The current commercial and open
source drivers are quite good.
>
> On Sat, Feb 27, 2021, 9:50 AM Aaron Boxer wrote:
>
Hello Everyone,
For those who aren’t aware, there is a pending PR for a new open source
JPEG 2000 driver, based on the Grok JPEG 2000 library
https://github.com/OSGeo/gdal/pull/3449
Notable Library Features:
1. support for reading TLM and PLT markers, for fast random access into
large tiled or
:):)
On Mon, Feb 20, 2017 at 1:56 PM, Kurt Schwehr wrote:
> Only 370K more LOC left to cover with proper library level unittests.
>
> On Mon, Feb 20, 2017 at 10:01 AM, Aaron Boxer wrote:
>
>>
>>
>> On Sat, Feb 18, 2017 at 8:14 AM, Kurt Schwehr wrote:
>>
&g
Feb 18, 2017 at 5:03 AM, Aaron Boxer wrote:
>
>> -- Forwarded message --
>> From: "Aaron Boxer"
>> Date: Feb 18, 2017 8:03 AM
>> Subject: Re: [gdal-dev] GDAL unable to write 4-band RGBA jp2 file with
>> Kakadu 7.8
>> To: "Ku
-- Forwarded message --
From: "Aaron Boxer"
Date: Feb 18, 2017 8:03 AM
Subject: Re: [gdal-dev] GDAL unable to write 4-band RGBA jp2 file with
Kakadu 7.8
To: "Kurt Schwehr"
Cc:
On Feb 18, 2017 7:26 AM, "Kurt Schwehr" wrote:
Jason,
Turns out
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
ze is around
> 7200x10800 px though, which might not be "large" for you?
>
> Cheers,
>
> Rob :)
>
> On 16 February 2017 at 15:28, Aaron Boxer wrote:
>
>> Hello,
>>
>> I'm interested in testing decode of large lossless-encoded J2K images.
>> I h
Hello,
I'm interested in testing decode of large lossless-encoded J2K images.
I have checked out Sentinel-2 and Pleides, are there other good sources
for this ?
Thanks so much,
Aaron
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo
.
>
Yes.
>
> Either way good luck.
>
Thank you.
Cheers,
Aaron
>
>
> On 3 February 2016 at 19:28, Aaron Boxer wrote:
>
>> Dear GDAL Developers,
>>
>> I am developing a new open source JPEG 2000 toolkit, based on OpenJPEG.
>>
>> It is a
Dear GDAL Developers,
I am developing a new open source JPEG 2000 toolkit, based on OpenJPEG.
It is a drop-in replacement for OpenJPEG, but features:
- fast precinct-level decode
- lower memory usage
- better performance - currently it is roughly 1/3 the perf of Kakadu,
(tested on windows), and
Hello,
I am curious about the OSS license landscape in the geospatial open source
community. Off the top of my head, these are the common licenses:
GPL (2.0,3.0,LGPL, Affero)
Mozilla Public License 2.0
Apache
MIT
BSD 2 clause
>From what I understand, Affero is the strictest, and MIT/BSD are the
time should come down by at least a factor of two.
One remaining issue is memory allocation: still need to allocate gigabytes
of memory to do this. But, this should be an easy fix over the next few
weeks.
Will keep you all posted.
Cheers,
Aaron
On Wed, Jan 13, 2016 at 2:49 PM, Aaron Boxer
on
>>
>> would this patch (or a patched version of complete Openjpeg source)
>> already be available for testing to assess the difference to current
>> release?
>>
>> Thanks
>> Armin
>>
>> On 12/01/16 15:13, Aaron Boxer wrote:
>>
>>&g
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 do
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 Mon, Jan 18, 2016 at 2:22 PM, Even Rouault
wrote:
> Le lundi 18 janvier 2016 19:59:01, Aaron Boxer a écrit :
> > Hello,
> >
> > I am trying to learn more about how open source projects manage copyright
> > of contributors.
> > I see that various GDAL files h
Hello,
I am trying to learn more about how open source projects manage copyright
of contributors.
I see that various GDAL files have different copyright assignees, although
they all use the MIT
license.
Is this difficult to manage? For example, if GDAL is packaged for a
distribution such as Fedor
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
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
> JP
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
-- Forwarded message --
From: Aaron Boxer
Date: Tue, Jan 12, 2016 at 4:06 PM
Subject: Re: [gdal-dev] Fwd: OpenJPEG: The Slumbering Giant Awakens
To: armin.bur...@gmx.net
Hi Armin,
Yes, indeed. You can find it here:
https://github.com/CodecCentral/openjpeg/tree/omnibus
and
> -- 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,
&
-- 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,
>
> That sounds great, thanks for your efforts. I e
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
Looks like the sleepy world of software j2k codecs is about to be jolted
into the 21st century with rise of the GPU codecs ( see comprimato, for
example)
On Dec 28, 2015 11:37 PM, "Aaron Boxer" wrote:
>
> http://blog.hexagongeospatial.com/jpeg2000-quirks/?utm_medium=tw
http://blog.hexagongeospatial.com/jpeg2000-quirks/?utm_medium=twitter&utm_source=twitterfeed#prettyPhoto
Amusingly, there is a link in the article to my recent discussion about
OpenJPEG.
Cheers,
Aaron
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
h
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> writ
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 i
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
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 po
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
-- Forwarded message --
From: Aaron Boxer
Date: Mon, Dec 21, 2015 at 10:27 AM
Subject: Re: [gdal-dev] OpenJPEG
To: Julien Malik
Hi Julien,
> Decoding at preccints level in OpenJPEG would definitely be a great
> addition.
>
Yes, sounds useful.
>
> I b
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
Friends,
I am now able to decode a lossless RGB image.
https://github.com/OpenCodec/ThousandthChicken
Current limitations:
- single layer
- lossless
- RLCP progression only
The license for this library is a bit of a mess, as I am pulling in source
from three other projects.
Please feel free
Friends,
I am nearing the end of the first part of my journey - I am just finishing
the port of the inverse wavelet transform. The code is a naive
implementation
of part 1 of the standard in OpenCL - no attempt to optimize with local GPU
memory or use memory coalescing or any hardware specific opt
Hello There,
Just wanted to let y'all know that I have implemented the OpenCL
coefficient decoding portion of the j2k decode workflow. I am testing it
with select images from OpenJPEG.
Remaining steps are: dequantization, inverse wavelet transform, and colour
decoding.
Cheers,
Aaron
___
Hi Jukka,
> I would like to see something that is open source and fast with JPEG2000. I
> think that it would be OK to support only a subset of JPEG2000 standard if
> the basic operations would be super fast. I took just a moment ago some
> timings for another purpose but they may be interesting.
Hello,
For those of you who are interested in high performance JPEG 2000, I have
just
launched my ThousandthChicken OpenCL library.
https://github.com/OpenCodec/ThousandthChicken
My design goals are:
- correctness
- speed
- stability - comprehensive test suite
- well documented :)
- cross platf
me know your
> > thoughts.
> >
> > Cheers,
> > Aaron
> >
> > On Sat, Mar 1, 2014 at 11:06 AM, Seth Price wrote:
> > > I am interested in seeing an OpenCL JPEG2000 decoder/encoder
> developed. I
> > > have a bit of experience writing OpenCL ke
houghts.
Cheers,
Aaron
On Sat, Mar 1, 2014 at 11:06 AM, Seth Price wrote:
> I am interested in seeing an OpenCL JPEG2000 decoder/encoder developed. I
> have a bit of experience writing OpenCL kernels. Please contact me if you
> need help.
> ~Seth
>
> via iPhone
>
> &
n Sat, Mar 1, 2014 at 10:37 AM, Norman Vine wrote:
> These should help
>
> http://gdal.org/gdal_drivertut.html
>
> http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/openjpeg/openjpegdataset.cpp
>
> On Mar 1, 2014, at 10:27 AM, Aaron Boxer wrote:
>
> Hello,
>
>
Hello,
I recently started developing an open source jpeg2000 compression library
using opencl.
I would like to base the library design on the very successful gdal library
design.
Can anyone recomend any resources to help me to grok the high level design
of gdal?
Thanks so much,
Aaron
55 matches
Mail list logo
