StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Can you link to somewhere people have said that GDI+ shouldn't be used on the server? Maybe they know something I don't.</p> <p>I know a few things about how GDI+ works but nothing about ImageMagick. I did happen upon this page describing ImageMagick's architecture: <a href="http://www.imagemagick.org/script/architecture.php" rel="nofollow">http://www.imagemagick.org/script/architecture.php</a></p> <p>It seems ImageMagick will internally convert images to an uncompressed format with 4 channels and a specific bit depth, typically 16 bits per channel, and do its work with the uncompressed data, which may be in memory or on disk depending on the size. 'identify -version' will tell you what your bit depth is. My impression is that in practice ImageMagick will typically work with a 64-bit RGBA buffer internally, unless you use a Q8 version which will use 32-bit RGBA. It also can use multiple threads, but I doubt that will matter unless you're working with very large images. (If you are working with very large images, ImageMagick is the clear winner.)</p> <p>GDI+ Bitmap objects will always store uncompressed data in memory and will generally default to 32-bit RGBA. That and 32-bit RGB are probably the most efficient formats. GDI+ is a drawing library, and it wasn't designed for large images, but at least a Bitmap object won't hold any resources other than the memory for the pixel data and image metadata (contrary to popular belief, they do not contain HBITMAP objects).</p> <p>So they seem very similar to me. I can't say one is clearly better than the other for your use case. If you go with imagemagick, you should probably use a Q8 build for the speed and memory gains, unless the extra precision is important to you.</p> <p>It seems like if your only operations are load, save, scale, and crop, you should be able to easily replace the implementation later if you want.</p> <p>Unless you need to work with metafiles, you should probably be using Bitmap objects internally and not Images. Then you wouldn't have to create an intermediate Bitmap object in your Crop function. That intermediate object may be behind some of the extra memory consumption you observed. If you get Image objects from an external source, I'd suggest trying to cast them to Bitmap and creating a new Bitmap if that doesn't work.</p> <p>Also, the "using" statement calls Dispose automatically, so there's no need to also call it explicitly.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload