glraw
glraw copied to clipboard
converting images with non-power-of-two width does not work
When converting this image
with
glraw-cmd -f GL_RGB -t GL_UNSIGNED_BYTE hpicgs.png
, the program glraw-cmd
crashes. The glraw file is generated, but it has a strip in the top row:
I did this on Windows 8.1.
thanks for the report. what i found:
converting images with a power-of-two width always works. but for textures with non-power-of-two width, glGetTexImage
always returns GL_RGBA
format, ignoring the provided format
. this obviously writes more data into the QByteArray
than anticipated, and either results in a crash in glGetTexImage
, glFinalize
, or when destroying the QByteArray
instance, which asserts that data with more than reserved size was written.
The following images can be used to try this (also with various formats like GL_RED
etc.) and debug with, e.g., photoshop raw import.
This works not due to non-power-of-two width of 111px (111x128px):
These are working (128x111px and 128x128px):
and
Note: i also tried to use glReadPixels
instead of glGetTexImage
, but the same issue occured. Furthermore, i tested on IntelHD, NVIDIA, and AMD mobility, with the exact same results.
To fix this issue, we need to handle this case explicitly; getting texture data in GL_RGBA
and selecting the channels depending on the requested format. I hope this is not an issue for compressed textures though, because this fix would not apply on these.
alternative approach: extend the texture to match the next power of two width and fill the additional vertical lines with some fill color. after reading it back in the desired format, remove the filled area. Note: this would only work for uncompressed textures...
in any case - if no "good" solution is available or until this is not fixed, a warning/error should be provided.
I did some tests permutating the pictures, formats and types. I came up with this, the checked cases crash:
I think we should present our issue to some opengl mailing list.
thanks a lot, this is good - we could try this on stackoverflow or here: https://www.opengl.org/discussion_boards/