Is progressive decoding of raster geodata possible?

Question

When e.g. WMTS or COGs are visualized, only the image data in the viewport (certain zoom and extent) is loaded. This makes the rendering time quite fast. But e.g. with low internet connection unloaded tiles are visible frequently when panning/zooming around.

To my understanding these image data (tiles) in the viewport have to be loaded entirely before they are rendered. I wonder if there are any possibilities to achieve a progressive rendering of tiles in the viewport, so that a low quality image is rendered with the first data bytes loaded and image quality enhances until the entire data is loaded? This would give a smoother visualization experience, since an entire viewport rendered in low quality is often more desired than if only one tile is rendered in high quality.

Recent updates to gdal added support for jpeg-xl compression which supports progressive rendering. A video showing the decoding process can be seen here: https://m.youtube.com/watch?v=UphN1_7nP8U&feature=emb_logo

Would progressive decoding be possible with geodata in theory or is it already implemented somewhere?

Answer 1

Yes, it is possible.

The JPEG 2000 Interactive Protocol (JPIP) https://en.wikipedia.org/wiki/JPIP is developed to support progressive decoding. At least one open source project supports JPIP http://www.openjpeg.org/doxygen/openjpippage.html. Commercial solutions tend to be expensive but it should be possible to make some testing with Kakadu demo programs kdu_server and kdu_show https://kakadusoftware.com/documentation-downloads/.

Normal JPEG can be progressive as well but GIS viewers probably do not utilize that feature. For example GDAL https://gdal.org/drivers/raster/jpeg.html

PROGRESSIVE=ON: Enabled generation of progressive JPEGs. In some cases these will display a reduced resolution image in viewers such as Netscape, and Internet Explorer, before the full file has been downloaded. However, some applications cannot read progressive JPEGs at all. GDAL can read progressive JPEGs, but takes no advantage of their progressive nature.

Based on the browsers, this part of documentation must be pretty old.