[gdal-dev] Long Term Prognosis for JPEG 2000

[Aaron Boxer]

On Mon, Mar 29, 2021 at 2:40 PM Javier Jimenez Shaw <j1 at jimenezshaw.com>
wrote:

> 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).
>

Interesting. So spatial progression is baked into the file, and the
underlying compression format becomes somewhat irrelevant.



> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> 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/01d81964/attachment-0001.html>