Хотя мой ответ приходит ужасно поздно, я надеюсь, что это будет полезно для других людей.
Учитывая ограничения C#, которые ОП определил до сих пор, приведен список критериев, которые по-прежнему дают ограниченную свободу программисту в отношении форматов пикселей.
- Гибкая растровый ручка класса C#, который поддерживает различные форматы пикселей, не будучи в C# универсальный класс
- Так как общий класс в языке С # не был бы дает никаких преимуществ пользователю обработки изображений ,
- Некоторые безопасности гарантия - некоторые характеристики объекта ручки растровый должны быть неизменны
- В частности, размеры формата пикселей и пиксельные растрового изображения не должно быть позволено изменить после создания. Чтобы изменить их, необходимо создать новый объект.
- Обеспечивает как изменяемый интерфейс (позволяет изменение значений пикселей) и неизменное интерфейс объектной модели
- Для того, чтобы обеспечить индикацию на любой функции API, что не должно быть никакой попытки записать к конкретному растрового аргумента.
- Набор классов алгоритмов обработки изображений, которые принимают и возвращают класс дескриптора битмапа.
- Каждый алгоритм пытается изо всех сил обрабатывать различные типы пиксельных форматов, насколько это экономически целесообразно.
С критериями в виду, я бы рекомендовал использовать System.Windows.Media.Imaging в качестве субстрата библиотеки вы строите.
Пространство имен System.Windows.Media.Imaging представляет собой экземпляр C# для библиотеки Microsoft Windows Imaging Component (WIC). Поэтому базовая обработка реализована на языке C++, что дает ей скорость, необходимую для практического использования.
Благодаря широкому диапазону поддержки формата пикселей, реализованному в WIC, C# -компонент также поддерживает тот же range of pixel formats.
WIC (и System.Windows.Media.Imaging) не обеспечивает широкие возможности обработки изображения (ничего подобного из Канни обнаружения края, преобразование Хафа, обнаружение объекта и т.д.)
Тем не менее, с точки зрения использования интерфейса обмена битовыми объектами в памяти (для интеграции различных библиотек изображений с интерфейсами или связями C#) подходят как System.Windows.Media.Imaging.WriteableBitmap, так и System.Drawing.Bitmap.
С точкой зрения реализации алгоритмов, иногда трудно сделать алгоритмы в равной степени применимы к одноканальным изображениям и изображениям многоканальным. Для этого требуются годы, если не десятилетия исследований в многомерной математике.
Таким образом, он является общим для классов алгоритмов обработки изображений, чтобы сосредоточиться на поддержку узкого подмножества пиксельных форматов:
- 1bpp Черной Белом (для логического/решения растровых изображений, например, краевой карты или подключенного членства компонента блобы)
- 8bpp Серый
- 24bpp BGR
- 32bpp BGRA
- 32bpp Серый Поплавок
- 96bp р BGR Float
- 128bpp BGRA Поплавок
Если класс алгоритм видит входной дескриптор точечного рисунка, который не один из указанных выше типов, было бы попробовать все возможное, чтобы без потерь «продвигать» формат ввода в один из выше форматов.
С этим автоматическим повышающим преобразованием в виде, пользователь этого алгоритма класса теряет строгий контроль над форматом пикселя выходного растрового изображения, но получает гарантию того, что внешнего вида выходной будет осуществляться в соответствии с ожиданием.
Я не уверен, что вы имеете в виду, но мы должны иметь дело с большим количеством различных форматов изображений в нашем проекте, и мы просто делаем это, используя управляемую инфраструктуру расширяемости. – TimothyP
MEF классный, но я не уверен, что он обращается к тому, что я говорю. Можете ли вы взглянуть на GIL? http://www.boost.org/doc/libs/1_39_0/libs/gil/doc/index.html. Это буквально позволяет писать один алгоритм для записи в любом формате изображения. Создайте итератор, который может перечислять каждый пиксель независимо от количества каналов или глубины бита или даже если каналы были выложены в чередующемся или планарном порядке.Это и многое другое сделано в GIL, но на близких ручных закодированных скоростях из-за шаблонов. – Charles
Я предполагаю, что яснее: скажем, у меня есть алгоритм вычисления гистограммы. Я не хочу писать отдельный для оттенков серого, 565 RGB, 24 RGB, 32 RGB, RGBA, ARGB, BGRA, ABGR или даже других цветовых пространств, таких как CYMK и HSL. Благодаря магии программного обеспечения эти различия должны быть абстрагированы, поэтому разработчику алгоритма обработки изображений нужно написать только один алгоритм, который будет работать во всех форматах. – Charles