cginternals / glraw

C++ library that converts Qt supported images to OpenGL raw format.
MIT License
63 stars 7 forks source link

converting images with non-power-of-two width does not work #27

Open PFischbeck opened 10 years ago

PFischbeck commented 10 years ago

When converting this image hpicgs 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: hpicgs-strip

I did this on Windows 8.1.

cgcostume commented 10 years ago

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): hpicgs-111-128

These are working (128x111px and 128x128px): hpicgs-128-111 and hpicgs-128-128

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.

cgcostume commented 9 years ago

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

cgcostume commented 9 years ago

in any case - if no "good" solution is available or until this is not fixed, a warning/error should be provided.

mjendruk commented 9 years ago

I did some tests permutating the pictures, formats and types. I came up with this, the checked cases crash: screen shot 2014-11-27 at 00 40 21 I think we should present our issue to some opengl mailing list.

cgcostume commented 9 years ago

thanks a lot, this is good - we could try this on stackoverflow or here: https://www.opengl.org/discussion_boards/