Ernest Murphy's image library

[raymond]

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]

[raymond]

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]

[PBrennick]

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

[raymond]

Thanks Paul. I'll have the opportunity to test it on XPHE when I go back north in about a month.

Raymond

[hutch--]

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.

[Mark Jones]

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

[raymond]

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

[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

[hutch--]

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.

[PBrennick]

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

[Mark Jones]

Mark,
How many folders are not showing on your system?

Hmm, probably 85% of them are not showing up. Very strange indeed. :wink

[EvilSoft.de]

Hello,
is it possible to make a JPEG-texturelaoder for OpenGL with the content of imagelib5.zip?