Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compressed Texture Formats #122

Open
progschj opened this issue Mar 6, 2024 · 0 comments
Open

Compressed Texture Formats #122

progschj opened this issue Mar 6, 2024 · 0 comments

Comments

@progschj
Copy link
Collaborator

progschj commented Mar 6, 2024

The question of compressed texture formats came up in relation to https://www.khronos.org/ktx/
I started WIP json definitions here: KhronosGroup/ANARI-SDK#186

The gist is that a new sampler type "compressedImage2D" is introduced that takes a plain Array1D of bytes instead of a 2D array as its image and the format and image size are set via the sampler instead of being derived from the array. The alternative would be to have ANARIDataType of compressed texture blocks and then use these in Array2D as before. This however creates surprising relationships between pixel sizes and byte sizes of the array. For example a 5x5 pixel texture would consist of 4 BC1 blocks (4x4 each) and therefore have the same byte size as a 8x8 texture. Introducing this kind of information at the sampler stage avoids this complication.

It would however make sense to add a type ANARI_COMPRESSED_BYTES to the data type list to indicate the intent of the data. The jsons as drafted above use uint8/int8 however the data can't actually meaningfully interpreted as that and is effectively opaque.

In addition to the compressed sampler extension there are multiple extensions that simply add allowed compression formats (BC, ETC, ASTC, etc.) to said samplers format parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants