如何将QImage格式转换为OpenGL支持的格式
我使用 QImage 加载图像,然后将其用作 OpenGL 中的纹理。 问题在于 QImage 和 OpenGL 中颜色分量的顺序不同。 目前我在 OpenGL 中使用 GL_RGBA 格式,在 Qt 中使用 QImage::Format_ARGB32 格式。 因此,在 OpenGL 中创建纹理之前,我必须手动交换加载图像的每个像素的字节。此外,为了正确交换字节,我需要知道机器的字节序。
有谁知道更好的解决方案吗?至少,有什么方法可以使这种转换独立于字节序吗?
谢谢。
I'm using QImage
to load images which then used as textures in OpenGL.
The problem is that color components have different order in QImage
and OpenGL.
Currently I'm using GL_RGBA
format in OpenGL and QImage::Format_ARGB32
in Qt.
Because of that, I have to manually swap bytes for each pixel of loaded image, before creating a texture in OpenGL. Moreover, to swap bytes correctly I need to know endianness of a machine.
Does anyone know a better solution for this? At least, is there any way to make this conversion endianness-independent?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
glTex(Sub)Image
的最后三个参数定义像素如何传输到OpenGL 发生。如果您有 4 个 8 位值,按 ARGB 顺序依次排列,那么我建议执行以下操作:要处理字节序转换问题,请使用
glPixelStore
参数。具体来说,GL_UNPACK_SWAP_BYTES
。上面是为小端机器设计的,所以如果您在大端机器上,您应该在调用此函数之前调用glPixelStorei(GL_UNPACK_SWAP_BYTES, GL_TRUE);
,然后将其设置回 <之后代码>GL_FALSE。注意:我知道您没有提到它,但如果您正在考虑移动平台,请记住 OpenGL ES 不是 OpenGL。桌面 OpenGL 要求实现能够处理传输操作中的各种像素排列。 GL ES 的要求几乎相反。像素传输格式必须完全匹配纹理的内部格式。因此,如果您正在进行 GL ES 开发,则必须自己进行字节交换。
The last three parameters to
glTex(Sub)Image
define how the pixel transfer to OpenGL takes place. If you have 4 8-bit values, sequentially, in the ARGB order, then I would suggest the following:To deal with endian conversion issues, use
glPixelStore
parameters. Specifically,GL_UNPACK_SWAP_BYTES
. The above is designed for little-endian machines, so if you're on a big-endian machine you should callglPixelStorei(GL_UNPACK_SWAP_BYTES, GL_TRUE);
before calling this function, and then set it back toGL_FALSE
afterwards.Note: I know you didn't mention it, but in case you're considering mobile platforms, remember that OpenGL ES is not OpenGL. Desktop OpenGL requires implementations to be able to handle a wide variety of pixel arrangements in transfer operations. GL ES mandates almost the opposite. The pixel transfer formats must exactly match the internal format of the texture. So if you were doing GL ES development, you would have to do the byte swapping on your own.