ETC2 SRGB test files have an invalid glBaseFormat about ktx-software HOT 6 CLOSED

"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.

from ktx-software.

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

from ktx-software.

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.

from ktx-software.

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.

from ktx-software.

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.

from ktx-software.

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.

from ktx-software.