Does Mali's Astc encoder scan textures from top-to-bottom or from bottom-to-top.

i can't get my astc decoder to work when i use a top-to-bottom scan order, as you suggest.

to test Astc's scan order, i compiled astcenc in Visual Studio on Windows and i created a 12-pixel x 12-pixel png test texture that is all black except for a red texel in the top left, a green texel in the top right, a blue texel in the bottom left and a white texel in the bottom right.

1) when i decode the astc encoded image, the first block seems to contain a single blue texel as the first texel in the block.  of course my decoder could have bugs, but it looks correct.

2) in astcenc, in routine load_image_with_stb(), there is a variable called y_flip that is hardcoded to 1.  y_src is set to "y_flip ? (ysize - y - 1) : y;".  in prior encoding work, i have used the stb_image library to load textures and i believe it scans top-to-bottom.  since astcenc sets y_flip, i would think that this indicates that astc's scan order is bottom-to-top.

3) in astcenc, in routine encode_astc_image_threadfunc(), when compress_symbolic_block() is called for the first block, the first 4 floats in pb->orig_data[] are 0.0, 0.0, 1.0, 1.0 (opaque blue).  this would also seem to indicate that astc's scan order is bottom-to-top.

i could of course be approaching the scan order in an incorrect manner, but everything i try in my decoder or see in the debugger tells me the astc's scan order is bottom-to-top.

do you still stand by your assertion that astc's scan order is top-to-bottom?

i can't get my astc decoder to work when i use a top-to-bottom scan order, as you suggest.

to test Astc's scan order, i compiled astcenc in Visual Studio on Windows and i created a 12-pixel x 12-pixel png test texture that is all black except for a red texel in the top left, a green texel in the top right, a blue texel in the bottom left and a white texel in the bottom right.

1) when i decode the astc encoded image, the first block seems to contain a single blue texel as the first texel in the block.  of course my decoder could have bugs, but it looks correct.

2) in astcenc, in routine load_image_with_stb(), there is a variable called y_flip that is hardcoded to 1.  y_src is set to "y_flip ? (ysize - y - 1) : y;".  in prior encoding work, i have used the stb_image library to load textures and i believe it scans top-to-bottom.  since astcenc sets y_flip, i would think that this indicates that astc's scan order is bottom-to-top.

3) in astcenc, in routine encode_astc_image_threadfunc(), when compress_symbolic_block() is called for the first block, the first 4 floats in pb->orig_data[] are 0.0, 0.0, 1.0, 1.0 (opaque blue).  this would also seem to indicate that astc's scan order is bottom-to-top.

i could of course be approaching the scan order in an incorrect manner, but everything i try in my decoder or see in the debugger tells me the astc's scan order is bottom-to-top.

do you still stand by your assertion that astc's scan order is top-to-bottom?

in the previous response i forgot to mention that i am using a 6x6 footprint

Do you still stand by your assertion that astc's scan order is top-to-bottom?

Ah, sorry - I misunderstood your original question - I was talking about the UV coordinate expectations from the application point of view when addressing into the textures from shader code (which is also what the Microsoft article is talking about, as far as I can tell).

The internal layout of compressed blocks, and the addressing from the application point of view are somewhat orthogonal (hence the same compressed texture can be decompressed differently on DirectX and OpenGL ES because the expectations of the UV addressing are different).

This basically all comes down to how do you define "top" and "bottom" - the original storage format on the host (origin may be top or bottom depending on data format), compression (origin is top left), and decompression (origin may be top or bottom depending on API) are all variables. It's entirely possible to have a texture which is "correct" for OpenGL which will be "upside down" for DirectX ...

HTH,
Pete