Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Core Image Processing

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: .NET Core Image Processing

#61

Post by jamessouth »

redcalx wrote: post #38
jamessouth wrote: post #11

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.

Cool. I'm assuming you do a lot of matrix operations, so I'm wondering if you've come across the Matrix type in Math.Net?; It has plug-in 'providers' for concrete implementations, and there are providers that are backed by Intel MKL, OpenBLAS, ATLAS, CUDA, etc. If you don't register a provider you just get plain .NET code running serially (though it may user Vector in future versions). See: https://github.com/mathnet…

Thanks. Didn't know about that library. We do a lot of matrix operations but have so far found System.Numerics.Vectors covers our immediate use cases.

Re: .NET Core Image Processing

#62

Post by keithnz »

gthtjtkt wrote: post #39

What are the best resources for someone who wants to move from .NET desktop development to .NET web development? All the popular sites like Udacity and FreeCodeBootcamp rarely (if ever) touch the MS stack. I know this isn't exactly the right place to ask, but I've had no luck anywhere else...

You need to be specific. Most people doing web on .NET probablly use .NET Asp.NET MVC... I've used it a lot, and it's ok. But there are alternatives. For instance using F# and https://suave.io/ Which I think is really nice.

Re: .NET Core Image Processing

#63

Post by jamessouth »

jsingleton wrote: post #33
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…

This makes sense as System.Drawing (aka GDI+) was mainly used for WinForms and has never been supported for web servers. I suspect Mono ported it to support their Windows Forms port. It may just work on Windows but it won't keep working when used server-side in a web app. MS specifically recommend against using it in ASP.NET. I learned the hard way what happens if you ignore the warnings when I was supporting a site…

I may have to buy that!

Re: .NET Core Image Processing

#64

Post by simooooo »

kodfodrasz wrote: post #12

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 su…

Magiic.net works fine but it occludes the real API so you might struggle to do certain things

Re: .NET Core Image Processing

#65

Post by kodfodrasz »

simooooo wrote: post #64
kodfodrasz wrote: post #12

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 su…

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.

Re: .NET Core Image Processing

#66

Post by redcalx »

jamessouth wrote: post #61
redcalx wrote: post #38

Earlier quoted context omitted.

Cool. I'm assuming you do a lot of matrix operations, so I'm wondering if you've come across the Matrix type in Math.Net?; It has plug-in 'providers' for concrete implementations, and there are providers that are backed by Intel MKL, OpenBLAS, ATLAS, CUDA, etc. If you don't register a provider you just get plain .NET code running serially (though it may user Vector in future versions). See: https://github.com/mathnet…

Thanks. Didn't know about that library. We do a lot of matrix operations but have so far found System.Numerics.Vectors covers our immediate use cases.

I found that matrix multiplication of dense matrices using MKL was about 60x faster than 'plain' C# code (on a recent core i7 CPU). The Vector class will get you only some of that gain - mainly because MKL uses the FMA CPU instruction (fused multiply and add) that is designed specifically for matrix multiplication, + lots of other optimisations that Intel can make that the .NET jitter can't/won't.

Re: .NET Core Image Processing

#67

Post by pjmlp »

gthtjtkt wrote: post #39

What are the best resources for someone who wants to move from .NET desktop development to .NET web development? All the popular sites like Udacity and FreeCodeBootcamp rarely (if ever) touch the MS stack. I know this isn't exactly the right place to ask, but I've had no luck anywhere else...

Pluralsight is the best training site for MS related technologies, it is how they started, before embracing other stacks.

Re: .NET Core Image Processing

#68

Post by jamessouth »

redcalx wrote: post #66
jamessouth wrote: post #61

Earlier quoted context omitted.

Thanks. Didn't know about that library. We do a lot of matrix operations but have so far found System.Numerics.Vectors covers our immediate use cases.

I found that matrix multiplication of dense matrices using MKL was about 60x faster than 'plain' C# code (on a recent core i7 CPU). The Vector class will get you only some of that gain - mainly because MKL uses the FMA CPU instruction (fused multiply and add) that is designed specifically for matrix multiplication, + lots of other optimisations that Intel can make that the .NET jitter can't/won't.

That's some improvement. Will definitely have a proper look.

Re: .NET Core Image Processing

#69

Post by bleroy »

wolfspider wrote: post #47
bleroy wrote: post #46

Earlier quoted context omitted.

Because it's not Skia that is tested, but SkiaSharp, which is a .NET / Mono wrapper for Skia. It was included because the work to make it compatible with .NET Core is close to completion and because it's promising work. I hope this clarifies. If there were Pixman/Cairo .NET Core wrappers in existence or close to completion, I'd be happy to update the post with them.

https://github.com/zwcloud/CairoSharp

Thanks, I'll check it out.

Re: .NET Core Image Processing

#70

Post by bleroy »

jononor wrote: post #54

5-10 megapixels input images might be more representative, as many phones produce such sizes.

It doesn't make a difference in the relative performance of the libraries on the metrics in the post, it only makes the benchmarks slower to run. This being said, the code is available, so this is easy for anyone to check. If I ever get to do a memory benchmark, that would probably be a different story, however.
Post reply on HN