OSGeo
Proposal: Add AVS Perceptual Lossless Compression (PLC) Support
Feature description
Objective: Integrate AVS PLC (a low-latency, visually lossless codec) into GDAL, mirroring JPEG XL’s implementation.
Why AVS PLC?
- Critical for Chinese geospatial datasets.
- 3–15x compression ratios with hardware-friendly decoding.
- Government-backed standardization (AVS Working Group).
Implementation Plan:
- Link to AVS PLC’s reference SDK (non-patent-encumbered components).
- Add GDAL driver with encode/decode wrappers (C++).
- Collaborate with PengCheng Laboratory and Peking University for validation.
Request:
- Feedback on licensing/technical barriers.
- Interest in co-development partnerships.
References:
Additional context
No response
- Critical for Chinese geospatial datasets.
Which geospatial formats use that codec ?
Request: Feedback on licensing/technical barriers. / Interest in co-development partnerships.
I may be wrong, but I doubt anyone in the GDAL core dev team has experience with that technology to provide useful feedback. Is the SDK free&open source ? Do you intend to implement that support yourself ? People can always experiment developing an out-of-tree GDAL driver (e.g. https://github.com/OSGeo/gdal-grass/)
Thank you for your concerns and questions.
We've tested the codec on the dataset "40 - year human settlement changes in China (Urban and rural data)" which can be accessed at https://data-starcloud.pcl.ac.cn/zh/resource/12.
Regarding the SDK, it is free. Moreover, we are making progress in making it open source.
The method we added focuses on image encoding and decoding. Our aspiration is to achieve a similar implementation as the JPEG XL Driver. We understand that there might be a lack of experience with this technology within the GDAL core dev team. However, we believe that with the characteristics of our codec and the development of the SDK, it could potentially bring new value to the GDAL ecosystem.
We're also aware that people can experiment with developing an out-of-tree GDAL driver, just like the example you provided (https://github.com/OSGeo/gdal - grass/). This is indeed a feasible direction, and we're open to exploring such possibilities in the future.