通用图像处理库的 C# 设计指南
在任何图像处理库中，始终存在必须为每种图像格式（色彩空间、通道、位深度、内存布局等）提供每种算法的实现的问题。 Boost GIL 是解决该问题的一种非常优雅的解决方案。通过 C++ 的强大功能和出色的设计，所有这些问题都被抽象出来，您可以编写适用于任何类型图像的单一算法。
我想在 C# 中创建类似的东西，但是缺少许多必要的构造，例如模板和某些运算符重载（例如一元 *）。我愿意接受我所创造的东西不会像 GIL 那样健壮和优雅，但我想尽可能地对这些概念进行建模。最终，目标是抽象图像差异并编写通用处理算法。
有了 C# 中可用的功能、泛型、lambda，甚至动态 IL /cringe，人们认为设计库的一些可能方法是什么？
In any image processing library there is always the issue of having to provide an implementation of every single algorithm for every single image format (color space, channels, bit depth, mem layout, etc). One very elegant solution to the problem is Boost GIL. Through the power of C++, and a great design, all of these issues are abstracted away and you can write a single algorithm that will work on any type of image.
I wanted to create something similar in C#, but many of the necessary constructs such as templates and certain operator overloads (like unary *) are missing. I'm willing to accept that what I can create will not be nearly as robust and elegant as GIL, but to the extent possible I would like to model the concepts. Ultimately, abstracting image differences and writing generic processing algorithms would be the aim.
With what there is available in C#, generics, lambdas, even dynamic IL /cringe, what do people think some possible approaches would be to designing the library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否见过 Aforge.NET，它的设计方式非常通用。
该库的作者通过接口解决了您正在谈论的很多问题。在我的脑海中，诸如 IFilter、IFilterColourToAny 等之类的东西
要在 .NET 中进行高效的图像处理，您需要使用 Bitmap.LockData（我认为）进入不安全的代码，这可能会否定您所有很酷的 .NET 东西。正在谈论...
Have you seen Aforge.NET, the way that's designed is pretty generic.
The author of that library solved a lot of the problems you are talking about through interfaces. Off the top of my head stuff like, IFilter, IFilterColourToAny etc
To do efficient image processing in .NET you'll need to go into unsafe code using Bitmap.LockData (I think), which could negate all the cool .NET stuff you're talking about...
虽然我的回答来得很晚，但我希望它对其他人有用。
考虑到 OP 迄今为止已确定的 C# 的局限性，这里列出了一些标准，但这些标准仍然为程序员在像素格式方面提供了有限的自由。
考虑到这些标准，我建议使用 System.Windows.Media.Imaging 作为您正在构建的库的基础。
System.Windows.Media.Imaging命名空间是 Microsoft Windows 成像组件 (WIC) 库。因此，底层处理是用原生C++实现的，使其具有实际使用所需的速度。由于 WIC 中实现了广泛的像素格式支持，C# 对应项也支持相同的 像素格式范围。
WIC（和 System.Windows.Media.Imaging）不提供任何高级图像处理功能（任何 Canny 边缘检测、霍夫变换、对象检测等）。
但是，就内存位图而言对象交换接口（用于将不同的图像库与 C# 接口或绑定集成），两者都
System.Windows.Media.Imaging.WriteableBitmap和System.Drawing.Bitmap是合适的。在实现算法方面，有时很难使算法同样适用于单通道图像和多通道图像。这需要数年甚至数十年的多元数学研究。
因此，图像处理算法类通常侧重于支持像素格式的狭窄子集：
如果算法类发现输入位图句柄不是上述类型之一，它将尽力无损地将输入格式“提升”为上述格式之一。
考虑到这种自动上转换，该算法类的用户失去了对输出位图像素格式的严格控制，但获得了输出视觉外观符合预期的保证。
Though my answer comes awfully late, I hope it will be useful for other people.
Given the limitations of C# that the OP has identified so far, here is a list of criteria that would still give limited freedom to the programmer in terms of pixel formats.
With the criteria in mind, I would recommend using System.Windows.Media.Imaging as the substrate of the library you are building.
The
System.Windows.Media.Imagingnamespace is the C# counterpart to the Microsoft Windows Imaging Component (WIC) library. Therefore, the underlying processing is implemented in native C++, giving it the speed needed for practical use.Thanks to the wide range of pixel format support implemented in WIC, the C# counterpart also supports the same range of pixel formats.
The WIC (and System.Windows.Media.Imaging) does not provide any advanced image processing capability (nothing of the sort of Canny edge detection, Hough transform, object detection, etc.)
However, in terms of being an in-memory bitmap object interchange interface (for integrating different image libraries with C# interfaces or bindings), both
System.Windows.Media.Imaging.WriteableBitmapandSystem.Drawing.Bitmapare suitable.In terms of implementing algorithms, it is sometimes difficult to make algorithms equally applicable to single-channel images and multi-channel images. Such requires years if not decades of research in multivariate mathematics.
Thus, it is common for image processing algorithm classes to focus on supporting a narrow subset of pixel formats:
If an algorithm class sees an input bitmap handle that is not one of the above type, it would try its best to losslessly "promote" the input format into one of the above formats.
With this automatic up-conversion in mind, the user of this algorithm class loses strict control on the output bitmap's pixel format, but gains the guarantee that the output's visual appearance will be in accordance with expectation.