А не написать ли нам свой собственный графический редактор?

[Shaos]

Уже какое-то время видится мне необходимость наличия простого графического редактора для перевода фоток и картинок в недоформаты для ZX-Spectrum, TS2068, ATM Turbo2+, Спринтера, Специалиста, Xorya и т.д. - чтобы было всё в одном и опенсорц (на wxWidgets). Кто что думает?

[Icer]

Надеюсь будет темка в виде бложика с кусочками кода и коментами.
Хоть одним глазком увидеть как "кодют" боги

[Shaos]

Не боги горшки обжигают

[Lavr]

Я думаю, что "не написать".
Мы тут много чего за последние 12 лет "не написали"...
На мой взгляд, и без графического редактора мир переживёт.

[Shaos]

Ну делать клон фотошопа я не собираюсь (и даже не клон GIMPа), но вот иметь простейшие возможности типа изменение размеров с чтением-сохранением основных форматов (JPG/PNG/GIF/XBM/XPM), отрезанием лишнего, поворотами, переводом из RGB в индексированный и монохромный форматы, и это плюс к конвертированию в недо-форматы - плюс единообразно работающее в Linux, Windows и MacOS - вот это была бы няшка

P.S. Пока я смотрю в отрыв выходит nedopixels
К слову все короткие буквосочетания, что идут ниже, это я какое-то время назад перехватил заброшенные .com домены с такими именами

[Lavr]

Ну делать клон фотошопа я не собираюсь (и да же не клон GIMPа), но вот иметь простейшие возможности типа изменение размеров с чтением-сохранением основных форматов (JPG/PNG/GIF/XBM/XPM), отрезанием лишнего, поворотами, переводом ...

Значит ты собираешься делать клон MS Paint ?

[Shaos]

MS Paint не умеет сохранять картинки в xbm/xpm и zx-форматах…

[Xom]

Пока я смотрю в отрыв выходит nedopixels

Я как раз за этот вариант и голосовал.

[zooleek]

хочу поделиться алгоритмом конвертирования grayscale в 1 битный пиксель
итак. пусть RND(255) функция, возвращающая случайное число от 0 до 255.
число A содержит градацию серого данного пикселя от 0 до 255
b ето пиксель, значение 0 черный или 1 белый.
делаем if (A+1)>RND(255) then b=1 else b=0

метод "монте карло"

[Shaos]

если со случайным числом сравнивать, то будет шумно по-моему
тут же просто ошибку можно нкапливать в строке и корректировать её путём переключения в 0 или в 1
а вообще софты ещё чуть более изощрённо делают, распределяя ошибку по соседним пикселам:
https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering
хотя я могу предоставить возможность пользователю прямо ручками корректировать матрицу и тонкости алгоритма на попробовать
так сказать все кишки наружу

[zooleek]

если со случайным числом сравнивать, то будет шумно по-моему
тут же просто ошибку можно нкапливать в строке и корректировать её путём переключения в 0 или в 1

согласен, немного шумно. но на вид даже ничего.
там получается теория вероятности работает.
нужно чтобы случайное число равномерно распределялось по диапазону. вероятность что выпадет 240 и 17 к примеру чтобы была одинакова. тогда диапазон от 0 до значения текущего пикселя как мишень в которую мы хотим попасть случайным числом. чем пиксель белее тем мишень больше и попасть вероятности больше поетому закрашиваем белым.

[Shaos]

Вобщем минимальный набор фич наверное должен быть такой:
- работа только с одним изображением;
- поддержка трёх общеупотребимых форматов: JPG, GIF, PNG (а также дружественных C-программистам форматов XBM и XPM);
- возможность подкрутить яркость и контрастность;
- возможность переключения из RGB в Grayscale, Indexed или Monochrome;
- возможность вырезать прямоугольник из картинки и сделать из него новую картинку (с закрытием предыдущей);
- возможность менять размер изображения и соотношение сторон (с поддержкой неквадратных пикселов);
- возможность повернуть изображение на 90, 180 и 270 градусов, а также отразить его по горизонтали или по вертикали;
- наложение произвольных фильтров (включая размазывание и подчёркивание краёв);
- сохранение в SCR (для Спектрума) и GFF (для Спринтера).

Далее можно поддержать мультиколор (TS2068, ATM Turbo2+, Специалист, Орион), гигаскрин (Спектрум) и Xorya (с показыванием реальной NTSC картинки).

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

P.S. Возможно надо воспользоваться результатами моих экспериментов 2020 года по измерению эффекта ограниченного размера кеша данных первого уровня и работать с массивами, которые не более 16КБ размером, чтобы всё умещалось в один кэш данных даже на AMD процах (там правда может быть нарезка по 64 байта из разных мест памяти, но тем не менее - основные данные лучше бы располагались компактно). В таком случае желательно обрабатывать картинки квадратами не более 128x128 при 1-байтовых пикселах либо не более чем 73x73 в случае 3-байтовых пикселов RGB - в этом случае наверное надо уменьшить предельный размер до степени двойки 64x64. Можно каналы R, G и B держать в отдельных друг от друга квадратах 64х64 - при этом кэш ещё имеет возможность вместить до 4КБ из других мест для работы алгоритмов обработки пикселов - переменные, пограничные пикселы из соседних квадратов и т.д. Ну и плюс разделение изображения на квадраты позволит обрабатывать несколько квадратов одновременно на разных корах многокоровых процессоров...

[Shaos]

хочу поделиться алгоритмом конвертирования grayscale в 1 битный пиксель
итак. пусть RND(255) функция, возвращающая случайное число от 0 до 255.
число A содержит градацию серого данного пикселя от 0 до 255
b ето пиксель, значение 0 черный или 1 белый.
делаем if (A+1)>RND(255) then b=1 else b=0

метод "монте карло"

вот нашёл статью по алгоритмам дизеринга и там этот метод тоже описан (под названием "белый шум"):

https://surma.dev/things/ditherpunk/

P.S. кстати чтобы накапливать и распределять ошибку по пикселам значения пикселов должны быть нецелыми - это значит что квадраты пикселов, которые как я написал выше желательно умещаемые в один кэш данных, будут занимать больше места, чем ожидалось - double на пиксел это наверное жырновато (8 байт на пиксел), а вот float наверное более-менее (4 байта на пиксел), хотя наверное надо экспериментировать с фиксированной точкой, скажем 8.16 (3 байта на пиксел) или даже 8.8 (2 байта на пиксел)...

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

P.P.P.S. вот тут ещё можно подсмотреть и попробовать матрицы коэффициентов для сглаживания и подчёркивания границ: https://generic-github-user.github.io/Image-Convolution-Playground/src/
(значения в матрице брались с википедии: https://en.wikipedia.org/wiki/Kernel_%28image_processing%29 - интересно, что в русской версии статьи есть дополнительные матрицы)

[Shaos]

P.S. Возможно надо воспользоваться результатами моих экспериментов 2020 года по измерению эффекта ограниченного размера кеша данных первого уровня и работать с массивами, которые не более 16КБ размером, чтобы всё умещалось в один кэш данных даже на AMD процах (там правда может быть нарезка по 64 байта из разных мест памяти, но тем не менее - основные данные лучше бы располагались компактно). В таком случае желательно обрабатывать картинки квадратами не более 128x128 при 1-байтовых пикселах либо не более чем 73x73 в случае 3-байтовых пикселов RGB - в этом случае наверное надо уменьшить предельный размер до степени двойки 64x64. Можно каналы R, G и B держать в отдельных друг от друга квадратах 64х64 - при этом кэш ещё имеет возможность вместить до 4КБ из других мест для работы алгоритмов обработки пикселов - переменные, пограничные пикселы из соседних квадратов и т.д. Ну и плюс разделение изображения на квадраты позволит обрабатывать несколько квадратов одновременно на разных корах многокоровых процессоров...

С другой стороны т.к. кэш данных состоит из 64-байтовых строк, то можно пикселы не группировать в квадраты, а просто работать не по всей строке, а по N пикселов, идя "полосой" сверху вниз, при этом пикселы в памяти будут представлены в натуральном построчном виде, а в кэше будет всё тот же квадрат (нижние сколько-то строк пикселов из "полосы") - можно попробовать написать тесты на эту тему и сравнить производительность...

[Shaos]

А так-то я обработкой изображений очень давно занимаюсь - вот скрины из моей дипломной работы 1996 года:

demo_000.png

там например можно было поиграться со спектром преобразования Уолша:

demo_001.png

и даже получить обратно картинку из урезанного спектра:

demo_002.png

программа работала с BWS форматом изрбражений (это мой собственный формат представления картинок в градациях серого без потерь с 6 битами на точку):

demo_003.png

интерфейс пользователя был самописный ( я его создал в 1995 году и назвал GRAPHIN : ) т.к. всё работало на голом досе в 320x200:

demo_005.png

как можно видеть я там реализовал несколько простых фильтров и ещё в этой программе можно было поиграться с экспериментальными алгоритмами фрактального сжатия и самодельной "аппроксимации сферами" (тоже моё изобретение):

demo_004.png

Потом была аспирантура, которую я к 1999 году закончил, но дисер так и не защитил (т.к. научрук на тот момент уехал из страны на несколько лет), хотя успел написать несколько статей по фрактальному сжатию видео - последняя вышла на английском языке в наработках конференции "2nd International Symposium on Image and Signal Processing and Analysis" 2001 года (туда ездил мой соавтор - немецкий профессор Кройцбург, который на тот момент работал в Финляндии):

https://ieeexplore.ieee.org/document/938693

И на эту статью до сих пор ссылаются молодые учёные по всему миру

Screenshot from 2023-06-25 13-09-58.png

(в интернете можно найти русский более ранний вариант статьи например вот тут: http://www.infocity.kiev.ua/prog/other/content/progother023.phtml)

Кроме того я нашёл старый диск 2001 года где были примеры сжатых видеороликов и кодер с плеером в исходниках

ba1.gif

P.S. А вот тут можно скачать "классические" картинки 256x256, 512х512 и 1024х1024 на поиграться с алгоритмами обработки изображений и сжатия: https://sipi.usc.edu/database/database.php

P.P.S. К сожалению Lena там с некоторых пор отсутствует, возможно по причине копирайтнутости (это был скан плейбоя 1972 года):

lenna.jpg

P.P.P.S. А - всё понятно, Лена сама в 2019 году попросила свою фотку больше не использовать, хотя чуть раньше писала, что ею гордится:

Screenshot from 2023-11-07 19-44-42.png