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

[Stidor]

Fantastic post LaVolpe, you've made it seem quite easy. Can't wait to give it a go when I get home from work this evening. I've never had a need to play with Property Pages so this should be a great learning exercise.

Thank you for the explanation and example code, much much appreciated.

[Stidor]

LaVolpe,

I appear to be getting a type mismatch error when trying to use;

LoadPictureGDIPlus(bData())

Is LoadPictureGDIPlus able to load from a byte array? I'm getting this error with your example code but was also getting it with my own code.

After looking at LaVolpeAlphaImg source code it does look like LoadPictureGDIPlus can import from a byte array. No doubt it's something simple I'm not seeing.

I'm even getting it with;

Set cImage = LoadPictureGDIPlus(cBrowser.FileName, , True)

[LaVolpe]

The control definitely can load a byte array. Ensure you are using Option Explicit atop your usercontrol and propertypage too. I'm guessing whatever is on the left side of the equal sign wasn't declared. It isn't the LoadPictureGDIplus function as I wrote it. FYI: Why is there a capital P in the Plus in LoadPictureGDIPlus? My function doesn't have a capital P.

You might want to post a couple of snippets where you use those lines. Also include what type of object those lines are written in (form, uc, propertypage, class, etc).

Edited: Can you upload a clipped snap shot of your expanded project explorer tree? (top right treeview in IDE design window)

[Stidor]

FYI: Why is there a capital P in the Plus in LoadPictureGDIPlus? My function doesn't have a capital P.

Well don't I feel silly. Would you believe I had another function called exactly that already existing in my project. You have a very good eye LaVolpe.

My apologies. Will refrain from posting late at night without looking at it again the next day with a fresh mind.

[Stidor]

Back again, hopefully this time with a legitimate issue. I seem to be having an issue transferring one image from a picturebox to an AlphaImgCtl. When I try I get an "invalid picture" error. Looking through your control source I see that via LoadPictureGDIplus it should be possible to load from a picturebox.picture?

Update: Ah! Upon further reading of your control source comments, I noticed the comment about loading from the handle instead. So basically I'm now using..

Set AlphaImgCtl.Picture = LoadPictureGDIplus(PictureBox.Picture.Handle)

Which works just fine. :-) Thought I'd leave this post here in case anyone else finds it helpful.

[LaVolpe]

...Update: Ah! Upon further reading of your control source comments, I noticed the comment about loading from the handle instead. So basically I'm now using..

Set AlphaImgCtl.Picture = LoadPictureGDIplus(PictureBox.Picture.Handle)

Glad you figured it out, some notes for clarification only

1) You can't do: Set AlphaImgCtl1.Picture = Picturebox1.Picture because the Picturebox object's .Picture property is a stdPicture class. The AlphaImgCtl object's .Picture property is a GDIpImage class. A type mismatch error should occur.

2) You can load a picturebox's picture a couple of ways
a) by handle as you described
b) also: Set AlphaImgCtl1.Picture = LoadPictureGDIplus(Picture1.Picture)

Edited: Note that by handle will fail if the picture is a metafile & transparency lost if transparent GIF. I'd recommend staying with option 2b above as a general rule.

[petersen]

Another bug?

I was doing something concerning some thumbnail stuff on my own program when I bumped into a likely GDI+ bug. So I fetched a copy of Image control to see if it also applies there - it seems so.

Attached zip has 2 GIF sample files. Note the characteristics of aaa1.gif file: the first frame is smaller than the background size, the first frame is non-transparent, there are some other frames with transparency. And aaa2.gif, all frames are non-transparent.

[LaVolpe]

Another bug?

I was doing something concerning some thumbnail stuff on my own program when I bumped into a likely GDI+ bug. So I fetched a copy of Image control to see if it also applies there - it seems so.

Agreed another GDI+ bug in both cases. Appears GDI+ takes some shortcuts that do not render the GIFs correctly. I'll consider adding my own GIF routines, but not committed at this point.

FYI. If there has ever been any doubt that the Windows Picture & Fax Viewer uses GDI+, use that viewer to display those GIFs

Edited: I'm playing with the idea of using my own GIF routines. Not yet sure of how I want to go about this while maintaining the same methods I use for other image formats. Right now, I know I can do this a couple of ways to maintain those methods: a) create 1 large bitmap that will include all frames and then segment the image to produce frames or 2) create each frame, fully rendered, and add them to a multi-page TIF. Though either will work well and allow minimal 'special handling' for GIFs, I fear load time could be an issue since the entire GIF would have to be rendered to bitmap(s) initially. GDI+ is fast, but obviously, has its issues too. I still want to wrap a GDI+ handle around the GIF-data so I can continue to use all the other image processing methods/properties of the usercontrol; don't want to render individual GIF frames manually, per frame during animation, using GDI vs. GDI+. Still thinking...

[petersen]

Yes GDIplus can be extremely efficient when selectively used. For your reference, the craziest animated GIF file I've ever come across is with 1600+ frames; the background size is about a palm's size.

[LaVolpe]

As I'm contemplating taking over GIF rendering responsibilities vs. using GDI+, some other ideas hit me...
Whatever method I decide upon for GIFs can be used to support APNG (animated PNG) and MNG also. If I go that route, I will only support some subsets of MNG, specifically PNG & JPG most likely if I can find enough examples to play with.

Edited: I think I've discovered a really clever & fast way to load/render individual GIF/APNG/MNG frames while avoiding GDI+ bugs. Still working on it.
Update: Works fantastically. Will modify class to support APNG also, then post the updated control. MNG will wait a bit until I can find enough samples to play with. Expect the GIF/APNG updates 1st weekend of December.

[petersen]

Good luck and enjoy yourself.

[Jonney]

MNG Spec:
http://www.libmng.com/pub/mng/spec/

[LaVolpe]

Jonney, thanx for the specs link. I was aware of it, however, I haven't gone searching for MNGs at this point.

For all: Updated project to support APNG and better GIF handling
Here are some sample APNGs you can play with.

http://www.spreadfirefox.com/node/1872
http://animatedpng.com/index.php/category/samples/
http://treebuilder.de/default.asp?file=89031.xml
also Google for APNG

Note about APNG. Rare. The following browsers/viewers are only ones I know of that support APNG
Mozilla Firefox 3, Opera 9.5, KSquirrel 0.7.2, XnView 1.92

And if you want to play with creating your own. Look at APNG's site: http://animatedpng.com/index.php/software/

[tmighty]

Great work! Thank you!

I don't have GDIPLUS.dll v 1.1. I am not sure why...
Can anybody please tell me where he/she got their v1.1 from (if you downloaded it later) and how you distribute it? Do you put the GDIPLUS.dll into your app directory?

[tmighty]

Sorry, I did not find a "Kill message" button. I found out that gdiplus v1.1 may not be distributed :-(

[LaVolpe]

Project updated to include the PCX image format. 1, 8, 24, 32 bit image support for displaying and 8, 24 bpp support for writing. 32 bpp support is included in the project but very few readers will recognize it. So I turned it off. If you wish to turn it on then see comments in cFunctionsPCX.SaveToStream

Also updated... can now save as WMF or EMF. Saving alphablended images to WMF may not produce best results.

Hoping for a happy and prosperous New Year for all.

[petersen]

La Volpe,

As you know, I don't use Alpha Image Control myself (as I have my own stuff), nevertheless I have done some testings for you and provided some feedback and bugs reports per my postings earlier, as a matter of interest.

Following our discussion on PCX last night, I've now fetched the new copy and carried out some tests in selected areas.

Here is a particularly point I want to bring your attention to. The screenshot below shows two images obtained from Alpha Image Control and from AZ Paint Pro program respectively. The source image is a 32-BPP PNG, saved to 24-BPP PCX file.

(1) There is a discrepance between the image displayed and the image retrieved from the saved file using Alpha Image Control. Despite the background used is White on loading the file and the display on screen showed the background being white, the saved file is invariably turned into using Black background.

(2) There is no option in Alpha Image Control to allow user to opt for a desired background color on loading a 32-BPP images.

Whatever background color to use usually doesn't matter; however it matters in the case of 32-BPP images. That is why programs such as AZ Paint Pro and IrfanView provide options for users to select a desired screen color to use (although the latter is basically a viewer program only).

Apparently Black is not a good background to use in this case - especially the jagged edges in the fishbow stand structure are conspicuously visible.

.

[LaVolpe]

There is an option to choose a background color. In the comments in the very first post I urge people to at least open the AICGlobals class and read the comments in that class for the few functions in that class.

Here are the comments in the SavePictureGDIplus call that pertains particularly to background color

RenderingStyle :: Pass a filled RENDERSTYLESTRUCT or don't pass it if no special rendering style needed
- This function does not use rendering attributes utilized by any control maintaining the passed Picture object
- The BackColor member of the rendering style is used as follows
If BackColorUsed is True, the image will be filled with the BackColor member

[petersen]

La Volpe,

Please don't take it hard. I've just pointed out a point which I considered worth pointing out. If you don't like it, I would just stop here after this posting.

(A) You have ignored/overlooked a condition which has been clearly stipulated in my posting. (i) My current background color is already what I have chosen to be, white, what else do I have to change? (ii) What is better to guide the user to opt for a change than what is currently shwon on screen. When the screen is already showing what I want it to look like, why should I select any option to change it still? Common sense should prevail.

(1) There is a discrepance between the image displayed and the image retrieved from the saved file using Alpha Image Control. Despite the background used is White on loading the file and the display on screen showed the background being white, the saved file is invariably turned into using Black background.

(B) Incidentally, I have just received a mail from someone who is also a graphics programmer (and VB fan) and with whom I have been communicating on this topic for fun. What he says is self-explanatory.

Contrary to my previous email, changing the background color of a 32bpp image in AZ Paint Pro all works OK even when made black. So it takes the background color into account properly, unlike LaValpe's AlphaImage

The following image is what is meant in "B" above:
.

[LaVolpe]

This was your statement: There is no option in Alpha Image Control to allow user to opt for a desired background color on loading a 32-BPP images.

That statement is false. I do not plan on changing the control for this item of interest. When saving to an image format that does not support transparency, transparency will be lost. To dictate the color you want to use to replace the transparency, use the options provided. My logic is not unlike other applications and is not unreasonable. Call it poetic license. I appreciate bug reports and will consider enhancements, but not this one because it is already addressed

[petersen]

Again, you are just "too quick".

I didn't say I make any change via an option provided in Alpha Image Control. I changed the background color of the canvas, that is in this case the Form, to White (I may change it to say Black or Red). When I changed the background color of the Form to white, the image loaded shows what I wanted. It is only the Save that fails to honour what I wanted.

I guess I should stop discussion now.

[LaVolpe]

Well, let me take 1 step back. The optional attributes you apply via the usercontrol (backcolor, grayscale, rotation, mirroring, transparency, blend, etc) are applied on the fly; they are not assigned to the image. Those attributes are maintained at the usercontrol not the image itself. The SavePictureGDIplus routine is passed an image class, not a usercontrol instance. The image class has no knowledge of what usercontrol(s) may be referencing it. Many usercontrols can share the same image class and each usercontrol can have different attributes applied. The only way the SavePictureGDIplus call can know of the attributes would be to pass that routine a usercontrol instance, not a GDIpImage class instance. But this isn't practical because the image class can be created on its own with the NEW keyword and will not have any control associated with it.

Here's what I will consider. Adding a SaveImage-like call in the usercontrol that will call the SavePictureGDIplus to produce a WYSIWYG result. That's an idea.

[petersen]

I can fully understand what you've explained.

But I have to put myself in an ordinary user postion. Ordinary users wouldn't care and/or understand the code itself. They just use it, and use it the way they are used to (or the way that the other programs/controls normally go).

The very purpose of my posting is to raise the point on a justified ground, whether your actual situation permits you to do something about it at the current moment (I can of course see that the code is far from a simple code), or indeed whether the point warrants a code modification at all, is entirely upto you to consider - but that is a separate issue.

[LaVolpe]

But I have to put myself in an ordinary user postion. Ordinary users wouldn't care and/or understand the code itself. They just use it, and use it the way they are used to (or the way that the other programs/controls normally go).

I disagree 100% with your statement. The ordinary user is a coder. The control is used in the coder's application they are designing. It is up to the coder to understand the controls they are using. By the word 'understanding' I specifically mean what options it offers and how to use it. And in this case, it is pretty well documented within the code and it is open source.

For argument's sake. If someone wanted to save a stdPicture object in VB to a file, they'd use VB's SavePicture function, correct? Well what if that stdPicture was assigned to an image control that was stretched and had a border? Would VB save it in that scale and with a border? No. If VB could've offered 32bpp support for the stdPicture, what backcolor do you think it would have saved transparency as when saving to a format that doesn't support transparency? I believe the answer is black, same as other Microsoft products currently do: PhotoEditor & Paint. At best, VB might have offered an optional parameter for a backcolor, which is exactly what I did.

When I changed the background color of the Form to white, the image loaded shows what I wanted. It is only the Save that fails to honour what I wanted.

By setting the BackColor & BackColorUsed values, the result is exactly as you wanted. Following is PNG saved to PCX with white & black backcolors.


Again, it is not the control's responsibility to guess what the coder wants. It is the coder's responsibility to make the control do what he/she wants. The control has no knowledge of, nor does it care, nor does it need to care what its container's background state may be. That state is not part of the image, the image is rendered over it. Keep in mind that this is just a control, a tool for larger applications. Same applies to that stdPicture example above. If a coder wanted to save it in a different scale and style, they'd have to a) do it manually b) use one of the control's options to do it for them, if the option existed.

Obviously this control is not a stand-alone exe. It could be used as a key component for a larger application and offers a wide range of options that no other free control offers VB users. If someone wants to use it, it is their responsibility to play with and learn to use it, just like any other control in their toolbox. It appears you are comparing my control to a full application & that's like comparing the WinSock control to Mozilla. If I were to build an app that uses my control, I could replicate any 'paint-like' app and probably more because this control enables the coder to modify the image before, during, after drawing. Not only that, less code on my part is required because so many options have been included with the control. Its limitations are restricted only by the coder's imagination & experience, not by the control.

Edited: And to that point, I even took the time to create some sample projects people could use to play with the control and better educate themselves. Those can be found in the 1st posting.

[petersen]

If the following still cannot convince you to recognise that there are flaws in existence in Alpha Image Control, then I don't know what else to say.

Attached is a zip containing a 32-BPP PNG file (32bpp.PNG).

Image0 (first image shown) shows its image (using Black screen color, in order to be in line with the blackish background on saving PCX with Alpha Image Control).

Image1 (2nd image shown) shows what are the images in PCX, when saved with Alpha Image Control on one hand and AZ Paint Pro/IrfanView on the other.

Image2 (3rd image shown) shows what the images are in EMF, when saved with Alpha Image Contro, IrfanView and PNGnMNG2 respectively.

Readers who want to try save PCX using Alpha Image Control for
yourselves can refer the syntax given by La Volpe in Posting #28 at
http://www.vbforums.com/showthread.php?t=636793

(PNGnMNG2.zip containing PNGnMNG2.exe is available at
XXXX://XXX.XXX (removed now as origi...intended) XXXX
URL will be removed later today, latest tomorrow.
Just Open 32bpp.PNG, then click Save As EMF there)

.

[LaVolpe]

If the following still cannot convince you to recognise that there are flaws in existence in Alpha Image Control, then I don't know what else to say.

I am not convinced. I have to repeat again, that if you don't use the backcolor options (saving transparency to format that doesn't support transparency), you will not get what you want. You tell the control what you want, it does not tell you what you want. Here is the same image rendered from png to pcx and to emf with the RenderingStyle parameter's BackColor & BackColorUsed properties set.

' Example saving to another format and loading it at afterwards
    Dim c As New GDIpImage
    Dim rs As RENDERSTYLESTRUCT
    rs.BackColor = vbWhite: rs.BackColorUsed = True
    SavePictureGDIplus AlphaImgCtl1.Picture, c, lvicSaveAsEMF, , rs
    AlphaImgCtl2.Picture = c 
' Example saving to file
    Dim rs As RENDERSTYLESTRUCT
    rs.BackColor = vbWhite: rs.BackColorUsed = True
    SavePictureGDIplus AlphaImgCtl1.Picture, "C:\MyImage.pcx", lvicSaveAsPCX, True, rs

Readers who want to try save PCX using Alpha Image Control for yourselves can refer ...

Readers who want to try to use the control, read the comments, especially those in the AICGlobal class, and play with the control !

Your previous post does not mention how the EMF was saved. Is it transparent? Probably not & if it is, please post the emf here so I can see. But using the control properties provided to you, you can reproduce the same images as your previous post. I have mentioned in post #1, at the very top, that I am working on revamping the SaveAs routines. If you do find an error, I'd be happy to address it. But you are not posting errors, you are posting examples of 'how not to use the control the way you want'. And to be clear about the PNG over backcolor... The backcolor is not part of the PNG, the control's backstyle is set to opaque

Edited: Just so one doesn't question my integrity, attached are examples of the saved images. And if someone still questions it, just do it yourself. The source image provided in previous post by Petersen, sample code provided by me above.

[petersen]

Why I have to bother myself again and again, if the other side does not follow the facts:

I have already presented so clearly all materials in posting above.

(1) PCX was obtained using exactly the command you gave, repeated here.

Readers who want to try save PCX using Alpha Image Control for
yourselves can refer the syntax given by La Volpe in Posting #28 at
http://www.vbforums.com/showthread.php?t=636793


(2) Correct EMF was obtainable from PNGnMNG2, repeated here

(PNGnMNG2.zip containing PNGnMNG2.exe is available at
XXXX://XXX.XXX (removed now as origi...intended) XXXX
URL will be removed later today, latest tomorrow.
Just Open 32bpp.PNG, then click Save As EMF there)


Edited: For the benefit of general readers: To understand why "Save PCX" had come up in the first place. In the course of doing tests for Alpha Image Control, in Posting #26 of http://www.vbforums.com/showthread.php?t=636793, I specfically asked:

.... how do I save a loaded image to a PCX file?

and the specific answer given in #28 is:

SavePictureGDIplus AlphaImgCtl1.Picture,[path/filename], lvicSaveAsPCX, True

Change True to False for uncompressed. Supply path/filename

If you are interested in knowing how the subject matter has come about, browse the above link/thread, especially the later postings there.

[LaVolpe]

Petersen, At that point in time, I was just designing the pcx parser and you KNOW that. Things changed since that posting. If you want to use the correct syntax use what I provided in my previous post.

If you don't want to use the control, then don't. You want to point something out that is wrong with the code, post the applicable code snippet, otherwise, I'd very much appreciate if if you'd just stop posting erroneous stuff on this thread and stop trying to make a point that doesn't exist. I have no time for people that don't want to try to understand the code. Enough said.

[petersen]

If I recall correctly, you once explained that La Volpe means "The Fox" in Italian, now I can't help wondering whether in Indian it means "The Sacred Cow". Only the day before you expressed apppreciation for my tesing in the above said link/thread, now you are so mad at my "not so pleasant" feedback whcih is just a continuation of the said testing.

Cheers.

[LaVolpe]

Only the day before you expressed apppreciation for my tesing in the above said link/thread, now you are so mad at my "not so pleasant" feedback whcih is just a continuation of the said testing.

Cheers.

I'm not mad, I have told you no less than 2 times how to replicate the images you provided. You refuse to accept that advice and consistently harp on 'it doesn't do what AZ Paint or InfranView does'. Of course not, it isn't an application. It is a control. The control will do what those do if you pass it the right parameter information. This is now the 3rd of 4th time I've said that. Your feedback is not even constructive, I can deal with bug reports as history has proven. I can't deal with someone that apparently doesn't want to try to understand the control they are using and posting uneducated feedback.

[petersen]

Fair. Let us put a stop here on the subject matter.

[petersen]

Take this as an independant issue (i.e.not to be related to the earlier subject)

Got an error message (screenshot attached) with the file (zip attached).

Debug line: If inStream(UBound(inStream) - 768&) = 12& Then

[LaVolpe]

Thanks, that's something I will look into. I was sure I ran appropriate tests to prevent that, obviously not. It will wait until the save routines I'm designing are done.

And to the point of filling default background for formats that don't support transparency. That's on my list of things to do too. Bmp, Jpg are definite as they don't support transparency (except 32bpp bmp). PCX I'm still undecided with since it can support transparency, but not many viewers will display it. One of the options when saving to a particular format will be to dictate the bit depth as this will allow 32bpp to be saved with/without transparency or even bit reduced to paletted if desired using one of 4 palette options. I'm still not agreeable to having the control guess whether transparency should or should not be applied, simply because it permanently removes the option for the coder. Or... I am completely agreeable to default to 24bpp (or less) if format doesn't naturally support alpha channel (bmp, jpg, pcx for example) and let coder override for bmp/pcx. Converting WMF/EMF from 32bpp can produce horrible results if not rendered over a non-transparent background and that's going to be the coder's decision.

Last but not least, with every update comes more options. Included with the new SaveAs routines, will be option to save image rendered over an image background (tiled, stretched, clipped), a gradient/hatch brush, and/or solid backcolor.

[petersen]

When I was about to remove temp folder for Alpha Image Control, I spotted a 1-BPP file, hence just in time to do the above test.

The following are but for your reference:

Regarding PCX, I wouldn't give it the slightest thought about 32-BPP, as it is basically for legacy uses nowadays.

I don't come across any particularly dilamma situation regarding the transparency aspect. My programs do show transparency for many formats (GIF, PNG, TGA, TIFF, J2K, JP2, ICO, CUR, ANI and 32-BPP BMP, the last one is for vb guys only). In my own experience, three areas are comparatively tough (one is not difficult, one is difficult and one very difficult):

(A) Taking the trouble to tell whether a simple transparency PNG has been faked by GDI+ as if reaal 32-BPP. This one is not difficult at all, only causng some nuisance.

(B) To allow user to enlarge a displayed GIF/Simple Transparency PNG on chessboard, in a situation (1) Halftone is required, (2) use of GDI+ not allowed and (3) the chessboard grid size must maintain the same size as before.

(C) In one of my programs, I have to allow users to edit 32-BPP images, e.g. rotate, resize and touch up alpha values, and after that allow them to save to various formats at will (e.g. user loads a 32-BPP PNG, rotates at 70 degree, enlarges it by 2, then saves to a 32-BPP TGA). This is comparatively much more difficult. If GDI+ is used, obtaining un-premultiplied images is the key.

At the moment, I don't see you have any of "B" and "C" situations.

[LaVolpe]

Above
(A) Not an issue for me, I have routines that will identify via a 32bpp stream whether transparency is used and whether or not that stream is ARGB or pARGB

(B) GDI+ not allowed is not an option. This control is based on GDI+. GDI+ is redistributable if for some odd reason it doesn't exist. I have used GDI+ on Win95 and up. Yes, Win95. Regarding chessboard. Not an issue, since it isn't part of the control. The control will render over the chessboard background; therefore you can resize all you want without it affecting the background. Transparency with this control is not faked, it is rendered as-is.

(C) It is already there. The optional RenderingStyle parameter allows that. In your example, the image would be rendered resized & rotated simultaneously by GDI+, the resulting image would then be saved to TGA. Use negative angles for counter-clockwise rotation.

    Dim RS As RENDERSTYLESTRUCT
        RS.Height = AlphaImgCtl1.Picture.Height * 2
        RS.Width = AlphaImgCtl1.Picture.Width * 2
        RS.Rotation = 70
    SavePictureGDIplus AlphaImgCtl1.Picture, "C:\MyPic.tga", lvicSaveAsTarga, True, RS

The main idea I had for this control was 1) show image formats VB won't, 2) make it enable tons of features/effects, 3) enable coder to do a lot with very little code. You can see how easy it is for the coder to do what you termed as 'much more difficult' by using just a few lines of code. The control has so many more options and only reading the comments/examples within AICGlobals class can one get a feel for the core functions and also press F2 and reading the usercontrol's property descriptions for that contrrol's properties/methods. I spent a lot of time adding those function descriptions & would expect those that want to play with the control to browse thru the ones they find of interest.

[petersen]

I can see you have the advantage since GDI+ is used throughout and you don't have to allow user to edit paint and alpha values of individual pixels. As there are so many features and functions which can be included, a decision to provide what (and forego what) and how to best organize the arrangements need hard work still.

[LaVolpe]

Yes GDI+ is an advantage. My first image control I created used GDI+ sparingly and my own routines for a vast majority of the graphics including rotation, grayscaling, blurring, mirroring, etc, etc. I still have my own manual PNG reader/writer class I wrote that doesn't use GDI+ at all. I don't include those non-GDI+ routines any longer because 1) slower overall than GDI+ most of the time, 2) far less code needed for me, 3) wide-availability of GDI+, and 4) ease of use once one is comfortable with GDI+. Sure, it has its disadvantages also, but IMO those are far out-weighed by its advantages.

Edited: One disadvantage to GDI+ I really dislike is inability to set compression type of a PNG & various color depth formats. My manual PNG writer can out-perform GDI+ regarding file size, but not even close on speed. I can even create interlaced PNGs, but GDI+ can't/won't.

[petersen]

Most of my graphics programs started to build since 10 years ago when GDI+ was not common in users' machines, hence I had to do lots of detailed and dirty work, e.g. for anialiased line (guaranteed always smooth at any angle and brush size). Gradually I found that I am using more and more GDI+ and I come to like it.

Taken a quick look of your GDI+ call, the very long one, I can tell what you are doing and why you use that long one.

[LaVolpe]

You must be talking about GdipDrawImageRectRectI? Lots of parameters, but it does soooo much. That one function replicates many GDI calls, mainly due that attributes parameter. That one function can do same as these: BitBlt, StretchBlt, AlphaBlend. And with the use of the attributes parameter: grayscale, invert colors, blending, lightness/darkness, & TransparentBlt, color skewing/rotation, and many other color/matrix-related operations with just 1 API call. Lots of parameters, but oh so many options

[petersen]

Your subroutine with a long parameter list is Function Render, I meant.

Some of my GDI+ subroutines also use GdipDrawImageRectRectI, e.g. inside the one below, there is such a call.

Public Function ReadFileToDIB32_via_GDI(inFileSpec As String, inDIB As clsDIB, _
Optional inIsTrueBPP32 As Boolean, _
Optional ByVal inBkgdColor As Long = &HFFFFFF, _
Optional ByVal inAlphaCutOff = 25, _
Optional ByVal inTranspPercent As Long = 100, _
Optional ByVal inRecreateDIB As Boolean = True, _
Optional ByVal inDestX As Long = 0, _
Optional ByVal inDestY As Long = 0, _
Optional ByVal inDestW As Long = -1, _
Optional ByVal inDestH As Long = -1, _
Optional ByVal inHighQty As Boolean = True, _
Optional ByVal inPageIndex As Long = 0) As Boolean

By a glance you are able to tell what I am doing there. In most cases I only need to pass first few parameters, Note inIsTrueBPP32 is passed ByRef, as its values is established within this subroutine (and the calling module uses that). I only involve attributes when inTranspPercent is not 100. If the incoming image is to be drawn on existing image in DIB, inRecreateDIB would be passed as False (actual use of True or False will be subject to certain condition).

My situation is diff to yours (e.g. mine has to go through edit of individual pixels), hence Resize and Rotation are in separate subroutines. I guess in your case (I didn't look at in detail of yours), you must include Stretch and Rotate jobs in a single subroutine, because you don't use "un-premultiplied" image.