Library Inter-op extensions

[tocsoft]

ImageSharp should provide an initial standard structure for adding library inter-op apis.

• ImageSharp <=> System.Drawing interop
  ** Simple API the allows for converting System.Drawing.Image into an ImageSharp.Image<TPixel>.
  ** Simple API the allows for converting an ImageSharp.Image<TPixel> into a System.Drawing.Image .
  ** Simple API for creating an Image<TPixel> that wraps the memory used by a System.Drawing.Image
• ImageSharp <=> Xamarin IOS CoreImage
  ** Simple API the allows for converting UIImage into an ImageSharp.Image<TPixel>.
  ** Simple API the allows for converting an ImageSharp.Image<TPixel> into a UIImage .
  ** Simple API the allows for converting CIImage into an ImageSharp.Image<TPixel>.
  ** Simple API the allows for converting an ImageSharp.Image<TPixel> into a CIImage .
  ** Simple API for creating an Image<TPixel> that wraps the memory used by the various image types (if possible)
• ImageSharp <=> SkiaSharp
  ** as above for the various skiasharp constructs
• ImageSharp <=> UWP
• ImageSharp <=> WPF

Maybe we just need to provide a System.Drawing version (as a new package SixLabors.ImageSharp.InterOp.SystemDrawing) but would then allow third party developers to be able to follow common patterns to allow them

[vpenades]

Microsoft has recently released System.Drawing.Common , which is a cross platform and NetStandard compatible package of the classic NetFX exclusive System.Drawing.Bitmap namespace.

So maybe it's worth to take into account too... but, as @saucecontrol commented here ... maybe not.

[saucecontrol]

The sad thing is, the majority of devs will continue using System.Drawing because that's what they know. And a large percentage of them will take a Microsoft-authored package over literally anything else. One could at least hope that easy integration and a couple of unique features would tempt some devs to dip a toe in the ImageSharp waters. Maybe then they'll see the light :)

[vpenades]

@tocsoft There's much more image interops than just these, and imho, some critical ones that are worth of attention;

• DirectX, OpenGL and Vulkan textures.
• GPU Computing: OpenCL, OpenCV, Cuda, etc
• UWP has its own device image format called Windows.Graphics.Imaging.SoftwareBitmap, that is typically used along with System.Windows.Media.Capture namespace. To make things worse, the whole System.Windows.Media.Capture uses, extensively, the Windows.Storage.Streams.IBuffer which is a half baked analogue of Span exclusive of UWP.
• I haven't checked in depth, but I can pressume the RealSense imaging acquisition library https://github.com/IntelRealSense/librealsense also uses some low level form of image format optimized for high frequency image acquisition.
• Pretty much the same goes for https://orbbec3d.com/ imaging aquisition devices.

[JimBobSquarePants]

We're only writing these to help migration. I think it's up to individual library providers to create interop solutions. DirectX, OpenGL and Vulkan textures are going to be included in gaming engines and will be specific to their API's.

Veldrid for example has managed it without us having to write a line of code.

[hansmbakker]

It would be very helpful if this was provided out of the box like SkiaSharp does:
https://github.com/mono/SkiaSharp/blob/master/source/SkiaSharp.Views/SkiaSharp.Views.UWP/UWPExtensions.cs