PNG/TGA (specifically 32-bpp type files) Editing Tool

[Elroy]

Note, this project uses mscomctl.ocx version 2.2. If you have an older version, the project may not load correctly for you. To fix this problem, you will need to update your mscomctl.ocx. Here's a link to a post by LaVolpe that explains the issue more fully, and provides links for the updates. Also, mscomct2.ocx version 2.0 is used for the status bar. If you have an older version of that, you may need to update it as well (or remove the status bar, which wouldn't be difficult).

Version 1.03 (original release, attached to this OP)
Version 1.04 released in post #16
Version 1.05 released in post #17
Version 1.06 released in post #18
Version 1.07 released in post #19

Hi All,

This was a request and I thought it would be fun. It turned out to be quite the learning experience.

Basically, I've developed a tool for editing the Gamma, Brightness, or Contrast of a 32-bit RGBA type PNG or TGA image. Sorry, but it's specifically limited to that type of an image file.

Here's a screen-shot of the main form:


Basically, when you open a PNG file, it loads it (via GDI+), displays it on a form, splits it into four channels (Red, Green, Blue, & Alpha), displays each of these on separate forms, and then displays one last form that shows modifications to the image. Here's a reduced screen-shot of how it looks:



A couple of caveats: I do use SaveSettings to save a few things to the registry. I know that some people are concerned about this. Therefore, if you're running in the IDE, upon normal exit, I ask if you'd like to delete all of these settings.

Also, to try and keep things speedy, I startup the GDI+ upon opening the app, and don't shut it down until you're exiting. I didn't have any problems with the IDE stop button, but I'm not totally clear on whether or not an IDE stop is totally safe here. I'm hoping that the worst case is a memory leak (that's cleared up when you exit the IDE).

The entire project is in the attachment to this post. A PNG file has also been supplied for you to play with (same one shown).

Now, I'd also like to take this opportunity to outline how I did things. Basically (because I want to handle PNG files with an active Alpha channel), I used the GDI+ to load the image. And then I immediately use the GDI+ to show this original image. Next, I get the image's RgbQuad() data, and then split that into its separate channels, creating separate arrays for Red, Green, Blue, & Alpha. And then I use the regular GDI32's SetDIBits to show these channels on the separate forms. And then, I take the four RgbQuad() channel arrays, re-combine them, and then show them on a Modifications form (using GDI+ and the still open hBitmap to do this).

Just as an FYI, the individual RgbQuad() channel arrays have no Alpha in them (it's always zero). The original image's Alpha channel is copied into the Red, Green, & Blue channels of the Alpha's RgbQuad() array, effectively creating a gray-scale image to show the Alpha channel.

I also "save in memory" all kinds of information (thinking that this would keep things speedy). Therefore, this thing is not memory efficient. Here's a list of what I maintain in memory:

1. I keep the original file open (hBitmat) with the GDI+.
2. I keep the original RgbQuad().
3. I keep each channel's original RgbQuad() (four of them).
4. I keep each channel's modified RgbQuad() (four of them).
5. I keep a modified RgbQuad() of the full modified image.

Some of the things I learned during all of this:

• When leaving a PNG file open (active hBitmap) with GDI+, somehow, GDI+ keeps its hooks into that file until you execute a GdipDisposeImage (or something similar).

• These PNG files can have a DPI scaling factor embedded in them that makes using GdipDrawImage a bit dubious. If you want to "think" in pixels, this will get fouled up. To "think" in pixels, you must use GdipDrawImageRectI.

• The GDI+ seems to prefer scanning images from top-down, whereas the GDI32 prefers seeing them as bottom-up. That just caused me to jump through a few hoops to tell the GDI+ that I want them bottom-up so that I'm not constantly flipping them.

• As I got into it, it dawned on me that the order in which Gamma, Brightness, & Contrast are applied might matter. The approach I took was to always go back to the original image when making changes (and hence saving all those RgbQuad() arrays). Always going back to the original allows me to return to that original while editing, if I so desire. Rather than get overly complicated, I just decided on a Gamma(first), Brightness(second), & Contrast(last) approach to applying things.

• I also learned that Contrast can be complicated. There are several theories/ideas on how this should be done. I'm not entirely happy with my approach, but it works. I save the mean value (as a Single) of each of the channels upon load. And then, pixels are either stretched away from (or pushed toward) this mean to achieve contrast changes. Other approaches would be to go toward or away from 128 (middle value). Yet another approach would be to calculate the mean each time (thereby accounting for brightness and gamma changes) but this could have speed consequences.

• I also learned that, with larger images, my approach can bog down. At first, I was showing all changes "in real time" on each click of a control. However, it quickly became apparent that this wasn't going to work. Therefore, I implemented a timer that fires every 200ms. If a bIsModDirty flag is true and if the mouse button isn't down, it calculates and shows the changes. This allows the interface to work much more smoothly, although you don't see changes until you release the mouse button.

And, here's a list of things I may want to consider for the future:

• Possibly exploring (learning more about) how to use the GDI+ to do my Gamma, Brightness, Contrast changes. I feel certain it's capable of this, and it may make the entire project more memory efficient, and possibly more speedy as well.

• Possibly learn how to read a TGA (Targa) file as well. This was actually part of the original request, but I had to start somewhere. If I do this, I'd probably want my SaveAs... to be able to convert between the two.

• Think more about the order in which the effects are applied (especially since I'm always going back to the original). I might let that be user-specified, just to see what difference it makes.

• Possibly consider additional effects (soften, sharpen, etc.).

I've done my level-headed best to keep this code as organized as possible. However, I do use somewhat deeply nested UDTs to keep track of everything. However, for a somewhat seasoned VB6 programmer, that shouldn't be a huge deal.

If you're interested in studying this code for purposes of how to manipulate images, the place to start is the code in frmMain. And then, you'll want to get into the modPng code, and then the modGdip code. I've tried to make the modGdip code as generic as possible (i.e., not really tied to the specifics of this project). The code in modPng is rather specific to this project. You'll see all the stuff that's maintained in memory in the ThePng UDT variable that's in the modPng file. There's also a touch of GDI32 stuff in the modPng file.

Enjoy,
Elroy

p.s. Please stay focused and please don't be upset if I don't respond to all of these, but critiques and suggestions for improvement are welcomed and encouraged.

[dilettante]

The registry is not a playplace. You are causing registry fragmentation woes. This is exactly why some sort of config file makes sense and has been advocated by Microsoft for a very long time now. What next? Stuffing random items into System32 or C:\ "because it is there?"


I'm not convinced any of this makes sense. Gamma, contrast, brightness... all apply to the whole image and not to individual channels.

I assume you had some reason to want this though. Can you explain concisely what you were really after so we'd know why we might want to do that to our own images? If it is needed very often why don't common image tools like IrfanView provide this?

[Elroy]

It was an idea proposed to me by a friend for quickly changing the colors and shades of an RGBA type image, making alternate images. Maybe nobody in this forum will find a use. I had fun doing it, and I didn't see any reason to not share.

Regarding the registry, like I said, I gave you a way to clean it up. If my little program causes registry fragmentation (compared to all the other programs constantly massaging the registry, just the recently opened file stuff to mention one), then someone has problems much larger than anything caused by my little program. And, since I'm really not creating a database for permanent storage, the registry seemed like an ideal spot for my handful of settings. Compared to all the ways other programs use the registry, I just truly don't see anything resembling a problem. But I suppose that's just my humble opinion. If that concerns you, search for SaveSetting and GetSetting, and comment them out.

Best Regards,
Elroy

[LaVolpe]

Elroy, just FYI... If you delve into GDI+ even more, you will find usage of GDI+ image attributes very useful here

1) You can show individual R,G,B,A channels
2) You can brighten/darken
3) You can adjust gamma
4) You can color shift (i.e., contrast)
5) Other color adjustments

All this is done via a color matrix that is sent to the image attributes creation API. The gamma adjustment has its own function and its settings are not included in the matrix; however, gamma is applied to created image attributes object.

In short, there is no need to extract bits and modify them for display. This is all done on-the-fly by GDI+.

GDI+ functions...
GdipCreateImageAttributes
GdipSetImageAttributesColorMatrix
GdipSetImageAttributesGamma

[Elroy]

Hi LaVolpe,

Yeah, I've already got the declarations for those functions. I'm amazed at how few resources there are for them. I can find extremely little that tutors me on how to use them, especially with respect to VB6, and even just in general. A Google search of GdipSetImageAttributesGamma gets only 77 hits (many of which are garbage). I'll probably eventually get it sorted, but nothing is clear about this stuff at the moment, at least not to me.

I'm sure I'll eventually look into making it more of a pure GDI+ application (forgetting about any RgbQuad arrays).

But truth be told, I'm more interested in adding the ability to edit a TGA file with it (exactly the same way that I'm editing a PNG file). There is some stuff out there on that, but I just haven't fully gotten into it. It doesn't seem that the GDI+ can read a TGA file, which is sad. I'm thinking I'll need to create a "temp" PNG (using some TGA-to-PNG conversion code), do my editing, and then put it back (if saved).

Thanks For All Your Help,
Elroy

[LaVolpe]

Regarding Targa (TGA), you can find a parser/writer class in my AlphaImage control. Within that class should be a link to where I got the format specs (if site is still valid). The class initially may be a bit to walk thru because it references other project classes/functions. But it is commented pretty well. TGA is one of the earlier image formats that supported alpha channels.

TGA pixel data can be added to a GDI+ image easily after the pixel data has been parsed:
1. Create an empty/blank GDI+ image: GdipCreateBitmapFromScan0. Use no Scan0 pointer and no stride, but do specify pixel format & dimensions
2. Use LockBits/UnlockBits to put the parsed pixel data into the GDI+ image
3. You can save the GDI+ image as PNG without any problems

You use the word PNG a lot. Don't consider GDI+ as PNG, TIFF, GIF, etc, etc. Consider it as either bitmap or metafile. GDI+ images are much like a DIB with ability to express those bytes in various pixel formats. When loading an image, GDI+ parses the format and creates its own version of "DIB". Then when you save the image to a format (bmp, png, tiff, etc), GDI+ converts the pixel data into the image format.

Edited. Notes about that TGA parser. I went back and quickly scanned it. Has a couple logic flaws that should be addressed for completeness sake only. In the IsTGAResource function, there are checks to see if some value is < 0, using CopyMemory to get the values. If you notice, the number of bytes copied is 2 and they are copied to a Long variable. Well, if you copy 2 bytes to a Long variable, value will never be < 0. Those tests should change the variables to Integer or rewritten or ignored if willing to handle a 65K x 65K potential image. That class' functions were pulled from an older project of mine that probably used integers and I didn't pay attention when I re-purposed it for the alpha image control.

[LaVolpe]

Here's a good page to help get one's head around the color matrix

The color matrix looks like this

	dstRed	dstGreen	dstBlue	dstAlpha	*
srcRed	1
srcGreen		1
srcBlue			1
srcAlpha				1
Add/Sub	0	0	0		1

The columns can be considered as the calculated channel and the rows can be considered as the source channel values. The values placed above is called an identity matrix, no change in colors. And any values not shown can be considered as zero. Calculated channel colors are made from values in its own column...
dstColor = (srcRed*value+srcGreen*value+srcBlue*value+srcAlpha*value) + (Add/Sub * 255)
So using dstBlue for example: (srcRed*0+srcGreen*0+srcBlue*1+srcAlpha*0) + (0*255)

Simple grayscale "average" formula can look like this:

	dstRed	dstGreen	dstBlue	dstAlpha	*
srcRed	.33	.33	.33
srcGreen	.34	.34	.34
srcBlue	.33	.33	.33
srcAlpha				1
Add/Sub	0	0	0		1

To fade an image, the value at intersection of srcAlpha and dstAlpha can be less than 1, i.e., a value of 0.5 would result in 50% fade into background.

The values in each column can literally be any value. Typically these would be in the range 0 to 1. However, if you wanted twice as much blue, you would make the appropriate dstBlue column value 2.0 for example. In the last matrix example below, the values are negative to produce color inversion. And if the need ever arose to rotate colors, those values may actually be SIN/COS values; example shown at that link I provided at top of the reply. If any calculated value falls out of bounds, then they are adjusted automatically.

Hope that is a starting point for you. And just FYI, the bottom right value in the table must be one. It's not used, but is a requirement. Otherwise, I haven't seen any sample matrices that use the far right column (except the bottom right grid) nor any that use the other dstAlpha column values. However, no harm in plugging in values anywhere in the matrix and testing for the fun of it.

Edited: You can find so many pages on the web that talk about color matrices and how to set them to achieve desired effects. Once you can visualize the matrix, then those pages make so much more sense

Example: Extract Blue channel only:

	dstRed	dstGreen	dstBlue	dstAlpha	*
srcRed
srcGreen
srcBlue			1
srcAlpha				1
Add/Sub	0	0	0		1

Example: Extract Alpha channel only, as grayscale:

	dstRed	dstGreen	dstBlue	dstAlpha	*
srcRed
srcGreen
srcBlue
srcAlpha	1	1	1	1
Add/Sub	0	0	0		1

Note & just for fun. If you were to remove the value in the dstBlue column, then the alpha channel would be represented as shades of yellow vs grayscale: RED + GREEN = Yellow

Example: Darken pixels by 20%

	dstRed	dstGreen	dstBlue	dstAlpha	*
srcRed	0.8
srcGreen		0.8
srcBlue			0.8
srcAlpha				1
Add/Sub	0	0	0		1

Note: It might seem logical to simply subtract (last row values) 20% (0.2) from each channel instead. But that isn't really darkening by 20% is it? It's subtracting 51 (255*.2) from each channel. Instead, the matrix above only keeps 80% of the individual R,G,B values which is more correct. To lighten the value 20%, set each R,G,B value to 1.2

One more example: Invert colors

	dstRed	dstGreen	dstBlue	dstAlpha	*
srcRed	-1
srcGreen		-1
srcBlue			-1
srcAlpha				1
Add/Sub	1	1	1		1

The above works like this for each R,G,B channel, looking at Red for now:
1) Take srcRed and make it negative
2) Then add 255 and clamp result between 0 and 255; that's the "And 255" part
Formula looks like: dstRed = ((srcRed * -1) + 255) And 255
Another way of doing this would be: dstRed = (srcRed Xor 255)

[Brenker]

Just a feedback:

-- After I clicked "PngEditor.vbp", an error msg flagged - see screenshot below. I clicked "No", then none of the Forms and BAS had been loaded. I ended the session.

-- In 2nd round, I clicked "Yes". But I got a Main.log file, saying

Line 123: Class MSComctlLib.StatusBar of control staFileSpec was not a loaded control class.
Line 130: The property name _ExtentX in staFileSpec is invalid.
Line 131: The property name _ExtentY in staFileSpec is invalid.
Line 132: The property name _Version in staFileSpec is invalid.
Line 139: The property name Panels in staFileSpec is invalid.

-- Since this time I saw Forms & BAS were there, so the first thing I did was to block "GetSetting" & "SetSetting" lines (quite a few there). I then clicked "Run", then another error msg on screen - see screenshot below.

I am on Win 10 v1709.

[LaVolpe]

@Brenker. Look at this link, it'll explain the problem and how to resolve it.

@Elroy, may want to read that too & tweak your project so others don't have the same issue & assume your project is broken

[Brenker]

LaVolpe,

Thank you for the link; clear enough to me.

After above is performed, those downloading your sample project will be using their version (same or higher). Only when their version is older than the one listed in the project, will there be a problem for them. Luckily, so far, the different versions remain binary compatible with each other.

FYI: The version installed on any PC is due to SP6 and/or one of its security patches, possibly other Microsoft software you've installed, or maybe even Windows updates. Asking people to install a more recent SP6 security-patch to make their version the same or higher than yours is typically not an option.

It looks like that unless Windowns' own Updates have put a new version of MSComCtl... to my machine, I won't have a chance of trying out Elroy's project because I myself have never done a VB SP, not even SP1. (Remarks: There has never been a problem in all these years for my own programs to reach out to users on all versions of Win platform, this is because I use my own code for ShowOpen/ShowSave etc, and I only use VB intrinsic controls).

Brenker

[LaVolpe]

It looks like that unless Windowns' own Updates have put a new version of MSComCtl... to my machine, I won't have a chance of trying out Elroy's project because I myself have never done a VB SP, not even SP1.

Brenker

Nah, just open his files in NotePad and change the common control version to 1.0 wherever you find them. When you run the project after changes made, you may get a prompt that your version is newer and will be used instead. But you'll be able to run the project. I had to do the same thing.

[Brenker]

LaVolpe,

Main.frm is the only place where MSComCT2.OCX is referred:

Object = "{86CF1D34-0C5F-11D2-A9FC-0000F8754DA1}#2.0#0"; "MSCOMCT2.OCX"

So I changed #2.0# to #1.0#.

On first run after the said change, I got an error msg per screenshot below. But then I had a 2nd try and this time the said error msg no longer appeared. There was no confirmation MsgBox in between.

The current status is: I got bogged down by the run-time error in Sub Form_Load, as shown in my previous lot of screenshots.

Brenker

[Brenker]

This one is unrelated to this thread, it is just that while I am here in this Code Bank, I can't help wondering about the phenomenon that with a total of 84 downloads of the code in

http://www.vbforums.com/showthread.p...VB6-Icon-Maker

I was the only one to say something there.

[Elroy]

I just made a note at the top about the mscomctl.ocx and mscomct2.ocx. If people are truly interested, they should be able to sort those things out. The fact that I'm using GDI+ is already evidence that I'm not coding to the lowest-common-denominator. And, getting these updated shouldn't be a huge deal.

All The Best,
Elroy

[Elroy]

Wow, 20 downloads of my little utility. Apparently someone is interested.

Hey guys, I'm working on a more pure GDI+ version, but I've got some other work coming up so it may be a few weeks. We'll see.

[Elroy]

Okay, attached is another version of my little utility. I'm calling this one version 1.04. It's a fairly major reworking of version 1.03, with many of the ideas discussed above incorporated into it.

For one thing, it's a much more pure GDI+ program now. In fact, there are no longer any GDI32 calls in it.

Also, Gamma, Brightness, & Contrast are all derived via GDI+ tools, rather than manually doing it pixel-by-pixel as version 1.03 had done.

In addition, the Gdip.bas module is becoming a fairly nice set of wrappers for the GDI+ API functions. There is much more you can do with the GDI+, but this is a start, particularly with respect to making gross (whole image) changes to PNG files.

Please read the OP, as it basically still applies.

Enjoy,
Elroy

[Elroy]

Well, I can't seem to leave this thing alone. I've added the ability to edit TGA (Targa) files as well as PNG files. Again though, they must be 32-bbp files before the little utility will allow you to open them. You can also save these TGA files. And, you can convert PNG to TGA (or vice-versa) if you so chose.

To read the TGA files, I leaned heavily on LaVolpe's Alpha Image Control, basically cannibalizing it so that it only reads the TGA 32-bpp files. (@LaVolpe, thank you!) To write them, I took the simple way out and just wrote them as the simplest possible TGA file. This was easy since I've limited things to 32-bpp, and these TGA files are not terribly complex (to write).

I've also enhanced the Color Selection Dialog (for changing the background color) to allow for double-clicking, and several other small enhancements.

I'm also considering making a scale/zoom feature since I'm now never reading the pictures from the forms. It would be fairly easy to do and would help with large images. But that's for the next release.

Again, most stuff I said in the OP still applies.
I'm calling this one Version 1.05.

Enjoy,
Elroy

[Elroy]

Ok, I'm thinking this'll be the last update for a while.

I've got the scale/zoom feature going, as well as a few other small enhancements (polishing). Also, I removed the dependency on mscomctl.ocx (although there's still one in it for mscomct2.ocx for the spinner controls).

As usual, most stuff I said in the OP still applies.
I'm calling this one Version 1.06.

Enjoy,
Elroy

[Elroy]

Alrighty, another release. The big improvement on this one is the addition of a paintbrush-touchup tool. Here's a screenshot of the main menu:



This is Version 1.07.

Enjoy,
Elroy

EDIT1: Made a change to the way PNG headers are verified. See the following few posts for the rationale for this change.

[xxdoc123]

 
Private Type PngHeaderType
    ID          As Long       ' Only read as 4 bytes (not unicode) when used with "As Binary".
    DosLineEnd  As String * 2       ' Only read as 2 bytes (not unicode) when used with "As Binary".
    EofChar     As String * 1       ' Only read as 1 byte (not unicode) when used with "As Binary".
    UnixLineEnd As String * 1       ' Only read as 1 byte (not unicode) when used with "As Binary".
End Type

Dim ID As Long
    
    '
    ID = 1196314761 ' Chr$(137) & "PNG"
    '
    iFle = FreeFile
    Open sFileSpec For Binary Access Read As #iFle
    Get #iFle, , ThePng.Header
    Get #iFle, , ThePng.Ihdr
    Close #iFle
    '
    If ThePng.Header.ID <> ID

[Elroy]

@xxdoc123,

Yeah, always more than one way to skin a cat. For my money, that's not code that's executed frequently (or in some tight loop), so I'd rather let the code self-document a bit, rather than a cryptic 1196314761 number. But that's just my preference.

I often muse at some of the speed tests performed around here. Sure, if we're talking about something that's going to be done 1000s of times, let's make it fast. But opening and closing files? Nahh.

Take Care,
Elroy

[xxdoc123]

@xxdoc123,

Yeah, always more than one way to skin a cat. For my money, that's not code that's executed frequently (or in some tight loop), so I'd rather let the code self-document a bit, rather than a cryptic 1196314761 number. But that's just my preference.

I often muse at some of the speed tests performed around here. Sure, if we're talking about something that's going to be done 1000s of times, let's make it fast. But opening and closing files? Nahh.

Take Care,
Elroy

yes you are right. but in my chinese system can not used.so i change str to long .Only this.Thank you for your code

[LaVolpe]

Yeah, always more than one way to skin a cat. For my money, that's not code that's executed frequently (or in some tight loop), so I'd rather let the code self-document a bit, rather than a cryptic 1196314761 number.

FYI... not cryptic

The first eight bytes of a PNG file always contain the following values:

(decimal) 137 80 78 71 13 10 26 10
(hexadecimal) 89 50 4e 47 0d 0a 1a 0a
(ASCII C notation) \211 P N G \r \n \032 \n

This signature both identifies the file as a PNG file and provides for immediate detection of common file-transfer problems. The first two bytes distinguish PNG files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a PNG file; also, it catches bad file transfers that clear bit 7. Bytes two through four name the format. The CR-LF sequence catches bad file transfers that alter newline sequences. The control-Z character stops file display under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem.

but in my chinese system can not used.so i change str to long

Always a risk when forcing binary data into a string...

[Elroy]

Okay okay. I'll "fix" it.

Momentarily, the following will be fixed in post #19. I'm not going to go through and fix all the prior versions though.

xxdoc123, thanks for bringing this to my attention. And LaVolpe, thanks for driving this home for me.

Here's my new formulation of the UDT:

Private Type PngHeaderType
    ID1         As Long
    ID2         As Long
    '
    'ID          As String * 4       ' Only read as 4 bytes (not unicode) when used with "As Binary".
    'DosLineEnd  As String * 2       ' Only read as 2 bytes (not unicode) when used with "As Binary".
    'EofChar     As String * 1       ' Only read as 1 byte (not unicode) when used with "As Binary".
    'UnixLineEnd As String * 1       ' Only read as 1 byte (not unicode) when used with "As Binary".
End Type

And here's my new code in the GetHeaderAndValidatePngType function:

    Dim ID1 As Long
    Dim ID2 As Long
    '
    ID1 = &H474E5089    '   Chr$(137) & "PNG"
    ID2 = &HA1A0A0D
    '
    iFle = FreeFile
    Open sFileSpec For Binary Access Read As #iFle
    Get #iFle, , Header
    Get #iFle, , Ihdr
    Close #iFle
    '
    If Header.ID1 <> ID1 Or Header.ID2 <> ID2 Then:                 sError = "Bad PNG ID header": Exit Function

Hopefully, this solves the problem.

All The Best,
Elroy

[wqweto]

FYI, Adobe Photoshop Source Code - version 1.0.1, mostly pascal w/ a bit of ASM

cheers,
</wqw>

[DEXWERX]

FYI, Adobe Photoshop Source Code - version 1.0.1, mostly pascal w/ a bit of ASM

cheers,
</wqw>

Pascal/ASM is so retro! that's the kind of code I first learned from.

[dreammanor]

PhotoShop is a legend and it's one of the greatest software on the planet. Unfortunately, it's not developed in Basic.