On the OpenGL Wiki we can find the following remark:
https://www.khronos.org/opengl/wiki/...ion#DimensionsNote: The ASTC extension is... unclear as to exactly how ASTC compressed images work in desktop OpenGL. Because it was written against OpenGL ES 3.0, it does not mention many elements of desktop GL, such as 1D textures and the like. Clarifications on these elements are in the process of being compiled, but are not available at this time.
Is this information out of date or does this mean ASTC currently has some weak spots?
There being lack of generalised N-dimensional encoding/decoding and data layout strategy.
Resulting in a lack of 1D textures, generalised N-dimensional array, array image views and other features.
And that for a next gen texture compression format touted as being Adaptable Scalable Texture Compression (ASTC). The words adaptable and scalable are right in the name.
This is not the only issue the wiki remark seems to indicate, another problem seems to be unspecified desktop OpenGL. Having important functionality unspecified on many elements seems a big, important flaw that should be addressed. Especially since ASTC is to be used on OpenGL, OpenGL ES and Vulkan.
Last but not least for a scalable adaptable texture compression format I really hoped to see a mention about ROI decoding and encoding in the wiki page.
Such a feature would be very welcome in software using arrays of textures and texture views.
Other compression formats seem to support and prominently document that stuff, like PGF:
No mention of MIPmap levels in the ASTC wiki page.
And no finds when using LOD or Level of Detail (case insensitive) in the wiki page and ASTC specification.
(Could at least put those words in the specification along MIPmap and other stuff in the relevant registry section and in the wiki.)