Visual Basic

6-Aug-21 4:02

I have a small clock/calendar Applet that lives on my desktop, since (for at least some purposes) I like to have an analog clock. I recently decided to clean up the Panel that displays the clock to make the square background to the round clockface transparent, so that the clock face would just 'float' over the desktop. I discovered that this was not simply a matter of making the relevant area in the source image transparent, since the transparency 'disappears' when the image is loaded into the Panel. However, the following load code almost works when the panel is displayed:

Private Function ConvertImageToRGBFormat(img As Image) As Image
        Dim temp As New Bitmap(img.Width, img.Height, System.Drawing.Imaging.PixelFormat.Format32bppRgb)
        Dim g As Graphics = Graphics.FromImage(temp)
        g.DrawImage(img, New Rectangle(0, 0, img.Width, img.Height), 0, 0, img.Width, img.Height, GraphicsUnit.Pixel)
        g.Dispose()
        temp.MakeTransparent(temp.GetPixel(1, 1)) ' pixel(1,1) is part of the transparent area
        Return temp
End Function

I say that it 'almost' works because the square background of the displayed image is, indeed, transparent, except for a very thin green 'halo' round the clock. I typically use bright green as the guide color for image areas that I am going to make transparent, so I initially thought that the feathering at the edges of the clock had caused this, and changed the color for the transparent area to a dark gray (similar to the background color on my desktop), so that there was no green anywhere in the image (or in its color palette). Notwithstanding this change, the green halo persists. This is how the Panel appears on the desktop, and this is the source image.
Does anyone have any idea what is going on?

Dave Kreskowiak6-Aug-21 5:02

6-Aug-21 5:02

Yeah, it's aliasing. The "green" halo isn't green. At least, it's not the green of your transparency green.

In order to get rid of the green, you have to get rid of the antialiasing while drawing the clock image. On your Graphics object, set the SmoothingMode = None.

Your clock image will end up with "jaggies" all around it, but you won't get the halo any more.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

Peter R. Fletcher6-Aug-21 5:49

6-Aug-21 5:49

Thanks for your response, which makes sense. I have, however, now tried setting the SmoothingMode to None in the Panel's overridden OnPaint Event without changing the (mis)behavior. I assume that the aliasing is occurring earlier, probably when the image (a .png file included and passed as a Resource item) is read in and converted to its internal Bitmap format, and I don't see how I can influence that step.

Dave Kreskowiak6-Aug-21 6:16

6-Aug-21 6:16

It could also be in the image itself if it was created with antialiasing turned on.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

Peter R. Fletcher6-Aug-21 6:31

6-Aug-21 6:31

Yes. Looking at the image at a very high zoom, I do now see that it is antialiased. However, the 'smoothing' is all grayscale, which would not be a problem if it carried over to the final displayed image. It is the green false color introduced by the Panel's rendering of it that is the major issue. I will see if I can 'un-antialias' the original image, but that may introduce different, but equally unsightly, problems.

Peter R. Fletcher6-Aug-21 8:27

6-Aug-21 8:27

Since writing my last message, I 'un-antialiased' the source image and tried again. Even though there are only three colors of pixels in the new source image (pure black, pure white, and the very dark gray used for the area to be rendered as transparent), the panel appears exactly the same when displayed on the desktop - with the thin green 'halo' round the clock. The new source image can be found here. It really does look as if the false color aliasing is happening when the image is created/initialized.

modified 6-Aug-21 16:06pm.

Dave Kreskowiak6-Aug-21 13:25

6-Aug-21 13:25

I did something similar, though not transparent, a couple decades ago.

Instead of using an image like that, I just drew the entire clock face when needed.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

Peter R. Fletcher7-Aug-21 3:45

7-Aug-21 3:45

Since the clock face is invariant, it seemed to me to make sense to use a static image. My other experiments, described in the other 'branch' of this thread, would also suggest that your approach would not solve the haloing problem with transparency.

Dave Kreskowiak7-Aug-21 5:14

7-Aug-21 5:14

I think no matter what color you pick for the chroma key, you're going to have the same problem. It comes down to the key color you pick isn't the resulting key color when the black of the clock face and the key color are blended together. I don't think there's going to be any solution to the problem while using a chroma key.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

Peter R. Fletcher7-Aug-21 9:10

7-Aug-21 9:10

I am not sure what you mean by 'chroma key' in this context. The placeholder 'color' I am using for the transparent area is a very dark gray - the entire palette of the image is grayscale. If you blend black, white, and a pure grey in any proportions, you shouldn't get bright green!

Dave Kreskowiak7-Aug-21 9:40

7-Aug-21 9:40

The "chroma key" is the color chosen to be replaced by "transparent", or "green screen".

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.

Dave Kreskowiak

Peter R. Fletcher7-Aug-21 9:59

7-Aug-21 9:59

That's what I thought you meant, hence my comment that blending white, black, and gray shouldn't give you green!

Gerry Schmitz6-Aug-21 6:52

Gerry Schmitz

6-Aug-21 6:52

PixelFormat.Format32bppRgb

With black and white you can get by with 8 bits.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

Peter R. Fletcher6-Aug-21 8:14

6-Aug-21 8:14

Yes. I was reusing old code which allowed color images. I wasn't the original author, so I didn't change anything that I didn't think absolutely had to be changed, and I wasn't sure whether any of the other reused code implicitly assumed the specified format. Indeed, experimentation since you raised the issue showed that using other formats (including indexed and grayscale ones) does cause other problems.

Gerry Schmitz6-Aug-21 8:46

Gerry Schmitz

6-Aug-21 8:46

In general, Windows (10) recommends against bit maps because they don't scale well. Use (font) icons and vector graphics. Segoe UI MDL2 assets can be overlayed, reversed and rotated. The .NET shape classess provide circles, polygons, etc.

In your case, I would try overlaying the outter problem area with an ellipse / circle (black stroke, transparent fill) for a quick fix.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

Peter R. Fletcher6-Aug-21 10:01

6-Aug-21 10:01

Well, that was very interesting! Doing as you suggested does not solve the problem. If you use a sensible sized pen (fairly small), nothing visible happens, and the 'halo' looks just as before, though there is a suggestion of it disappearing at the points where the drawn circle overlaps the edges of the original image (the top, bottom, and two sides). If you use a thicker pen, it is more obvious that the 'halo' is gone at the overlapped edges, but it is just pushed out to the edge of the drawn circle over the rest of the rendered image - it still always appears where a 'transparent' pixel was adjacent to one of another color, whether that pixel was part of the original bitmap or subsequently drawn on the Graphic. Presumably, therefore, it is an artefact of the [Bitmap].MakeTransparent() Function, but I have no idea why it has not (as far as I can tell) been described before
Parenthetically, I now see that that function forces the Bitmap on which it is invoked to 32bppRgb mode, since that format has the alpha channel which it needs, so any attempt to use a different format would be pointless.