Out of memory when loading image?

[AxiomsofDominion]

I get an error which I previously hadn't gotten without much of a change to explain it. I'm loading an image and I get an error saying I'm out of memory. I have plenty of ram left and similar images had loaded fine before. Does SFML have some sort of memory limit I'm not aware of for this function:

sf::Image *ImageManager::addImage(std::string imgPath) {
    sf::Image *image = new sf::Image();
    if (!image->loadFromFile(imgPath))
    {
        // error...
    }
    images.push_back(image);
    return image;
}

Specifically load from file? For reference the image is only 36865KB.

[Redys]

Maybe format of file is unsupported? Documentation:

"The supported image formats are bmp, png, tga, jpg, gif, psd, hdr and pic. Some format options are not supported, like progressive jpeg. If this function fails, the image is left unchanged."

[eXpl0it3r]

What's the exact error message you get?
What's the overall memory usage of your application? What's your OS? What version of SFML are you running?

[AxiomsofDominion]

What's the exact error message you get?
What's the overall memory usage of your application? What's your OS? What version of SFML are you running?

SFML 2.0, task manager says about 1.3gigs, Windows 7. Its also just a standard bitmap image. None of these things were different previously when it was working and I've had the memory use higher. The exact error message is just: "Failed to load image "". Reason: Out of memory. I guess it was crashing earlier with just Code::Blocks saying cxa_throw() so I moved a vector initialization ahead of the image load. But the vector doesn't affect the image so there does seem to be some sort of memory limit thing going on.

Actually checking again, the crash comes from this: Program received signal SIGSEGV, Segmentation fault.
In sf::Image::getPixel (this=0x7cdc1ff8, x=3566, y=1950) at D:\sfml-release\_Sources\SFML\src\SFML\Graphics\Image.cpp:281 ()

Presumably because you can't use getPixel on an image that doesn't load. But I've got 8 gigs on ram and I'm not even close to that so I can't figure out why I'm getting an our of memory error.

[Laurent]

What the size (width and height) of your image?

[eXpl0it3r]

If you really use SFML 2.0, then I highly recommend to upgrade to at least SFML 2.3 or 2.4. We've added a lot of bugfixes since 2.0 (4+ years ago).

If you remove everything from main() and just load an image, does it still happen?

[AxiomsofDominion]

What the size (width and height) of your image?

5000 by 3000 more or less. I don't have exact values cause I'm at work.

I load a base image of the same size all blue for water then I add land then I color 10000 uniquely colored provinces and then I exit out and start again but go to the play game mode instead of map gen. That's why I don't understand why it won't load again as it was initially made/modified by sfml already. Is sfml checking against a smaller amount of memory than the program is?

[AxiomsofDominion]

I attempted to run the program with different province counts on the map. It worked at 4000. At 7000 it closed with code 0x3. At 6000 I got some useful errors:

An internal OpenGL call failed in Texture.cpp <161> : GL_OUT_OF_MEMORY, there is not enough memory left to execute the command

An internal OpenGL call failed in Texture.cpp <375> : GL_INVALID_VALUE, a numeric argument is out of range

The game proceeded to post this error each time I load the image and then continued to run. The GUI works, the image appears to exist and I can even use the unique province colors plus getPixel to color pick and cause TGUI to put up proper province data. However the image outside of TGUI GUI panels is pure white.

[korczurekk]

The problem is most likely your vRAM in GPU being too small to load image to its memory. Hover it can be contained within your normal RAM, so sf::Image methods work properly, as they use image stored as array of pixels.

[AxiomsofDominion]

The problem is most likely your vRAM in GPU being too small to load image to its memory. Hover it can be contained within your normal RAM, so sf::Image methods work properly, as they use image stored as array of pixels.

I thought it might be that. I should have quite a bit of vram but ah well. Is there a way to force it to stay in RAM?

[korczurekk]

As far as I know textures in vram are not compressed, so they may take quite more place. And YOU do load it to vram somewhere by using sf::Texture, sf::Image itself stores everything in RAM, and if it crashes, there may be some problem with SFML. If you want to draw it, you should divide it into smaller pieces, place in sf::Image/s and dynamically create sf::Textures to upload those to VRAM. However it can be pretty slow. Maybe lower image's resolution?

[AxiomsofDominion]

As far as I know textures in vram are not compressed, so they may take quite more place. And YOU do load it to vram somewhere by using sf::Texture, sf::Image itself stores everything in RAM, and if it crashes, there may be some problem with SFML. If you want to draw it, you should divide it into smaller pieces, place in sf::Image/s and dynamically create sf::Textures to upload those to VRAM. However it can be pretty slow. Maybe lower image's resolution?

No image doesn't crash as far as I know. It's a map which is why it has that resolution. The only reason it appears to crash is that it has more unique colors. Otherwise the images are identical. Also apparently you can load 3 or more images with half as many colors but one image with 6000 fills memory. Seems weird.

[AxiomsofDominion]

Okay so I upgraded to TGUI-0.7.1 and SFML-2.4.0.

Although every image, they are .bmp, is the same size of 36MB they range in unique province colors between 1000 and 10000. 6000 and up crashes, 4000 and down loads properly and I haven't tested any in between.

I assume when uncompressed the difference in number of unique colors causes them to be wildly different sizes?

Would switching to .png make any difference?

The total image size is 4096x3072 if that matters.

[AxiomsofDominion]

I am stupid, so sorry. Apparently the problem was that I was foolishly using a 32-bit application like a giant dufus. I recompiled SFML-2.4.0 and TGUI-0.7.1 and then my own project with the mingw-w64 compiler. I screwed it up repeatedly last night somehow but this morning I finally got everything right. 10000 provinces went all the way to 2.4GB of memory. I expect it'll go to more when the game is in full swing. Luckily 64 bit doesn't really care so I'm in the clear. Thanks for the help guys.