search

KhronosGroup / KTX-Software

KTX (Khronos Texture) Library and Tools
Other
854 stars 226 forks source link

Fix recreateBytesPlane0 and add test #856

Closed MarkCallow closed 6 months ago

MarkCallow commented 6 months ago

for all valid VkFormats.

Merge needs to wait until issue #857 is fixed so it can be tested against correct DFDs.

MarkCallow commented 6 months ago

@aqnuep there are now a small number of failures in the extract tool tests having to do with extracting X8_D24_UNORM_PACK32 format to .raw files. I suspect it because the previous version of recreate... returned a value of 3 for this format. The new one returns the correct 4. Most likely I just need to regenerate the golden files. What is a good way to examine the content of a .raw file? I can see the current golden file has a size of 192 while the new output is 256 bytes which suggests it is indeed due to the 4 instead of 3.

Apologies for the bug in the previous version of recreate....

I think I'm going to rename the function to reconstructBytesPlane0. I prefer your "reconstruct" and the current name is too long. I think I'll also make it return the value. For dfdutils users I'll have to provide a wrapper for backward API compatibiility.

aqnuep commented 6 months ago

> What is a good way to examine the content of a .raw file?

There's no easier way than to inspect the file in a hex viewer. You should be able to compare the payloads. But you can also try to feed that raw file back into ktx create, if that makes it easier.

-Daniel

On Fri, Feb 9, 2024 at 10:02 AM Mark Callow @.***> wrote:

@aqnuep https://github.com/aqnuep there are now a small number of failures in the extract tool tests having to do with extracting X8_D24_UNORM_PACK32 format to .raw files. I suspect it because the previous version of recreate... returned a value of 3 for this format. The new one returns the correct 4. Most likely I just need to regenerate the golden files. What is a good way to examine the content of a .raw file? I can see the current golden file has a size of 192 while the new output is 256 bytes which suggests it is indeed due to the 4 instead of 3.

Apologies for the bug in the previous version of recreate....

I think I'm going to rename the function to reconstructBytesPlane0. I prefer your "reconstruct" and the current name is too long. I think I'll also make it return the value. For dfdutils users I'll have to provide a wrapper for backward API compatibiility.

— Reply to this email directly, view it on GitHub https://github.com/KhronosGroup/KTX-Software/pull/856#issuecomment-1935556140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIBZY3NZORXIXVZ4M2Y5RXLYSXQ2ZAVCNFSM6AAAAABDAZTIXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGU2TMMJUGA . You are receiving this because you were mentioned.Message ID: @.***>

MarkCallow commented 6 months ago

I can see the current golden file has a size of 192 while the new output is 256 bytes which suggests it is indeed due to the 4 instead of 3.

The incorrect bytesPlane0 value messed up the calculation in ktxTexture2_GetImageSize resulting in not writing enough bytes to the raw file. I've updated the golden images in https://github.com/KhronosGroup/KTX-Software-CTS/pull/17. Hopefully I've managed to point this branch at the branch in the CTS. .gitmodules is still pointing at branch main.

aqnuep commented 6 months ago

Hopefully I've managed to point this branch at the branch in the CTS. .gitmodules is still pointing at branch main.

The branch in .gitmodules is the the "tracked" branch. That confused me to in the past, don't worry about it. Only the commit hash the git module points to is relevant.