Hi friends,
There was a local bug in Ernest Murphy's image displaying function BitmapFromFile.asm
Thanks to El_Choni for discovering and fixing this bug:
http://board.win32asmcommunity.net/viewtopic.php?t=10650
f0dder suggested fixing another bug found in BitmapFromMemory.asm
http://board.win32asmcommunity.net/viewtopic.php?p=145356#145356
Here is a small example displaying a JPG image from file.
[attachment deleted by admin]
Vortex,
Actually, as it turns out, El_Choni was mistaken. He apologized for the false bug report.
Paul
No, It's not a false bug report. To proove this : put the original image handling functions to the sample project and you get only a blank dialog box with no image.
http://board.win32asmcommunity.net/viewtopic.php?p=81754#81754
Posted: February 14th, 2003
Quote
Oh, I see... then I don't understand why I can't make it work (sorry for posting a false bug, anyway).
Posted: February 16th, 2003
Quote
Ok, adding 1 to dwLength solved the whole thing. It must be a problem of terminating zeroes or something like that. Thanks for your help.
http://board.win32asmcommunity.net/viewtopic.php?p=82146#82146
This example displays the same image from memory.
[attachment deleted by admin]
Finally, here is the image library with the latest bug fix of lamer.
Many thanks to f0dder , El_Choni and lamer for the corrections.
Concering the functions BitmapFromFile and BitmapFromMemory, the statements :
invoke CoInitialize, NULL at the beginning of the source code
invoke CoUninitialize at the end of the source code
should be included to initialize and uninitiaize COM
http://board.win32asmcommunity.net/index.php?topic=10650.0
http://board.win32asmcommunity.net/index.php?topic=18776.0
http://www.masmforum.com/simple/index.php?topic=2743.0
EDIT: Below, you will find the attachment.
Many thanks to KetilO who found another bug in the BitmapFromPicture function.
The screen DC is not released, this can cause to run out DC's.
This line releases the DC :
invoke ReleaseDC,NULL,compDC
Here is the new attachment.
[attachment deleted by admin]
BitmapFromPicture still doesn't release the screen DC in the last attachment you posted. Also BitmapFromFile doesn't release the memory allocated by CoTaskMemAlloc.
In any case I'd suggest a restructuring of all the code, since exiting the function in more than one place is rather messy, and it lacks a lot of error checking... :( If you're interested I could do that, got some free time this weekend.
One more thing, in BitmapFromResource, the resource type for images should not be the string "IMAGE" but the numeric constant 2110. However this would break backwards compatibility... not sure what to do about that.
Hi QvasiModo,
About the CoTaskMemAlloc problem, you can check this post :
http://board.win32asmcommunity.net/index.php?topic=18776.msg145356#msg145356
Back home, I will restudy the problem about releasing DCs.
Dougiem's OLE image routine is a stable one :
http://www.masmforum.com/simple/index.php?topic=2946.msg22966#msg22966
You are right about CoTaskMemAlloc :thumbu in that case only a small change has to be done, if CreateStreamOnHGlobal fails then the memory has to be released. Also if OleLoadPicture fails pStream should be released, and if BitmapFromPicture fails pPicture should be released.
The problem I mentioned about releasing the DC also only happens on error, so in normal circumstances it won't be noticed. But for the sake of reliability, specially since it's a static library to be used in many programs, we have to consider every case. :)
Thanks for the link to Dougiem's code, I'll add it to my masm32 folder :U
Hi QvasiModo,
Thanks for your support. Here is the revised package according to your suggestions. Would you like to check the fixed source codes of the image library?
[attachment deleted by admin]
Seems great now :U
One detail: at BitmapFromMemory I think we should be checking for errors at the first call to CoTaskMemAlloc. Here's a revised version of BitmapFromMemory.asm, I also moved the call to release_pPicture higher in the code so the IPicture object is also released if BitmapFromPicture happens to fail.
What do you think of these changes?
[attachment deleted by admin]
Nice work :U
I replaced the previous version of BitmapFromMemory with your new one, thanks.
Here is the new package.
EDIT : I modified BitmapFromFile by moving up the call to release_pPicture
[attachment deleted by admin]
I need to know when this is dead stable so I can put it into the current project.
Hi Hutch,
I have to do some additional tests and I will announce the final revised package.
Hi Hutch,
Here is the latest release. Could you test the package to put it to the masm32 project?
[attachment deleted by admin]
Vortex,
I just tested the 4 demos and they appear to work fine. You should also add the credits for the people who worked on fixing them in the beginning of the source files for the library rather than just naming them in the readme.txt file.
Greate stuff and thanks to everyone involved. :U
LATER : I added this line to the header of each library module.
; Corrections have been made to this module by
; f0dder, El_Choni, lamer, KetilO, QvasiModo and Vortex.
Hi Hutch,
Many thanks for testing the library :U
QuoteLATER : I added this line to the header of each library module.
; Corrections have been made to this module by
; f0dder, El_Choni, lamer, KetilO, QvasiModo and Vortex.
Also, thanks for adding the lines to the header of the modules.
Ok, I have added the 4 files into the current image and they build as normal so they will be available in the next current image of te MASM32 project.
Hi Hutch,
Many thanks :U
I have adapted the code to my own needs for a small image viewer and "slide show" program and it generally works fine at least with .jpg, gif and bmp files.
One exception I have noticed up to now pertains to the size of .jpg files. Large images (I haven't defined the limit yet but at least 1700x1300) return the error code. And the code occasionally hangs up on very large files such as >2Mb.
Has anybody had a similar problem?
Raymond
P.S. Anybody interested in trying the BETA version of my program? :eek
Hi Raymond,
Can you post your image viewer? I think that many of us would be interested.
Perhaps you're simply running out of memory? That can happen when creating large bitmaps, but I think it's only a Win9X issue.
For all its worth, here it is. Currently, it's only prepared to view .BMP, .GIF, .JPG and .JPEG.
I'm doing this because I want to make a CD containing scanned slides and photos for my children and provide tham with a program which they can use immediately with a viewer available directly on the same CD.
This idea came about when a nephew prepared a CD of photos for his parents' 50th wedding anniversary, which CD is totally useless unless the MS Office Suite is installed on the computer where one would like to look at those images.
Any comments will be greatly appreciated. The unzipped file size may seem big but it's due to some resources which I will eventually try to modify.
And, yes, I can only test it right now with Win98SE with 128 Mb RAM.
Raymond
[attachment deleted by admin]
Very convenient tool, I like it! I see it has some problem with long dir names, you could write: "MyLongDir..." and show a tooltip (with full name) And icons aren't very cute, but since you are trying to minimize resource size ... :)
Bottom line: works perfect on WinXP with SP2 box...
I've cleaned up the resources and adapted the program for the modifications. The size is thus reduces considerably.
I also added a few instructions to prevent a potential problem with inadvertant erroneous input (i.e. idiot-proofing).
The file in the previous post has been replaced with the newer version.
Raymond
MYSTERY FINALLY RESOLVED!!!!
Although other graphics programs had no problem with this, Ernest Murphy's procedure will not display files with names which contain the "%" character IF (and only IF) that character is immediately followed by 2 characters which could be interpreted as a hex byte!!!! :eek
For example, files with names as follows would not be displayed, regardless of size:
01%2a.jpg, a234%f6k2.jpg, abc%def.jpg
while files with the following names would have no problem being displayed, again regardless of size:
01%2.jpg, 01%2g.jpg, a234%k6f2.jpg, cde%fgh.jpg
Raymond
URL decoding? Looks like some IE code is messing with it... what happens if you use two %'s?
01%%2a.jpg, a234%%f6k2.jpg, abc%%def.jpg
Or if you replace the % with %25?
01%252a.jpg, a234%25f6k2.jpg, abc%25def.jpg
QvasiModo
The only reason I found the effect of the "%" character in the file name was because someone sent me a bunch of photos taken with a digital camera which were probably downloaded to a computer with file names based on the camera's software. An example would be:
009%5F9%2EJPG.jpg
I did not try two consecutive "%". However, I've tried numerous combinations for the characters following one "%" and I would not expect a file name such as 01%252a.jpg to be rendered.
NEW PROBLEM!!!
My system under WIN98SE (128 Mb RAM) stops rendering images after processing some 60 JPEGs (approx. 1800x1200 in the range of 700-900 Kb each) and would even hang up if I continue to attempt rendering more images.
Although I tried that immediately after re-booting the computer fresh, and exited immediately when images stopped being rendered, the system resources were still being indicated as 93% free. But, when I tried to hook up to the internet, the system froze while loading the first page. Ctrl-Alt-Del managed to "End Task" IE but nothing else; I then had to "pull the plug".
I now intend to try learning about the JPG format and see if I can write my own converter from JPG to BMP. :boohoo: Any suggestion about the location of such information will be welcomed.
Raymond
Win9X stores GDI objects in shared memory, amongst other problems this means that leaking these objects has a global effect, and shared memory is rather scarce so you can't work with bitmaps too large (at least not using GDI). This is not really a problem in Ernie's imagelib so the only thing to do is ignore the problem, or switch to GDI+. :(
As for the filename problems, I'm puzzled as to why the library seems to treat them as URLs... may be a COM thing, dunno. :dazzled:
Ray,
Have a look at the API "GlobalMemoryStatus()" as it will tend to give you different results and it splits up physical and virtual memory so you know what is happening. I put this stuff in the about box in QE back when I used to develop on win98se just to keep track of whether the OS was running out of physical memory.
A quick and dirty way to fix it when the numbers get low is to allocate more memory than the system has then release it and you usually get it all back again.
After many, many, MANY hours of digging through that dissassembled "C code", I have finally succeeded in learning enough to render most JPG files. That JPG format may be good for compressing pictures but is very complex in addition to allowing numerous variants. Fortunately, I had JPG pics from various sources and eventually managed to render most of them. One type which I have not yet covered pertains to gray scale images.
Even in assembly, my app seemed kind of slow compared to some other available apps. Part of it requires between 24 and 48 multiplications (depending on the sampling ratio) for each pixel of the image during the IDCT (Inverse Discrete Cosine Transform). Although I'm very familiar with the FPU, I still had not ever tried MMX instructions. Looking at Randall's AoA chapter on the subject which I had downloaded in PDF format a few years ago, I got enough information yesterday to try a few things with the debugger and I eventually cut the time for rendering by about 1/3 by cutting the number of multiplications by a factor of 4.
The app is currently relatively small (23KB total); the JPG decoder itself is about 5KB, the supporting code for the app is another 5KB, initialized data about 5KB, and resources about 8KB. There doesn't seem to be any memory problem either. It ran on large files for long periods.
I may eventually expand it to include .BMP files (very easy) and maybe try to learn how to decompress .GIF files.
Meanwhile, the current version is attached if anyone is interested. Feedback will be appreciated.
[attachment deleted by admin]
Learning how to decode GIF images was a lot easier than for JPG. During this whole process, I learned a lot about the various image formats.
JPGs: Most JPG files contain the JFIF identification in their header. However, I have found numerous ones which don't. For example, Canon Digital doesn't include it (at least on my system) although its files seem to follow the JFIF conventions.
I have also encountered JPG files with the Megalux signature which are missing necessary Hoffman tables; no program is thus able to render such files. Megalux probably was using internal default Hoffman tables to render such files.
I have also encountered files with the JPG extension which were effectively BMP format files!!! All proper JPG files must have 0FFh 0D8h as the first 2 bytes of the file.
GIFs: The original GIF format was issued in 1987 and images compressed according to that format are identified by the GIF87a characters as the first 6 bytes of the file. The GIF format was expanded in 1989 to allow several options; those files are identified by the GIF89a characters. This latter format should still be backward compatible with the 1987 version.
However, I have found numerous GIF89a files which were deviating from the standard GIF87a format. Most of those had a NETSCAPE2.0 (at least one had a ADOBE:IR1) signature in them.
I also found one which was identified as being interlaced and crashed my program. The reason was that the vertical dimension of that image was only 2 and I was trying to copy the second line as the 4th line of the DIBSection as per the format description!!!
BMPs: This format is very well defined. All BMP files must have "BM" as the first 2 characters of the file.
The only problem which I encountered was when trying to StretchBlt an image onto an area smaller than the image size when the bits/pixel value was lower than 16. The result was unpredictable and awful. At first, I thought my algo was faulty and wasted some time with modifications. Then I read the "small print" and found:
Windows stretches or compresses the bitmap according to the stretching mode currently set in the destination device context.
After using SetStretchBltMode with COLORONCOLOR to modify the default stretching mode, those images were then being displayed correctly. (This was with Win98SE; I don't know if the default is different with other Windows versions.)
QUESTION: Would it be worthwhile to build a library of the functions which I have developed to render those various image formats? Each is currently designed to be called with 2 parameters:
lpSrc DWORD ;address of the image file name
hDC DWORD ;handle of the screen DC (used for creating a DIBSection)
Each function returns with 0 (failure) in EAX or the address of a global variable for the following STRUCT (created by each function in the uninitialized data section):
xxx STRUCT
hDIB DWORD ;handle for the created DIBSection
lpDIB DWORD ;address of the DIB image bytes
bmi BITMAPINFO
xxx ENDS
The hDIB is required to select the bitmap into a DC for displaying the image, and later for deleting the object and liberating memory. The lpDIB would be necessary if you need to alter the image. And the bmi is a necessity as it contains information about the dimensions and color format of the DIB (and the color table when required).
Attached is my latest image viewer which renders JPG (including gray scale ones), JPEG (which are the same as JPG), BMP and GIF images. Animated GIFs are not yet animated, only the first image of the file being displayed. I may in the near future also study the PNG format; my only problem is that I don't seem to have any image in that format and it may be difficult to cater for possible "variants" of such format.
I think that I have taken every precaution to prevent the program from crashing with bad file formats; it's supposed to simply return with the failure code. However, if it should ever crash while trying to render an image file, would you be kind enough to send me such file so that I can study it and take adequate measures.
Raymond
[attachment deleted by admin]
Raymond,
I do not do much image stuff but I though I would take a look at what you have.
The latest version crashes on my XPHE/SP2. The version just before this one does not crash. All versions, however, only show 21 folders on an HDD that contains 41.
Paul
Thanks Paul. I'll have the opportunity to test it on XPHE when I go back north in about a month.
Raymond
Ray,
This is looking like good stuff, it handles the 1280 * 1024 * 24 bit colour screen background images I use fine and its just about OK on most of the JPG files I could find in a hurry. I have a couple of older ones that the colour range seems to have been reduced on but these tended to be ones that I used variable levels of compression on.
If you have the time to make a library of these functions, they will be genuine killers. It almost doubles as a good file manager and its nice and quick. Spare a thought for those of use who run 16 partitions on a machine, I could only test up to drive H as it is and most of my image data is further back.
Hi Raymond, mine too doesn't list all the folders. XP Pro SP2.
My Avatar image is a .png file, non-interlaced and non-optimized-pallette. You could right-click and save it. Great work. :bg
hutch,
My intention was to provide only the image loading routines as library procedures. It would be another alternative to Ernest Murphy's image library for the more common image types. (I have no intention of writing compression procedures.)
I could also easily include in the library a separate procedure to identify the file type and call the appropriate procedure from there, saving that chore from the library user. That separate procedure could also read the first few bytes of the file to identify the file type instead of relying on the file name extension.
And, just for you, I'll try to expand my app to include all the letters of the alphabet so you can reach your image files. ::) :bg :toothy :wink
Raymond
Regarding folders not all being listed, I have also noticed that at least two of them are not listed either at the root of my system, i.e. Program Files and WUTemp. And at least the Temporary Internet Files subfolder of the WINDOWS folder does not get listed either.
I use FindFirstFile and FindNextFile with *.* as the search string and check only for FILE_ATTRIBUTE_DIRECTORY as the file attribute. (I also allow space to list up to 100 (sub)folders.)
Does anyone have any idea why some folders may not be detected by this approach??
Raymond
Ray,
I think the odd missing folder has some tho do with their attributes. The FindFirst - Next aproach is the right one but you may have to test for directory attributes as you scan the directories and subdirectories. I vaguely remember a few directories not deleting properly with a couple of recursive directory tree functions I worked on some time ago and I was setting the attributes on the fly and I solved it by performing another pass to get rid of the rest.
Another factor may be a characteristic of NT and later OS versions that do strange things with some special folders and I am not sure if they can be enumerated with the FindFirst - NextFile API pair.
Raymond,
I don't know, I have 42 folders on that volume and it only lists 22 of them. To me, that is not the odd, missing folder. Also, I use TotalCommander to create my folders , nothing else. So if it was an attribute thing, it would apply to them all.
Mark,
How many folders are not showing on your system?
Something is certainly odd here and I confess to having no clue but I love the software. I think it needs to be a lot more stable before any thoughts of using it in a library are to become a reality, though.
Good luck,
Paul
Quote from: PBrennick on March 16, 2006, 04:58:00 PM
Mark,
How many folders are not showing on your system?
Hmm, probably 85% of them are not showing up. Very strange indeed. :wink
Hello,
is it possible to make a JPEG-texturelaoder for OpenGL with the content of imagelib5.zip?