Test heightmap compression

[paoletto]

Following up on https://github.com/paoletto/qdemviewer/issues/3, test alternate approaches for heightmap compression.

For example,one approach could be to extract tile min-max, which, at least for high zl tiles, should in average be relatively low.

Then, if delta below 256, use a single channel ASTC texture for that tile for the meters, and another for the CM (or maybe just a 2 channel texture, idk, although a full channel for centimeters seem unnecessary). If, say between 256 and 1024, a second half sized uncompressed texture could be used to store the 2 most signficant bits of the meters range.

If delta is greater, either go full uncompressed, or choose a lighter compression scheme. These should be small in number anyway.

[paoletto]

On a second thought, this cannot work, as the cyclic modulation of the meters channel would be affected by compression, and that "affection" must match perfectly the high part (impossible) or block artifacts appear. The only sane way would be to have a single 16bits channel, which seems to be not possible at the moment at least not on all HW.

[paoletto]

On a third thought, it seems that the BPTC texture compression format supports 32f channels, and would be able to cut down the single sample space requirement to 8bit per sample. Not perfect, but still better than using half floats. Worth checking, perhaps. ASTC HDR seems to be a dead end as it has very little support

[paoletto]

BPTC tested, quality too poor to be actually an option for this use case. It seems the only viable option would be HDR ASTC, which sadly intel isn't supporting on Linux. given that Intel has also removed ASTC hardware from their graphics, maybe this is atm not something to invest more efforts on

[paoletto]

Example of BPTC compressed heightmaps on intel mesa

vs uncompressed:

[paoletto]

Eventually got around to testing HDR ASTC for Heightmaps. Results below seem quite promising, although there seems to be a variance in quality across tiles that isn't immediately easy to explain. at the present a 6x6 block size is used, as it matches well with the 258x258 tiles. The video is shoot with compressing the tiles doing exhaustive search, so the compressor, given these settings, shouldn't be able to do anything better.

https://github.com/paoletto/qdemviewer/assets/6912425/8b92a08b-d3ce-4a3f-8c38-900dcd8a3938

[paoletto]

Tested the same on Linux, despite the official lack of support for HDR ASTC textures on intel graphics. It turns out it works nevertheless, but, more interestingly, the compressor seems to do a much better and more uniform job across the tiles. There might be a difference in build flags when building the ARM astc compressor on linux, though. The different compiler itself should not -in theory- make a difference.

One last note: in the video above, crappy tiles seem to most of the times be those without borders (or, rather, with borders with a value of 0 of elevation). This might actually be the cause of the poor compression in some tiles, as well as of the quality variance.

https://github.com/paoletto/qdemviewer/assets/6912425/a43d14df-890b-4a58-b1ff-f139299b1139

[paoletto]

last bit left for this ticket is trying to bake normals into the heightmap (as ASTC is 4 channels internally in any case) and see how much this will degrade the quality of the heightmap. in the previous experiments the elevation value is replicated on all 4 channels.