[vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)

GDI+ renders to 32bpp DIB in premultiplied pixels. When using GDI+ one does not need to be concerned with premultiplied or not. Only real exception is when extracting data from the GDI+ image, one must choose which color format they want, other than that, it isn't a concern for nearly all of the GDI+ calls.

Edited: A downside here is that once you render to GDI DC, you can never get true RGBA back from the DC, it will always be pRGBA.
As a simple test, I used GdipGraphicsClear on a new DIB passing a transparent white (&H00FFFFFF) and then retrieving the color from the DIB, what I got back was not &H00FFFFFF, it was &H00000000 (black) because of pre-multiplication; any fully transparent color becomes black.

The GDIpImage class does all the rendering in its Render function. Before rendering, it is just a matter of setting up the device context description beforehand. You tell GDI+ what smoothing/anti-aliasing quality you want to render in, what scale to render in, what angle to render at, and several other options. Once you define that, then you tell GDI+ to render & it does all the pixel X,Y translations while it renders. Rotation with GDI+ is different. You don't manipulate pixels. Rather you tell GDI+ that the device context is rotated and GDI+ translates the pixels as it draws. I have in my possession very fast VB-only rotation code, but it is not faster than GDI+. I also have bilinear and bicubic Vb-only algorithms; again slower than GDI+

I think the old fashioned code is good to have for basic understanding of how rotation, scaling, etc, etc work. But I don't use any longer for reasons noted in previous post #77.

Quote:

---

GDI+ renders to 32bpp DIB in premultiplied pixels. When using GDI+ one does not need to be concerned with premultiplied or not.

---

In your case, yes. However, in my case it is different -- on many occasions I must obtain an "un-premultiplied" image (through a trick of mine, GDI+ itself doesn't have that). If later on I have to stretch the image, I pass the "un-premultiplied" image. If further later on I have to rotate the image, I pass the processed "un-premultiplied" image again. Why is that?

Take this as a simple example in my case: User loads the image of a 32-BPP TGA, after drawing a red line on it, he resizes the image to 1.2 times. After resizing, he decides to touch up some alpha values in some areas and a bit later he decides to write some text on the image as well. Before he saves the processed image a to 32-BPP PNG, he also decides to tilt the image by 45 degrees first. -- It is in this kind of scenario that I must first obtain an "un-premultiplied" image every time I load the file.

Lucky that I didn't have GDI+ to use in earliers years, that provided me with a chance to build a good foundation, and even today I still have to use those subroutines under certain circustances, e.g. to draw a 45-degree-tilted and antialised ellipse (draw on a pixel by pixel basis in that case).

With the "always monster size" digital camera JPG files nowadays, I found that GDI+ is a must for their thumbnail browsing, VB's ordinary way is simply not upto the job.

Well, as with all things, there are usually workarounds...

For purists & special cases, not having original pixel data is not acceptable. If I render a PNG with transparent patterned background, I should be able to save as PNG with same background from that DC, correct?. I can't since it was rendered to GDI DC and all full transparency becomes black values. I can get original data from the source PNG but that isn't always doable (i.e., I need to scale the image then target & source images have different data).

The workaround, and one that I will most likely employ while I'm updating this control, is rather simple. Using the same scenario from previous post. I can get original data after rendering this way: don't draw to GDI DC, draw to GDI+ DC (hGraphics). This requires creating a blank image, getting a GDI+ graphics object from that blank image, then rendering to it instead. This has a major advantage with viewers that don't support transparency or ignore the alpha channel... The transparent background will display &H00FFFFFF as full white instead of &H00000000 (premultiplied fully transparent white = black). And obviously, this means you'll always be rendering with original non-premultiplied data.

The only question I don't have an answer for yet is how the key GDI+ API (GdipCreateBitmapFromGraphics) is affected, if at all, when screen resolution is not 32bpp. Some testing needed by me.

Worthwhile to have a feedback:

Tested animation of all my collections of assorted animated PNG files, all okay.

In the previous link/thread, you asked about 4-BPP PCX, I've now obtained one (per ZIP attached).

Your Alpha Image Control cannot load it, but no run-time error this time. On the other hand, there are some softwares which can load it perfectly right. The softwares include AZ Paint Pro, Irfanview, and AHA (I used AHA to test it because I got a good impression of it when I tested it's icon editor a few years ago). PhotoShop7 cannot load it, but this is understandable as 4-BPP PCX is seldom seen and PhotoShop7 doesn't pay much attention to PCX (it cannot load uncompressed PCX).

Screenshots loaded images of AZ Paint Pro and IrfanView are appended below for your reference:

Edited: Have added a 2nd PCX in the ZIP.

Quote:

---

Originally Posted by petersen

In the previous link/thread, you asked about 4-BPP PCX, I've now obtained one (per ZIP attached).

Your Alpha Image Control cannot load it, but no run-time error this time.

---

Thanx for the sample, I'll look at it & make sure I can parse it. The control won't load it because I only support 1, 8, 24 & 32 bpp at this time. In the property page, you'll hear a beep if image fails to load. In code the LoadPictureGDIplus will return error. Since our last discussion, I also found 1 4bpp but am still concentrating on revamping my SaveAs routines. With 2 examples now, I should be able to add 4bpp support to PCX.

Since 4-BPP PCX is hard to come by (CGA & EGA no longer apply nowadays), would you please upload your 4-BPP one (I would like to take a look)?

Quote:

---

Originally Posted by petersen

Since 4-BPP PCX is hard to come by (CGA & EGA no longer apply nowadays), would you please upload your 4-BPP one (I would like to take a look)?

---

Will do, but will have to wait til later tonight. Its @ home & I'm not. Check back at this post after dinner time. I'll add it below.

Edited: Here are 2 4bpp pcx files.
Note: The one you provided reports as 4 bpp, 1 plane. Everywhere I've read says 4bpp should come in as 1bpp @ 4planes. The attached are 4planes, not 1 plane. But in reality, a parser can treat both as 16 colors and attempt to load it the best it can.

Thanks, both are of 1-bit-4-planes. The one in my zip earlier is of 4-bit-1-plane, so it suits to complement.

I've now added another 4-bit-1-plane file to the said zip. The newly added one is only different in image width. What for? To facilitate testing -- if byte alginment is not right, this one would not be displayed. (Because of it, I myself have to revise my 4 BPP Read subroutine a little bit for my own programs). So I thought it would be of use if you are going to implement 4-BPP PCX

Edited: Re your last message

Quote:

---

....Everywhere I've read says 4bpp should come in as 1bpp @ 4planes....

---

That is the trouble. Seems a lot, but most are just copycats, and narrative only. In practice, I haven't come across any program actually praticing that. Have you seen even a single one? (If yes, please furnish the URL, I am curious)

On the other hand, I've seen good-quality shareware program(s) go for 4-bit-1-plane only, despite programs capable of saving 4-BPP are so rare.

I've found two such links mentioned earlier, in case you're interested:

XXX.batchconverter.com
XXX.coolutils.com/TotalImageConverter (Auto 4-BPP if image is 4-BPP)

Here's one that will save to 4 planes: http://www.ultimatepaint.com/download.php
The freebie version does pcx too

Thanks. Indeed it does a great job for this particular function, 1-bit-4-plane.

Edited: Just an observation: This program (i.e. mentioned in #91) can load only 1-bit-4-plane PCX. Those mentioned in #90 can load both 1-bit-4-plane and 4-bit-1-plane ones.

Hello, new here. The control looks very nice and I got a noob question, will it work with Visual Basic 2010? If so, how do get it into the program and add it to my forms? If it doesn't work with VB 2010, is there something similar I could use?

Thanks:)

Quote:

---

Originally Posted by Catsmeat

Hello, new here. The control looks very nice and I got a noob question, will it work with Visual Basic 2010? If so, how do get it into the program and add it to my forms? If it doesn't work with VB 2010, is there something similar I could use?

Thanks:)

---

Can't answer your question 'cause I don't own .Net (VB2010). Maybe another member can answer that question here? If not, you may want to google a bit searching for: VB6 ocx .Net

I don't even know if .Net supports windowless controls created in VB6, let alone whether it supports VB6 controls at all; though I'd assume it might.
You can always compile the ocx and see if you can add it to your .Net project.

Quote:

---

Originally Posted by LaVolpe

Can't answer your question 'cause I don't own .Net (VB2010). Maybe another member can answer that question here? If not, you may want to google a bit searching for: VB6 ocx .Net

I don't even know if .Net supports windowless controls created in VB6, let alone whether it supports VB6 controls at all; though I'd assume it might.
You can always compile the ocx and see if you can add it to your .Net project.

---

Ok, thanks for the info. Now I'm a little bit wiser. I'll keep on googling for an easy fix for a while=) If that doesn't work, I'll try to add the ocx thing.:)

La Volpe,

This is but for your reference, as you are using GDI+.

I believe the following would be accepted by you if someone says "For a JPG file, if VB LoadPicture() can load it alright, GDI+ shouldn't have a problem with it."

I've bumped into a case to prove that the above may not be true. The Sample.jpg inside the ZIP can be loaded with LoadPicture(), but not GDI+.

Inside the ZIP, there is also a VB ready-to-run executable file for testing. (1) Click Open submenu, in the File Dialog screen you don't see the thumbnail preview when you select the filename. However, if you continue to just load the file, it would be loaded alright. (2) Click File Browser submenu, go to the folder containing the subject JPG file (if you don't see the thumbnail displays/rectangles, click Refresh button in the File Browser screen), you don't see a thumbnail preview for the subject JPG file. However, if you right click the thumbnail rectangle, the image is again loaded properly. This is because, in both "1" and "2" cases, GDI+ is used for the thumbnail preview, however, when you proceed to load the file, LoadPicture() is used and that succeessfully loads the image without any problem.

......(URL removed as originally intended) ....
(I will remove the URL later today, latest tomorrow)

Edited: Further info. I've tested with IrfanView and PhotoShop7, same as VB LoadPicture(), i.e. no problem loading the JPG file. However, failed on Alpha Image Control.

I'll take a look at the file, but am not interested in messing with that attached app.
Interesting nonetheless. MS Paint couldn't load it either (doubt it uses GDI+). Windows Pic&Fax viewer couldn't, but I expect that since it uses GDI+. MS PhotoEditor & VB loaded it just fine.

If I was well versed in JPG format, I might be tempted to look into it further. But as it stands. I see I have just 2 basic choices at the moment.
1) Live with it
2) Attempt to load JPGs via LoadPicture then convert to GDI+ JPG that GDI+ can use

Edited: I think I can work around that issue. GDI+ reports the JPG as 8 bpp & that may be the key? Anyway, GDI+ loaded it, it just reports its bounds as 0x0. I can test for that situation, render it to a GDI+ bitmap & back to JPG to keep it as a JPG. Awkward workaround, but very doable.

Follow-up. I have it working now; it wasn't too bad ;). The logic I used is as described above: Look for 0x0 successfully loaded JPG. If occurs, load to stdPicture & convert its handle to GDI+ JPG. End result is the image, but at 24bpp in this case, not 8 bpp. I'll be including that patch with the udpated control once I am happy with the new SaveAs routines.
P.S. Now have working 4bpp PCX read & write routines also.

I've already traced to the cause, though of no use to you here.

Just for your info, the culprit is a zero entry in a tag "ED" (the tag and its entry length of 2 are perfectly valid, but GDI+ just wouldn't accept any zero entry). When this particular tag is removed, GDI+ accepts the file alright.

You asked for 16-BPP PCX sample files a little while back; it is not until today that I've bumped into one. It is a proper 4-bit 4-plane compressed PCX file.

I now include this siad file in a zip, together with a viewer which is capable of loading it (click Inquiry --> General Properties, you see 4-bit 4-plane). IrfanView wouldn't reject the file but doesn't display its image correctly.

.... (removed as originally intended ....
(I will remove the URL a bit later today)

Thanx Petersen. Now I can see if my educated guesses will work. I won't be able to download til later tonight when I get home from work. I already have 16bpp routines for TGA & ICO that should work with PCX, more or less.

Edited: Snaggd the image, haven't looked at it yet.
Ah, that was quick. It isn't a 16bpp image. It is 4bpp. The format says 4bpp x 4planes, but there isn't enough pixels to make it 16bpp. It is really 1bpp x 4planes. If you change the BitsPerPixel field in the image format, any viewer that can render 1bppx4planes would be able to load it. Simple math helps prove it.
The image reports 80 bytes per plane and has 4 planes. That equates to 320 bytes per line.
The image is 640 pixels wide. At 2 bytes per pixel (16bpp), the image would need 640*2 bytes or 1280 total bytes.
But at 4bpp (2 pixels per byte), the image would need 640\2 bytes (320 bytes) which is what exists in the format.

Yes, you're right. I myself had been cheated.

I forgot the exact spot where I got it. But I remember it was in a PCX spec/tutorial site, the download zip contains this sample PCX and a subroutine in C.

Sorry that I didn't check it over first, accepting the face value of what was coded in the header (4 bits and 4 planes). A quick check would have revealed it is a faked one (decompressed bytes are only 112000, a quarter of what they should be).

Edited: Incidentally, I tried to revisit xxx.ultimatepaint.com/cgi-sys/suspendedpage.cgi, but the link is no longer valid (The Account Is Suspended, the screen shows).

Actually, my routines (not yet updated here) read it fine as-is. That is because I've modified my routines a bit to allow for various ways PCX information is reported from what I've read on the web. The logic is basically this.
- 1 Plane = paletted: 1, 2, 4, 8 bpp. BitsPerPixel should always be 1,2,4,8 respectively
- 3 Planes = 24 bpp. BitsPerPixel may actually say 24 in some cases, but should say 8
- 4 Planes = 4 bpp or 32 bpp.
... 4bpp: BitsPerPixel may say 1 or 4 (as is the case with the pcx file you recently got hold of)
... 32bpp: BitsPerPixel may say 8 or 32 (though not many viewers support 32bpp)

Along with the above assumptions, some sanity checks are employed to ensure the BytesPerPlane*NrPlanes >= image's expected scanwidth. Now those checks will fail to render a true 16bpp PCX correctly, but until I find several of them, I honestly don't care -- they may not even exist? And if they do exist, will they be 4x4 or 8x2?

The true problem is interpretation. Some obviously feel that BitsPerPixel is literal & make this field read 1,2,4,8,24,32. While others interpret it to be BitsPerPixelPlane to be multiplied by number planes and then the only possible values would be 1,2,4,8. Though I haven't heard of, nor seen a 2 bit x 2 plane 4bbp image. Haven't seen a 2bpp image yet either; but coded for it.

The only issue I have with trying to support foul-ups, is that it is black and white to me. When I find the PCX format online that references ZSoft throughout, this is their description for the BitsPerPixel field, which clearly states BitsPerPixel is per plane not for the image itself.

Quote:

---

Originally Posted by ZSoft

Number of bits to represent a pixel (per Plane) - 1, 2, 4, or 8

---

You and I are the last dinosaur in PCX world nowadays. Since my first posting in the other thread, and following our recent discussions, on and off I've played a little bit of it still.

For example, by changing the sequence of 16-color palette entries, the resultant file sizes can vary tremendously. Per the attached zip, for a normally compressed file the size is 13k, but with a suitable arrangement in the sequence of palette entries (and with a good algorithm) it can be reduced to only 5k, on the other hand, an unsuitable change in sequence may result in 23k.

I think the above should be my last play of PCX.

I'd think that palette order would optimize file size. Makes perfect sense to me.
Regarding 16pp. If I get truly interested enough, I'd create a 4x4 & 8x2 555-format 16bpp pcx and see if any of my few viewers can read it. If it can, I might support the one(s) recognized. But that will wait until I have time to play & feel like it ;)

FYI: With your zip... Using the badly compressed one, when saved via my current routines, it saved it at 10k. Not too bad. The palette is sorted numerically; otherwise no optimizations made. I don't plan on making it a goal of the AlphaImageCtrl to optimize palettes. The user will have the option to provide their own palette when saving, so I'll leave that to them.

Again, just for your info.

I've stumbled into a GDI+ bug again -- GdipGetImageThumbnail() fails to load an ordinary JPG file which otherwise is alright with LoadPicture(), AZ Paint Pro, IrfanView, MS Paint and PhotoShop etc. I thus avoid using GdipGetImageThumbnail in any of my programs.

Unlike that per my Posting #98, this time I cannot trace to anything special about the subject JPG file.

Quote:

---

Originally Posted by petersen

Unlike that per my Posting #98, this time I cannot trace to anything special about the subject JPG file. (If you are interested, I can supply you with the subject JPG).

---

Only if it doesn't load in the alpha image control. I also don't use the thumbnail function

Hi LaVolpe,

i'm a long time lurking fan of your work, great job, really.

i just looked into using your animated control and am having a problem displaying a gif. code looks like this:

Code:

---

Private Sub Form_Load()
    AlphaControl.Animate lvicAniCmdStart, 1
End Sub

---

this form is being called from elsewhere as

Code:

---

Theform.Show

---

which then returns to doing work. I tried inserting a DoEvents and Sleep(100) to get the animation going, but it doesn't work, only the first frame is shown. the picture, an animated .gif, was pre-loaded through the property page.

any ideas?

J

Jay, sorry I didn't notice your post earlier, been trying to wrap up this latest update.
I admit that my animation class/methods can use a little work. I'm open to feedback/suggestions.

Edited: I do see something I had to track down. When you called that method, the control did not know it was in runtime and that is wrong. The real patch, I'll include in the next minor update. But to get past the problem for now, try this instead.

Code:

---

' in your form load... change to
    DoEvents ' should allow the control's internal Show event to trigger & set the flags appropriately
    AlphaControl.Animate lvicAniCmdStart
    AlphaControl.Animate lvicAniCmdSetLoopCount, 1
    ' ^^ this sets the loop count, but must be called after animation starts. It think that is what you were trying to do?

---

For all. NEW VERSION OF CONTROL UPLOADED to post #1
Any previous version is no longer compatible; way too many modifications and changes

Hi LaVolpe,

Is there a process to updating your ActiveX control in a project that's already utilizing a previous version?

When I replace the LaVolpeAlphaImg.ocx file with a newly compiled one, I can no longer open the project. It basically errors out as if it can't find the control. I assume because the new version compiled has a new GUID.

Never really had to do this before for an ocx.

Quote:

---

Originally Posted by Stidor

It basically errors out as if it can't find the control. I assume because the new version compiled has a new GUID.

---

That's the reason. For future versions, I'll make every attempt to keep it backward compatible. However, I have made so many modifications to this new update that it wasn't possible. It is a "new" control. The version in this is set a 2.0.0. Future updates will be incremented 2.1.0 etc as needed. If for some reason I have to break compatibilty and create another version, it will be 3.0.0

I know it is a bit inconvenient, but in this case, there really wasn't much of a choice.

Edited: One way to try to overcome it, is to compile the control, add it to a new project and save it. Then go inside the vbp file via notepad and copy the reference (found near top of file). Then open your other project and find the reference & paste over it. You'll need to do this for both frm & vbp files. Once done, open project in VB & press Ctrl+F5 and fix any changes in constant names, method parameters that cause an error. Press Ctrl+F5 again and again until no more errors.

Note. When compiling, you may want to add the version number at the end of the filename, i.e., AlphaImgCtrl2.ocx

While playing around trying to get it to update I had actually done sort of what you have suggested.

I got a copy of the new GUID and pasted it into my current project's vbp file. (overwriting the old one)
Then I overwrote the LaVolpeAlphaImg.ocx file.

Voila. I don't know why but it's now working fine, I didn't have to change it anywhere else. This doesn't seem right though. Does it? I'm running through some tests and it seems to be working without any errors under the new v2 OCX.

Give it a good test. Hint. If you were calling the SavePictureGDIplus function, look at those carefully. They had a few optional parameters. The new version got rid of one parameter. And if you supplied it, then that parameter may be shifted one to the right which will cause an error and/or unexpected effects. That is the only major issue related to functions that I can think of right now. You obviously did not dim a variable to one of the following; else errors should have been reported
- RENDERSTYLESTRUCT, no longer used & now is RENDERSTYLESTRUCT2
- MULTIPAGETIFFSTRUCT, structure changed
- MERGEINFOSTRUCT, structure changed
- lvicSaveAsTarga, changed to lvicSaveAsTGA

Dim a variable as SAVESTRUCT. If you get no errors, you are referencing the correct version. That structure didn't exist before.

I don't believe I used any of those. At the moment I'm more or less only using it to display .png images in my controls. (Also slowly replacing all my other GDI related code that this control can now do instead)

Loving the load from URL addition to the control, also the mouse pointer/cursor properties. I hadn't updated in awhile so lots of new stuff for me.

Thanks a bunch LaVolpe, loving your work.

Quote:

---

Originally Posted by Stidor

...Also slowly replacing all my other GDI related code that this control can now do instead...

---

If you think whatever code you won't be replacing would be beneficial to the masses, submit its purpose here as a possible enhancement. I'm all for making the control more complete, but I'm not for making it a complete image processor.

Bug report for WMF. Actually a GDI+ bug I think.
If interested, you can follow-up on my trial and error troublehsooting in this thread. But to make a long story short, GDI+ and VB6 don't play nice when GDI+ used to create a WMF.

I've fixed all the issues I knew about, but encountered a new one today. If the source image being converted to WMF consists of only black and white colors, then regardless of the bit depth of the source (1,4,8,16,24,32 bpp), the WMF during runtime has white become transparent. I've included a patch in my local copy that appears to be ideal. Basically, the patch will ensure that if the scenario happens where only 2 colors are used (black and white) then black will be changed to a value of 1 vs. zero. This appears to work quite well. I have a couple of other minor things to update too. Will wait til end of this week to post the patches. Want to see if I or you find any additional ones.

Edited: Similar issues existed with other formats

PCX & TIFF: If 1bpp image was not black and white, but say red & yellow, PCX/TIF displays all 1bpp as black & white.
The fix to that was to ensure the color depth was minimal 4bpp when 1bpp images were not black and white.

ICO/CUR: VB-only. 1bpp color icon/cursor is not affected, but if a 1bpp black & white icon/cursor is loaded into a stdPicture object (.Picture/.Icon property), it is resized by VB to 32x32 regardless of image's actual size. This issue hasn't been addressed yet. It isn't VB, but rather one of the OLE APIs I use to create the stdPicture object. If the same icon is loaded via LoadPicture() and a file, no resizing occurs. Will be addressing this in next minor update.
Edited: Found fix for this issue. Will include in next update

I discovered those annoyances a couple weeks ago.

Quote:

---

Original post by La Volpe
PCX & TIFF: If 1bpp image was not black and white, but say red & yellow, PCX/TIF displays all 1bpp as black & white.
The fix to that was to ensure the color depth was minimal 4bpp when 1bpp images were not black and white.

---

I haven't read your other comment lines yet, but regarding the above-quoted point it is my opinion (and practice) that:

(1) If an image has two colors which are not B&W, it shouldn't be saved as 1-BPP.

(2) To save as ICO file, if the image has 16 or below colors, but one or more of them are outside the 16 static colors, not to be saved as 4-BPP. Some programs adhere to this and I myself had encountered at least two of them, e.g. WinZip Self-Extract (it disallows a non-standard 4-BPP icon file).

To exemplify the above practice, here is a PNGnMNG program, written in VB. Its submenus under File main menu has the following (omong others): Save As BMP (Auto 32, 24, 8, 4 or 1), Save As PCX (Auto 24, 8 or 1) and Save As ICO (Auto 32, 24, 8, 4 or 1). Now if you feed a 2-color image but with a non-B&W color, saved file is 4-BPP. If you feed a 16-color image but with a color outside 16 static colors, saved ICO is 8-BPP. Of course if you feed a 32-BPP image, the saved ICO will be 32-BPP even after the loaded image has been resized and/or rotated.

.....(removed as originally intended.....
(URL will be removed a bit later, latest by tomorrow).

Quote:

---

Originally Posted by petersen

(1) If an image has two colors which are not B&W, it shouldn't be saved as 1-BPP.

(2) To save as ICO file, if the image has 16 or below colors, but one or more of them are outside the 16 static colors, not to be saved as 4-BPP. Some programs adhere to this and I myself had encountered at least two of them, e.g. WinZip Self-Extract.

---

1) Personal opinion. Why double the size of file if not needed? 1 bpp compresses to 8 pixels per byte vs. 2 pixels per byte for 4 bpp. Windows Bitmap supports 1 bpp non-B&W images. So do icons & cursors. 1 bpp means 1 or 2 colors, not B&W. But, if an image format always interprets 1bpp as B&W only (PCX,TIF), then there is an exception obviously.

2) Not sure I understand your statement. "Static colors"? Halftone? Some arbitrary palette? If I'm guessing at the context correctly, then adhering to palette colors for systems that cannot support more than 16 colors is a bit antiquated IMO; almost like ensuring our code meets Win3.1 standards. However, because the user can supply their own palette, they can be guaranteed that no colors will be used outside of that palette. The user makes the determination, the code does not.

I don't want to enter into a debate, we may talk theory and MS rules and decrees the whole day, but the practices may still differ. As I specified, there are programs still adhere to the old rules, and if I don't adhere to the same, my customers will blame me when they cannot load their icons to WinZip SelfExtract program (for shareware program installation use). Over the years I had also encountered programs practicing the same as WinZip (through customers' feedback).

By 16 static colors, I meant the following 16 colors &HFFFFFF, &H808080, &HFF00FF, &HFF&, &HFFFF&, &HFF00&, &HFFFF00, &HFF0000, &HC0C0C0, &H0&, &H800080, &H80&, &H8080&, &H8000&, &H808000 and &H800000

I still adhere to the above on saving 4-BPP ICO, but laxed for other file formats.

The static colors you mentioned are what I call the Halftones. The default palette types offered are halftones for 16 & 256 colors.

The user (the coder, not a customer) has full control.
- If coder wants default colorless reduction, then if reduction results in 4bpp or 1bpp that's what they get, whether the palette contains halftones or not.
- If coder wants palette reduction to 256, 16 or b&W using default palettes, then the colors are guaranteed to be halftones
- Likewise, the coder can provide their own palettes

This control isn't the decision maker, other than ensuring the saved image can be read in the image format it is saved in. What colors, effects, sizes, etc, etc, are in the coders hands. If someone wants to argue that the coder doesn't know whether an icon should be paletted in hafltones, or if WinZip will accept it if not, then the coder needs to do the research as you did. The control offers a ton of flexibility, it forces nothing on the coder without offering other options/workarounds.

I've been asked twice now... "How do you apply multiple version 1.1 effects to an image?" Honestly, I don't know the answer. Can it be done in one call? The key function only accepts one effects handle. So, I don't think it can be done in one call. But since this control exposes all, a little GDI+ knowledge and some fun, we can do it ;)

Note: v1.1 of GDI+ required. Vista or better. See posts #1 thru #3 for a bit more on v1.1 of GDI+
1. Add two alpha image controls to your form and one command button. Leave default control names
2. Place an image into the 1st alpha image control. Size 2nd control to 1st control's size
3. Copy and paste this code

Code:

---

Option Explicit

Private Declare Function GdipGetImageGraphicsContext Lib "gdiplus.dll" (ByVal pImage As Long, ByRef graphics As Long) As Long
Private Declare Function GdipDeleteGraphics Lib "gdiplus.dll" (ByVal mGraphics As Long) As Long
Private Declare Function GdipGraphicsClear Lib "gdiplus.dll" (ByVal graphics As Long, ByVal pColor As Long) As Long

Private Sub Command1_Click()

    ' Tip. If the image is to be rotated, grayscaled, or any other non v1.1 effects, do that
    ' either first or last via a call to SavePictureGDIplus and filling out a SAVESTRUCT.

    Dim cFX As GDIpEffects
    Set cFX = New GDIpEffects
    ' create the v1.1 effects you want to apply
    cFX.CreateBlurEffect 2, True
    cFX.CreateBrightnessContrastEffect 40, -10
    cFX.CreateTintEffect 180, 40
    ' call this makeshift function & pass the effects in order that you want them applied
    Set AlphaImgCtl2.Picture = MultiEffectToImage(AlphaImgCtl1.Picture, cFX, lvicBrightnessContrastFX, lvicTintFX, lvicBlurFX)

End Sub


Private Function MultiEffectToImage(Source As GDIpImage, FXclass As GDIpEffects, ParamArray Effects() As Variant) As GDIpImage

    If GDIplusTokenVersion < 1.1 Then Exit Function ' need to have right version for effects

    Dim X As Long, Index As Long
    Dim hGraphics As Long
    Dim cImages(0 To 1) As GDIpImage
    Dim SS As SAVESTRUCT
   
    ' want a graphics object for this function to work. Can't have one if image is paletted.
    ' Need a copy anyway, so might as well just create a saved version in the right bit depth
    If Source.UsesTransparency Then SS.ColorDepth = lvicConvert_TrueColor32bpp_ARGB Else SS.ColorDepth = lvicConvert_TrueColor24bpp
    Set cImages(0) = New GDIpImage
    If SavePictureGDIplus(Source, cImages(0), lvicSaveAsPNG, SS) = False Then Exit Function
    Set cImages(1) = LoadPictureGDIplus(cImages(0)) ' copy the one we just made
   
    For X = 0 To UBound(Effects)
        ' now toggle between the two images, rendering the effects
        If GdipGetImageGraphicsContext(cImages(Index Xor 1).Handle, hGraphics) = 0& Then
            GdipGraphicsClear hGraphics, 0&
            cImages(Index).Render 0&, , , , , , , , , , , hGraphics, FXclass.EffectsHandle(CLng(Effects(X)))
            GdipDeleteGraphics hGraphics
        Else
            Exit For
        End If
        Index = Index Xor 1
    Next
    If X > UBound(Effects) Then Set MultiEffectToImage = cImages(Index)

End Function

---

Edited: Another version, no GDI+ knowledge needed. Just needed to put my thinkin' cap back on.

Code:

---

Private Sub Command2_Click()

    ' Tip. If the image is to be rotated, grayscaled, or any other non v1.1 effects, do that
    ' either first or last via a call to SavePictureGDIplus and filling out a SAVESTRUCT.

    Dim SS As SAVESTRUCT, cImage As GDIpImage
    Set SS.RSS.Effects = New GDIpEffects
    Set cImage = New GDIpImage
    ' create the v1.1 effects you want to apply
    SS.RSS.Effects.CreateBrightnessContrastEffect 40, -10: SS.RSS.EffectType = lvicBrightnessContrastFX
    SavePictureGDIplus AlphaImgCtl1.Picture, cImage, lvicSaveAsPNG, SS
    ' ^^ using PNG as destination to avoid issues if original image format doesn't support colors/effects
   
    SS.RSS.Effects.CreateTintEffect 180, 40: SS.RSS.EffectType = lvicTintFX
    SavePictureGDIplus cImage, cImage, lvicSaveAsCurrentFormat, SS
   
    SS.RSS.Effects.CreateBlurEffect 2, True: SS.RSS.EffectType = lvicBlurFX
    SavePictureGDIplus cImage, cImage, lvicSaveAsCurrentFormat, SS
   
    ' any other effects? If not, then...
    Set AlphaImgCtl2.Picture = cImage

End Sub

---

The above code is an example only. You should provide more error checking as needed/wanted.

And yet another method which is what I'd personally use if I wanted faster results.
1. Create a GDI+ bitmap 2x height and same width of source
2. Set clipping rect to top half, render source to top half using effects#1
3. Remove clipping rect & set new clipping rect to bottom half, clear bottom half, render top half with effects#2 to bottom half
4. Now continue toggling between top & bottom halves for remainder of effects, clear it before rendering
5. Create new GDI+ bitmap same size as source. Render last drawn half to it & clean up.
This method should be fastest I'd think. Oherwise, method 1 above will be faster than method 2 above because you aren't saving the image after each effect is rendered.