Displaying big files (.bmp)

[Mathew Joy]

Hi all,
My work involves displaying a big picture (satelite image of a terrain) zoom in - zoom out, and plotting on the image. I have solutions for all these but I want to know if they are efficient or is there is any better way to do it. We have seperate pictures for zoomed ones so that the image will be more detailed when zoomed. Now...the image of 5x cannot be loaded. So the image is cropped into many files each having the size of that of 1x. My idea is to load 4 such cropped files into a that surrounds the viewing point. And as the page is scrolled the appropriate files are loaded and deleted into/from the MemDC. For instance, if the DC has 4 images and the user is viewing the topleft image. Now if he clicks the up arrow, then I have to delete the last row(the second), transfer the first row image to the second and then load the 2 files that comes above to the DC, recalculate the next view co-ordinates and display it accordingly. Is this the prefered method or is there any better method? I use Bitblt to display the image and StretchBlt to zoom. I appreciate any comments or suggestions.

[Gabriel Fleseriu]

As far as I know, there is a limit on how large a bitmap to blit can be, in GDI. That is, depending on the OS, if you try to select a too large bitmap into a DC, the operation will fail.

It might be worth thinking of following approach: load the needed bitmaps into memory, that is, load their bits (GetDIBits() and so on). Create a "back buffer" bitmap that is exactly as large as the DC, and fill its bits on the flight, by copying the corresponding bits from the other bitmaps. I think that this can be done with a fast enough algorithmus.

My 2 cts, though.

[Mathew Joy]

Thanks Gabriel for your comments. However, the method might not be suitable for the kind of project I'm doing. Do you have any comments on the method I'm using?

[Simon666]

Maybe this (http://www.codeguru.com/forum/showthread.php?threadid=211145) and this (http://www.codeguru.com/forum/showthread.php?s=&threadid=220729&highlight=satellite) could be of help to you?

[galathaea]

It looks like what you are trying to do is buffer the file read access at the point of the operation of drawing into the memory DC, but you still want the full resource consumption. However, I'm unclear as to why this is desired when the only resource consumption actually needed is the viewport. Since you have already gone to the trouble of making file read access properly set up for dimensional movement through a picture (which can be difficult), it seems simple enough to just use those routines to draw to a DC that represents the viewport and leave out some all consuming resource which may have problems for very large bitmaps. You can still double buffer the viewport if you desire. I don't know about "best practice" but it seems that Gabriel's method is probably the fastest inside GDI or you look to see if DirectDraw or other technologies might have more appropriate capabilities (I personally do not know of the boundaries, if any outside of argument size, to Direct Draw memory lock down or bltting operations). The method I mention above conserves resources about as optimally as I think you could. Otherwise, I think I do not yet understand why you are considering building the file read system in a scanning manner (well, I mean the routines you build up to split a bitmap into separate files and use in the manner described are basically the same framework needed to scan a single large file), because it seems its major use would be to allow dropping the need for a resource to hold the entire bitmap.

[Mathew Joy]

Thanks galathaea for your comments. Let me make the situation more clear. I'm not much bothered about the memory usage, cause the system where this is implementing won't be a small PC. So I was thinking about trading memory for speed. My program do not crop the files into sizes of 1x...it is already there. I mean there will be folders like 1,2,3...2 will contain 4 files of the size of 1x, 3 will have 9 files and so on. So my job is to read the file 1x, zoom it (by, maybe, the magnitude of 0.2) and when it reaches 2x I've to display the image in the folder 2, which'll contain more detailed image. The time required for zooming is almost as propotional to that required for other s/w such as photoshop. I haven't tested my method yet (loading and zooming)...was just wondering what the experts out here think of it:) .

[DHillard]

Mathew,
I've done nearly exactly what you're planning to do. I can tell you that it will work, but response might not be what you'd like to see. When I wrote my program, I used a virtual display grid of 25 images arranged in a 5 x 5 array. I just calculated the center of the screen, converted it to a longtitude/latatude, decided which image file held the center position of the 5 x 5, then it was easy to load the other 24 images, then tiled them together for a seamless image to display.

I've found there to be about a 2 second delay loading a new "center reference point" even though new images might not need to actually be loaded. My algorithm ignored that possibility and just loaded 25 files each time.

My images are 200x200 pixel jpgs at 1,2,4,8,16,32,64 meters/pixel resolution divided into like named directories.


So... in short, what you're planning to do will work. Is it the best way? Couldn't tell ya.

[Mathew Joy]

Hi DHillard,
Nice to read your post. I did (in the conceptual level) what I posted in the begining of the thread. A few algorithms to calculate new positions. My technique is to have a grid (memdc) of 2x2, where one frame is as big as the 1x picture(which is just bigger that the screen). Now from 2x onwards 4 files that surrounds the viewing point is loaded. The problem comes when the image is scrolled (not using scroll bar; it is inefficient) beyond the grid. then you have to load 2 or 3 files which are near to the point. The time take to load a single file depends on its complexity(ofcourse in the case of bmp, the size depends on it).
Here what I did is to create 3 DCs, anticipate when the user will click the scroll button, load the images into the DC by a seperate thread, and when the user click the scroll button (or zoom) reload the grid(from the grid itself and the other 3 DCs). Now in my project the only time taken is to zoom and to load from disk. Loading is done as explained above. About zooming I wrote an alg that calculates the viewport that is to be zoomed. So in effect, the more you zoom the less time you take. The only delay here is when you zoom for the first time. Here what I do is I take that time to animate the cursor. So the user won't notice the delay :cool: