Hello,
How can I compress raw binary floating point (16 or 32) textures using astcenc tool?
I have these binary files with array of floats which is basically a raw data to be consumed by glTexImage2D. It has no headers with any information about texture dimensions, etc.
How should I consume such data into astcenc tool?
The only thing mentioned in documentation is that astcenc supports *.exr and *.hdr files for HDR source images.
Hi Oleksandr,
If you just have arrays of raw data, these are not supported directly via the command line tool, unless the uncompressed data is wrapped in a KTX or DDS wrapper.
The quickest solution here would be to write a small utility using the library interface, which can pass the data you need directly into the codec. There is a small standalone example application using the library interface in the GitHub tree:
* github.com/.../Example
Most of the settings in the library API are direct mappings to the command line options, so hopefully not to hard to modify to suit your needs, but shout if you get stuck.
Kind regards, Pete
Hello Peter!
Sorry for such late response, I was busy with other projects.
Thank you for suggestion. I've tried to configure encoder and feed it my source FP16 data.
In my modification of this example I've noticed some strange behavior.
My data has only 3 channels (RGB) of FP16 (2 bytes) data per texel. So, for example, 10x10 texture is 2*3*10*10 = 600 bytes. With block size 4x4 for the best quality this should compress really nicely into just 144 bytes of compressed HDR ASTC texture.
According to documentation, data must be 4-component so I added 2 bytes padding so each texel is now 4-component RGBA and can be processed by library.
I've modified example with {ASTCENC_SWZ_R, ASTCENC_SWZ_G, ASTCENC_SWZ_B, ASTCENC_SWZ_0} swizzle, ASTCENC_PRF_HDR profile and ASTCENC_TYPE_F16 image data_type.
{ASTCENC_SWZ_R, ASTCENC_SWZ_G, ASTCENC_SWZ_B, ASTCENC_SWZ_0}
ASTCENC_PRF_HDR
ASTCENC_TYPE_F16
data_type
However, after decoding compressed data, I see that all channels except B are zeros, and even B channel values seems to be incorrect.
Left is original, right is uncompressed:
Is this a problem of decoder or is something wrong with setup?
How can I test decoding of FP16 data (except of decoding it on ASTC HDR-capable GPU)?
OK apparently, wrong values are for negative numbers. HDR doesn't support negative values so this is expected.