Great to see the positive comments here. ImageSharp is my baby and it fills me with a lot of confidence that it's something that developers both want and need.
.NET Core Image Processing
11–20 of 70 posts
Re: .NET Core Image Processing
#12My 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!)
Re: .NET Core Image Processing
#13This might sound like a small thing but the .NET image processing stuff has traditionally depended a lot on Windows builtins. Mono shipped an entire mediocre rewrite of GDI (the graphics layer that's been Windows since the early nineties) just to support the .NET Framework image processing stuff. Note: not for image display (which is what GDI is mainly for) - even for headless image processing. In practice this meant…
Mono shipped a reimplementation of the types in the System.Drawing namespace which uses GDI+ (note the +) on Windows. This reimplementation is also what CoreCompat.System.Drawing is based on. To my knowledge Mono did shim a few Windows APIs, mostly related to window messages so WndProc can be overridden in a useful manner, but not actually GDI, as far as I know.
And the implementation was buggy as hell. When I needed to resize pictures on mono + Linux I finally had to resort to manually building libgb, writing a simple wrapper for the resizing part, and use that, as back then every other alternative as either incomplete, or pain to use and/or buggy.
Note: libgd is a well designed native library with design emphasis on simple interop wrappability.
Re: .NET Core Image Processing
#14If you need something right now, consider imagemagick or graphicsmagick.
Re: .NET Core Image Processing
#15My 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 su…
Definitely do please give it a try!
Re: .NET Core Image Processing
#16Amazed this is trending. If anyone has any interest in image processing of performance in general please get in touch and give me a hand. Any help will be appreciated.
Re: .NET Core Image Processing
#17This seems like a really great use case for dotnetcore. I can see it being perfect for an image manipulation microservice.
Re: .NET Core Image Processing
#18Is it a pipe dream to hope they go for DirectX in dotnetcore one day?
I'm so happy to read that they've gotten the image processing piece in place.
A while ago, on a bit of a lark and to see if I could, I started trying to port a copy of selenium webdriver to DNC and was initially surprised bow how successful I was in getting it to compile and build.
For the most part it was just re-pointing namespaces to their new locations.
When I got to the piece about image processing I hit a wall.
Maybe I'll take that on again sometime.
Re: .NET Core Image Processing
#19Is it a pipe dream to hope they go for DirectX in dotnetcore one day? I'm so happy to read that they've gotten the image processing piece in place. A while ago, on a bit of a lark and to see if I could, I started trying to port a copy of selenium webdriver to DNC and was initially surprised bow how successful I was in getting it to compile and build. For the most part it was just re-pointing namespaces to their new l…
>Is it a pipe dream to hope they go for DirectX in dotnetcore one day?
What do you mean ? DX is Windows specific, .NET core is cross platform. And DX doesn't even have official .NET bindings on full .NET AFAIK.
OTOH I'm sure SharpDX and the likes could be ported (if it already isn't - this : https://github.com/sharpdx/SharpDX/issues/520 suggest it should work but I haven't tried it)
Re: .NET Core Image Processing
#20I have a ton of code that relies on System.Drawing so I've been watching this closely. These are projects that go back over 10 years now. I have code in both web server and client side versions. System.Drawing offers some features that other image processing libraries don't. My use case probably isn't typical but when you are trying to go back and forth from vector to raster data you need access to the point data (along with manipulation) that is going to be drawn. System.Drawing provides this flexibility through the GraphicsPath object. It is good to see some official word on this though.