views:

195

answers:

4

I've tried to parallelize the resizing of jpegs using .Net. All my tries failed, because the Graphics.DrawImage-func seems to lock while active. Try the following snipped:

Sub Main()
    Dim files As String() = IO.Directory.GetFiles("D:\TEMP")
    Dim imgs(25) As Image
    For i As Integer = 0 To 25
      imgs(i) = Image.FromFile(files(i))
    Next

    Console.WriteLine("Ready to proceed ")
    Console.ReadLine()

    pRuns = 1
    For i As Integer = 0 To 25
      Threading.Interlocked.Increment(pRuns)
      Threading.ThreadPool.QueueUserWorkItem(New Threading.WaitCallback(AddressOf LongTerm), imgs(i))
    Next
    Threading.Interlocked.Decrement(pRuns)

    pSema.WaitOne()
    Console.WriteLine("Fin")
    Console.ReadLine()
  End Sub

  Sub LongTerm(ByVal state As Object)
    Dim newImageHeight As Integer
    Dim oldImage As Image = CType(state, Image)
    Dim newImage As Image
    Dim graph As Graphics
    Dim rect As Rectangle
    Dim stream As New IO.MemoryStream

    Try
      newImageHeight = Convert.ToInt32(850 * oldImage.Height / oldImage.Width)
      newImage = New Bitmap(850, newImageHeight, oldImage.PixelFormat)
      graph = Graphics.FromImage(newImage)
      rect = New Rectangle(0, 0, 850, newImageHeight)

      With graph
        .CompositingQuality = Drawing2D.CompositingQuality.HighQuality
        .SmoothingMode = Drawing2D.SmoothingMode.HighQuality
        .InterpolationMode = Drawing2D.InterpolationMode.HighQualityBicubic
      End With

      'Save image to memory stream
      graph.DrawImage(oldImage, rect)
      newImage.Save(stream, Imaging.ImageFormat.Jpeg)
    Catch ex As Exception

    Finally
      If graph IsNot Nothing Then
        graph.Dispose()
      End If
      If newImage IsNot Nothing Then
        newImage.Dispose()
      End If
      oldImage.Dispose()
      stream.Dispose()

      Console.WriteLine("JobDone {0} {1}", pRuns, Threading.Thread.CurrentThread.ManagedThreadId)
      Threading.Interlocked.Decrement(pRuns)
      If pRuns = 0 Then
        pSema.Set()
      End If
    End Try

  End Sub

All threads wait at graph.DrawImage(). Is there a way to speed up code performance using other functions? Is it impossible to use Graphics.Draw with multiple threads? In the real application multiple images should be resized at the same time (on a quad-core pc), not always the same. The posted code is only for testing purposes...

Thanks in advance

Edit: Updated the code according to comments

+2  A: 

I am not sure why execution of Graphics.DrawImage seems to serialize for you, but I actually noticed a race condition with your general pattern of queuing the work items. The race is between the WaitOne and the Set. It is possible for the first work item to Set before any of the others have even been queued yet. That will cause WaitOne to return immediately before all work items have completed.

The solution is to treat the main thread as if it were a work item. Increment pRuns once before queueing begins and then decrement and signal the wait handle after queueing is complete just as you would in a normal work item. However, the better approach is to use the CountdownEvent class if that is available to you as it simplifies the code. As luck would have it I just recently posted the pattern in another question.

Brian Gideon
I'm unable to use CountdownEvent-class. But (if main thread sleeps long enought) it could be possible, that the if statement in work function is never true, couldn't it? Do you have an idea how to fix that problem?
PTa
@PTa: No, you increment `pRuns` before the loop and then decrement it after the loop...before calling `WaitOne`. All of the `Increment` and `Decrement` calls should balance. Somebody will eventually decrement it to 0. It might be a work item or it might be the main thread. You actually have most of it correct already.
Brian Gideon
Sorry - I had an error in reasoning! :)
PTa
@Brian: Yes, nice catch. @Pta: and the Decrement should be in a Finally block
Henk Holterman
+3  A: 

If you don't mind a WPF approach, here is something to try. The following is a simple rescale method that accepts image streams and produces a byte[] containing the resulting JPEG data. Since you do not want to actually draw the images with GDI+, I thought this was suitable for you despite being WPF-based. (The only requirement is to reference WindowsBase and PresentationCore in your project.)

Advantages include faster encoding (by 200-300% on my machine) and better parallel speedup, although I also see some unwanted serialization in the WPF rendering path. Let me know how this works for you. I'm sure it could be optimized further if necessary.

The code:

 byte[] ResizeImage(Stream source)
 {
    BitmapFrame frame = BitmapFrame.Create(source, BitmapCreateOptions.IgnoreColorProfile, BitmapCacheOption.None);
    var newWidth = frame.PixelWidth >> 1;
    var newHeight = frame.PixelHeight >> 1;
    var rect = new Rect(new System.Windows.Size(newWidth, newHeight));
    var drawingVisual = new DrawingVisual();
    using (var drawingContext = drawingVisual.RenderOpen())
        drawingContext.DrawImage(frame, rect);
    var resizedImage = new RenderTargetBitmap(newWidth, newHeight, 96.0, 96.0, PixelFormats.Default);
    resizedImage.Render(drawingVisual);
    frame = BitmapFrame.Create(resizedImage);

    using (var ms = new MemoryStream())
    {
        var encoder = new JpegBitmapEncoder();
        encoder.Frames.Add(frame);
        encoder.Save(ms);
        return ms.ToArray();
    }
 }
Alan
+5  A: 

Use Processes.

GDI+ blocks per process a lot of ways. Yep, a pain, but there's no way around it. Fortunately with tasks like this one (and any one that processes files on the filesystem), it's too easy to just split the workload up between multiple processes. Fortunately it looks like GDI+ is using locks, not mutex, so it is concurrent!

We have some graphics programs where I work to do image processing. One programmer starts 6-7 copies at once of a conversion program, in production. So it is not messy, trust me. Hack? You're not getting paid to look pretty. Get the job done!

Cheap Example (note this will NOT work in the ide, build it and run the EXE):

Imports System.Drawing
Module Module1
    Dim CPUs As Integer = Environment.ProcessorCount

    Dim pRuns As New System.Collections.Generic.List(Of Process)

    Sub Main()
        Dim ts As Date = Now
        Try
            If Environment.GetCommandLineArgs.Length > 1 Then
                LongTerm(Environment.GetCommandLineArgs(1))
                Exit Sub
            End If

            Dim i As Integer = 0
            Dim files As String() = IO.Directory.GetFiles("D:\TEMP", "*.jpg")
            Dim MAX As Integer = Math.Min(26, files.Count)
            While pRuns.Count > 0 Or i < MAX

                System.Threading.Thread.Sleep(100)

                If pRuns.Count < CInt(CPUs * 1.5) And i < MAX Then ''// x2 = assume I/O has low CPU load
                    Console.WriteLine("Starting process pRuns.count = " & pRuns.Count & " for " & files(i) & " path " & _
                                        Environment.GetCommandLineArgs(0))
                    Dim p As Process = Process.Start(Environment.GetCommandLineArgs(0), """" & files(i) & """")
                    pRuns.Add(p)
                    i += 1
                End If

                Dim i2 As Integer
                i2 = 0
                While i2 < pRuns.Count
                    If pRuns(i2).HasExited Then
                        pRuns.RemoveAt(i2)
                    End If
                    i2 += 1
                End While


            End While
        Catch ex As Exception
            Console.WriteLine("Blew up." & ex.ToString)
        End Try
        Console.WriteLine("Done, press enter. " & Now.Subtract(ts).TotalMilliseconds)
        Console.ReadLine()
    End Sub


    Sub LongTerm(ByVal file As String)
        Try
            Dim newImageHeight As Integer
            Dim oldImage As Image
            Console.WriteLine("Reading " & CStr(file))
            oldImage = Image.FromFile(CStr(file))
            Dim rect As Rectangle

            newImageHeight = Convert.ToInt32(850 * oldImage.Height / oldImage.Width)
            Using newImage As New Bitmap(850, newImageHeight, oldImage.PixelFormat)
                Using graph As Graphics = Graphics.FromImage(newImage)
                    rect = New Rectangle(0, 0, 850, newImageHeight)

                    With graph
                        .CompositingQuality = Drawing2D.CompositingQuality.HighQuality
                        .SmoothingMode = Drawing2D.SmoothingMode.HighQuality
                        .InterpolationMode = Drawing2D.InterpolationMode.HighQualityBicubic
                    End With

                    Console.WriteLine("Converting " & CStr(file))
                    graph.DrawImage(oldImage, rect)

                    Console.WriteLine("Saving " & CStr(file))
                    newImage.Save("d:\temp\Resized\" & _
                                  IO.Path.GetFileNameWithoutExtension(CStr(file)) & ".JPG", _
                                   System.Drawing.Imaging.ImageFormat.Jpeg)
                End Using
            End Using
        Catch ex As Exception
            Console.WriteLine("Blew up on  " & CStr(file) & vbCrLf & ex.ToString)
            Console.WriteLine("Press enter")
            Console.ReadLine()
        End Try
    End Sub

End Module
FastAl
I'll second this advice. Sooner or later, with multi-threading in-process GDI operations, you'll run into deadlocks or completely random failures. After escalating one example to Microsoft PSS, they acknowledged corruption of the stack/heap due to some race conditions, but no real solution. Stick with out-of-process conversions if you want to parallelize (or use a third party solution that is thread safe)!
Kevin Pullin
Shouldn't you be `Dispose`ing of the processes when done with them?
notJim
A: 

Use a image-processing library other than GDI+.

We use ImageMagick at a pretty high-volume web site it resize uploaded images (the uploaded images are usually 10-40 MPixels but to be able to work with them in the website (in Flash modules), we resize them to have smallest size 1500 pixels). Processing is pretty fast and gives excellent results.

We currently start a new ImageMagick process using the command-line interface. This gives some overhead when starting new processes, but since the images are so large it is usually a pretty small time slice of the total resizing process. It is also possible to use ImageMagick in-process but have haven't tried that yet since it 1. we do not need the extra performance it gives and 2. it feels good to run third-party software in other processes.

When using ImageMagick, you also get a number of other possibilities like better filtering and lots of other functions.

Andreas Paulsson