Databases
StackOverflow2013
Postsdbo
POFreeImage: Pixel data accessed by FreeImage_GetBits is not correct (data + size)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POFreeImage: Pixel data accessed by FreeImage_GetBits is not correct (data + size)
    primarykey
    data
    text
    <p>I'm using the <a href="http://freeimage.sourceforge.net/" rel="nofollow">FreeImage 3.15.4 library</a> to analyze PNG images. I'm basically trying to build a simple data structure of consisting of a palette of all colors as well as an array version of the image per-pixel data consisting of indexes into the palette.</p> <p>The thing is that <code>FreeImage_GetBits</code> seems to be returning a pointer to invalid data and I'm not sure why. I am able to read the width and height of the PNG file correctly, but the data pointed to by <code>FreeImage_GetBits</code> is just garbage data, and appears to be of an odd size. No matter how many times I run the program, it consistently dies in the same place, when <code>iPix</code> in the code below is equal to 131740. I get a C0000005 error accessing bits[131740] in the std::find call. The actual and reported PNG image size is 524288.</p> <p>Furthermore, I've tried this code with smaller images that I myself have built and they work fine. The PNG I'm using is provided my a third party, and does not appear to be corrupt in anyway (Photoshop opens it, and DirectX can process and use it normally)</p> <p>Any ideas?</p> <p>Here's the data declarations:</p> <pre><code>struct Color { char b; // Blue char g; // Green char r; // Red char a; // Alpha value bool operator==( const Color&amp; comp ) { if ( a == comp.a &amp;&amp; r == comp.r &amp;&amp; g == comp.g &amp;&amp; b == comp.b ) return TRUE; else return FALSE; } }; typedef std::vector&lt;Color&gt; ColorPalette; // Array of colors forming a palette </code></pre> <p>And here's the code that does the color indexing:</p> <pre><code>// Read image data with FreeImage unsigned int imageSize = FreeImage_GetWidth( hImage ) * FreeImage_GetHeight( hImage ); unsigned char* pData = new unsigned char[imageSize]; // Access bits via FreeImage FREE_IMAGE_FORMAT fif; FIBITMAP* hImage; fif = FreeImage_GetFIFFromFilename( fileEntry.name.c_str() ); if( fif == FIF_UNKNOWN ) { return false; } hImage = FreeImage_Load( fif, filename ); BYTE* pPixelData = NULL; pPixelData = FreeImage_GetBits( hImage ); if ( pPixelData == NULL ) { return false; } Color* bits = (Color*)pPixelData; ColorPalette palette; for ( unsigned int iPix = 0; iPix &lt; imageSize; ++iPix ) { ColorPalette::iterator it; if( ( it = std::find( palette.begin(), palette.end(), bits[iPix] ) ) == palette.end() ) { pData[iPix] = palette.size(); palette.push_back( bits[iPix] ); } else { unsigned int index = it - palette.begin(); pData[iPix] = index; } } </code></pre>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. US8bitcartridge
    1. US8bitcartridge
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POFreeImage: Pixel data accessed by FreeImage_GetBits is not correct (data + size)
      1. This table or related slice is empty.
      1. VTUpMod
    1. COAre you sure that the format of the raw pixel data matches your structure? What if the order of the bytes are different? What if the compiler decides to add padding to your structure?
      singulars
      1. POFreeImage: Pixel data accessed by FreeImage_GetBits is not correct (data + size)
      1. USSome programmer dude
    2. COAlso, if you are trying to access `bits[524288]` and the number of entries in `bits` is 524288, then you are accessing out of bounds as the top index should be 524287.
      singulars
      1. POFreeImage: Pixel data accessed by FreeImage_GetBits is not correct (data + size)
      1. USSome programmer dude
    3. COSorry, that was a typo. It's failing at `bits[131740]`, actually. I'll have to investigate the data again, since 131740 is suspiciously close to 524288 / 4 (8bpp instead of 32bpp perhaps?). I checked the data format returned by my smaller test image and worked out the code to process that format; it hadn't occurred to me that the format would differ between file types. How does FreeImage decide what format to store the internal data in?
      singulars
      1. POFreeImage: Pixel data accessed by FreeImage_GetBits is not correct (data + size)
      1. US8bitcartridge
 

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