This project has moved. For the latest updates, please go here.

Execution speed slower in 7.0.0.0006Q16x86 than 6.8.901Q16x86

Oct 28, 2014 at 5:08 PM
I've created some code and with the 6.8.0 .dll it completes in approximately 1 second. Changing to the 7.0.0 .dll it takes approximately 1.5 seconds to complete the same operation (which I think I have narrowed down to the ToByteArray() method).

I've only done a cursory search, so I apologize if this has already been documented, but does anyone have insight in to why this might be?

FWIW I'm actually loading the assembly in to LabVIEW and calling it from there. I don't see this being terribly relevant, however, as the only change I am making is the assembly version.

Also, on a side note, how does execution speed with this .net assembly compare to the C .dll? Ultimately I'm likely going to be writing this in C or C# and the language choice is largely dependent upon execution speed.
Coordinator
Oct 28, 2014 at 7:03 PM
Edited Oct 28, 2014 at 7:32 PM
I need a bit more information before I can tell you what could be causing this. What is the exact version of the 6.X series you are using? And would you mind sharing the code and a sample image you are using so I can try to reproduce this?

I have no idea how much extra the overhead of using a .NET library is. I think it is safe to assume that using the C library will increase the performance but it have no idea if that will be milliseconds or nanoseconds. It might not be worth it because you will have to be doing your own memory management.
Oct 28, 2014 at 7:53 PM
Edited Oct 28, 2014 at 7:54 PM
Sorry, version are 6.8.8.901 Q16x86 vs. 7.0.0.0006Q16x86

I need to find a host for the image of my code, but I believe it would be as follows in pseudocode:
reference = MagickImage();
reference.BitDepth(All,16);
reference.ToBitmap(Tiff);
Height=reference.height();
Width=reference.width();
ColorType=reference.ColorType();
ByteArray=reference.ToByteArray()

//parse ByteArray in to something useful to me
The only only thing I change is the .NET assembly version, as mentioned above. No changes are made to the code.

Also, if it makes a difference I'm using a 10-bit TIFF as the input file.
Coordinator
Oct 28, 2014 at 8:25 PM
Edited Oct 28, 2014 at 8:26 PM
Feel free to contact me through CodePlex to get my e-mail and send it by e-mial. I use dropbox to share images.

Are you aware that 'reference.ToBitmap(Tiff);' creates a Bitmap and that you should do something with the return value? And why do you create a bitmap and use ToByteArray?
Oct 28, 2014 at 8:41 PM
The reference.ToBitmap does confuse me a bit. I started in one direction (converting to a bitmap and parsing the bitmap pixel by pixel), but execution speed was (predictably) horrendous.

I then went the bytearray route in parallel and was able to manually parse it that way with good result. When I went back and deleted the bitmap code it suddenly stopped parsing correctly. It turns out that for some reason when I make the call reference.ToBitmap(Tiff) it changes the output of reference.ToByteArray(). If I change it to a different argument (jpg for example), the ByteArray parses completely differently. So, I just make the call and throw away the resulting bitmap.

I'll ping you and get you my code. Thanks for all the help.
Coordinator
Oct 28, 2014 at 9:03 PM
What are you doing with the output created by the ToByteArray method? If you only need the pixels you might be better of calling reference.ToByteArray() with MagickFormat.Rgb or MagickFormat.Rgba as an argument. You can control the pixel order by setting the Interlace property before you call ToByteArray. You don't need the call to ToBitmap anymore if you specify the format as an argument for the ToByteArray method.
Oct 29, 2014 at 12:47 PM
Calling ToByteArray with Tiff as the argument seems to have eliminated the need for the ToBitmap method. This required upgrading to 7.0 rather than using the previous version, though the reduced number of operations seems to increase speed sufficiently to merit the conversion.

I considered calling it as Rgb or Rgba as you suggest, however it's not a given that I will be using RGB; I also need to provision for monochrome. Is there benefit to manually setting the interlace order and then using a Rgb or Mono as the format versus just using the tiff format?

Sorry if I'm showing my ignorance here, but I appreciate whatever help you can offer.
Coordinator
Oct 29, 2014 at 2:02 PM
What are you planning to do with the result from ToByteArray if the image is Monochrome instead of RGB. Will you be calling a different 'method'?

Using MagickFormat.RGB will increase the performance because only pixel data is written to the byte array. If you use MagickFormat.Tiff extra metadata has to be written and this is probably more difficult to parse.
Oct 29, 2014 at 2:06 PM
Yeah, the image I sent you isn't clear but there's another case of the image processing structure to process the monochrome images. I think I may actually be parsing wrong and just getting lucky because I'm ignoring that metadata. I'll rewrite it to use mono or RGB as appropriate before sending it to a byte array.

I really appreciate your help.