Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Part of the problem here seems to be a mismatch between the format of the pixel data you're getting from FreeImage and the format expected by <code>glTexImage2D</code>. </p> <p><code>FreeImage_ConvertTo32Bits</code> is going to return an image with 32-bit pixel data. I haven't used FreeImage but usually that would mean that each pixel would have 4 8-bit components representing red, green, blue and alpha (opacity). The format of the data you get from the BMP file depends on the file and may or may not have an alpha channel in it. However it seems safe to assume that <code>FreeImage_ConvertTo32Bits</code> will return data with alpha set to 255 if your original image is fully opaque (either because your BMP file format lacked an alpha channel or because you set it to opaque when you created the file).</p> <p>This is all fine, but the problem comes with the call to <code>glTexImage2D</code>. This function can take pixel data in lots of different formats. The format it uses for interpreting the data is determined by the parameters <code>type</code> and <code>format</code> as decribed <a href="http://www.opengl.org/sdk/docs/man/xhtml/glTexImage2D.xml" rel="nofollow">here</a>. The value of <code>format</code> in your code is <code>GL_RGB</code>. This says that each pixel has three components describing its red, green and blue components which appear in that order in the pixel data. The value of <code>type</code> (<code>GL_UNSIGNED_BYTE</code>) says each component is a single byte in size. The problem is that the alpha channel is missing, so <code>glTexImage2D</code> reads the pixel data from the wrong place. Also it seems that the order of the colours that FreeImage produces is blue-green-red, as pointed out by Roger Rowland. The fix is simple: set the <code>format</code> to <code>GL_BGRA</code> to tell <code>glTexImage2D</code> about the alpha components and the order of the data:</p> <pre><code>glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, nWidth, nHeight, 0, GL_BGRA, GL_UNSIGNED_BYTE, (void*)FreeImage_GetBits(pImage)); </code></pre> <p>To see if this problem could explain the weird outputs, think about the big blocks of blue colour in your original image. According to GIMP this is largely blue with a smaller amount of green (R=0, G=162, B=232). So we have something like this:</p> <pre><code>B G R A B G R A B G R A ... meaning of bytes from FreeImage_GetBits 1 - 0 1 1 - 0 1 1 - 0 1 ... "values" of bytes (0 -&gt; 0, - -&gt; 162, 1 -&gt; 232 or 255) R G B R G B R G B R G B ... what glTexImage2D thinks the bytes mean </code></pre> <p>The texture pixel colours here are: orange, light yellow, bright cyan and a purply colour. These repeat because reading 4 pixels consumes 12 bytes which is exactly equal to 3 of the original pixels. This explains the pattern you see running over much of your output image. (Originally I had gone through this using the RGBA order but the GBRA version is a better fit for the image - the difference is especially clear at the start of the rows).</p> <p>However I must admit I'm not sure what's going on at the beginning and how to relate it to the pink square! So there might be other problems here, but hopefully using <code>GL_BGRA</code> will be a step in the right direction.</p>
    singulars
    1. This table or related slice is empty.
    1. POloading texture from bitmap
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMike Dinsdale
    1. USMike Dinsdale
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POloading texture from bitmap
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload