[gdal-dev] Long Term Prognosis for JPEG 2000

[Marty J. Sullivan]

I’m not sure I’ve run into an issue with 16383x16383 yet other than when I was just experimenting with WEBP. As Jeremy mentioned, we are using COG in practice, where tiles are generally very small (512x512). I haven’t noticed any artifacts in the COGs I’ve created on the tile boundaries. I generally use level 95 for lossy compression so maybe if I used higher compression I could potentially start to see that.

With such small tiles, and several overviews, decoding COG is generally not an issue and you can quickly pull out as small or as large of an area as you like with GDAL.

It seems like if you’re using a traditional image in a desktop application, using JP2 might have a few advantages, but for network optimized access and web/browser support, WEBP is the clear winner for me.

Marty

From: Aaron Boxer <boxerab at gmail.com>
Date: Monday, March 29, 2021 at 1:59 PM
To: "Marty J. Sullivan" <marty.sullivan at cornell.edu>
Cc: gdal dev <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] Long Term Prognosis for JPEG 2000

On Mon, Mar 29, 2021 at 12:12 PM Marty J. Sullivan <marty.sullivan at cornell.edu<mailto:marty.sullivan at cornell.edu>> wrote:
Just my two cents, I have very little personal use of JP2 although I’ve experimented with it in the past.

I personally have switched to using WEBP and have not run into any issues (other than wide support). I think the one place JP2 beats WEBP is that JP2 supports virtually unlimited image dimensions whereas WEBP is limited to 16383 x 16383. Then again, with GeoTIFF tiling, this is pretty much a non-issue.

16383 x 16383 sounds a bit limited. Even if you use tiling, if your compression is lossy then you will see artifacts at the tile boundaries.


AVIF is also up and coming and superior to WEBP, so I’d imagine we’ll see support for that someday in GDAL as well. It supports larger image dimensions than WEBP (65536x65536)

With that in mind, I personally would never choose to use JP2 at this point, but maybe there are other use-cases I’m unaware of.

The problem with larger dimensions  in WebP is the impossibility of decoding a sub window in the image. You are forced to do
a complete decode each time you view it.



Marty

From: gdal-dev <gdal-dev-bounces at lists.osgeo.org<mailto:gdal-dev-bounces at lists.osgeo.org>> on behalf of Aaron Boxer <boxerab at gmail.com<mailto:boxerab at gmail.com>>
Date: Monday, March 29, 2021 at 10:22 AM
To: gdal dev <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>>
Subject: [gdal-dev] Long Term Prognosis for JPEG 2000

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. support for lossy and lossless compression in a single framework
2. support for TB images
3. fast on-the-fly random access into large images
4. decoder can determine what sort of progression it uses at decode time: resolution,
quality, component or spatial.
5. precise rate control
6. error and re-compression resilience
7. JPIP protocol for progressive transmission over low-bandwidth networks

The cons to JP2 were:

0. computational complexity i.e. dog slow
1. (until recently) buggy and slow OSS implementations
2. patent questions (largely resolved)
3. poor support from HW and browsers

Do you think there is currently a viable alternative which covers enough of the advantages while lacking enough of the negatives that plague JP2 ?  I'm curious because I have been devoting quite a bit of time to addressing some of those negatives, as discussed at length previously,
The standard remains essential in digital cinema, medical imaging and in the archive community. But, those last two fields may also be ripe for change.

In digital cinema, precise rate control is a must, so I think it is here to stay in the area.

Thanks,
Aaron



_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto: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/20210330/70204259/attachment-0001.html>