How to push a critical fix in Dicom.Native

151 views
Skip to first unread message

Hesham Desouky

unread,
Feb 19, 2015, 6:55:47 AM2/19/15
to fo-d...@googlegroups.com
Hello All,

I fixed a critical issue in Dicom.Native where the JPEG coded was facing a severe crash when it is used to Encode many DICOM images inside a long running process (PACS service)

The issue was in the PinnedByteArray was not Disposed after Encoding the images.

Disposing the PinnedByteArray after encoding process solved the memory related exception which cause corruption of the process memory address space.

It was not wise to depend on GC to dispose this class through finalizers since it uses GCHandle class which may result in the process goes out of Handles in certain situations.

I pushed this change in my Repository but I am not sure where to do pull request?

Hesham

TheWilliamSkipper

unread,
Feb 19, 2015, 9:50:05 AM2/19/15
to fo-d...@googlegroups.com
Does that mean that you have solved the memory access violation bug when proccessing large CR or MG images?

hash...@sigmalogic.com.au

unread,
Feb 20, 2015, 10:27:25 PM2/20/15
to fo-d...@googlegroups.com
I am also interested in this fix maybe you can post the file here for now?

I am hoping this will fix the following code crashing on large datasets.

Object imageLock = new Object();
            try
            {
                lock (imageLock)
                {
                    var dicomImage = new Dicom.Imaging.DicomImage(DicomFilePath);
                    System.Drawing.Image jpgFile = dicomImage.RenderImage();
 
                    jpgFile.Save(DicomFilePath.Replace(".dcm", ".jpg"), jpegImageCodecInfo, jpegEncoderParameters);
                }
            }
            catch (Exception e)
            { 
                Console.WriteLine("Exception: " + e.Message);
                Console.WriteLine("Stack trace: " + e.StackTrace);
            }


Chris Horn

unread,
Feb 21, 2015, 5:02:55 AM2/21/15
to fo-d...@googlegroups.com
Good work Hesham, I'll grab a copy of your fork and have a play

Hesham Desouky

unread,
Feb 22, 2015, 3:10:22 AM2/22/15
to fo-d...@googlegroups.com
We were facing access violation  System.AccessViolationException inside jpeg12_write_scanlines. This exception was occurring when randomly specially when the process runs for long time (windows service).

The added fix will dispose the created PinnedByteArray object the end of the Encode Method.

I don't know if the above will fix your issue or not. It depends on your work conditions.

TheWilliamSkipper

unread,
Feb 23, 2015, 4:35:53 AM2/23/15
to fo-d...@googlegroups.com
Yes, I have same bug, when decompressing large CR images, 12MP and more. I'll test it ASAP.

TheWilliamSkipper

unread,
Feb 23, 2015, 7:21:44 AM2/23/15
to fo-d...@googlegroups.com
Nope, it didn't fixed it for me. It still happens randomly when decompressing large JPEG Lossless CR images.

hash...@sigmalogic.com.au

unread,
Feb 23, 2015, 11:55:37 AM2/23/15
to fo-d...@googlegroups.com
My issues was nothing to do with the library. i fixed it using the best answer in

TheWilliamSkipper

unread,
Feb 24, 2015, 2:11:06 AM2/24/15
to fo-d...@googlegroups.com
I also had similar issue, but I compiled it for x64 and that worked for me.

Hesham Desouky

unread,
Feb 24, 2015, 12:52:40 PM2/24/15
to fo-d...@googlegroups.com
There is another fix for the decoding I will push tomorrow after finishing testing it. testing is going well tell now :)

Hesham Desouky

unread,
Feb 25, 2015, 7:38:51 AM2/25/15
to fo-d...@googlegroups.com
I pushed the update regarding the decode.

I am using VS2013 so the native DLLs will require VC2013 run time library (here).

Also I attached the updated DLLs to this post.

+TheWilliam Skipper: please let me know if this fixed your issue or not.

TheWilliamSkipper

unread,
Feb 26, 2015, 7:43:37 AM2/26/15
to fo-d...@googlegroups.com
It works!

I have pushed my code to decompress 20-30 large CR studies, and usually it breaks after 5-10 images, but now it is super stable. It fixed my issue!

Hesham Desouky

unread,
Mar 1, 2015, 4:01:01 PM3/1/15
to fo-d...@googlegroups.com
this is great news :)
Reply all
Reply to author
Forward
0 new messages