nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 19 Apr 2024 17:46



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

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

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

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

_________________
:dj: https://mastodon.social/@Shaos


22 May 2023 23:27
Profile WWW
Senior
User avatar

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


23 May 2023 09:04
Profile
Admin
User avatar

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

_________________
:dj: https://mastodon.social/@Shaos


23 May 2023 10:48
Profile WWW
Supreme God
User avatar

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

_________________
iLavr


25 May 2023 09:53
Profile
Admin
User avatar

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

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

_________________
:dj: https://mastodon.social/@Shaos


25 May 2023 21:01
Profile WWW
Supreme God
User avatar

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

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

_________________
iLavr


26 May 2023 05:18
Profile
Admin
User avatar

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

_________________
:dj: https://mastodon.social/@Shaos


26 May 2023 08:45
Profile WWW
Fanat
User avatar

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

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


27 May 2023 15:40
Profile
Novelist

Joined: 31 May 2007 08:23
Posts: 36
Location: Украина
Reply with quote
хочу поделиться алгоритмом конвертирования 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
Profile
Admin
User avatar

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

_________________
:dj: https://mastodon.social/@Shaos


28 May 2023 11:22
Profile WWW
Novelist

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

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


29 May 2023 09:05
Profile
Admin
User avatar

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

_________________
:dj: https://mastodon.social/@Shaos


24 Jun 2023 21:25
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22543
Location: Silicon Valley
Reply with quote
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) - интересно, что в русской версии статьи есть дополнительные матрицы)

_________________
:dj: https://mastodon.social/@Shaos


25 Jun 2023 04:40
Profile WWW
Admin
User avatar

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

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

_________________
:dj: https://mastodon.social/@Shaos


25 Jun 2023 11:43
Profile WWW
Admin
User avatar

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

Attachment:
demo_000.png
demo_000.png [ 24.64 KiB | Viewed 16220 times ]

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

Attachment:
demo_001.png
demo_001.png [ 10.54 KiB | Viewed 16220 times ]

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

Attachment:
demo_002.png
demo_002.png [ 9.14 KiB | Viewed 16220 times ]

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

Attachment:
demo_003.png
demo_003.png [ 9.84 KiB | Viewed 16220 times ]

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

Attachment:
demo_005.png
demo_005.png [ 5.8 KiB | Viewed 16214 times ]

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

Attachment:
demo_004.png
demo_004.png [ 3.83 KiB | Viewed 16220 times ]


Потом была аспирантура, которую я к 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
Screenshot from 2023-06-25 13-09-58.png [ 76.39 KiB | Viewed 16216 times ]

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

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

Attachment:
ba1.gif
ba1.gif [ 17.67 KiB | Viewed 12485 times ]


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

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

Attachment:
lenna.jpg
lenna.jpg [ 19.92 KiB | Viewed 14591 times ]

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

Attachment:
Screenshot from 2023-11-07 19-44-42.png
Screenshot from 2023-11-07 19-44-42.png [ 240.53 KiB | Viewed 14249 times ]

_________________
:dj: https://mastodon.social/@Shaos


25 Jun 2023 12:57
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 42 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 78 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

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