nedoPC.org

Community for electronics hobbyists, established in 2002
Last visit was: 27 Jul 2024 07:24
It is currently 27 Jul 2024 07:24



 [ 42 posts ]  Go to page 1, 2, 3  Next
А не написать ли нам свой собственный графический редактор? 

Как бы такой редактор мог называться?
photoshaos 0%  0%  [ 0 ]
nedopixels 29%  29%  [ 5 ]
nedopx 29%  29%  [ 5 ]
hmyra 0%  0%  [ 0 ]
ikzin 6%  6%  [ 1 ]
ixyba 0%  0%  [ 0 ]
kyosq 12%  12%  [ 2 ]
wmazo 0%  0%  [ 0 ]
xirip 0%  0%  [ 0 ]
yojog 6%  6%  [ 1 ]
никак - всё равно нифига не сделаешь... 18%  18%  [ 3 ]
Total votes : 17

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

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
Уже какое-то время видится мне необходимость наличия простого графического редактора для перевода фоток и картинок в недоформаты для ZX-Spectrum, TS2068, ATM Turbo2+, Спринтера, Специалиста, Xorya и т.д. - чтобы было всё в одном и опенсорц (на wxWidgets). Кто что думает?

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


22 May 2023 23:27 WWW
Senior
User avatar

Joined: 21 Aug 2018 07:39
Posts: 163
Location: Кемеровская обл.
Надеюсь будет темка в виде бложика с кусочками кода и коментами.
Хоть одним глазком увидеть как "кодют" боги :mrgreen:


23 May 2023 09:04
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
Не боги горшки обжигают :lol:

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


23 May 2023 10:48 WWW
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Я думаю, что "не написать". :wink:
Мы тут много чего за последние 12 лет "не написали"... :-?
На мой взгляд, и без графического редактора мир переживёт. :ebiggrin:

_________________
iLavr


25 May 2023 09:53
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
Ну делать клон фотошопа я не собираюсь (и да же не клон GIMPа), но вот иметь простейшие возможности типа изменение размеров с чтением-сохранением основных форматов (JPG/PNG/GIF/XBM/XPM), отрезанием лишнего, поворотами, переводом из RGB в индексированный и монохромный форматы, и это плюс к конвертированию в недо-форматы - плюс единообразно работающее в Linux, Windows и MacOS - вот это была бы няшка :mrgreen:

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

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


25 May 2023 21:01 WWW
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Shaos wrote:
Ну делать клон фотошопа я не собираюсь (и да же не клон GIMPа), но вот иметь простейшие возможности типа изменение размеров с чтением-сохранением основных форматов (JPG/PNG/GIF/XBM/XPM), отрезанием лишнего, поворотами, переводом ...

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

_________________
iLavr


26 May 2023 05:18
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
MS Paint не умеет сохранять картинки в xbm/xpm и zx-форматах…

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


26 May 2023 08:45 WWW
Fanat
User avatar

Joined: 24 Sep 2021 23:31
Posts: 73
Shaos wrote:
Пока я смотрю в отрыв выходит nedopixels :)

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


27 May 2023 15:40
Novelist

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

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


28 May 2023 10:15
Admin
User avatar

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

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


28 May 2023 11:22 WWW
Novelist

Joined: 31 May 2007 08:23
Posts: 37
Location: Украина
Shaos wrote:
если со случайным числом сравнивать, то будет шумно по-моему
тут же просто ошибку можно нкапливать в строке и корректировать её путём переключения в 0 или в 1

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


29 May 2023 09:05
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
Вобщем минимальный набор фич наверное должен быть такой:
- работа только с одним изображением;
- поддержка трёх общеупотребимых форматов: 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КБ из других мест для работы алгоритмов обработки пикселов - переменные, пограничные пикселы из соседних квадратов и т.д. Ну и плюс разделение изображения на квадраты позволит обрабатывать несколько квадратов одновременно на разных корах многокоровых процессоров...

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


24 Jun 2023 21:25 WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
zooleek wrote:
хочу поделиться алгоритмом конвертирования 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_(image_processing) - интересно, что в русской версии статьи есть дополнительные матрицы)

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


25 Jun 2023 04:40 WWW
Admin
User avatar

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

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

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


25 Jun 2023 11:43 WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 23104
Location: Silicon Valley
А так-то я обработкой изображений очень давно занимаюсь - вот скрины из моей дипломной работы 1996 года:

Attachment:
demo_000.png

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

Attachment:
demo_001.png

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

Attachment:
demo_002.png

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

Attachment:
demo_003.png

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

Attachment:
demo_005.png

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

Attachment:
demo_004.png


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

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

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

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

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

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

Attachment:
ba1.gif


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

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

Attachment:
lenna.jpg

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

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


You do not have the required permissions to view the files attached to this post.

_________________
https://mastodon.social/@Shaos :dj:
https://www.youtube.com/@Shaos1973


25 Jun 2023 12:57 WWW
 [ 42 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: Claude AI [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.