Artifact in texture output on Windows only

[jaadelgren]

While testing various compression settings, we came across an issue that only seems to manifest on Windows. Given the following image as input

and running toktx like so

toktx.exe --encode etc1s --clevel 1 --qlevel 192 --no_sse --assign_oetf linear --threads 1 <path/to/output> <path/to/png>

produces the following result:

So far this is the only image tested that has artifacts in the output. Versions v4.2.1 and v4.3.0-alpha3 were used (same result).

Please let me know if I can provide any additional information. I'll include a zip with the original PNG and resulting KTX files as well.

duck-ktx-issue.zip

[jaadelgren]

I neglected to mention--changing the --clevel argument to anything other than 1 causes the issue to disappear.

[MarkCallow]

This is not in anyway intended to suggest it is related to your problem, but why did you turn off SSE?

[MarkCallow]

The PNG has a gamma of 2.2. Insisting it is linear, as you are doing, will mess up the encoding. Please try without --assign_oetf linear, thus letting the tool convert it to the, almost the same, sRGB transfer function and encode it knowing it is an sRGB image. Report your result.

[javagl]

@MarkCallow Maybe you know from the tip of your head:

• Is there any difference in the implementation between the toktx executable and the ktx create function that may be relevant here? (I.e. could there be a bug in toktx that might be fixed in ktx create? Or is this calling the same functions under the hood, and thus, really only a difference in the CLI?)
• Iff one would try to do a ktx create call that is 'equivalent' to the given toktx call (regardless of whether the exact parameters 'make sense' or not), then what would this be?

This one could be close... ktx create --format R8G8B8A8_UNORM --encode basis-lz --clevel 1 --qlevel 192 --no-sse --assign-oetf linear --threads 1 InputFile.png OutputFile.ktx but I'm not sure about the format part.

[MarkCallow]

Both tools use the same libktx code under the hood so there is unlikely be any difference in results. The original input file is RGB not RGBA so I recommend using --format R8G8B8_UNORM. This is for clarity and a small memory and time saving as the ETC1S (basis-lz) encoder will not include an alpha channel in the encoded result when every pixel is 1.0. Other than that what you wrote is the equivalent command.

You have not answered my question regarding your use of --assign[-_]oetf. You should never use this unless you are absolutely certain that the input file color space is misidentified in the file's metadata or there is no metadata and you know what the color space is. In this case, as I wrote, the metadata indicates a gamma of 2.2.

[jaadelgren]

This is not in anyway intended to suggest it is related to your problem, but why did you turn off SSE?

No particular reason. I was simply toggling different settings while testing and --no_sse made it into my post. It does not change the result as far as I can tell.

I can confirm that removing --assign_oetf linear causes the issue to go away.

The CLI command above does not really reflect our use-case, but was intended to be a minimal reproducible example. In any case, signs are pointing towards a bug in our integration of the KTX library. Long story short, a very similar artifact (the exact same, to my eyes) appears when saving data processed using our current workflow. Using the exact same raw RGBA data and encoding with a standalone program that only uses KTX, equivalent settings, the artifact does not appear. Since this likely has nothing to do with the original issue, I'll go ahead and close. Apologies for the noise and thanks for your time and help.