hi.... evry body
i am writing a program to show over 600 picture "bmp", i do not want to use the resource file because it takes a lot of memory
what is the best way to show them. thanks
Hi
I think this is a good way from masm32lib BitmapFromFile.
Invoke BitmapFromFile,addr Filename
Greets
sudeer,
Are you asking what is the best way to show them, or the best way to store them?
sudeer,
Probably, the best method is to not store the images as resources but to load and display each bmp file. This Masm32 example is a good one :
\masm32\examples\exampl02\showdib
hi...........what i ment is to show them, if i use the normal way, i end up with 125 MB file size and i am using only 200 bmp's.
what if i use 600 bmp's i am going to end up with more than 375 MB file size, which is very large file.
ShowPage proc uses eax ebx numb:dword
m2m ebx,numb
.if ebx <= 222*4
invoke LoadBitmap,hInstance,Q_BMP[ebx]
mov hBmp1,eax
invoke ShowBmp,hBmp1,hBmpPage
.endif
ret
ShowPage endp
ShowBmp proc uses eax ebx esi hBmp:dword,hwin:dword
invoke GetDC,hwin
m2m ebx,eax
invoke CreateCompatibleDC,eax
m2m esi,eax
invoke SelectObject,eax,hBmp
invoke GetClientRect,hwin,addr rc
;invoke BitBlt,ebx,0,0,rc.right,rc.bottom,esi,0,0,SRCCOPY ;Copy the bitmap
invoke StretchBlt,ebx,0,0,rc.right,rc.bottom,esi,0,0,386,560,SRCCOPY
invoke DeleteDC,esi
invoke ReleaseDC,hwin,ebx
xor eax,eax
mov PageFlag,1
ret
ShowBmp endp
Hi sudeer,
If I understand correctly, you are stroring all your bitmaps in the resource section. With a lot of image files, you will have an oversized executable. You should load your images from disc and then display them using image functions like BitmapFromFile.
Also, consider compressing each image from a Bitmap into a JPEG file, if a very slight loss in quality is acceptable. This could easily reduce the amount of space taken by the images by 85% or more. Of course, there are times when the highest image quality must be maintained (medical imaging for example.) In that case, try the PNG compression algorithm. PNG gets less compression, but can be less lossy. Experiment, see which one works best for you.
Chris has posted some code to read JPG and PNG images from resources:
http://www.masm32.com/board/index.php?topic=10191.0
Or if the bitmaps are simple graphic images or similar, rather than photographs, in most cases you can use lossless compression (ZIP, RAR, GZIP, etc) to reduce the amount of space taken by the images substantially below that which would be required for a JPEG, with no loss of image quality.
Quote from: Mark Jones on November 15, 2008, 07:01:11 PM
PNG gets less compression, but can be less lossy.
PNG is by default lossless (http://www.libpng.org/pub/png/).
JJ, I say "less lossy" because often, in the case of PNG data, 256 or less colors are used along with a dither. This results in very good (perceivable) quality with filesizes approaching that of JPG, while eliminating the macro-block visual artifacting of JPEG.
Quote from: Mark Jones on November 15, 2008, 10:15:47 PM
JJ, I say "less lossy" because often, in the case of PNG data, 256 or less colors are used along with a dither. This results in very good (perceivable) quality with filesizes approaching that of JPG, while eliminating the macro-block visual artifacting of JPEG.
Which means the loss occurs
before the (lossless) png processing.
Oh god, here we go again...
whoops, double-post.
hi.....,yes
all my bitmaps in the resource section. With a lot of image files, i whould like first to try loading my images from disc and then display them using image functions like BitmapFromFile......?
how can i do that..........................an example whould better thanks a lot
sudeer,
You should be able to use the LoadImage() API function if the file is a genuine Windows bitmap. What I don't remember is if it will load a 24 or 32 bit image, especially if the latter has a transparency channel by I occaionally use that function for loading 24 bit gradient fills as bitmaps and it seems to work fine. The virtue of LoadImage() is that you can load an image from a freestanding bitmap file so your executable does not blow out in size by including the images in its resources.
Quote from: Mark Jones on November 16, 2008, 05:39:47 AM
Quote from: Mark Jones on November 16, 2008, 05:39:15 AM
Oh god, here we go again... Whatever.
Calm down, young friend. I just wanted to spare you from the doubtful honour to be the first on the Big World Wide Web who declared png a lossy format.
Hi sudeer,
Attached is a demo displaying an image with BitmapFromFile
[attachment deleted by admin]
Quote from: jj2007 on November 16, 2008, 09:36:25 AM
Quote from: Mark Jones on November 16, 2008, 05:39:15 AM
Oh god, here we go again... Whatever.
Calm down, young friend. I just wanted to spare you from the doubtful honour to be the first on the Big World Wide Web who declared png a lossy format.
Of course, young friend, if you considered the possibility that you are not the only person on the planet, then you might see why saying that PNG is "less lossy" is the
general perceivable case and therefore a valid concept in spite of the PNG format itself being lossless, since dithering and color reduction are common methods implemented to reduce the filesize of PNGs. (Note, PNGs are still much larger than JPEGs in most optical cases.) Furthermore, PNG images containing large luma and chroma variances benefit most from the "reduce color and dither" methodology, since these images are natively much larger in PNG format than JPEG (upwards of 15x larger or more.) Lineart and other low-color images should not need dithering at all -- the LZ77 compression is excellent in this case.
For your enjoyment, eight images are available here (http://heliosstudios.net/temp/WhyPNGareDithered.zip). These images illustrate why dithering PNGs is a good idea. Two comparisons are given: truecolor optical data, and truecolor lineart data. For the optical comparison, image 1 is an uncompressed DV bitmap. 2) is a typical compressed JPEG of image one. 3) is an un-modified, lossless 24-bit truecolor PNG of image one. And 4) is a color-reduced and dithered PNG version of image one. The second set of images mirror the first set, but utilize lineart source data. Examine these filesizes and image qualities and then tell me wether or not it is important to consider "lossy" PNG implementation as a general-case for truecolor optical data.
Thanks, Mark. Your reply is now definitely more detailed than "...less lossy png...", which I found inappropriate, especially in The Campus. Still, I can't find a good reason why anybody would prefer a lousy quality 406881 bytes png image to a top quality 151672 bytes jpg version. Load 1.bmp, 2.jpg and 4.png into PaintShop and press repeatedly Control F6 to see the difference. IMHO an image with 75103 different colours is commonly called a "photo", and the appropriate format for a photo is lossy jpg, not "lossy png".
hi.....
i have done it, thanks to every body especially to "Vortex", the file size redused from 177MB to less than 1 MB
ShowPage proc uses eax ebx numb:dword
m2m ebx,numb
.if ebx <= 272*4
invoke GetCurrentDirectory,sizeof FindBuffer,addr FindBuffer
invoke lstrcat,addr FindBuffer,Q_BMP1[ebx]
invoke BitmapFromFile,addr FindBuffer
mov hBmp1,eax
invoke ShowBmp,hBmp1,hBmpPage
.endif
ret
ShowPage endp
THANKS AGAIN
Hi sudeer,
You are welcome. Note that the BitmapFromFile function is not limited with bitmaps :
QuoteDescription
BitmapFromFile returns a bitmap handle from an image file.
An image may be in either .bmp, .gif, .jpg, or .wmf format