Several months ago, I attempted to write a program to display image files (mainly JPG) as a "slide show". The only assembly algo available at the time seemed to be Ernest Murphy's. However, I had numerous problems with it and decided to write my own.
After some two months of "intensive labor", with barely any description of all the details anywhere on the web for this complicated encoding format, I finally managed to render most JPG images using strictly assembly instructions. Being quite familiar with the BMP format, I also quickly wrote a procedure for loading such files. I then attacked GIF files which proved to be relative simple to decode (as compared to JPG files).
I have now prepared individual modules of those procedures and made them part of a new library for rendering images. I have also included a procedure to identify the supported image files according to their header (regardless of the file extension), and then call the appropriate procedure to render the image if so indicated.
I'm currently still trying to understand the PNG format which seems to be a cross between JPG and GIF formats. When I finally succeed (failure is not an option :snooty:), it will also be added to the library.
Although I have tested the current procedures extensively on my system (P3-550 with Win98SE), I still need feedback from other potential users before I officially issue the library. The attached zip file only contains the INC and LIB files, in addition to a preliminary Help file. The source code will be made available later.
The Help file does contain an example of code to render a valid JPG, BMP or GIF image in a window.
If feedback is positive, this library could eventually be considered as an alternative to Ernest Murphy's algo.
Raymond
[attachment deleted by admin]
Ray,
I just had a read through the help file and it is looking like a very useful range of functionality to have available. Ernie's work has been fixed to some extent by a number of members of both this and the win32asm forum but having newer up to date versions is a far better prospect and it can be tweaked here and there if any problems are discovered.
These will be appreciated by many when you are satisfied with them.
Hi Raymond,
A suggestion for your library, change your second argument for loadJPG to a pointer to a DIBINFO structure and place the following code in your procedure.
INVOKE GetDC,NULL
mov hdcdesktop,eax
mov edx,lpDIBINFO
mov ecx,edx
add edx,4
add ecx,8
INVOKE CreateDIBSection,hdcdesktop,ecx,DIB_RGB_COLORS,edx,NULL,NULL
mov edx,lpDIBINFO
mov DWORD PTR[edx],eax
INVOKE ReleaseDC,NULL,hdcdesktop
My concern is if your returning a pointer to a DIBINFO structure, how do I free the memory when I am done with it?
I am writing a bitmap editor myself and believe I have a grasp on everything to read a jpg except for the Inverse Discrete Cosine Transform step. Will you help me with this algorithm?
I haven't looked it over yet, but puff.c in the folder contrib\puff of the zlib c source code (http://www.zlib.net/) is supposed to provide more detail of the deflate algorithm used for png compression. Have you found a better explaination of the deflate algorithm than rfc1951?
Attached is a copy of the bitmap editor I am working on.
Regards,
Darrel
Edit: Go here (http://www.masm32.com/board/index.php?topic=5234.msg39149#msg39149) for a copy of the bitmap editor.
Great stuff Raymond! :) I'm gonna look at it at work :)
QuoteMy concern is if your returning a pointer to a DIBINFO structure, how do I free the memory when I am done with it?
The DIBINFO structure is a library specific structure. It is described and included in the library's .inc file.
I have to assume that you downloaded the RFimageLibV09.zip which contains a Help file. The "Example" section of that Help file contains information on how to free the memory correctly. Let me know if it needs more clarification and/or if it answers your question.
Raymond
I read the "Example" section of the Help file. I still don't know how to free the memory (48 Bytes) used by the DIBINFO structure.
It's good to see someone else working with image file formats.
btw: Thanks for making the FPU tutorials available, they have been very beneficial.
Regards,
Darrel
Some time ago I wrote a png reader - in assembly.
You will have to decompress zlib data, for which I used the default zlib library.
The main difficulty with png is that it supports many bit depths and color formats, so you'll have quite some work. (the reader I wrote only understands some of the formats)
I don't have the code on this computer, but I could send it if you're interested.
Stan
Stan,
I am definitely interested.
Thanks,
Darrel
QuoteI read the "Example" section of the Help file. I still don't know how to free the memory (48 Bytes) used by the DIBINFO structure.
Whenever you assume something.....
I had assumed you were talking about the created DIB. As for the DIBINFO structure itself, you cannot free the memory taken up by it since it is part of your global variables in your uninitialized .data? section. (The JPG module actually adds over 8kb of global variables to that .data? section and a little over 100 bytes to your initialized .data section.)
I also started last winter to work on a module to read PNG files. I didn't think that anything could be as bad as the JPG format (which took me about 2 months to decipher). Whoever designed that PNG format must have been ????. For example, Huffman encoding is used for the data and for the Huffman tables themselves; however, the coded bits are packed from left-to-right in one case but right-to-left in the other case!!!
And, as Stan pointed out, the range of bit depths and color format supported, coupled with 5 different filters, makes it a nightmare to cover all the possibilities.
Have fun
Raymond
Ray,
It sounds like the "experts" in the design group for JP "experts" G have struck again. :P
Here is the png reader I wrote some time ago. It decodes the file to a simple structure in ARGB format.
It only decodes two formats yet: 24-bit RGB colors, and 32-bit ARGB, but can easily extended to support all other formats. All filter types are supported (up,sub,average,paeth), interlacing is not supported.
It's part of a larger project, and will need some modifications before you can use it in your own program. (for which I didn't have time yet) I plan on rewriting the reader so it supports any png format, and release it as open-source library. But I'm currently busy with another project, so that will be for later.
The zlib library is supplied too. More info about zlib at www.zlib.org (http://www.zlib.org).
Stan
[attachment deleted by admin]
QuoteI am writing a bitmap editor myself and believe I have a grasp on everything to read a jpg except for the Inverse Discrete Cosine Transform step. Will you help me with this algorithm?
Sorry for the delay in answering that question. I did that work more than 6 months ago and I had to "recycle" myself on my algo.
The JPG format is usually based on the processing of an 8x8 block of pixels. The Inverse Discrete Cosine Transform (IDCT) involves the multiplication of each of the 8 components of each line by a specific cosine value and add them up for each component of the line in an intermediate block. Then, each of the 8 components of each column of that intermediate block must be multiplied by a specific cosine value and added up for each component of the transformed block (the cosine values used for the lines can be reused for the columns). And, for 24-bit color, you need to process 3 separate blocks. This IDCT is the part of JPG conversion which is the most computer intensive because of all those multiplications.
My approach was to precalculate the required 64 cosine values in an array; (otherwise, you wouldn't render a large JPG until dooms day). After I got the algo working correctly using FPU instructions, I converted it using MMX instructions and single precision floats. The speed increase was very significant.
Attached is my algo for computing the table of required cosines and my procedure using MMX instructions for computing the IDCT of an 8x8 block. Hope you can understand it.
Raymond
[attachment deleted by admin]
Raymond, I don't know if you are aware, but there is a much faster algorithm for this. If you look at the values in the IDCT matrix, you will see a lot of repeated and symmetric values. Therefore the algorithm can split the 8x8 IDCT (and DCT matrix - but they are just transposes as they are orthonormal) into once 4x4 and 2 2x2 submatrices. I forget the name, but I do remember that the reduction is as follows:
Multiplies: 64 -> 22
Additions: 56 -> 28
which is significant.
OK, I just googled and got this page (which makes me laugh - it's written by the guy who gave the lectures on this subject): http://cnx.org/content/m11093/latest/
Anyway, hope it helps,
Ossa
Thanks Ossa.
The algo which I posted was my very first attempt to use MMX instructions. I am thus a newbie with that set. Maybe someone more familiar with it could reply if that "faster" algo could make use of MMX instructions.
Otherwise, with MMX, the 64 mults become 16 mults and a lot of additions are part of the pmaddwd instruction. I am assuming that the 16 parallel MMX multiplications are close to being as fast as 16 regular multiplications. If so, the 16 mults with MMX may be faster than the 22 regular multiplications of the "faster" algo.
Please anyone correct me if my assumptions are wrong.
Raymond
Nearly. The speeded up algo still uses a 4x4 matrix, which means that those 16 mults can be reduced to 4 SSE mults. This leaves us with a maximum of 10 equivalent mults. Also the algorithm can use the general purpose registers to do the data manipulation overheads whilst the SSE instructions are executing on the other execution ports (IIRC that is). If I have time (unlikely for the next month or so unless I get bored) I will code a drop-in replacement for your code.
[edit] Just noticed that your code uses word sized values (can't remember the required bit-depth for JPEG etc) so I'm unsure if I can get the speed-up noted above [/edit]
Ossa
Bit depth for JPG is 8 bits max. YUVs are computed from RGBs, the max Y being 0FFh. When computing the DCT, the max positive value for Y becomes 7Fh and the maximum DC which can result is 8*7Fh=3F8h. Dwords are thus sufficient.
Raymond
Hi Raymond,
Have the load from memory version of your image functions?
Quote from: Vortex on July 12, 2006, 08:35:03 PM
Hi Raymond,
Have the load from memory version of your image functions?
Do you mean
AFTER loading an image file from external storage to memory?? If so, why would you have loaded it in the first place?
Raymond
Hi Raymond,
You can always embed your images into your executable with the help of tools like Hutch's fda.exe
( or put them in the resource section ) This is why I asked about the load from memory versions.
Thanks Vortex. I'll take that into consideration when I eventually get back into that project.
Personally, I would not embed image files into an executable, neither directly nor along with resources.
Raymond
Hi Raymond,
I understand your point of view. Sometimes, embedding small sized images into an executable can be a usefull method. Thanks for your consideration.
Is Wrote by this?
_Monkeycd_Jpg_Paint_Proc proc hWndDC:DWORD , hDI:DIBINFO
LOCAL @hOld:DWORD
LOCAL @memDC :DWORD
invoke CreateCompatibleDC , hWndDC
mov @memDC, eax
.if hDI != 0
mov eax,hDI
mov ebx,eax
invoke SelectObject , @memDC , [eax].DIBINFO.hDIB
mov @hOld , eax
mov eax,ebx
mov ecx,[eax].DIBINFO.bmih.bmiHeader.biWidth
mov edx,[eax].DIBINFO.bmih.bmiHeader.biHeight
test edx,edx
jns @F
neg edx
@@:
invoke BitBlt,hWndDC,0,0,ecx,edx,@memDC,0,0,SRCCOPY
invoke SelectObject,hWndDC,@hOld
invoke DeleteDC,@memDC
.endif
ret
_Monkeycd_Jpg_Paint_Proc endp
I have to assume that you would already have called the loadJPG function from the library. The function creates a global variable having the DIBINFO struc format as given in the .inc file, and returns the
ADDRESS of that global variable.
Quote_Monkeycd_Jpg_Paint_Proc proc hWndDC:DWORD , hDI:DIBINFO
You should thus be passing the address of that global variable to your proc, such that hDI should only be a DWORD in the above description of parameters. In addition,
SelectObject,hWndDC,@hOld should be
SelectObject,@memDC,@hOldApart from that, the remainder of your code looks OK to display the image.
Don't forget to delete the hDIB object once you are finished with it
Raymond
Hi Raymond!
It's any chance to include a LoadJPGFromMemory function?
You see, often I need to show a JPG's file projected/loaded into Memory buffer, and it will be easier than figthing with .tmp files.
Thank you in advance!
Quote from: caraveiro on October 14, 2008, 04:23:27 PMIt's any chance to include a LoadJPGFromMemory function?
You probably got the original version of the library. It was expanded last summer at the request of others to include loading JPEG (and GIF files) from memory. You can download the latest version from this thread:
http://www.masm32.com/board/index.php?topic=9538.0
Be sure to read the thread to understand the required parameters of the newer functions. They are not yet covered in the HELP file.
Raymond
Wow!... Last version will do!
Thank you very much!