.NET Core Image Processing

#1

Post by jamessouth » Fri, Jan 20, 2017, 7:44 AM UTC

.NET Core Image Processing
blogs.msdn.microsoft.com

Re: .NET Core Image Processing

#2

Post by jsingleton » Fri, Jan 20, 2017, 8:08 AM UTC

Nice post. Looks like I'll need to update the compatibility list: https://github.com/jpsingleton/ANCLAFS#image-manipulation

NB: You shouldn't use System.Drawing in a web app. It can lead to memory leaks and lots of pain. Even the newer WPF equivalents are not safe for use on a web server.

Re: .NET Core Image Processing

#3

Post by skrebbel » Fri, Jan 20, 2017, 8:27 AM UTC

This 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 that if you were cropping an image server-side in C# code on a Linux server, a C-rewrite of a Windows UI layer would kick in and do the work for you. Amazing work from the Mono team, because it worked, but also pretty nuts.

If there's one place I remember having stuff that "just worked" on Windows and had weird subtle quirks on Mono, it's image processing (I'm talking a few years ago). So IMO it's pretty awesome that they're replacing all that legacy with a decent 100% .NET image processing library.

(Sidenote: this was also the only real problem we faced developing a C# backend with a team on Windows, Linux and OSX computers, and running it all on Mono on Docker on Linux - all well before .NET Core. Mono really is/was that good)

Re: .NET Core Image Processing

#4

Post by ygra » Fri, Jan 20, 2017, 8:39 AM UTC

skrebbel wrote: post #3

This 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.

Re: .NET Core Image Processing

#5

Post by romanovcode » Fri, Jan 20, 2017, 8:55 AM UTC

Offtopic:

I am the only one who absolutely hates charts like [0]these? Like what are those numbers on top, why it has no legend? Is it CPU utilization, miliseconds, seconds (maybe it was done over 1000 images or so)?

[0] - https://msdnshared.blob.core.windows.net/media/2017/01/Resiz...

Re: .NET Core Image Processing

#6

Post by skun » Fri, Jan 20, 2017, 8:56 AM UTC

jsingleton wrote: post #2

Nice post. Looks like I'll need to update the compatibility list: https://github.com/jpsingleton/ANCLAFS#image-manipulation NB: You shouldn't use System.Drawing in a web app. It can lead to memory leaks and lots of pain. Even the newer WPF equivalents are not safe for use on a web server.

[OT] I didn't know about this repo. Its so amazing! Thanks so much for maintaining it :)

Re: .NET Core Image Processing

#7

Post by jsingleton » Fri, Jan 20, 2017, 9:42 AM UTC

skun wrote: post #6

jsingleton wrote: post #2

Nice post. Looks like I'll need to update the compatibility list: https://github.com/jpsingleton/ANCLAFS#image-manipulation NB: You shouldn't use System.Drawing in a web app. It can lead to memory leaks and lots of pain. Even the newer WPF equivalents are not safe for use on a web server.

[OT] I didn't know about this repo. Its so amazing! Thanks so much for maintaining it :)

You're welcome. I'm glad it's useful. It's a community effort so feel free to submit a PR or an issue.

P.S. There used to be a separate website but since GH broke how pages work the domain now just redirects to the repo.

Re: .NET Core Image Processing

#8

Post by morrbo » Fri, Jan 20, 2017, 10:04 AM UTC

Great to know, and good article. Can't help but feel that the author should have put in the full compressed images so we can view them. From the table at the bottom, Skia looks like it has quality issues, but it is kind of hard to say without seeing the full-sized compressed images. The uncompressed ones are on github, unless i've missed something, the compressed ones aren't.

Re: .NET Core Image Processing

#9

Post by endorphone » Fri, Jan 20, 2017, 11:21 AM UTC

romanovcode wrote: post #5

Offtopic: I am the only one who absolutely hates charts like [0]these? Like what are those numbers on top, why it has no legend? Is it CPU utilization, miliseconds, seconds (maybe it was done over 1000 images or so)? [0] - https://msdnshared.blob.core.windows.net/media/2017/01/Resiz...

In this case does it matter though? The purpose of the chart is relative performance, which it conveys minus a legend. Though I would agree that if they aren't including the legend, they should remove the axis and standard range labels entirely.

Re: .NET Core Image Processing

#10

Post by koyote » Fri, Jan 20, 2017, 11:41 AM UTC

jsingleton wrote: post #2

Nice post. Looks like I'll need to update the compatibility list: https://github.com/jpsingleton/ANCLAFS#image-manipulation NB: You shouldn't use System.Drawing in a web app. It can lead to memory leaks and lots of pain. Even the newer WPF equivalents are not safe for use on a web server.

What would you recommend instead of System.Drawing in a web app?

Any of the ones listed in the article?