Предлагаю добавить библиотеку, содержащую классы для работы с изображениями в разных цветовых пространствах (RGB, LAB, XYZ). Сделать её совместимой с GraphABC, GraphWPF. Иногда необходимо использование цветовых пространств, отличных от RGB. Думаю, она может стать полезной для серьёзных проектов.
Для серьезных проектов есть opencv…
А еще можно взять любой проект отсюда, подключить скомпилированные сборки к проекту, и жить счастливо. По поводу OpenCV - вот.
GraphABC несовместим с серьезными проектами в силу отсутствия поддержки аппаратного ускорения на GPU.
А речь идёт именно о обработке изображений (от переложения цвета до нейросетей). Там аппаратное ускорение не обязательно.
Совместимость с GraphWPF тоже можно сделать. Сейчас есть некоторые наработки, совместимые с System.Drawing.Color и, соответственно, GraphABC.
Идея хорошая, но делать надо не тяп ляп. Ориентируйтесь не на GraphABC, а на максимальную оптимизацию(особенно раз вы заговорили про нейросети). Для GraphABC можно в конце костыль прикрутить, ибо он всё равно с оптимизацией не очень совместим.
Собственно я разрабатываю библиотеку с собственными классами. Прямой связи с GraphABC там и нет. Для ввода-вывода используется System.Drawing.Color, являющийся предком GraphABC.Color, и System.Drawing.Bitmap. Но обработка происходит именно в классах библиотеки. Если надо-могу скинуть то, что готово на данный момент.
Синонимом а не предком*
А потеря производительности в GraphABC как раз из за битмапов в основном. Вы протестируйте во сколько раз отличается чтение/запись 4 байта массива(одномерного) и Color Bitmap'a ;). Точно так же с составляющими цвета Color. Ладно если бы у них были функции с которыми работать эффективнее с запакованными данными чем с массивом байт, но таких нет. И нет, Graphics хоть и быстрее чем по пиксельное чтение/запись, но так же медленнее работы с массивом байт.
И, кроме всего прочего, 4 байта на пиксель это стандарт для максимального качества экрана, но так далеко не всегда. В тех же нейросетях - уменьшение качества для большей производительности не редкость.
А я и не сказал, что Bitmap и Color являются основами моей библиотеки. Они являются одним из средств ввода-вывода (то есть, например, вы отредактировали изображение в CIELAB, и хотите вставить его в PictureBox). Основой являются всё те же массивы байт… Всё своё: цвет, изображение, Graphics. Другой метод (для файлов)-стандартные форматы (их 9 что-ли ;)) для RGBBitmap (*.jpg; *.bmp и т.д) или разработанные мной для LAB и XYZ.
- [quote=“Sun_Serega, post:10, topic:1912”] А потеря производительности в GraphABC как раз из за битмапов в основном [/quote]
Тут уж зависит от Ваших потребностей и возможностей оборудования… У меня он может менять изображения с частотой 15-20 fps, хотя работаю я не на Tianhe-2. На этом первое время даже пробовал видеоплеер сделать, пока не узнал про System.Windows.Controls.MediaElement 
.
А в чем, собственно, будет заключаться “библиотека”? Переход между цветовыми пространствами это умножение на матрицу 3х3 (плюс еще деление, если меняете white point), там нЕчего оптимизирвоать. Ну, интринсиком AVX2 можете перемножить матрицы — это максимум. Или что-то еще планируется сделать?
Я Вас не понял. Это больше похоже на операцию свёртки (свёрточные нейросети). Переход между цветовыми пространствами происходит по формулам. Разным. Об оптимизации существующих методов никто и не говорит. Планируется реализовать модуль цветовых пространств для паскаля (с открытым исходным кодом). Для нейросетей, возможно, тоже сделаю модуль.
Свертки — это немного не в ту степь (хотя их и можно реализовать с помощью умножений на теплицевы матрицы, но это не то, о чем я говорил). В случае же с цветовыми пространствами, они (пространства) задаются “стандартной белой точкой” (white point) и тремя трехмерными векторами цветностей, определенных в пространстве XYZ. Начиная с этого момента, вы можете думать о задаче перехода в новое цветовое простраснтво как о поиске оператора, который переведет вектор (1,0,0) в первый вектор цветности, вектор (0,1,0) — во второй и т.д. Кроме того, вектор (1,1,1) должен переводится в “точку белого”. Так вот такой оператор всегда можно построить и он определяется матрицей размера 3х3. Вот потому я и удивился, зачем для такой простой операции нужна какая-то отдельная библиотека.
Даже если так. В библиотеке находятся не только методы переводов цвета между 3-мя цветовыми пространствами (RGB, LAB, XYZ, в последствии ещё и CMYK), там будут соответствующие типы (Записи и классы), описывающие как сам цвет, так и само изображение. К тому-же, алгоритмы перевода нужно ещё поискать и реализовать. Согласитесь, проще иметь готовый модуль и его исходник? Эта библиотека (во всяком случае переходы между пространствами) необходима при обработке изображения. Например, в пространстве RGB попросту невозможно работать отдельно с цветом и яркостью (а это является основой большинства функций любого Фотошоп’а), однако это разделение является структурой пространства LAB. Таких примеров можно привести множество.
Мы согласны. Пишите - добавим.
3 лайка
Первую версию библиотеки написал. Реализованы структуры, представляющие цвета RGB, LAB, XYZ; реализован класс ColorConverters, содержащий методы для переходов между цветовыми пространствами RGB, LAB, XYZ и обеспечения совместимости с System.Drawing.Color; реализованы классы, представляющие изображения в цветовых пространствах RGB, LAB, XYZ; реализован класс BitmapConverters, предоставляющий методы переходов между цветовыми пространствами RGB, LAB, XYZ для изображений и обеспечения совместимости с System.Drawing.Bitmap. Сейчас ведётся разработка следующей версии библиотеки, в которой будет реализован класс Graphics.ColorSpaces.pas (46,6 КБ)
1.У вас описание типов находится за type и не применяется. К примеру:
/// Представляет цвет в цветовом пространстве RGB
type
RGBColor = Record
надо заменить на
type
/// Представляет цвет в цветовом пространстве RGB
RGBColor = Record
чтоб описание работало.
2. Если вы уже используете имена низкого уровня почему не замените PABCSystem.Round(PABCSystem.Int(...) на аналоги из System.Math?
3. Зачем вы запретили запись в составляющие цвета и размеры ваших битмапов?
4. Для чего нужна строчка {$Reference 'System.dll'}?
5. Зачем навязывать {$AppType Windows}?
6. Способ сохранения и загрузки ваших битмапов - ужасный костыль. Поищите как правильно сохранять каждый формат, вместо использования ужасно медленного System.Drawing.Bitmap как посредника.
7. Я не уверен, но вроде бы в вашем применении {$OMP Parallel For} не будет работать.
8. if System.IO.File.Exists(fname) = True Then. 
. =true? Что за извращенство?)))
9. raise new System.Exception это табу, ибо при дебаге будет очень не удобно. Надо использовать для каждого типа ошибок не разный текст, а разный тип исключений.
10. Используйте System.IO.BinaryReader для правильного по байтового считывания из потока.
3 лайка
- Заметил, сейчас исправлю.
- PABCSystem-увы, пока что обязательный модуль, соответственно писать везде PABCSystem не нужно, хотя, пожалуй, исправлю.
- А Вы загляните в GraphABC.Picture и System.Drawing.Bitmap. Нигде нет возможности менять размер, не меняя объекта. Доступ к цвету есть через SetPixel, GetPixel. В следующей версии (будет дней через 4-5) появится Graphics, там будет возможность извлечь из изображения цветовой канал.
- Не будем забывать, что System.dll - это сборка, содержащая пространство имён System, а оно активно применяется в модуле.
- Вы можете переопределить тип приложения в своей программе, попробуйте не поставить {$AppType Windows} в любой программе с GraphABC, и увидите кроме графики чёрное окошко консоли.
- А где Bitmap - посредник? Это одна из возможных систем стандартного ввода-вывода изображения.
- Почему же? Скорость с {$OMP Parallel For} у меня выше, чем без неё.
- Это где такое?
- С исключениями согласен. Исправлю.
- А в чём проблема ReadByte()? Чем он плох?
- Описания типов исправил.
- Где Вы увидели стандартную функцию без PABCSystem? У меня везде он стоит. Добавил директиву
Uses PABCSystem;9 . Добавил и внедрил собственные классы исключений Так лучше? ColorSpaces.pas (48,3 КБ) ColorSpaces.pcu (9 ТБ) ColorSpaces.xml (19,6 КБ)
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021