This project has moved and is read-only. For the latest updates, please go here.

Scaling large images

Jan 13, 2014 at 8:28 AM
Edited Jan 13, 2014 at 8:28 AM
I try to use library to scale large grayscale psd images (about 10k pixels). Hovever, it takes a lot of time to scale. I tried to use Scale() and Sample() but it takes about 20 minutes to 400% scale 5000x5000 image. Is there any way to improve speed of processing?
Jan 13, 2014 at 9:57 AM
Edited Jan 13, 2014 at 11:10 AM
Would you mind sharing your image so I can run some tests with it? If you don't want to share your image publicly feel free to contact me through CodePlex.

20 minutes to scale an image sounds way too long. It might be possible that ImageMagick decides to use disk cache. You could try to change the cache threshold:
I will change this method in a property the next release so you can see the current threshold. And I might also change it from bytes into megabytes.
Jan 13, 2014 at 11:29 AM
Thank you for answer.
I'm using folowwing code:
using (var img = new MagickImage(@"D:\sample.psd"))
    img.ColorType = ColorType.Grayscale;
    img.IsMonochrome = true;
    img.Scale(img.Width * 4, img.Height * 4);
For sample file application creates 2 temp files with size of 580 Mb and 9.2 Gb and it takes 824 seconds to proceed image. Application doesn't utilize memory but uses disk a lot.
Jan 13, 2014 at 11:32 AM
Also tried to do the same with imagemagick command line tool, took about 10 seconds and utilized cpu (13%) and memory(1.8 Gb).
Jan 13, 2014 at 12:03 PM
I can reproduce this, I will look into it later today.
Jan 13, 2014 at 12:18 PM
Thank you.
Jan 13, 2014 at 4:26 PM
Edited Jan 13, 2014 at 6:50 PM
What is the amount of memory in your system? And are you using the x86 or x64 version of Magick.NET / convert.exe ? Do you still see a temp file being created with the command line?
Jan 13, 2014 at 5:27 PM
I have 8 Gb of memory and using x86 version. No, command line tool doesn't create temp files, but application based on library creates huge temp files.
Jan 13, 2014 at 7:28 PM
I just realized why this doesn't work. Magick.NET is build with HDRI support which means each channel uses 4 bytes. For each pixel this will be a total of 16 bytes (RGBA). This will be changed in ImageMagick 7, only 1 channel will be used for a grayscale image.

Your output image has a size of 31200x15152. That is a total of 7563878400 bytes, which is 7gb. In a 32 bit application the maximum about of memory that can be addressed is 2gb and that is why Magick.NET is using your hard disk to store the pixel data.

Did you run your test with the command line with the option: -define registry:temporary-path=d:\?

If possible I would advice you to switch to the x64 version of Magick.NET, this will allow you to address more memory.
Jan 13, 2014 at 9:27 PM
I get it.
Is there any way to improve performance of application, except switching to x64 version, which, I assume, won't help much? Maybe using gcAllowVeryLargeObjects?
Performance in my case is quite critical.
Jan 13, 2014 at 10:14 PM
Edited Jan 13, 2014 at 10:15 PM
Switching to the x64 can improve the performance as long as your image still fits in your computer his memory. Your performance will degrade dramatically once disk cache has to be used. With the x86 version this will happen with an image uses more than 2gb of memory. Your convert.exe is probably build without HDRI enabled which cuts the amount of memory in half. And with a Q8 non HDRI version you will even use half of that. The current Q8 build of Magick.NET also has HDRI enabled but maybe I should disable HDRI for that build. Instead of 16 bytes per pixel it will then only use 4 bytes. But then your channel will only have a range of 0-255. Would that be enough for you?

Setting gcAllowVeryLargeObjects will not help because the ImageMagick code is unmanaged.
Jan 14, 2014 at 2:42 AM
Yes, switching from 16 to 4 bpp would be great and pixel range 0-255 is exactly what I need. How can I obtain this version?
Jan 14, 2014 at 7:43 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.