Question

Here is the test i wrote and that will currently fail:

var unusableColor = Color.FromArgb(13, 19, 20, 19);
var retrievedColor = Color.Empty;
var tempFile = Path.GetTempFileName();

using (var bitmap = new Bitmap(1, 1))
{
    bitmap.SetPixel(0, 0, unusableColor);
    bitmap.Save(tempFile, ImageFormat.Png);
}

using (var image = Image.FromFile(tempFile))
// This will lead to the error
using (var bitmap = new Bitmap(image))
// But this will work
//using (var bitmap = (Bitmap)image)
{
    retrievedColor = bitmap.GetPixel(0, 0);
}

Assert.That(retrievedColor, Is.SameAs(unusableColor));

If you take a look into the retrievedColor you’ll find that it will be the same as Color.FromArgb(13, 19, 19, 19). So the difference will be that the green part has changed from 20 to 19.

Any idea why this happens or under which circumstances the constructor of the Bitmap will change a pixel?

Update

Seems to be a deeper nested problem. By replacing the Bitmap constructor by a simple cast of the image variable the problem goes away. This maybe solves the problem, but it doesn’t explain it. Further more i was able to reproduce the problem even in Paint.Net by the following procedure:

• Open Paint.Net and create a new image (size doesn’t matter)
• Select all (Ctrl+A)
• Remove the selection (Del)
• Open the color dialog (F8)
• Enter the above values for RGB (19, 20, 19) and at the bottom the transparency (13).
• Select the fill tool (F)
• Fill the color into the empty image
• Select the color selection tool (K)
• Click somewhere into your fresh image and watch the color dialog

So it seems it is maybe a deeper problem, not caused by the Bitmap or Image class but maybe by some deeper functionality like GDI+ or something similar.

Update 2

I just wrote a new test to find out all affected colors:

for (int a = 0; a < 256; a++)
{
    for (int r = 0; r < 256; r++)
    {
        for (int g = 0; g < 256; g++)
        {
            for (int b = 0; b < 256; b++)
            {
                using (var bitmap = new Bitmap(1, 1))
                {
                    var desiredColor = Color.FromArgb(a, r, g, b);
                    bitmap.SetPixel(0, 0, desiredColor);

                    // This will fail in a lot of colors with a low alpha channel value
                    using (var copiedBitmap = new Bitmap(bitmap))
                    // This will work, cause the information is entirely copied.
                    //using (var copiedBitmap = (Bitmap)bitmap.Clone())
                    {
                        var retrievedColor = copiedBitmap.GetPixel(0, 0);

                        if (desiredColor != retrievedColor)
                        {
                            Debug.Print(desiredColor + " != " + retrievedColor);
                        }
                    }
                }
            }
        }
    }

Please don’t let it run completely on itself, cause it will take a loonng time to finish and it also finds a looots of differences. But what you can see, if you play around with the transparency (setting to 1 or 10) then you’ll see that the RGB values use this as some kind of bit depth.

So the problem occurs if you create a new Bitmap from an existing one that uses low transparency values. The real root cause seems to be far down in GDI, Kernel or somewhere in this area and can’t be solved from .Net.

Simply be aware that a color can change by calling the bitmap constructor if the color has a low transparency value. If you really need the original colors to stay alive in a second instance instead use (Bitmap)myBitmap.Clone() or if you load it from disk use (Bitmap)Image.FromFile(filename) cause Image is only an abstract class which will normally instantiated through the Bitmap class.

Answer 1

I checked PNG file saved with your code using Paint.NET and pixel color is exactly unusableColor.
If you change your reading code with this:

using (Bitmap bitmap = (Bitmap)Image.FromFile(tempFile))
{
    retrievedColor = bitmap.GetPixel(0, 0);
}

everything works