This is a test of a way to create B&W images from full color ones with decent speed. It was intended for TBPaint v2 but since that is on hiatus as I will be leaving on the 14th I thought I would post the test bed in case someone can use it. It is a marked improvement of the standard way of blting into a monochrome bitmap both in terms of speed and quality of output.

added Faster Grayscale
added Emboss image
added Watermark
added Invert image
added Trace edges
added ApplySkin
added Free Rotate DIBSection

Some people are having cache problems so I moved the attachment to later in the thread
Posted on 2004-08-02 22:50:02 by donkey
I combined a few other test routines into the program including a watermark routine that embosses text onto any image. The text must be in the form of a B&W bitmap (color depth is ignored), I have included a background and a sample watermark. Load the background with "Open Bmp" then the watermark with "Watermark".
Posted on 2004-08-03 11:08:14 by donkey
While I was playing around with it I decided it would be neat to have an edge tracer as well so I added a simple tracer. The threshold can be adjusted as it uses the litho function to convert to B&W. This is an example of a photo of a helicopter hangar:
Posted on 2004-08-03 20:36:39 by donkey
donkey, I like this program. I plan on digesting your code sometime soon. BTW, are you aware that this program doesn't work with 16-bit images that don't use the default color masks?

Posted on 2004-08-03 23:47:43 by SowWn
Yes, I cannot generate a 16 bit image and do not support them in Toolbar paint or any of my other software. 16bpp bitmaps are only efficient when the size is greater than around 484K so for toolbar graphics they are not useful, a 32 bit bitmap will almost always result in a smaller file. Also as it says in the notes in the code I removed all palette related code, another thing that TBPaint does not support. This is after all a set of tests for toolbar paint and I did not develop outside of that scope, so only 32bit DIB sections and no palettes. Though LoadImage should have been able to load them, and I use standard GDI functions to convert up to 32 bit so there shouldn't have been a problem. However, if you are using NT4 or 2K there is a known issue with LoadImage when using LR_LOADFROMFILE, the colors can be a bit messed up.
Posted on 2004-08-04 00:37:49 by donkey
very nice with edge tracer. Have you used some well known algo or made one yourself ??
Posted on 2004-08-04 06:11:57 by AceEmbler
litho.exe crashes when I try opening a 1280x1024 bitmap :(
Posted on 2004-08-04 06:32:11 by f0dder

very nice with edge tracer. Have you used some well known algo or made one yourself ??

Made it myself but it exploits a well known oddity of BitBlt with monochrome images and MERGEPAINT.

litho.exe crashes when I try opening a 1280x1024 bitmap

Bit large for a toolbar graphic but I will try to find out why, probably the image copy routine.
Posted on 2004-08-04 07:57:12 by donkey
Hi f0dder,

Should be OK now.
Posted on 2004-08-04 08:11:31 by donkey
I added a rotate DIBSection, it will rotate a 32 bit DIB Section by a given angle in radians. It is a free rotate, any angle is acceptable as long as it can be expressed in radians in REAL4 (FLOAT). The new image is resized to allow the full rotated DIB to be displayed. The routine I worked from was by my GDI hero Zafir Anjum, man that guy is good, but I had to radically alter the original C routine in order to allow for DIB sections instead of raw DIBs. That way you can use the returned handle directly in a DC, the rotate example is set to 0.7853981 radians (~45 degrees). Example :
Posted on 2004-08-04 19:36:16 by donkey
There was a problem with resizing the bitmap to fit the entire rotated image when the rotation was into quadrants 2 and 4, this was also in the original C code. I have fixed it and uploaded a new version. Also added a Degrees to Radians conversion proc, it requires a REAL4 value in degrees and returns a REAL4 value in radians in EAX.
Posted on 2004-08-04 23:55:03 by donkey
Still can't open 1280x1024 bitmaps, and I don't see the "rotate 45" button... perhaps there's some caching problem here, and I'm getting the old zip? (disabled my proxy)
Posted on 2004-08-05 07:44:21 by f0dder

Still can't open 1280x1024 bitmaps, and I don't see the "rotate 45" button... perhaps there's some caching problem here, and I'm getting the old zip? (disabled my proxy)

Hi f0dder,

Yeah, probably a caching problem, try downloding it then refresh the page and see if the download count increments.
Posted on 2004-08-05 07:54:19 by donkey
Hm, pretty weird - I just deleted all the IE temporary internet files, but it still gives me the same, and download count doesn't increase. Perhaps it's a combination of quirky IE and board behaviour?
Posted on 2004-08-05 08:03:15 by f0dder
Try this one..
Posted on 2004-08-05 08:10:31 by donkey
Works perfectly, thanks - the problem must be that when you update an attachment, it has the same URL (because attachments are related to postid). I don't know why this is a problem when I delete temporary internet files, though. (Hm, I had turned the proxy back on after deleting the files...)

Perhaps the "file date" returned by the webserver is creation time rather than modify time, and old file is kept rather than deleted+recreated? Just a wild thought - would explain proxy behaviour anyway.
Posted on 2004-08-05 08:14:57 by f0dder
Crashed on Win98SE. I just loaded a small bitmap and hit the "Invert" button. :(

Do I post some more info you might need?
Posted on 2004-08-06 12:38:00 by QvasiModo
Hi QvasiModo,

Yeah, I just tried them on Win98SE. There appears to be some difference between the way NT and 9x map the bits for a DIB section. For some bizarre reason they do not appear to be contiguous in 9x. It works fine in 2K and NT4 but fails in 9x and 98SE. I will have to find out where the failure point is, could you give me the register states at the point it crashes (especially EIP, EDI and ESI). I will find the problem but it is a tough one.
Posted on 2004-08-06 13:47:18 by donkey
Hi QvasiModo,

Not my fault, the CopyImage API reacts in an undocumented manner in 9x, actually completely contrary to what it says in the docs...

The CopyImage function creates a new image (icon, cursor, or bitmap) and copies the attributes of the specified image to the new one. If necessary, the function stretches the bits to fit the desired size of the new image.

However it does not faithfully reproduce the attributes in 9x, a 32 bit DIB section is reduced to a 24 bit DDB. Pretty much completely wrong but in NT4, 2K and XP it does what it actually says it does and the returned bitmap is 32 bit. I uploaded a version with a DIB copy routine that should take care of the problem.
Posted on 2004-08-06 14:35:03 by donkey
Well, I found the root cause of the problem f0dder originally had and have reverted to the faster method for the functions. It was pretty dumb, I was calculating the number of pixels then using BASE+nPIXEL*4 to index from top to bottom. Problem is that it was going 1 DWORD past the end of the image, subtracting 1 from nPIXEL and watching for a zero crossing instead of zero took care of the problem. The upload now has faster routines for GrayScale, LithoImage, CopyDIBImage and InvertImage. The changes have been made to the lib at my website also.
Posted on 2004-08-06 17:25:51 by donkey