Parallel.For statement return "System.InvalidOperationException" with a Bitmap Processing

Question

Well, I have a code to apply a Rain Bow filter in "x" image, I have to do in two ways: Sequential & parallel, my sequential code is working without problems, but the parallel section doesn't work. And I have no idea, why?.

Code

public static Bitmap RainbowFilterParallel(Bitmap bmp)
    {

        Bitmap temp = new Bitmap(bmp.Width, bmp.Height);
        int raz = bmp.Height / 4;

        Parallel.For(0, bmp.Width, i =>
        {
            Parallel.For(0, bmp.Height, x =>
            {

                if (i < (raz))
                {
                    temp.SetPixel(i, x, Color.FromArgb(bmp.GetPixel(i, x).R / 5, bmp.GetPixel(i, x).G, bmp.GetPixel(i, x).B));
                }
                else if (i < (raz * 2))
                {
                    temp.SetPixel(i, x, Color.FromArgb(bmp.GetPixel(i, x).R, bmp.GetPixel(i, x).G / 5, bmp.GetPixel(i, x).B));
                }
                else if (i < (raz * 3))
                {
                    temp.SetPixel(i, x, Color.FromArgb(bmp.GetPixel(i, x).R, bmp.GetPixel(i, x).G, bmp.GetPixel(i, x).B / 5));
                }
                else if (i < (raz * 4))
                {
                    temp.SetPixel(i, x, Color.FromArgb(bmp.GetPixel(i, x).R / 5, bmp.GetPixel(i, x).G, bmp.GetPixel(i, x).B / 5));
                }
                else
                {
                    temp.SetPixel(i, x, Color.FromArgb(bmp.GetPixel(i, x).R / 5, bmp.GetPixel(i, x).G / 5, bmp.GetPixel(i, x).B / 5));
                }

            });

        });
        return temp;
    }

Besides, In a moments the program return the same error but says "The object is already in use".

PS. I'm beginner with c#, and I Searched this topic in another post and I found nothing.

Thank you very much in advance

Answer 1

While not strictly relevant I wanted to post a better faster version than any of the one's that I see given in the answers. This is the fastest way I know of to iterate through a bitmap and save the results in C#. In my work we need to go through millions of large images, this is just me grabbing the red channel and saving it for my own purposes but it should give you the idea of how to work

//Parallel Unsafe, Corrected Channel, Corrected Standard div 5x faster
     private void TakeApart_Much_Faster(Bitmap processedBitmap)
    {
        
        _RedMin = byte.MaxValue;
        _RedMax = byte.MinValue;
        _arr = new byte[BMP.Width, BMP.Height];
        long Sum = 0,
        SumSq = 0;
        BitmapData bitmapData = processedBitmap.LockBits(new Rectangle(0, 0, processedBitmap.Width, processedBitmap.Height), ImageLockMode.ReadWrite, PixelFormat.Format24bppRgb);
//this is a much more useful datastructure than the array but it's slower to fill.
        points = new ConcurrentDictionary<Point, byte>();
        unsafe
        {
       int bytesPerPixel = Image.GetPixelFormatSize(bitmapData.PixelFormat) / 8;
            int heightInPixels = bitmapData.Height;
            int widthInBytes = bitmapData.Width * bytesPerPixel;
            _RedMin = byte.MaxValue;
            _RedMax = byte.MinValue;
            byte* PtrFirstPixel = (byte*)bitmapData.Scan0;
            Parallel.For(0, heightInPixels, y =>
            {
    //pointer to the first pixel so we don't lose track of where we are
         byte* currentLine = PtrFirstPixel + (y * bitmapData.Stride);
         for (int x = 0; x < widthInBytes; x = x + bytesPerPixel)
                {
                    //0+2 is red channel
                    byte redPixel = currentLine[x + 2];
                    Interlocked.Add(ref Sum, redPixel);
                    Interlocked.Add(ref SumSq, redPixel * redPixel);
          //divide by three since we are skipping ahead 3 at a time.
                 _arr[x/3, y] = redPixel;
                 _RedMin = redPixel < _RedMin ? _RedMin : redPixel;
                 _RedMax = redPixel > RedMax ? RedMax : redPixel;
                }
            });
         

            _RedMean = Sum / TotalPixels;
_RedStDev = Math.Sqrt((SumSq / TotalPixels) - (_RedMean * _RedMean));
            processedBitmap.UnlockBits(bitmapData);
        }
    }

Answer 2

Parallel is hard on the singular mind. And mixing it with legacy GDI+ code can lead to strange results..

Your code has numerous issues:

• You call GetPixel three times per pixel instead of once
• You are accessing the pixels not horizontally as you should
• You call y x and x i; the machine won't mind but us people do
• You are using way too much parallelization. No use to have much more of it than you have cores. It creates overhead that is bound to eat up any gains, unless your inner loop has a really hard job to do, like millions of calculations..

But the exception you get has nothing to do with these issues. And one mistake you don't make is to access the same pixel in parallel... So why the crash?

After cleaning up the code I found that the error in the stack trace pointed to SetPixel and there to System.Drawing.Image.get_Width(). The former is obvious, the latter not part of our code..!?

So I dug into the source code at referencesource.microsoft.com and found this:

    /// <include file='doc\Bitmap.uex' path='docs/doc[@for="Bitmap.SetPixel"]/*' />
    /// <devdoc>
    ///    <para>
    ///       Sets the color of the specified pixel in this <see cref='System.Drawing.Bitmap'/> .
    ///    </para>
    /// </devdoc>
    public void SetPixel(int x, int y, Color color) {
        if ((PixelFormat & PixelFormat.Indexed) != 0) {
            throw new InvalidOperationException(SR.GetString(SR.GdiplusCannotSetPixelFromIndexedPixelFormat));
        }

        if (x < 0 || x >= Width) {
            throw new ArgumentOutOfRangeException("x", SR.GetString(SR.ValidRangeX));
        }

        if (y < 0 || y >= Height) {
            throw new ArgumentOutOfRangeException("y", SR.GetString(SR.ValidRangeY));
        }

        int status = SafeNativeMethods.Gdip.GdipBitmapSetPixel(new HandleRef(this, nativeImage), x, y, color.ToArgb());

        if (status != SafeNativeMethods.Gdip.Ok)
            throw SafeNativeMethods.Gdip.StatusException(status);
    }

The real work is done by SafeNativeMethods.Gdip.GdipBitmapSetPixel but before that the method does a bounds check on the Bitmap's Width and Height. And while these in our case of course never change the system still won't allow accessing them in parallel and hence crashes when at some point the checks are happening interwoven. Totally uncesessary, of course, but there you go..

So GetPixel (which has the same behaviour) and SetPixel can't safely be used in a parallel processing.

Two ways out of it:

We can add locks to the code and thus make sure the checks won't happen at the 'same' time:

public static Bitmap RainbowFilterParallel(Bitmap bmp)
{
    Bitmap temp = new Bitmap(bmp);
    int raz = bmp.Height / 4;
    int height = bmp.Height;
    int width = bmp.Width;
    // set a limit to parallesim
    int maxCore = 7;
    int blockH = height / maxCore + 1;

    //lock (temp) 

    Parallel.For(0, maxCore, cor =>
    {

        //Parallel.For(0, bmp.Height, x =>
        for (int yb = 0; yb < blockH; yb++)
        {
            int i = cor * blockH + yb;
            if (i >= height) continue;
            for (int x = 0; x < width; x++)
            {
                {
                  Color c;
                  // lock the Bitmap just for the GetPixel: 
                  lock (temp) c  = temp.GetPixel(x, i);
                  byte R = c.R;
                  byte G = c.G;
                  byte B = c.B;
                  if (i < (raz)) { R = (byte)(c.R / 5); }
                  else if (i < raz + raz) { G = (byte)(c.G / 5); }
                  else if (i < raz * 3) { B = (byte)(c.B / 5); }
                  else if (i < raz * 4) { R = (byte)(c.R / 5); B = (byte)(c.B / 5); }
                  else { G = (byte)(c.G / 5); R = (byte)(c.R / 5); }
                  // lock the Bitmap just for the SetPixel:
                  lock (temp) temp.SetPixel(x, i, Color.FromArgb(R,G,B));
                };
            }

        };

    });
    return temp;
}

Note that limiting parallism is so important there is even a member in the ParallelOptions class and a parameter inParallel.For to control it! I have set the maximum core numer to 7, but this would be better:

int degreeOfParallelism = Environment.ProcessorCount - 1;

So this should save us some overhead. But still: I'd expect that to be slower than a corrected sequential method!

Instead going for a LockBits as Peter and Ron have suggested method makes things really fast (1ox) and adding parallelism potentially even faster still..

So finally to finish up this length answer, here is a Lockbits plus Limited-Parallel solution:

public static Bitmap RainbowFilterParallelLockbits(Bitmap bmp)
{
    Bitmap temp = null;
    temp = new Bitmap(bmp);
    int raz = bmp.Height / 4;
    int height = bmp.Height;
    int width = bmp.Width;
    Rectangle rect = new Rectangle(Point.Empty, bmp.Size);

    BitmapData bmpData = temp.LockBits(rect,ImageLockMode.ReadOnly, temp.PixelFormat);
    int bpp = (temp.PixelFormat == PixelFormat.Format32bppArgb) ? 4 : 3;
    int size = bmpData.Stride * bmpData.Height;
    byte[] data = new byte[size];
    System.Runtime.InteropServices.Marshal.Copy(bmpData.Scan0, data, 0, size);

     var options = new ParallelOptions();
     int maxCore = Environment.ProcessorCount - 1;
     options.MaxDegreeOfParallelism = maxCore > 0 ? maxCore  : 1;

    Parallel.For(0, height, options, y =>
    {
        for (int x = 0; x < width; x++)
        {
            {
              int index = y * bmpData.Stride + x * bpp;

              if (y < (raz))   data[index + 2] = (byte) (data[index + 2] / 5);
              else if (y < (raz * 2))  data[index + 1] = (byte)(data[index + 1] / 5);
              else if (y < (raz * 3)) data[index ] = (byte)(data[index ] / 5);
              else if (y < (raz * 4))
                {   data[index + 2] = (byte)(data[index + 2] / 5); 
                    data[index] = (byte)(data[index] / 5); }
              else
              {   data[index + 2] = (byte)(data[index + 2] / 5);
                  data[index + 1] = (byte)(data[index + 1] / 5);
                  data[index] = (byte)(data[index] / 5);  }
          };
        };

    });
    System.Runtime.InteropServices.Marshal.Copy(data, 0, bmpData.Scan0, data.Length);
    temp.UnlockBits(bmpData);
    return temp;
}

Answer 3

As commenter Ron Beyer points out, using the SetPixel() and GetPixel() methods is very slow. Each call to one of those methods involves a lot of overhead in the transition between your managed code down to the actual binary buffer that the Bitmap object represents. There are a lot of layers there, and the video driver typically gets involved which requires transitions between user and kernel level execution.

But besides being slow, these methods also make the object "busy", and so if an attempt to use the bitmap (including calling one of those methods) is made between the time one of those methods is called and when it returns (i.e. while the call is in progress), an error occurs with the exception you saw.

Since the only way that parallelizing your current code would be helpful is if these method calls could occur concurrently, and since they simply cannot, this approach isn't going to work.

On the other hand, using the LockBits() method is not only guaranteed to work, there's a very good chance that you will find the performance is so much better using LockBits() that you don't even need to parallelize the algorithm. But should you decide you do, because of the way LockBits() works — you gain access to a raw buffer of bytes that represents the bitmap image — you can easily parallelize the algorithm and take advantage of multiple CPU cores (if present).

Note that when using LockBits() you will be working with the Bitmap object at a level that you might not be accustomed to. If you are not already knowledgeable with how bitmaps really work "under the hood", you will have to familiarize yourself with the way that bitmaps are actually stored in memory. This includes understanding what the different pixel formats mean, how to interpret and modify pixels for a given format, and how a bitmap is laid out in memory (e.g. the order of rows, which can vary depending on the bitmap, as well as the "stride" of the bitmap).

These things are not terribly hard to learn, but it will require patience. It is well worth the effort though, if performance is your goal.