简体   繁体   中英

C# Threaded image processing

                    for (int x = 0; x < blockCountX; x++)
                    {
                        for (int y = 0; y < blockCountY; y++)
                        {
                            //get blocks from image to new image and send to threaded processor
                            imageBlocks[x, y] = image.Clone(clipRectangle, System.Drawing.Imaging.PixelFormat.Format8bppIndexed);
                            System.Threading.Thread t = new System.Threading.Thread(new System.Threading.ParameterizedThreadStart(ThreadedFromHeightMap));
                            t.Start(imageBlocks[x,y]);
                            clipRectangle.Offset(0, IMAGEBLOCKSIZE);
                        }
                        clipRectangle.Offset(IMAGEBLOCKSIZE, clipRectangle.Location.Y * -1);
                    }
                    break;
            }
        }
        private void ThreadedFromHeightMap(object Image)
        {
            Bitmap image = (Bitmap)Image;
            int width = image.Width;
            int height = image.Height;

            for (int x = 0; x < width; x++)
            {
                for (int y = 0; y < height; y++)
                {
                    map.Hexes.Add(new Point(x, y), new Hex(image.GetPixel(x, y).B));
                    //tempHexes.Enqueue(new Hex(image.GetPixel(x, y).B));
                }
            }
        }

I'm trying to take pixel data from a 2048 x 2048 8bpp grayscale heightmap and building a hex map with corresponding height values. I'm storing the hexes in a Dictionary collection. All told there's ~4 million hexes in the collection.

To do this efficiently I'm breaking the image up into 256 x 256 chunks and passing that image to another thread which will parse it and add the hexes to the collection. This is were it all goes haywire. Instead of one image with (0,0) as its top left corner, I now have 64 image chunks that have (0,0) as their top left corner. However I'm using the pixel location as an index for the dictionary. This crashes when the second thread tries to add another value with index (0,0).

How do I mitigate this problem? I've thought about building a class that just has an image member and a chunk number member and pass that to the thread so I can adjust the pixel location depending on what chunk the thread is working on but that seems less than optimal.

(I realize the Dictionary I'm using isn't thread safe. I've since fixed that.)

May I recommend a few things?

  1. Forget about image.GetPixel(), which is horribly slow; work directly with the bitmap data, and the performance of your algorithm will improve by so much, that you will not need to run parallel threads to improve its efficiency. See MSDN: http://msdn.microsoft.com/en-us/library/system.drawing.imaging.bitmapdata.aspx

  2. If you insist on parallel threads, make use of the threadpool, instead of spawning 64 threads. (See MSDN: http://msdn.microsoft.com/en-us/library/3dasc8as(v=vs.80).aspx )

  3. If you insist on spawning many threads, do NOT spawn more threads than the cores of your CPU. I do not suppose you have 64 cores on your machine, do you?

  4. If you insist on spawning many threads, you will, of course, need to pass the location of each tile to the thread, so that you know exactly where that tile should be placed when you reconstruct the big picture. That's not less than optimal, it is necessary.

Why do you believe that breaking up the large image into smaller chunks will be more efficient? Is the large image too large to fit into system memory? 4million pixels x 8bpp (1 byte per pixel) = 4 megabytes. This was a lot of memory 20 years ago. Today it's chump change.

Creating multiple 256x256 sub-images will require copying the pixel data into new images in memory, plus the image header/descriptor overhead for each new image, plus alignment padding per scanline. You will more than double your memory use, which can create performance problems (virtual swapping) itself.

You are also spinning up a new thread for each image block. Allocating a thread is very expensive, and may take more time than the work you want the thread to do. Consider at least using ThreadPool.QueueUserWorkItem to make use of already available system worker threads. Using .NET 4.0's Task class would be even better, IMO.

Forget .GetPixel(). It's a thousand times slower than pixel memory access.

If you want to distribute processing the image pixels across multiple CPU cores, consider processing each scanline or group of scanlines to a different task or worker thread.

  1. I think, encapsulating chunk location among image data in a class is not that bad. I can't see any other option.
  2. As an optimization, you can grab pixel pointer from image.Scan0 if you don't have any restriction about unsafe operations.
  3. Creating a fresh image for each block is not a very clever idea. Pass region of interest to the thread.
  4. If you can use .NET Framework 4, use Parallel.ForEach for such usages. If you can't use it, you can use thread pools. I guess your computer does not have (2048 x 2048) / (256 x 256) = 64 core CPU.
  5. Updating global hex map after a thread termination may improve performance dramatically. Due to Dictionary is not thread-safe, locking global hex map inner loop within a thread is not good idea.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM