CBitmap + big images = bad?

hello,

can anyone confirm my suspicion that there is some sort of 'memory/size limit' enforced when creating a CBitmap?

i've tried to load 4k by 4k images, and i can read the tiff file fine, and the data is all present and correct, but when i do the 'bmp->create()' call it returns 0. it also doesn't work with 3k by 3k images but it DOES work with 2k by 2k and 1k by 1k. so the only thing i can think of is that there is some sort of limit imposed by CBitmap.... like i say can anyone confirm or deny this?? i've trawled through the MSDN stuff, but [of course] i haven't found anything that indicates that there is a limit.... if this is the case anyone got any ideas of how to load and display 4k by 4k images???


many thanks,
dug.

thanks, as far as i understand this would only happen if size was less than zero... which it isn't....

the only thing i can compare this to is when you use a CSting, it seems to have a secret limit as to the number of characters it can contain... although it's not documented... so i'd just like someone to say 'yes there is a limit...' so i can stop bashing my head against this brick wall... or someone to say 'no there's no limit... you're just stupid...' so that i could figure out whether or not to continue pusuing this..... i'm convinced there must be a way to do it... but i don't really want to mess about with creating bitmap headers and all that nonsense....

cheers,
dug.

just out of interest....
when the:

>> bmp->createBitmap()

call fails....

>> GetLastError()

returns '8'. anyone know what that means? or how to turn it into something useful? i'm using the following code:

Code:

---

if(!bmp->CreateBitmap(width, height, 1, 32, bmp_pixels))
{
        CHAR szBuf[80];
        DWORD dw = GetLastError();
        sprintf(szBuf, "bmp load failed: GetLastError returned %u\n", dw);
        MessageBox(NULL, szBuf, "Error", MB_OK);
}

---

on other thing... when creating a CBitmap, you specify the number of color planes... in this case it's 1, originally i was trying to use 3 or 4, RGB and RGBA respectively..... but this didn't work and the documentation says to set number of color planes to 1 if you want a color bitmap... i don't understand this.... can anyone explain? also it might be worth double checking that '32' is OK for the number of bits per pixel.... anyone?

cheers,
dug.

8 is ERROR_NOT_ENOUGH_MEMORY, the errors are defined in winerror.h.

I don't use a class library, so I'm really guessing, but is the array big enough for the size you are asking for?

thanks.

OK, well, that's interesting.... why would that happen? because i've already done the 'hard work' in terms of memory allocation, i.e. the pixel data is loaded correctly, all i'm doing is passing a pointer to the pixel data block to the CBitmap object...

it certainly not a physical memory shortage, even after one CBitmap fails to create, i can still load more pixel data for other images... so does that mean there is some sort of hard-coded limit on CBitmap sizes and if so WHY bill.... WHY?

it don't make no sense.

as to the array you mentioned... are you refering to 'bmp_pixels' in the createBitmap() call? because that's the array of pixels [32-bits per pixel] loaded from file and it seems fine, it's already full of information. like i say the same code works fine up until an image of around 2900x2900....

cheers,
dug

the plot thickens....

>> if(!bmp->CreateBitmap(2500, 2500, 1, 32, NULL))

is OK.

BUT:

>> if(!bmp->CreateBitmap(3000, 3000, 1, 32, NULL))

is NOT!

so my conclusion is that there is some hard-coded limit in there somewhere.... is it possible that there is a 'maximum memory allocation' setting somewhere in the project settings that i could maybe increase?

>>> i = BMP.CreateBitmap(3000,3000,1,32,NULL);

That returns 1 for me.

*** EDIT ***

4900,4900 works, 5000,5000 returns zero.

*** EDIT ***

4999,4999 works!

stranger still, if i crank up my virtual memory to like '4000 Mb' i can open one image at 4kx4k, but it won't load anymore, AND if i look at the system manager, the physical memory use is relatively small.... i just don't understand this...

adrian.... what are your virtual memory settings on your machine?

thanks,
dug.

The bitmaps are handled by windows internally so there is really no way to allocate more memory for this task. adrianxw's results are very interesting. I think HeapAlloc() may give windows more breathing room. However, it might not since I'm not sure if an HBITMAP goes into a processes heap or into the global heap. Stupid windows.

>>> what are your virtual memory settings on your machine?

The amount of virtual memory allocated to a task is variable, (up to 4GB). What info do actually want? I'll try and find it.

These bitmaps, they really are VERY big. Is there not another way to handle whatever it is you are trying to do?

well, ideally we'd like to be able to zoom right in and use the detail you get at 4000x4000 pixels, that's why we've got camera's that capture at this resolution.... what i don't understand is that the pixel data is already loaded... the memory is already allocated, CBitmap is simply wrapping itself onto this data... but throws a 'not_enough_memory' exception, even though there's plenty of physical and virtual memory, it doesn't make any sense...

what i may have to do is have a limt to the size of window.... maybe 800x800, and then basically create a new CBitmap of which would be a 'region' of the full 4000x4000 image, and every time the user scrolls around the image or whatever... i could just destroy the old region and create a new one, but that's not very efficient... but it would still make viewing the entire image impossible.... so i don't know..... need to think about this, didn't think there would be any problem with this at all..... Feckin' windows...

Unless you have some truly impressive screens, you not going to be able to show a 4000x4000 bitmap anyway, only a part of it.

You can always load parts of the full image into an array of back buffers and then just blit the various visible parts to an additional DC that was shown on the screen. I did something similar to this several years ago when I was fiddling with some astronomical images. Of course, that was all pure API stuff.

i don't mean that we could show the 4kx4k all at once on screen... you're right that would be SOME display!!! but to be able to zoom out, to see the whole image, and also to be able to zoom right in would be nice.... to do this efficiently you would need the whole image... just scale it up and down. rather than having to have different sized images on file, one for zooming 'regions' of large file, and one smaller file that allows you to see the whole image.... if you know what i mean?

That would be some video card too!

Traditionally speaking you would use an array of images for this task. Its done in games, renderers, and other types of programs where you would ever need 4000x4000 pixels worth of imagery. I remeber a while back a thread where someone was trying to create a "big image" and couldn't figure out what he was doing wrong. Then he sent me a private message that said his target image was 45,000x45,000 pixels! I had to break his heart and tell him that even a monochrome image at that resolution wouldn't fit into his memory. Let alone the 4gigs worth of RGB data that he wanted. At least this thread is reasonable.

there must be some trick... because photoshop can view the images... you see, we want to be able to see the whole image [zoomed out of course] and be able to see at 100% as well [obviously this would just be a small region of the image]... so i'm going to have to make a smaller image from the big image... i guess for 1/8 size i could just create a new image.... and use every 8th pixel value horizontally and vertically.... and then depending on zoom value... 1/4 size would be every 4th pixel or something... but it seems a bit inefficient to me to have to create a new bitmap from the large data every time you scroll/zoom.... i dunno.... i think of something hopefully...

This is just a guess...........

Got a 64Mb graphics card?

Correct me if I am wrong, but a 4000*4000 bmp with 32bit colour is just under 64Mb.

CreateBitmap() and CreateCompatibleBitmap() (which should be used to create colour bitmaps as it improves performance) are device dependant.

You could try CreateDIBSection() to create a device independent bitmap.

Novacain:

I've never done this, and don't have time to try right now, but have you ever blitted from multiple back buffers to a displayed DC that has a world transform applied to it, (in GM_ADVANCED mode), with the XFORM.eM11 and XFORM.eM22 matrix members set to a fractional value?

If that works, then the world transform would scale the various blits and produce a composite "zoomed out" view, and by changing the matrix values, progressive "zoom ins" could be acheived, all without ever loading the whole bitmap into a singe structure.

Sorry, we are in acceptance testing, again, so very busy...

>>but have you ever blitted from multiple back buffers to a displayed DC that has a world transform applied to it,

Have not done a lot with world transforms on multiple or composite images.
Should work, would probably have to use some overlap and experiment to get it aligned.

StretchBlt() will not work IMHO. The results will be poor (even with HALFTONE set) and the drawing slow. Best results would be achived with int multiples.

Use a image lib that has some good, fast image resizing functions for jpg's (ImageSource by Small Animals Software). I use this to resize the area of an image for zoom ect. My stuff is designed for 56k internet and so uses small compressed images.