Библиотека цветовых пространств

[Gleb]

Только вот боюсь, добавление директивы на подключение PABCSystem.pcu сильно ухудшило размеры файла модуля (откомпилированного).

[Sun_Serega]

1. чтоб нумерация не ломалась.
2. Я про System.Math.Truncate, System.Math.Ceiling и System.Convert.ToInt32 которые использует PABCSystem в Int и Round. Вы же используете более низкоуровневые имена как System.byte вместо byte, которые на производительности не влияют, так зачем вы добавляете лишний уровень рекурсии, который как раз уже влияет.
3. И? С их структурой запись отдельной составляющей цвета и т.п. будет не эффективна но у вас то что мешает?
4. Да, вот только попробуйте убрать эту строчку - ничего компилироваться не перестанет.
5. Я знаю зачем это, но ваш модуль не для запуска графического окна а для операций. Он может использоваться не только в графической программе, а к примеру в утилите преобразующей 1 файл к другому, поэтому я и называю это навязыванием. Те кто будут пользоваться или используют эту строчку в своей программе, или подключат GraphABC и т.п.
6. Вы сначала записываете, по пиксельно(хотя бы уже массив байт в него пихали а не так, попиксельная запись в Bitmap ужасно медленная), а потом уже даёте битмапу записать своё содержимое в файл. Поэтому он посредник, нормальный способ записи включает запись в файл заголовка соответственно формату, и после этого запись туда же каждого пикселя картинки.
7. Если вы протестировали уже - хорошо.
8. С Crtl+F поищите = True - там оно много раз попадается.
9. чтоб нумерация не ломалась.
10. Вы хотя бы посмотрите тип возвращаемого значения - integer. System.IO.FileStream совершенно не оптимизировано для побайтового чтения. Кроме того посмотрите на возможности System.IO.BinaryReader и System.IO.BinaryWriter, там много полезного для запаковки стандартных типов в файл. Как раскладывание Single на 4 байта и запись их в поток, и такое же считывание.

Хотелось ещё кое что объяснить, System.Drawing.Bitmap не содержит просто массив байт, там очень сложная структура, поэтому чтение и запись медленнее чем у массива байт, ну и ваших типов тоже. Разница в 160 раз на чтение одного байта между массивом и битмапом, вот программа которой я тестировал. И поэтому же невозможно так легко перезаписать одну составляющую цвета одного пикселя.

И ещё, ваш модуль содержит только подпрограммы для обработки данных, эта обработка может запускаться несколько тысяч раз в секунду, поэтому я так яро борюсь за оптимизацию))).

[Gleb]

Я про System.Math.Truncate, System.Math.Ceiling и System.Convert.ToInt32 которые использует PABCSystem в Int и Round. Вы же используете более низкоуровневые имена как System.byte вместо byte, которые на производительности не влияют, так зачем вы добавляете лишний уровень рекурсии, который как раз уже влияет.

Имена не могут быть низкоуровневыми. Низкоуровневыми могут быть только компоненты. Рекурсии там никакой нет. Использую PABCSystem только потому, что его пока-что (надеюсь, что разработчики всё-таки это исправят) нельзя отключить.

И? С их структурой запись отдельной составляющей цвета и т.п. будет не эффективна но у вас то что мешает?

Какой в этом смысл? Зачем это нужно? Чем плох GetPixel()?

Да, вот только попробуйте убрать эту строчку - ничего компилироваться не перестанет.

Но и с ней всё компилируется!

Я знаю зачем это, но ваш модуль не для запуска графического окна а для операций. Он может использоваться не только в графической программе, а к примеру в утилите преобразующей 1 файл к другому, поэтому я и называю это навязыванием. Те кто будут пользоваться или используют эту строчку в своей программе, или подключат GraphABC и т.п.

По видимому, Вы меня не правильно поняли. Тип приложения можно заменить на свой. То есть, если модуль консольный, то его совершенно спокойно можно использовать и в графическом режиме. Пример - преславутый PABCSystem, он консольный, всегда добавляется к программам и библиотекам, но это не мешает написать в программе {$AppType Windows} и пользоваться Windows-программой. Так и наоборот, если написать (или не написать ничего о типе приложения, так как в Паскале тип приложения по умолчанию-консольный) {$AppType Console} в программе, использующей GraphABC, будет консольный режим (Графическое окно и консольное одновременно), так как WindowsForms всё же немного дружит с консолью. Так что выбор здесь полностью Ваш.

Вы сначала записываете, по пиксельно(хотя бы уже массив байт в него пихали а не так, попиксельная запись в Bitmap ужасно медленная), а потом уже даёте битмапу записать своё содержимое в файл. Поэтому он посредник, нормальный способ записи включает запись в файл заголовка соответственно формату, и после этого запись туда же каждого пикселя картинки.

В упор не понимаю, о чём Вы говорите! Может Вы приведёте код? Сохранить изображение в LAB и XYZ в файл можно не только через Bitmap, но и в специальном формате, разработанном для каждого класса. Это реализовано в виде массива байт и потоков. Если Вам так хочется обходиться без ООП, то можете просто взять и скопировать методы перевода цвета в свою программу, исходный код модуля будет в инсалляторе Паскаля, лицензия также это позволяет. Тогда можете писать всё в виде массива байт, но я очень сомневаюсь, что этот код сможет прочитать кто-то, кроме Вас.

Если вы протестировали уже - хорошо.

В среде разработки должны быть примеры (уверен, что Вы знаете, где они лежат). Находите там папку OMP Samples и изучаете примеры. Среди них есть параллельное перемножение матриц с помощью {$OMP Parallel For}(сравнение скорости выполнения с параллельным циклом и без него). Собственно, здесь задача похожая.

Вы хотя бы посмотрите тип возвращаемого значения - integer. System.IO.FileStream совершенно не оптимизировано для побайтового чтения. Кроме того посмотрите на возможности System.IO.BinaryReader и System.IO.BinaryWriter, там много полезного для запаковки стандартных типов в файл. Как раскладывание Single на 4 байта и запись их в поток, и такое же считывание.

В таком случае в следующей версии (дней через 5) я это поправлю. Тут Вы скорее всего правы.

Хотелось ещё кое что объяснить, System.Drawing.Bitmap не содержит просто массив байт, там очень сложная структура, поэтому чтение и запись медленнее чем у массива байт, ну и ваших типов тоже. Разница в 160 раз на чтение одного байта между массивом и битмапом, вот программа которой я тестировал. И поэтому же невозможно так легко перезаписать одну составляющую цвета одного пикселя.

Это я тоже знаю. Но ведь иногда чем-то приходится жертвовать. Понятно, что работа с массивом байт будет быстрее, чем со сложной структурой типа bitmap, но чтобы так работать нужно иметь большой опыт работы и немало времени, поэтому и сделано всё таким образом. Но хотел бы заметить, bitmap и color устроены гораздо сложнее, чем мои классы и структуры, они содержат больше информации.

И ещё, ваш модуль содержит только подпрограммы для обработки данных, эта обработка может запускаться несколько тысяч раз в секунду, поэтому я так яро борюсь за оптимизацию))).

Если Вы открывали код моего модуля, то увидели бы, что там, помимо методов, ещё и куча классов и структур, описывающих все изображения и цвета (во всех пространствах). Я тоже борюсь за оптимизацию, но не будем забывать, что иногда задача требует не оптимизации, а понятного кода, который ,увы, крайне трудно сделать, используя только массивы. Так же хотел бы попросить показывать примерный код того, что Вы предлагаете. По словам ориентироваться очень трудно.

[Admin]

(9 ТБ)

Это много конечно

А вот модель HSV - она присутствует?

И почему не использовать стандартный тип Color для RGBColor?

[Admin]

Использую PABCSystem только потому, что его пока-что (надеюсь, что разработчики всё-таки это исправят) нельзя отключить.

Мы ещё раз повторим, что сделать это невозможно - после отключения системного модуля работать в оболочке с кодом невозможно. Кроме того, если это модуль, а не dll, то такое отключение вообще не имеет смысла, поскольку на размер результирующего файла не влияет.

[Gleb]

А вот модель HSV - она присутствует?

Скоро добавлю.

И почему не использовать стандартный тип Color для RGBColor?

Сделал тип только для того, чтобы он был в формате, общем для библиотеки. При сохранении в файл соответствующего изображения, используются стандартные форматы (jpg, bmp), на выбор. Для этого есть перечисление.

[Gleb]

Кроме того, если это модуль, а не dll, то такое отключение вообще не имеет смысла, поскольку на размер результирующего файла не влияет.

Проблема в том, что в любом случае результатом работы будет dll или exe, где размер будет.

после отключения системного модуля работать в оболочке с кодом невозможно

В чём заключается проблема? Чего кроме стандартных типов, классов и подпрограмм не будет? Может, если с отключением всё так плохо, тогда сделать две версии модуля, первая содержит только самое необходимое, а вторая-то что есть сейчас? Почему Паскаль обязательно должен иметь какое-то нехорошее свойство? Обидно.

[Gleb]

Обновление для библиотеки. Добавлено цветовое пространство CMYK (Пока работает с некоторыми погрешностями). Добавлен класс Graphics (пока только конструктор и метод для установки цвета пиксела). Добавлен новый класс исключения. В ближайшие два дня добавлю HSV.ColorSpaces.pas (71,4 КБ)

[Gleb]

Как и обещал, обновление для библиотеки:blush::

1. Добавлено цветовое пространство HSV.
2. Graphics’ы решил сделать отдельными для каждого цвет. пространства, что бы увеличить производительность.
3. Класс исключения, добавленный в предыдущей версии сохранил(может в дальнейшем пригодиться).
4. Добавлен системный метод для конвертирования RGB в HSL. Может, завтра добавлю всё пространство. Файлы: Исходник: ColorSpaces.pas (89,0 КБ) Откомпилированный: ColorSpaces.pcu (182,9 КБ) Описание (XML): ColorSpaces.xml (35,9 КБ)

[Sun_Serega]

Если уж будет по графиксу на битмап, может добавить битмапам функцию типа GetGraphics? К примеру чтоб можно было в записи

var b := new RGBBitmap(5,5);
var gr := b.GetGraphics;

менять тип только для b, а переменной gr он автовыведится. Этот примеру простенький, но в разных подпрограммах может быть свой gr.

[Gleb]

Хорошая идея! Попробую реализовать.

[Gleb]

В принципе, если будут добавлены пространства имён, можно будет “разделить” библиотеку на логические части: на каждое цветовое пространство-своё пространство имён. То есть в пространстве имён RGB будет RGBBitmap; RGBColor; RGBGraphics. Добавить пространство имён с конвертерами для цветов и изображений… Будет удобнее, чем искать нужное имя среди пары десятков других. Надеюсь, Разработчики сделают их в ближайшее время. Очень полезная конструкция.

[Gleb]

Итак, обновление для библиотеки цветовых пространств:

1. К каждому цветовому пространству добавлен свой класс Graphics(поверхность рисования). В классы Bitmap добавлены методы CreateGraphics для получения экземпляра класса Graphics для текущего изображения. В классах Graphics реализовано: 1.1 GetPixel(x, y: System.Int32): ***Color; 1.2 SetPixel(x, y: System.Int32; C: ***Color); 1.3 DrawRectangle(x1, y1, x2, y2: System.Int32; C: ***Color); 1.4 FillRectangle(x1, y1, x2, y2: System.Int32; C: ***Color); 1.5 DrawEllipse(x1, y1, x2, y2: System.Int32; C: ***Color); 1.6 DrawEllipse(x1, y1, x2, y2: System.Int32; Density: System.Int32; C: ***Color); 1.7 DrawLine(x1, y1, x2, y2: System.Int32; C:***Color); Файлы: Исходный код: ColorSpaces.pas (123,9 КБ) Описание (XML): ColorSpaces.xml (49,2 КБ) Откомпилированный: ColorSpaces.pcu (312,5 КБ) В следующей версии реализую цветовое пространство HSL и расширю возможности Graphics. Версию добавлю в течение 3-х дней.