Open rlesch opened 4 years ago
can you provide a transparent png with instructions on how to reproduce the error?
i used a Bitmaphandle for Imagesearch since it does support them ( https://www.autohotkey.com/docs/misc/ImageHandles.htm ) And it failed all the time when the targeted image had transparency (but works the normal way via filename) so, given that Gdip_CreateBitmapFromHBITMAP doesnt support transparency, i came to aboves conclusion.
just tested the same with splashimage and it shows the image with black background instead of transparent orignal.
adding testcript and testimage (its a very small one, white text on transparent background, not the ideal, but its the one in the script)
actually not sure if splashimage is a good choice (just started with ahk)
so, given that Gdip_CreateBitmapFromHBITMAP doesnt support transparency, i came to aboves conclusion.
However, this script doesn't use Gdip_CreateBitmapFromHBITMAP
This script takes a file, converts it into a base64 string using CryptStringToBinary
And then in the output script, converts that base64 string back into a bitmap using Gdip_CreateBitmapFromStream, and then converts the bitmap to an hBitmap
using Gdip_CreateHBITMAPfromBitmap
So if you're saying the transparency is lost, its either lost in the conversion to string, or in the conversion from string to bitmap, or the conversion from bitmap to hBitmap.
The function you linked from iseahound is for converting from hBitmap to bitmap
, but this image2include script never makes that conversion in that direction. Unless I'm missing something, I don't think this is a bug of this script
Im definitely lacking the knowledge do discuss that on your level. The only thing i have basically is the different behaviour of ImageSearch with and w/o bitmap handles. Maybe the other GDI stuff has problems with transparency too or - i start to believe that its rather a problem with ImageSearch itself.
SKAN said this in an old thread from 2005 "ImageSearch will not work with GDI bitmap handles.."
even though i think there have been improvements in ImageSearch since then + given the info from the help, there may be still problems with it? maybe the gdi+ version of imagesearch works better?
anyway, thanks for looking into it!
edit: after some further testing and ironing out other errorsources, i still have to say that the transparency is gone somewhere in the process
edit2: https://www.autohotkey.com/boards/viewtopic.php?p=221247#p221247
Did you try using HICON as mentioned in that post?
so in the thread on the ahk forums for this script, you might have asked the same question, i'm not sure, but iseahound responded and yes he recently added some argb funcs to this gdip lib here: https://github.com/mmikeww/AHKv2-Gdip
Gdip_CreateARGBHBITMAPFromBitmap() is one of the new funcs he added, and might be what you need to use, to replace Gdip_CreateHBITMAPfromBitmap in this script
I didnt try with HICON yet, but thats in my todo list for curiosity. And yes, that was me, ill try as you suggested. Also tried 'TheDudes' solution (3. last post in aboves link), it gives a different output than I2I when the source has transparency and both again give different results with Imagesearch compared to the file method. So currently im trying to get the stuff sorted out :)
as an effect it looks that image2include kills transparency on png sources.
isahound from autohotkey forum found a solution for that: https://www.autohotkey.com/boards/viewtopic.php?t=63345
but im not experienced enough to adapt that into image2include. so i hope you could add this :)