Hi,

I am looking for a possibility to display a high resolution picture (jpeg) as shaped window (so that the background is transparent). I saw the source of doing that in the download area of iczelion. But this is just for bmps. Now my question: Is that also possible for jpegs? Or do those formats differ too much? I couldnt get it to work.

DKT
Posted on 2004-07-16 11:31:48 by Kreatief
I think it's possible using Ernies Jpeg library. here:
http://www.asmcommunity.net/board/index.php?topic=4239&highlight=jp%2Ag
After you got the DC from the picture the steps should be the same.
Posted on 2004-07-16 11:56:38 by JimmyClif
Remember that when using Ernie's JPEG routines, you need to fix BitmapFromMemory.asm, line 113, remove the "invoke CoTaskMemFree, pGlobal" line - it's already handled when calling the IStream Release method.

Most of the "create regions from bitmap" sources out there are pretty inefficient (read: ungodly slow), you should access the pixel data directly (rather than call GetPixel), and build the RECT list and finally use ExtCreateRegion. (I've written code to do this in C, couldn't be bothered writing it in assembly since my C code already beat everything else I could find).

Look at these two threads, btw:
http://www.asmcommunity.net/board/index.php?topic=17519
http://www.asmcommunity.net/board/index.php?topic=14967
Posted on 2004-07-16 12:13:23 by f0dder
Hi,

hmm reading your relplies make me feel i dont know much...

It seems as if I made a step into an area I shouldnt access now. I know too less to understand all that.

Anyway, thank you!


DKT
Posted on 2004-07-16 12:49:50 by Kreatief
Don't be scared away :) - you can always start with the simpler methods, and look into the the more advanced methods when you feel ready.

And please do ask any questions and such here, we will try to help you :)
Posted on 2004-07-16 13:57:15 by f0dder

Remember that when using Ernie's JPEG routines, you need to fix BitmapFromMemory.asm, line 113, remove the "invoke CoTaskMemFree, pGlobal" line - it's already handled when calling the IStream Release method.

Most of the "create regions from bitmap" sources out there are pretty inefficient (read: ungodly slow), you should access the pixel data directly (rather than call GetPixel), and build the RECT list and finally use ExtCreateRegion. (I've written code to do this in C, couldn't be bothered writing it in assembly since my C code already beat everything else I could find).

Look at these two threads, btw:
http://www.asmcommunity.net/board/index.php?topic=17519
http://www.asmcommunity.net/board/index.php?topic=14967


Here's some ASM code that I use to load an image and create a region from it. This code assume you already have the image into a HBITMAP handle. There are two functions inside the ASM file. Call CreateRegionFromHBITMAP passing it the HBITMAP handle, width, height, color used for transparency and a bool value (specifying it should use the first pixel color instead of the transparency color).

Relvinian
Posted on 2004-07-16 16:36:54 by Relvinian
Hmm ok. Youre right, I will give it another try!

For the beginning I am dealing with simple bitmaps. Everything works fine. I get a shaped window! But I have one problem:

I just see half of the picture painted (colored), the rest is grey. And when I drag the picture and move it outside the Windows-window, and move it back this part is also greyed!

What can that be? Can you answer this question or do you need any source code or any more infos?

I know Ill get a wonderful shaped window in some time...;)

Thanks so far!


DKT
Posted on 2004-07-17 07:50:19 by Kreatief
Very nice code, Relvinian! :alright:

Well structured, well commented, etc :)

Just a few things: access instead of GetProcessHeap? Isn't that a bit unnecessary? It might be unlikely that this address will ever change, but it will suck if it does!

BitBlt vs. GetDIBits - what about color conversions? Pretty interesting, BitBlt says "ICM: No color management is performed when blits occur.", so BitBlt might actually be better than GetDIBits - I guess I should do some test with a non-32bpp desktop resolution.

But again, nice code :alright:
Posted on 2004-07-17 09:36:13 by f0dder
Can you see my last post? Or do I just need to wait a bit longer for a replie? :notsure:


DKT
Posted on 2004-07-17 13:41:41 by Kreatief
Hm, I think attaching your source in a .zip and/or a screenshot of what happens would help a lot :)
Posted on 2004-07-17 14:00:59 by f0dder
Heres the complete source...

I just heard, it may be the graphiccard... Is that possible? Then I am asking: Is there any better code than that, that will do the job?!

DKT
Posted on 2004-07-17 14:06:27 by Kreatief

Very nice code, Relvinian! :alright:

Well structured, well commented, etc :)


Thanks. This is my normal style. Takes a little longer to code because of comments, etc but I think it is worth it. Same goes for modifying because I will change comments, etc.


Just a few things: access instead of GetProcessHeap? Isn't that a bit unnecessary? It might be unlikely that this address will ever change, but it will suck if it does!


I think for the most part, if you want to GetProcessHeap instead of using the FS:xxx stuff, there's no problem. Definitely safer for and new versions coming out. But I was in the habit of using that and so I dont' even think about the GetProcessHeap API call. I just code the mov eax, fs:[30h] without thinking about it now.


BitBlt vs. GetDIBits - what about color conversions? Pretty interesting, BitBlt says "ICM: No color management is performed when blits occur.", so BitBlt might actually be better than GetDIBits - I guess I should do some test with a non-32bpp desktop resolution.


I have tested this in 16bit, 24bit and 32bit colors and haven't seen any difference with doing it this way. When reading a HBITMAP, etc and using DIBs, then there are. But with the BitBlt, there seems to be some correcting in windows which helps.


But again, nice code :alright:
Posted on 2004-07-17 16:17:47 by Relvinian

Thanks. This is my normal style. Takes a little longer to code because of comments, etc but I think it is worth it. Same goes for modifying because I will change comments, etc.

I think it's worth it - makes it easier to read the code, makes it easier to remember what you did more than a week ago, makes it easier to re-use, and makes it easier for _other_ people to understand (and learn from) your code.


I think for the most part, if you want to GetProcessHeap instead of using the FS:xxx stuff, there's no problem. Definitely safer for and new versions coming out. But I was in the habit of using that and so I dont' even think about the GetProcessHeap API call. I just code the mov eax, fs:[30h] without thinking about it now.

I do a single GetProcessHeap() call at the start of my applications and store that in a global variable - I _think_ this is safe, probably "safer" than the fs:xx stuff anyway, and a bit more optimal :)


I have tested this in 16bit, 24bit and 32bit colors and haven't seen any difference with doing it this way. When reading a HBITMAP, etc and using DIBs, then there are. But with the BitBlt, there seems to be some correcting in windows which helps.

What I'm wondering, is... if you load a 32bit image, and the desktop is either 16bpp or (heavens forbid) 256color, do colors get remapped? Since BitBlt documentation says no ICM is being done, I think not... but GetDIBits (as you say) is slow, so this _might_ actually do color mapping? Under any circumstance, we _must_ avoid color mapping, or we risk the region-color is remapped, so invalid region data is created...
Posted on 2004-07-17 16:47:05 by f0dder
Originally posted by f0dder

I do a single GetProcessHeap() call at the start of my applications and store that in a global variable - I _think_ this is safe, probably "safer" than the fs:xx stuff anyway, and a bit more optimal :)



I did that at first then I started sharing ASM files and people wondered or tried to use the code I posted and started giving too much tech support about what a variable was and how to set it up. Maybe I just hit the wrong crowd or something.



What I'm wondering, is... if you load a 32bit image, and the desktop is either 16bpp or (heavens forbid) 256color, do colors get remapped? Since BitBlt documentation says no ICM is being done, I think not... but GetDIBits (as you say) is slow, so this _might_ actually do color mapping? Under any circumstance, we _must_ avoid color mapping, or we risk the region-color is remapped, so invalid region data is created...


I know if you create a 32bit image and try to display it on a 16bit desktop, using what I posted works well. My original code that I wrote didn't do well in this method. But I finally have it down. Now, I don't know how it looks at 256colors though.

Relvinian
Posted on 2004-07-17 22:53:37 by Relvinian

I did that at first then I started sharing ASM files and people wondered or tried to use the code I posted and started giving too much tech support about what a variable was and how to set it up. Maybe I just hit the wrong crowd or something.

;-) - that sort of stuff should be fixable with a comment anyway, and (if extreme), add a "see declaration of dwProcessHeapID for explanation" on each use of the variable, hehe.


I know if you create a 32bit image and try to display it on a 16bit desktop, using what I posted works well. My original code that I wrote didn't do well in this method. But I finally have it down. Now, I don't know how it looks at 256colors though.

Thanks, seems like I should fix my own code not to use GetDIBits - I'll play around a bit if I get the time.
Posted on 2004-07-18 04:17:17 by f0dder