I want to make a copy of loaded BMP with inverted colors.
And get it as separate object for further use.
Any ideas?
Posted on 2002-05-01 15:43:04 by The Svin
Well you could always create an extra DC, select a new bitmap into it the same size as the one you want to copy and then do a simple BitBlt with SRCINVERT.
Posted on 2002-05-01 15:48:39 by Graebel
You can also use:

Invert color values: if all values are higher than 127 then c = 2 * lowest - c, if all values are lower than 128 then c = 2 * highest - c;

Posted on 2002-05-01 15:54:02 by Sliver
If you're inverting light, why wouldn't you just NOT each color?

So for example #FF8000 (orange) would become #007FFF (aqua)
Although if you're doing a pigment invert then you'd have to convert to CMYK first.
Posted on 2002-05-01 16:51:15 by iblis
I have no problem with inverting colors in bmp.
I'm sorry I didn't stress main problem.
I need to get loaded bmp object with LoadBitmap
as data.
Then invert it (I can code it alright)
Then make an object from it.
The idea behind it is very simple -
I want to it once ( in some loading process)
for the code will need to run just once from me proc.
and then just use the object with BM_SETIMAGE.
For decreasing module size and simplicity of coding.
I know how to invert colors or how select it etc.
I need to know how to get data from handle,
and after performing some work with it save it with
new graphic object handle.

So from one bitmap resource I could get two graphic
objects inverted to each other
to get the effect:
Posted on 2002-05-01 17:37:30 by The Svin

Your question intreaged me into digging into it for you. (Since i didnt have clear idea to start with).

After some snooping around the MSDN, i think i got it hacked out:

WARNING: I never tested with any code, this is all speculation :)

    [*]Use LoadBitmap or LoadImage to get the bitmap from the resource.
    [*]Use GetDIBits to get the 'bit' map data copied into a separate buffer (provided by you), as DEVICE INDEPENDANT bits.
    [*]Do whatever you want to the bits stored in the buffer (invert).
    [*]Use CreateDIBitmap with the style flag CBM_INIT, and provide the address to the buffer (and a Bitmap Header Structure). This will create a new DDB (Device dependant bitmap), which should now be the 'inverted bitmap'. From here you can use the second bitmap handle as you would the first.
    [*]Destroy the buffer memory useded.
    [*]Destroy the handles when finished with them.

    Hope this helps... again. This is untested, just what i managed to read on the MSDN on the topic. As well, there is other stuff that needs attention that is not listed, such as filling out BITMAP INFO structs before you use the CreateDIBitmap. I trust you will look up these API's on your own to properly use them. ;)

    Good luck.
Posted on 2002-05-02 00:51:45 by NaN
Hi The Svin

Maybe my grid brush demo is of some help here.

Posted on 2002-05-02 02:27:22 by KetilO
what does the grid brush demo show? It looks on my Win95 like this:
Posted on 2002-05-02 04:11:34 by beaster
Hi beaster

The problem probably is that win95 only supports brushes with size 8x8.

Posted on 2002-05-02 04:26:59 by KetilO
There is one thing I'm not sure of.
For example I've got poiter to array of bits with GetObject.
How to calculate the length of the array?
Posted on 2002-05-02 16:42:30 by The Svin
I would sugest using GetBitmapDimensionEx.

As well this is the Bit dimensions. So you will need to make adjustments depending on the # of colors used (weather a byte represents a bit, or a DWORD represents a bit).

Here is the MSDN like i used to dig up the info: Bitmaps

To get the # of colors, there is another api : GetDIBColorTable

Good Luck.
Posted on 2002-05-02 17:33:42 by NaN
Thanx to all,
I noticed one thing that my English is usefull only for flames and cool chats :)
I solve it using GetBitmapBits + SetBitmapBits.
Posted on 2002-05-02 17:45:15 by The Svin
Could you post your source... I would be interested in seeing how you did it?

Posted on 2002-05-02 17:50:12 by NaN
Ha, ha!
Though it is very simple thing - I fill myself a winner :)
I did exactly what I wanted (to get two inverted bmp objects from of one resource) and I did it a very simple way - as I wanted too :)
Though wasted for it almost a day :(

OK now anyone can do it - even very beginners.
Posted on 2002-05-02 18:27:17 by The Svin
Nice work Svin, however, there is no Close button on the dialog box ;) (need to use ALT F4 ~ but i see you handle it in your dlgproc)

As well, i see your counting on the fact that the user will know the bitmap size... so its a somewhat static solution. But still thanx for the source!

Posted on 2002-05-02 18:40:14 by NaN
1. I always implement esc-close logic on dlg.
2. I had absolutly no idea of size, I just made a buffer large enough for size of small bmp, in different case I would get bigger buffer.
3. Size of bmp returns to me.

With a pig it looks absoluly fantastic :)
(Note - I didn't change source, though size of bmp is different
I just changed resource bmp)
Posted on 2002-05-02 18:45:06 by The Svin
Sorry i missed the command message at the bottom ;)

As well sorry for my error, i made some bad assumptions on the last post :rolleyes: , I didnt realize your using the api's that the MSDN considers outdated. I didnt mention them cause i didnt think that we should use api's with messages like:
Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should use the GetDIBits function.

What is the pro/con's to using these api's?

PS: Your right, The pig does look pretty kool :grin:

Posted on 2002-05-02 19:41:15 by NaN
The fun about it - we can easily get any number bitmaps with different colors produced from original bmp or the bitmap object rapidly changing colors.
For example performing psllrw mm1,somenumber before xoring.
In a loop shifting each time words in mm1 before xoring loop we can get the whole gallery of bmps with different colored pigs.
Posted on 2002-05-02 19:54:11 by The Svin
I didnt realize your using the api's that the MSDN considers outdated.

It is rather strange statement.
NaN, dodn't tell me you had a close look at the two alternatives :)

If you had you would have noticed that they are not alternatives -
they are different API's.
In case you really interested, I suggest you reread my questions
about it, you didn't answered.
GetDIBits in my case is inconvinient.
It asks for a lot of params that needed only if you derectly work with some DC. In my case as I twice said I needed to change independent hBmp object. Or shall we say create independent object from independent object.
GetDIBits ask for DC.
But when you load bitmap with LoadBitmap do you need any DC?
Nobody gave me a formula of how to caculate gotten bytes also.'
So had I used GetDIBits + SetDIBits I would have been forced to fill a lot of params that are not needed in my case, and in addition to get some DC though I need to created independant hBmp object.

If you are asking of low level implementation on SetBitmapBits
I make some changes in the source for you
showing how it is implemented through int 2Eh in decent 32 bit code in NT.
(!!!DON'T RUN IN in 9x or XP!!! - it's derect interrupt call thus OS dependent!)

You can see that code doesn't thank in any old 16 code.
And work perfectly in 32 bit code without WDM.
Posted on 2002-05-02 23:27:59 by The Svin
I agree, the MSDN sugested API's are not exactly convienent. And there is alot of 'extra' work involved. Im not disputing the fact that the old API's are better for your purpose.

Im just currious if its safe to trust that they will remain in all OS's either now, or in the future. To err on side of safety i avoid using api's that have these 'MSDN warnings' on them.

However, your right, to do it the MSDN correct way would be *alot* more work, and involve DC's and Header structs. (( Why i asked for your source originally, i thought you have gone throuht these hurdles, and was hopping to see how you tacked them)). ;)

Posted on 2002-05-02 23:40:02 by NaN