[gdal-dev] Long Term Prognosis for JPEG 2000

Javier Jimenez Shaw j1 at jimenezshaw.com
Mon Mar 29 11:40:36 PDT 2021


What about COG (Cloud Optimized GeoTIFF - https://www.cogeo.org/)?
No file size limit (using BigTIFF), different encodings (LZW, deflate,
JPEG, zstd, ...), direct access to any part of the image,
overviews/pyramids for different levels of detail, well known format (TIFF).
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 29 Mar 2021 at 19:59, Aaron Boxer <boxerab at gmail.com> wrote:

> On Mon, Mar 29, 2021 at 12:12 PM Marty J. Sullivan <
> 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> on behalf of Aaron
>> Boxer <boxerab at gmail.com>
>> *Date: *Monday, March 29, 2021 at 10:22 AM
>> *To: *gdal dev <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
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> gdal-dev mailing list
> 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/20210329/a3c276ed/attachment-0001.html>


More information about the gdal-dev mailing list