Feature request: Texture loading without OpenGL context about ktx-software HOT 16 CLOSED

What exactly do you mean by "in raw data?" You can today use standard functions, on whatever platform you are using, to read the KTX file into memory, e.g. fopen, fread. Then later when you are ready to load the texture into GL, you can use ktxLoadTextureM from libktx to load the texture into GL from memory.

from ktx-software.

Well let me rephrase the question.

As a example, in Blender we are using a separate thread to create thumbnails for the images when using a file browser.
This results in the need to expose a GL context for the separate thread which makes no sense at all.
For editor tools, it makes no sense to stick a GL context everywhere to be able to author or work on the content, so a context-less load function would benefit a lot.

A different example would be introduction to image loading libraries, which by themselves do not allow for dependencies such as GL, and why a accelerated version would be recommended, a slower version without the dependency should at least be available to use for applications where loading times are not crucial.

from ktx-software.

Hi, Antony here, working with Joey on blender integration of the format.

The problem we have is that we even want to move loading of thumbnails to a separate process to prevent failures from crashing the main application. Such a process will not have access to a GL context even.

For simple image processing tools (open -> simple operation -> store -> close) requiring a GL context is a bit of an overkill. I understand the library is geared towards adoption by game developers mostly, but if you make the library more friendly for content authoring as well it will help a lot.

from ktx-software.

It sounds like you are talking about displaying the image not just loading it.

Remember that KTX files often contain complete mipmap pyramids, the textures may not be images and there may be formats that cannot be displayed by whatever graphics library is being used. A proper specification of how to cope with all these issues is needed.

I think that the way the images should be laid out in memory (component order, padding, stride, etc) will have a dependency on whatever is ultimately being used to display them. If libktx takes on the task of displaying the textures without OpenGL, there will be a dependency on something else, that the application may not have.

I need a clear specification of what is required.

from ktx-software.

Would requesting a tightly packed RGBA array from a certain mipmap level be difficult?

User should be able to probe dimensions of the image at a certain level and then provide an array that will be filled with the image data or so. Having an extra dependency is not so terrible at least from our side.

from ktx-software.

Not all KTX files are RGBA and there are many different data formats. Supporting everything requires the entire pixel unpack code from an OpenGL implementation.

Perhaps providing a callback that is called with a pointer to the data for each mipmap level, as the level is extracted, would work. From either a query or another callback, called when the header is read, the application can determine the format and type of the data. Would this work for you?

I think this feature could be added along with support for using glTexStorage. Default callbacks would be provided for the TexStorage and non TexStorage cases. For the former, the callback after the header reading would set up the texture object using glTexStorage. The mip level callback would load the data of the level into GL glTexSubImage_. For the latter case, the first callback would be a NOP, the second would load the data via glTexImage_.

from ktx-software.

Hmm..I thought that there would be a software implementation of the compression algorithm of the format already even if the library would offload most of the work to the GL implementation.

I am not sure if I understand correctly if the proposed solution will need OpenGL calls...
To repeat the problem, we want to bypass the GL implementation entirely - even if needed by the linker during linking of the library, we are not guaranteed to have a GL context at image loading time.

If a GL implementation is available everything works already for us, in fact we have already implemented a loading scheme by querying the texture from the OpenGL implementation after loading, see

https://git.blender.org/gitweb/gitweb.cgi/blender.git/blob/5e060bed27bd3e2a5e75f0c16ea65dc4534fdf04:/source/blender/imbuf/intern/ktx.c

A callback would be OK. I don't think the R/RG/RGB/RGBA format is the real problem - as long as we have that information beforehand we can adapt to it. Rather, the issue is decompression. If a compressed format is provided we'd need a way to get the uncompressed image data back.

from ktx-software.

The proposed solution would not need OpenGL calls. Those would only be made by the default callbacks, which you would be overriding with your own.

I think you still do not understand the complexity of OpenGL textures. It is not just R/RG, etc. There is also the data type, including floats, and some textures are not image data at all and may require some sort of filtering to make a suitable visual representation.

Regarding the compressed formats I do not know if there are open source decompressors available for all the supported formats. Even the ETC decompressor, the only one currently included in libktx, is not open source. The license restricts how it may be used. I think ARM may have an open source decompressor for ASTC. I don't know about any of the other compressed formats. Any that are available can be added to libktx guarded by #ifdefs like ETC.

Your opening comment makes me wonder if you realize the whole point of compressed texture formats is that they remained compressed. The needed texels are decompressed on the fly during sampling. Decompressed images are never stored.

from ktx-software.

Excellent!

I know that the point is to keep the texture compressed, but for image editing, you need access to individual image pixels.

I see there are indeed issues with the licence. Not sure how much the sentence (from the licence) "The code for unpacking ETC1, ETC2 and EAC compressed textures has a separate license that restricts it to uses associated with Khronos Group APIs." can be stretched to include editing software such as blender in this case.

Of course we can rule out importing compressed formats if the licence does not allow it with a nice message - and explicitly only allow exporting. That's fine as well, as long as the implications to users of the format are clear - ie "use compressed formats only as final formats, not to be used for editing", which also makes sense if the format is lossy.

I expect users would like to edit compressed formats too anyway, but I understand if there are issues with this and hope there is a way to at least handle the rest.

from ktx-software.

I am now designing a fix so that the library can be used to obtain the format/structure information of the texture and the raw image data for each array element/cube face/level without needing an OpenGL context. I need to know, is it okay if ktx.h continues to include gl.h and friends? Even if it does, a context or indeed linking with an OpenGL {,ES} library will only be necessary if one of the ktxLoadTexture* functions is called.

from ktx-software.

IMHO it would be better to not include opengl headers or allow the user to override it.

It would help (at least) Windows users to handle Opengl in their own way - as there is many Opengl loaders around.

This would also apply to the GL function pointers I think.

from ktx-software.

Thanks for the feedback. I will try without including gl.h and see how it goes. I will probably need to include KHR/khrplatform.h though for some typedefs. Actually the only things being used from gl.h are some other typedefs.

ktx.h does not use any GL function pointers and I fully agree it should not.

from ktx-software.

FWIW, to me, an ideal API would allow to load/parse the KTX and provide me the data so that I can upload it myself using OpenGL (using AZDO techniques, or older, or whatever suits my needs), and an ideal distribution medium would a single header file, just like stb_image (https://github.com/nothings/stb/blob/master/stb_image.h) - it would IMHO help adoption by removing any friction that could come from using cmake or whatever.

FWIW bis, I started going in this direction, but I lack time to continue for now : https://gist.github.com/rotoglup/9a6340752a2629496d4b

from ktx-software.

I have just pushed the new API to the noglcontext branch (commit 2cc5b36). I have also rewritten the loader functions to use the new API. Next I'll write a test that displays the images without using OpenGL. The new API is in the file reader.c. There are open functions that return a new KTX_context handle and ktxReadHeader, ktxReadKVData and ktxReadImages functions that operate on this context. The latter takes a callback function that is called for each image. You can look at ktxLoadTexture in loader.c to see one way of using this API.

Please send me feedback here.

from ktx-software.

Commit 2cc5b36 has problems on Linux. They are now fixed. Please use commit 62951bb or later.

from ktx-software.

The new API complete with new tests is now on the incoming branch.

from ktx-software.