image handling...
BlitzMax Forums/BlitzMax Programming/image handling...
| ||
| How are images handled internally? IE: Is it possible to get the hdc of an image? Are they DIBs internally? I am back to trying to pass an image to a dll (via pointer obviously) and if they are dibs they it's probably trivial to get it working. If not we're back to the same problem that blitz has always had with that kind of thing. |
| ||
| Images are hardware textures and at least the OpenGL ones do not exist as textures in system memory anymore. Pro point is that you only need to send an int but are forced to use OpenGL commands ... The DX ones are DX Surfaces and thus handled by DX on its own, so you should be able to send a BytePtr to the Surface structure Might I ask, what reason you have to pass it to a DLL instead of performing the operation within BM? (Implementation for GLEW and DX9 are present) |
| ||
| Stupid question, but instead of using the built in image commands, wouldn't loading the image via user32.dll meet your needs if you are just wanting to pass it to a DLL? |
| ||
| Might I ask, what reason you have to pass it to a DLL instead of performing the operation within BM? Rewriting the printer dll again. I can open a bmp file and print it no problem. But I would LIKE to pass blitzmax timages just by passing a reference to them. Brice... I probably COULD do that, but I'm sure BMP is the only resource I could load like that, and I can already do that from the dll itself. I'd much rather use blitz's image handling that the rest of the language can already use. |
| ||
| heloo |
| ||
| use pixmaps + convert to format + store in bank + call function passing the banks buffer... |
| ||
| a pixmap is a bank (linear array of int data), you only need to convert it to the needed pixmap format and then handle the byteptr to the dll. As you can't render to textures but only to pixmaps, using them will be the faster way as well. |
| ||
| I have no clue where to start converting a pixmap to a device independent bitmap... I guess once again mark didn't take into account wanting to pass bitmaps to a dll. GRRRRR. |
| ||
| How about this? I have the hwnd of the printer object at this point and can pass it back to the blitz program. Can I send an image to an hdc from blitz itself? |
| ||
| If you know how to programm with WinAPI (and the other apis if it shall be crossplattform), then yes. |
| ||
| I have the code to turn a b3d image into a DIB... but I'm thinking that's the wrong way to go about it now... I think taking the hdc of the printer object and blitting a blitz image to the printer directly would be better. But... I'm not all that sure how to go about that. (And yes it's windows only dreamora... I don't care about cross platform much.) I guess the obvious would be bitblt, but I still need to get a handle to the source at that point and it's gdi... |
| ||
| In this case you might have some use for the GDI Driver project :-) http://www.blitzbasic.com/Community/posts.php?topic=56055 |
| ||
how about something like this?Function BitmapFromPixmap(pix:TPixmap) Local x,y Local hdc,bm Local src:Byte Ptr Local bi:BITMAPINFOHEADER pix=ConvertPixmap(pix,PF_BGR888) hdc=GetDC(0) bm=CreateCompatibleBitmap(hdc,pix.width,pix.height) If Not bm Throw "CreateCompatibleBitmap failed" bi=New BITMAPINFOHEADER bi.biSize=SizeOf(bi) bi.biWidth=pix.width bi.biHeight=-pix.height bi.biPlanes=1 bi.biBitCount=24 bi.biCompression=BI_RGB src=pix.pixels For y=0 Until pix.height SetDIBits hdc,bm,pix.height-y-1,1,src,bi,DIB_RGB_COLORS src:+pix.pitch Next Return bm End Function |
| ||
| That very well might do it skid. Thanks. |
| ||
I think I'm correct in assuming this returns a DC to the DIB that was created correct? If so, then this_BitBlt(phdc, 0,0, 5120,3840, imap, 0,0, 13369376) Should put the image I load and convert onto the current page in the printer assuming that phdc is the dc of the printer. I can verify that it is, as I used 0 for the last parameter in the bitblt which blacks all pixels in rect that is defined by parameters 2-5. But when I change the last parameter to SRCCOPY (13369376) I get nothing. So I can only assume that either the pixmap wasn't loaded by pmap = LoadPixmap("C:\picture.bmp")or it wasn't converted by the above function. Any ideas? |
| ||
| No it returns a bitmap. BitBlt takes an hdc source, which should be a printer compatible dc (CreateCompatibleDC) with the bitmap selected as current object (SelectObject). Check the example code in the MSDN for more confusion. |
| ||
| heh... I'm not sure I can take any more confusion. |
| ||
imap = BitmapFromPixmap(pmap)
ihdc = CreateCompatibleDC(imap)
SelectObject(ihdc, imap)
_BitBlt(phdc, 0,0, 5120,3840, ihdc, 0,0, 13369376)I think I'm closer now... But still getting a big ol blank piece of paper shooting out of the printer. |
| ||
| nonono ihdc = CreateCompatibleDC(phdc) the CreateCompatibleBitmap call should also probably be using phdc also |
| ||
| ahhhh... I understand now. I actually got it to spit out the bitmap now, though at a really tiny resolution compared to the 5120,3840 that I passed to bitblt. But I could probably use stretchblt for that... The colors though are a bit screwed up. People look a bit like oompa-loompas or something. :) |
| ||
| The image I'm attempting to print (which as stated is indeed printing now) is a 24 bit bmp. I changed the PF_BGR888 to PF_RGB888 and SOME of the colors are correct now but others are still wacky. The grass is purple for example. Skin-tones are correct (or pretty close to it) and the sky has a bit of a green tinge to it. Upon looking at it again, the colors are just "close" on the parts I thought were correct. There's a lot more red in the picture than there should be I think. |
| ||
| I can see where this is probably happening in SetDIBits, but I'm just not sure how it could be getting screwed up... unless... the colors are getting screwed up when it's loaded into the pixmap eh? |
| ||
Changed the createcompatiblebitmap call to pix=ConvertPixmap(pix, PixmapFormat(pix)) for "just in case" situations... It gives me the original results of what basically looks like a negative. |
| ||
| Just for poops and grins I changed and used StretchBlt and can resize the image easily enough... But I'm still getting a "negative" of the image. Any ideas why? |
| ||
| pix=ConvertPixmap(pix, PixmapFormat(pix)) huh? no it must be PF_BGR888 I meant try changing bm=CreateCompatibleBitmap(hdc,pix.width,pix.height) to bm=CreateCompatibleBitmap(phdc,pix.width,pix.height) |
| ||
| I tried passing that to the function after you mentioned it and it didn't do anything. I don't think the colors are getting into the bitmap correctly (or into the pixmap maybe). At least that's what it LOOKS like anyway. |
| ||
| I just verified it's not just on one image either. (And I did change it so that createcompatiblebitmap uses the printer's hdc now too). I tried it on a 24 bit bitmap and a 24 bit jpg from difference sources. |
| ||
| I would give it a test image of 5 solid rectangles, white black red green blue to work out what's happening. if the RGB are incorrect order then yes change PF_BGR888 to PF_RGB888 but I doubt thats your problem, it still sounds like an incorrectly configured context to me with a probable test result of cyan, magenta, yellow instead. |
| ||
| Ok... I forgot I still had PixmapFormat(pix) in the convertpixmap command... once I changed that back the jpg worked as did any other jpgs I created in photoshop for testing (including the 5 box pic you suggested). But that original bmp file just flat out won't print correctly. I'll do some more testing but it's LOOKING like loadpixmap isn't loading that bmp file correctly. (just that one or maybe all bmp files?) |
| ||
| ok... I have no idea what's wrong with that bmp file that was my primary test image. I probably wasted more time with that damn thng than I did the whole project. I've tested with other bmp files that I've created in photoshop and can't reproduce the weird "negative" effect on any of them. So I guess... passing pixmaps to the dll for printing is a success. Thanks skids. |
   |