ASTC Evaluation Codec

Devendran,

You are right that this is strictly not necessary, as the bit-transfer procedure does indeed guarantee that the unsigned value b is in the correct range. You do need to clamp e1, because the previous addition operation may overflow. I suspect that the description is down to the way the hardware works - the LDR endpoints which clamp their output share a common unit which clamps both values, and it is more expensive to special-case this decoding mode than it is to allow half of the unit to operate as a "no-op".

Sean.

Mokosha,

I am not aware of any plans to output compressed data to .ktx or .dds. Do you have a specific use case in mind? Reusing a generic .ktx loader in your application would be attractive in itself, of course.

Sean.

That was the only use case I had in mind.

I have a few other questions about the OpenGL ES spec that hopefully you can shed some light on. If this is better suited for a separate thread, I'd be happy to move the conversation.

1. The weight infill section (C.2.18) covers the method by which the texel weights are converted from a low resolution texel grid into a full block resolution weight grid. I'm a little bit confused about how to calculate the neighboring weights for bilinear interpolation for this step. The outline is given as:

v0 = js + jt*N;
p00 = decode_weight(v0);
p01 = decode_weight(v0 + 1);
p10 = decode_weight(v0 + N);
p11 = decode_weight(v0 + N + 1);

For a 4x4 texel grid expanding to a 4x4 block grid, I assume each of the texels correspond one-to-one. However, if I follow this procedure, I get index out of bounds problems when trying to decode weights in the bottom right portion of the block grid. The corresponding blend values end up being zero, but in the decode step that's not clear until later. My question: is this a lazy procedure? In other words, if the blend values are zero, do we avoid decoding the weights? It seems like you'd run into issues in the bottom right borders of the texel weight grid regardless.

2.  I'm also a bit confused about how to interpret the texel weight data. (C.2.16) The spec says "The weight information is stored as a stream of bits, growing downwards from the most significant bit in the block. Bit n in the stream is thus bit 127-n in the block." Does this mean that the weight data is read in reverse order from the rest of the block information? I.e. does the decompressor start reading from the most significant bit backwards to the least significant of the block data? How does this work with the little endian byte storage? I assume it's something like this:

Memory ---->
Bit |120 - 112|128 - 121
----|---------|
-------------- ^ Start here reading this way ---->

3. Finally, I'd like clarification on a small redundancy w.r.t partition selection. Section C.2.21 says that the partition selection algorithm takes as input a seed which is initialized as the block's partition index (bits 11-22 in table C.2.6). However, it also takes as input the number of partitions in the block (bits 11-12 in table C.2.4). This means that the number of partitions always one more than the value stored in the two least significant bits of the partition index, and the partition function could be simplified to:

int new_select_partition(int seed, int x, int y, int z, int small_block) {
return select_partition(seed, x, y, z, (seed & 0x3) + 1, small_block);
}

Is this correct?

Thanks!

Hi Sean,

I was doing basic testing with ASTC encoder, I find for the below config I am fing visiable artificats:

Encode setting are : medium with upto 4 possible partitions and 1024 partition indices.

other tools such as 1/2 plane and refinement iteration 2 times are also enabled.

Visible patched at the boundaries of the objects.  Is it expected?

Note: I could not up load the image, due system issue.

What kind of behaviors/artifacts are expected for 4x4 & 8x8 configuration with best & medium quality configurations.

Thanks,

Devendran Mani.

ASTC is a lossy compression - if you reduce the bitrate you will expect to get more artefacts, in particular around edges which often have high-frequency components.

Hi Pete,

Kindly clarify the below:

We find that the images are flipped(in Y direction) before encoding and then encoded.

Please let me know why the image is flipped? - is flipping function needed in encoder?

Thanks,

Devendran Mani.

Hi Pete,

Kindly clarify the below:

We find that the images are flipped(in Y direction) before encoding and then encoded.

Please let me know why the image is flipped? - is flipping function needed in encoder?

Thanks,

Devendran Mani.

Like most things in graphics much depends on where you think your origin is. In OpenGL ES the texture origin is in the bottom left (in Direct 3D and many related texture encoding formats it is in the top left).

Hi Devmani,

These 2 releases probably ship with different builds of the astc encoder, hence the difference in output. Thanks for flagging this,

Chris

hi kirpich30000,

Thanks for highlighting this, I think for now you should be able to replace the astcenc binary shipped with TCT with one of your faster builds, and it will use it.

Thanks,

Chris

Yep, I've already done it. Here is some numbers for Intel Core i5 660:

astcenc_tct_v42.exe -ts turret_diffuse_map.png out.astc 4x4 -thorough -time -showpsnr -silentmode

PSNR (LDR-RGBA): 47.471549 dB

Alpha-Weighted PSNR: 47.471548 dB

PSNR (LDR-RGB): 46.222219 dB

Elapsed time: 28.51 seconds, of which coding time: 28.46 seconds

astcenc_eval_x64.exe -ts turret_diffuse_map.png out.astc 4x4 -thorough -time -showpsnr -silentmode

PSNR (LDR-RGBA): 47.471834 dB

Alpha-Weighted PSNR: 47.471834 dB

PSNR (LDR-RGB): 46.222503 dB

Elapsed time: 18.58 seconds, of which coding time: 18.52 seconds