On Mon, Mar 29, 2021 at 2:40 PM Javier Jimenez Shaw <j...@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 <boxe...@gmail.com> 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 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-boun...@lists.osgeo.org> on behalf of Aaron >>> Boxer <boxe...@gmail.com> >>> *Date: *Monday, March 29, 2021 at 10:22 AM >>> *To: *gdal dev <gdal-dev@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@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
