ETC2 SRGB test files have an invalid glBaseFormat

[jherico]

The test files etc2-sRGB.ktx, etc2-sRGBa1.ktx, etc2-sRGBa8.ktx use either 0x8C40 (GL_SRGB) or 0x8C43 (GL_SRGB8_ALPHA8) as their base internal format.

The spec seems a little unclear on this point...

For uncompressed textures, this value will be the same as glFormat and is used as the internalformat parameter when loading into a context that does not support sized formats, such as an unextended OpenGL ES 2.0 context.

GL_SRGB is part of EXT_sRGB, so it's not valid for an unextended context. On the other hand, EXT_sRGB doesn't add the functionality of sized formats, except for the use of renderbuffers.

While GL_SRGB might be valid if we assume the target platform supports EXT_sRGB, GL_SRGB8_ALPHA8 seems incorrect, and should be replaced with 0x8C42 ('SRGB_ALPHA') or 0x1908 (GL_RGBA) depending on how you interpret the case of GL_SRGB.

[MarkCallow]

"unextended ... context" is given as an example only. I need to review the spec but to see if EXT_sRGB adds GL_SRGB as a value you can use for the format parameter. You're correct that GL_SRGB8_ALPHA8 is an incorrect value for base format.

Thanks for raising this issue.

[jherico]

For context, I'm currently trying to work on a header-only C++ KTX library, similar to the kind of compact, easy to use functionality you get from tinygltf or Niels Lohmann's json library. The work in progress is here: https://github.com/jherico/khrpp

[MarkCallow]

For context, I'm currently trying to work on a header-only C++ KTX library

Good. I'm thinking about doing the same for libktx so let me know how it goes. Will you be supporting OpenGL & Vulkan? Please be aware of KTX2 while you do your design work.

Regarding this issue, I will change etc2-sRGBa1.ktx and etc2-sRGBa8.ktx to use 0x8C42. It ultimately doesn't make any difference because base internal format is ignored when loading compressed textures, which these are. Only internalformat is passed to glCompressedTex2D.

[MarkCallow]

The generator of these KTX files might still be generating files with these incorrect base internal formats. You can file an issue at https://github.com/Ericsson/ETCPACK, if so.

[jherico]

Will you be supporting OpenGL & Vulkan?

The core header won't have a dependency on either. It will just be an abstraction for parsing, validating, and possibly creating KTX files. However, I plan to include unit tests and a sample application of uploading a KTX to the GPU using the library, and eventually possibly a viewer application, just cause I'm kind of disappointed with the currently available KTX viewers I've found. All of that would likely be using Vulkan (and if I build a full viewer application, Qt).

Trying to add in a 'standard KTX loader' that results in a VkIimage or a GLuint is, I think, problematic. For GL you start to have to tangle with what kind of GL loader the client is using, which complicates the headers with a bunch of directives. For Vulkan, most serious projects will be using a custom memory allocator with per-image sub-allocation and a dedicated transfer queue, while most beginner projects won't be doing either. Basically, once you get past the point of "I have an array of bytes that represents a mip face", the right way of getting it onto the GPU depends too much on who the user is and what kind of environment they're working in.

The generator of these KTX files...

I'll try to take a look at the upstream project and see if it is.

[MarkCallow]

I see. So basically you have something like ktxTexture object without the VkUpload and GLUpload functions.

VkUpload takes an allocator pointer (which can be null) and the desired tiling and usage. There is also a helper function that calls this with the most common options for tiling and usage and does not take an allocator pointer.