Hacker News new | ask | show | jobs
by kodfodrasz 3444 days ago
My experience with any ImageMagick and derivateives is terrible. Obscure install is needed, app is not portable (which is normally a great default feature of .Net apps), or building it is difficult. Also its security track (of the native parts) is very bad, so i strongly discourage anybody using those libraries.

On the other hand ImageSharp is convinient, and the author is a nice helpful, responsive guy. I totally suggest using his library. When I needed it once for mono, though then it did not meet my needs, Mr. South was really helpful. Eventually I had to stick to manually wrapping libgd, but I'm about to revisit that code and change it to use a new ImageSharp version! (Also the fluent APIs make working with images using that lib pretty awesome!)

2 comments

Magiic.net works fine but it occludes the real API so you might struggle to do certain things
The real api is a bit of brainfuck to me. I'm not sure what psychedelic the creators of ImageMagick were on, or maybe they thought it is kinda funny, but for me the GetMagicWand call was also a single sign that I don't want to use that.

So what I mean by this: in my opinion occluding the real API is probably a feature of Magiic.net. Still I do not like if a library needs systemwide install and config files, etc, as ImageMagick/GraphicsMagic does. Maybe the creators of these libs have solved the portability problems created by this, but I'm disgusted by these native libraries, and I avoid them. (Back then the one wrapper I tried needed a systemwide install of imagemagick. A click through wizard needing administrative rights, instead of dropping a dll into the PATH or the program directory... Also it has config files. Config files.. for a library. IMHO this is insane! It is a good approach to configure apps by config files. Libraries should be configured by API calls, or build time constants.)

Having custom build scripts for 3rdparty code is a huge work to keep up to date which will always lag behind, thus the security will also lag behind. On the other hand this is needed to solve the portability issues of the native parts. I find this approach unproductive, but wish the maintainers the best.

Definitely do please give it a try!