cGDIPImageLoader, small class for "universal" image loading

This is a tiny, lightweight class which I put together some months ago for various uses. It is a "Universal" image loader - images can be loaded from file, bytes, image handle, or stdpicture. A few other useful functions are also contained within. No image caching nor other advanced techniques as this is intended to be only a simple loader.

Most of the code is my own, along with a few bits here & there which I shamelessly stole from Olaf Schmidt so as not to reinvent the wheel :).

A simple demo is included.



EDIT: Demo program updated to allow resizing

EDIT 8/05/25: Final update, fixed a bug within the class which would cause an error when loading from an image handle.

It feels fantastic. Thanks for sharing

I shall have a look!

Silly question, but what is the advantage of using GDI vs a straight copy to a properly sized PictureBox?

J.A. Coutts

It is GDIP not GDI. GDIP can read all sorts of more modern image types.

This is someYguy's program in testing.

https://www.vbforums.com/images/ieimages/2025/08/1.gif

Does it do TIFF?, Not tested that yet.

Unplanned dupe post....

Quote:

---

Originally Posted by yereverluvinuncleber

Does it do TIFF?, Not tested that yet.

---

It should, yes because GDI+ supports that format

Just to let everyone know, the demo is only meant to showcase use and capability of the class. Not really meant to be a useful tool of its own but you CAN view pictures with it :).

I thought so. In one of my older programs I have some older image handling routines from La Volpe that provide access to the same formats and at the core at least one of his routines use GDIP.

I use GDIP already in my dock and I was thinking of replacing some of La Volpe's older code just to play with the GDIP in this program as well using my own code. I was planning that for the future but you have stimulated me to make progress, I will try your loader and see how quick it is in comparison.

Quote:

---

Originally Posted by couttsj

Silly question, but what is the advantage of using GDI vs a straight copy to a properly sized PictureBox?

J.A. Coutts

---

Not silly at all :).

Many advantages. GDI+ supports many more image file formats than the VB6 picturebox i.e. PNG for one. Also much more control over every aspect of image rendering from transformation & effects to placement to quality. Further, direct rendering to a DC means that the image can be rendered not only to pictureboxes but actually any object which exposes a valid Device Context such as a form or a custom usercontrol. Another big advantage is loading directly from a byte stream, which allows support for database images. Lots more advantages also.

It is important to note that I haven't done anything new and exciting here, just written a class which makes the basics quick & easy.....

Quote:

---

Originally Posted by yereverluvinuncleber

I thought so. In one of my older programs I have some older image handling routines from La Volpe that provide access to the same formats and at the core at least one of his routines use GDIP.

I use GDIP already in my dock and I was thinking of replacing some of La Volpe's older code just to play with the GDIP in this program as well using my own code. I was planning that for the future but you have stimulated me to make progress, I will try your loader and see how quick it is in comparison.

---

Very good and I LOVE looking at pictures of your steampunk stuff. As to speed, hard to say. Should simply be as fast as GDI+ can load & render something. I doubt that it will be an improvement over anything that LaVolpe wrote but maybe a slight advantage due to sheer simplicity. My aim was to provide just enough to get the job done.

Demo program updated to allow resizing.....

Class updated so as to correctly handle alpha channel transparency.

I think that some of La Volpe's code would not compile under TwinBasic due to unimplemented functionality re: some TYPES not yet being supported, one opf the reasons why I wasn't testing my older project with TwinBasic yet.

Are you testing yours under TB too? It could be useful to know it compiles, I will try and test later myself.

It compiles and works well under TwinBasic.

GDI+ is a simple API for loading, manipulating, and saving images. Completely sufficient in most cases. The disadvantage of GDI+ is that it only supports a limited number of image formats. On a modern system, I believe WIC (Windows Imaging Component) would be the better interface. Like GDI+, WIC contains a fixed number of built-in codecs. However, WIC can also be extended with WIC-compatible codecs, so that many more image formats can be loaded or saved using WIC. It is also possible to write your own WIC codecs. WIC itself only offers limited image manipulation options (rotation, scaling, etc.), but if you want more, there is the option of further processing a WIC bitmap with Direct2D/3D.

Good job

Quote:

---

Originally Posted by -Franky-

GDI+ is a simple API for loading, manipulating, and saving images. Completely sufficient in most cases. The disadvantage of GDI+ is that it only supports a limited number of image formats. On a modern system, I believe WIC (Windows Imaging Component) would be the better interface. Like GDI+, WIC contains a fixed number of built-in codecs. However, WIC can also be extended with WIC-compatible codecs, so that many more image formats can be loaded or saved using WIC. It is also possible to write your own WIC codecs. WIC itself only offers limited image manipulation options (rotation, scaling, etc.), but if you want more, there is the option of further processing a WIC bitmap with Direct2D/3D.

---

All true but I've stuck with GDI32 & GDI+ in many of my applications for backward compatibility and also portability because pretty much anything that I produce doesn't require any external references nor components. Purely API unless I really need something else.

As to the limited format problem, here's how I addressed that in one of my programs: That app can optionally use the FreeImage library dll if it is on system. The code will detect the presence of that library and make use of it if it exists. All the user has to do is copy the FreeImage dll either to the app directory or to the system directory if they want the extra formats. Further, during loading, the program will only use the FreeImage library for image types which are not already natively supported. In other words, it tries GDI+ first and then falls back to FreeImage. If I remember, FreeImage supports 30+ formats. It is abandonware but the last release is still available and works well.

Final revision of DrawImageToDC function. Leaned to only necessary code.

Note: This change is already incorporated into the final download version in the original post.

Code:

---

Public Function DrawImageToDC(ByVal nHdc As Long, ByVal nImage As Long, Optional ByVal dX As Single, _
                              Optional ByVal dY As Single, Optional ByVal dW As Single, _
                              Optional ByVal dH As Single, Optional ByVal sX As Single, _
                              Optional ByVal sY As Single, Optional ByVal sW As Single, _
                              Optional ByVal sH As Single)

'- Draws passed image at specified x, y coordinates
'- and at specified width & height.
'- Returns zero if successful.

    Dim ImGraphics As Long
    Dim lRet      As Long

    If (dW = 0) Then dW = m_Width
    If (dH = 0) Then dH = m_Height
    If (sW = 0) Then sW = m_Width
    If (sH = 0) Then sH = m_Height

    lRet = GdipCreateFromHDC(nHdc, ImGraphics)
       
        If lRet <> 0 Then Exit Function              '- Can't create graphics object so bail out
       
        lRet = GdipDrawImageRectRectI(ImGraphics, nImage, dX, dY, dW, dH, sX, sY, sW, sH, 2)

        If lRet = 0 Then
            '- No error
            DrawImageToDC = 0
        Else
            '- Something went wrong
            GdipDeleteGraphics (ImGraphics)
            GdipDisposeImage nImage
            DrawImageToDC = lRet
        End If
 

    '- Clean up
    If ImGraphics Then GdipDeleteGraphics ImGraphics
 
End Function

---

Quote:

---

Originally Posted by SomeYguy

All true but I've stuck with GDI32 & GDI+ in many of my applications for backward compatibility and also portability because pretty much anything that I produce doesn't require any external references nor components. Purely API unless I really need something else.

As to the limited format problem, here's how I addressed that in one of my programs: That app can optionally use the FreeImage library dll if it is on system. The code will detect the presence of that library and make use of it if it exists. All the user has to do is copy the FreeImage dll either to the app directory or to the system directory if they want the extra formats. Further, during loading, the program will only use the FreeImage library for image types which are not already natively supported. In other words, it tries GDI+ first and then falls back to FreeImage. If I remember, FreeImage supports 30+ formats. It is abandonware but the last release is still available and works well.

---

I can understand your point of view. Backward compatibility plays a rather minor role in my examples. I don't know anyone who uses PCX, TGA, or PGM images and other exotic image formats anymore, which FreeImage.dll can certainly read or write. If only there were someone who would reprogram such exotic image formats as a WIC codec. :D