A nice jpeg library in asm ?

[BlackVortex]

I found this one, and it seems to work fine, but maybe there is a better alternative ? I'm having some weirdness after implementing it, I'm sure there is a better one ? (I searched a lot already)

http://www.programmersheaven.com/download/14954/download.aspx

(what I do is I inclube the jpeg as raw data resource in my executable, then I use one of that library's functions to convert to bmp, my project is one executable,size and speed is of the utmost importance)

Thanks in advance.

P.S.: I only care about decoding. Also I did some searching on this forum and found this library by Raymond, I'll check that out to see if it fits my needs.
http://www.masm32.com/board/index.php?topic=4266.0

P.S.2: Damn, it seems Raymond's library currently just loads external files   :-(

[PBrennick]

BlackVortex,
If you need to use it anyway, just save your data into a temporary file.

-- Paul

[BlackVortex]

BlackVortex,
If you need to use it anyway, just save your data into a temporary file.

-- Paul

Well, yes, but that's a crude workaround, very inefficient. I will keep fiddling with that library I found (link in my first post), it's just that it's old, I thought something better would have been released ...

[raymond]

I'll have a look if I can easily modify the module to accept a memory address instead of a file name. I'll get back within a few days.

Raymond

[BlackVortex]

I'll have a look if I can easily modify the module to accept a memory address instead of a file name. I'll get back within a few days.

Raymond

That would be excellent, I will check back first thing when I come back from my holidays !

:green2   :bg

[dsouza123]

What about GDIplus ?

There has recently been a post in the Campus dealing with bmp to jpeg conversion using GDIplus.
http://www.masm32.com/board/index.php?topic=9528.0

This link discusses using C to do it in memory (involves streams), many background details (doing streams, GDIplus) need to be already understood by anyone trying to implement it.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.win32.programmer.gdi&tid=ff8933be-0fae-471b-a5d2-c4d90d611146&p=1

[BlackVortex]

Too much work. I'm not interested in jpeg compression, I just need an easy library to use to make my exes smaller (HUGE size difference!)

Thanks for contributing everyone  :-)

* BlackVortex pets Raymond's head

[raymond]

This may have been easier than expected. However, I have no foreseeable use for finding the address of resources in memory. You will thus have to do that yourself. If the whole thing works fine, I may then use your experience to include some code in the module to access the resource directly.

The name of the new function in the library is simply: memJPG
It requires three parameters:
lpsrc :DWORD //the memory address of the raw data
filesize :DWORD //the size of the raw data
hDC :DWORD //the handle to the window's DC

The attached zip file contains the .inc file, the .lib file and the old help file. This "new" function is not described as such in the help file. However, apart from the number and type of parameters required, the loadJPG description should be mostly applicable.

If it works for you, I don't think you would find a smaller and faster JPG decoder elsewhere.

P.S. I have not tested it!!


[attachment deleted by admin]

[BlackVortex]

AWESOME !!! 


I used these APIs:
FindResource
LoadResource
SizeofResource
then I supplied the info to your memJPG function
and finally ...
invoke SelectObject,hMemDC, [eax].DIBINFO.hDIB

You know that  [eax].DIBINFO.hDIB took me half an hour to figure out, never used structures ... err ... dynamically

And it loads FAST !!!

Now after all my experimenting I have to clear the fallout out of my sources, hehe.

[raymond]

Glad to hear it worked out OK. Your holidays must have been quite short!! :wink :lol

[BlackVortex]

Glad to hear it worked out OK. Your holidays must have been quite short!! :wink :lol

I'm leaving tomorrow   :dance:

[Vortex]

Hi Raymond,

Thanks for the new release of your image library.

Here is a demo displaying a JPG image embedded into the main executable. Hutch's fda tool is used to convert the image file to a MS COFF object file. This module is linked with the project module to store the image in the final executable. You can get the GeneSys version of the demo from here

Raymond, could you create the memGIF function to load GIF images from memory?

[attachment deleted by admin]

[BlackVortex]

Why use some external tool to put the image in the file ? I put the jpeg file in as a raw data resource ! Easier and cleaner I believe.

[raymond]

Nice demo Vortex. It also tells me that images can be inserted in executables in various fashions, and not only as part of "resources". Inserting specific code in modules to get the raw data using a resource identifier as a parameter may thus not be the best idea. Leaving the chore of providing a memory address should thus be left to the user.

Thanks for the new release of your image library.

The library was first released two years ago. (http://www.masm32.com/board/index.php?topic=4266.0). And I notice that you had asked then for funcitons to handle images already in memory!! :red

Raymond, could you create the memGIF function to load GIF images from memory?

I did the same thing as for the JGP module. The name of the new function in the library is simply: memGIF
It requires three parameters:
lpsrc :DWORD //the memory address of the raw data
filesize :DWORD //the size of the raw data
hDC :DWORD //the handle to the window's DC

Again, this "new" function is not described as such in the help file. However, apart from the number and type of parameters required, the loadGIF description should be mostly applicable.

P.S. Not tested either.

Meanwhile, I'll have to find time to modify the help file and cover these additional functions.


[attachment deleted by admin]

[hutch--]

 :bg

BlackVortex,

> Why use some external tool to put the image in the file ? I put the jpeg file in as a raw data resource ! Easier and cleaner I believe.

No size limit for any Windows version, genuinely fast and you get a seperate object modle and include file which is much easier to manage than messing around with the various limits and notation of resource files.