76

Re: Утилита DaDither: конвертация изображений

avivanov76 пишет:

Технически, конечно, это будут два разных полупикселя - нижняя часть пикселя из первой строки и верхняя часть пикселя из второй. Они не обязаны быть одинаковыми.

Да, разумеется, они не обязаны быть одинаковыми. Ключевое во всем этом - это яркости этих полупикселей, а они будут либо оба светлые, либо оба темные.

avivanov76 пишет:

Да, вполне.

Т.е. технически возможен и гигаскрин 128x256.

77 Отредактировано avivanov76 (25-04-2021 18:24)

Re: Утилита DaDither: конвертация изображений

Dec пишет:

Т.е. технически возможен и гигаскрин 128x256.

Да, на девятке все нужное для этого есть. Например, в одном кадре показываем чересстрочно страницы 1 и 2, а в другом - страницы 3 и 4.
Вот на семерке уже не получится - там штатно только 4 страницы с разрешением 128x128, причем самой первой пользоваться нельзя - она находится по адресам $0000-$1FFF, то есть там же, где нулевая страница и стек процессора. Ну и частота IRQ на семерке другая  - одно прерывание на 32 телевизионных строки. Из-за этого момент преключения строк будет сильнее уплывать.

====

С этим переключением строк я тут напоролся на неожиданную проблему. В первом варианте, когда я заливал экран вертикальными полосами все выглядело прилично:

Spoiler

http://forum.agatcomp.ru//misc.php?action=pun_attachment&item=922&download=1

Тут используется всего 4 цвета (1, 6, 11 и 16 полосы - это исходные Агатовские цвета), из которых получается 10  смешанных цветов (6 штук повторяются, типа зеленый + желтый = желтый + зеленый).

Но как только я сделал шахматку, вылезла неприятность. Вот исходные страницы (разводы кругами - это не часть картинки, это из-за съемки телефоном):

Spoiler

http://forum.agatcomp.ru//misc.php?action=pun_attachment&item=923&download=1
http://forum.agatcomp.ru//misc.php?action=pun_attachment&item=924&download=1

А вот то что получилось в режиме гигаскрин:

Spoiler

http://forum.agatcomp.ru//misc.php?action=pun_attachment&item=925&download=1

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

И это при том, что задержки в коде для всех строк одинаковые и все было просчитано несколько раз.
Я даже думал, что это ДК как-то реагирует на дергание страниц. Но нет, вот разброс времени переключения по осциллографу:

Spoiler

http://forum.agatcomp.ru//misc.php?action=pun_attachment&item=926&download=1

Первый канал - СГИ, второй - разряд D5 регистра режима ДК. Разброс почти 8 мкс. Я ожидал, что он будет не больше 4. При включенных прерываниях работает только цикл опроса клавиатуры из двух команд:

M:     LDA $C000
         BPL M

И прерывание в лучшем случае вызовется сразу, в худшем случае - после того как закончится текущая команда. Самая длинная команда - LDA. Это 4 такта.

Но получается, что нет, вызов прерывания запаздывает. Я нашел подсказку почему так происходит, но надо разбираться как с этим бороться.

Post's attachments

Attachment icon gigascreen0.jpg 298.45 kb, 837 downloads since 2021-04-25 

Attachment icon gigascreen_jitter.png 13.78 kb, 850 downloads since 2021-04-25 

Attachment icon gigascreenmix2.jpg 309.39 kb, 864 downloads since 2021-04-25 

Attachment icon gigascreenp1.jpg 286.54 kb, 863 downloads since 2021-04-25 

Attachment icon gigascreenp2.jpg 293.83 kb, 834 downloads since 2021-04-25 

78 Отредактировано Dec (26-04-2021 00:51)

Re: Утилита DaDither: конвертация изображений

avivanov76 пишет:

А вот то что получилось в режиме гигаскрин

А каково ощущение мерцания в целом? Отдельные полупиксели видны или поверхность однородна?

79

Re: Утилита DaDither: конвертация изображений

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

80

Re: Утилита DaDither: конвертация изображений

Dec пишет:

Я не имею ни одной идеи, как автоматически конвертировать во что-то более менее адекватное в Hires, поэтому отложено на неопределенное будущее.

http://forum.agatcomp.ru//viewtopic.php?id=416

81

Re: Утилита DaDither: конвертация изображений

garnizon пишет:

Можно даже круче фокус сделать - палитру ведь можно менять по прерываниям. IRQ, по моему, генерируется на каждую текстовую строку. Проблема правда в том, что все 48 регистров за время обратного хода луча по строке перезагрузить не удастся - быстродействия не хватит. Но если поделить палитру на 2 части по 8 цветов, а картинку подготовить так, чтобы больше 8 цветов в смежных строках не использовалось, то можно обновлять палитру блоками по 8 цветов.

Не совсем понял. В строке можно менять произвольные 8 цветов или только последовательно идущие 8?

82

Re: Утилита DaDither: конвертация изображений

Dec пишет:

Не совсем понял. В строке можно менять произвольные 8 цветов или только последовательно идущие 8?

Так, вроде это моя идея была http://forum.agatcomp.ru//viewtopic.php?pid=3136#p3136. Вот только надо вспомнить, что я там 4 года назад придумал :)

Речь вроде бы шла про режим 128x128 16 цветов при наличии платы цветовых палитр. У платы палитр есть 48 регистров цвета. Их можно перепрограммировать в процессе отображения кадра.

С этим есть проблема - время обратного хода луча в графическом режиме - 12,8 мкс. Этого мало даже для перепрограммирования одного регистра палитры (один вызов IRQ требует 7 мкс). А если мы начнем менять палитру во время прямого хода луча, то, во-первых, это будет видно, а во-вторых, не факт, что мы будем успевать поменять цвет до того момента, когда он понадобится. Результатом будет картинка с неправильными цветами и "снегом" на экране.

Но есть обходной путь:
1) разбить изображение на блоки строк
2) картинку подготовить так, чтобы в каждом блоке строк использовалась только половина палитры (8 цветов)
3) во время отображения очередного блока менять цвета в другой половине палитры, которая текущим блоком не используется

Время отображения 4 строк в режиме 128x128 - 512 мкс. Должно с запасом хватить на перепрограммирование половины палитры (около 300 мкс). Размер в 4 строки еще выбран потому, что IRQ будет приходить каждую 4 строку.

Итого:
1) надо побить картинку на блоки (полоски) 128x4 пикселя
2) в каждом блоке разрешить использовать не более 8 цветов
3) порядок цветов строго не задан, но менять его на протяжении всего кадра нельзя: всегда 8 записей (24 регистра) палитры будут заняты в отображении текущего кадра, поэтому менять можно будет только оставшиеся 8.

Ну и спрашивается, зачем усложнять процесс обновления палитры, если можно просто выбрать 8 последовательных цветов (0-7 для четных полосок, 8-15 для нечетных)? Ведь смена порядка никаких выгод не дает?

83

Re: Утилита DaDither: конвертация изображений

avivanov76 пишет:

Так, вроде это моя идея была

Ок, не буду оспаривать авторство :) Просто увидел я это предложение у garnizon.

avivanov76 пишет:

2) в каждом блоке разрешить использовать не более 8 цветов

8 цветов это прям не очень густо. Но я попробую реализовать.

84

Re: Утилита DaDither: конвертация изображений

Я думал будет сильно хуже, но получается довольно неплохо. Хотя, конечно, все сильно зависит от исходного изображения.

Для сравнения слева на право сверху вниз
1) Оригинальное изображение
2) Обычный режим 128x128 с Флойдом
3) Обычный режим 128x128 без Флойда
4) Новый режим

https://www.dadither.com/img/AgatHAM.png

В каком формате сохранять изменения палитры? В виде отдельного файла или вместе с картинкой? Что по поводу 128x256?

85

Re: Утилита DaDither: конвертация изображений

Dec пишет:

Я думал будет сильно хуже, но получается довольно неплохо. Хотя, конечно, все сильно зависит от исходного изображения.

Ух ты! Очень здорово получилось! Особенно самая верхняя и самая нижняя четверти картинки. Я думал, что этот подход будет нормально работать только с картинками типа заставки Buena Vista https://www.closinglogos.com/page/Buena … Television.
То есть, градиент на фоне, плюс не слишком сложная картинка на переднем плане. А тут практически фотография.

В середине картинки, конечно, ограничение на 8 цветов сказалось - бандинг полез. Сюда бы Флойда со Стейнбергом. Правда, большой вопрос, как тут выбирать исходные цвета. Просто брать самые частотные цвета плохо - на мелких деталях цвета будут теряться. Надо как-то учитывать, используется ли цвет для отображения контрастных деталей, и поднимать ему приоритет. Ну или можно попробовать просто взять и принудительно включать в палитру самый темный цвет из блока.

Изменения палитры можно сохранять просто как массив из 32 элементов по 24 байта (8 записей R, G, B). Упаковывать не нужно, все равно для показа картинки придется распаковывать, а экономия нескольких сотен байт при объеме картинки 8 Кб, мне кажется, смысла не имеет. Удобнее сохранять все в один файл, чтобы потом не потерять ничего.

Совместить режим 128x256 со сменой палитр вряд ли получится. Там очень замороченный обработчик прерываний. Так, на вскидку, циклов на обновление палитры не хватит.

86

Re: Утилита DaDither: конвертация изображений

avivanov76 пишет:

Сюда бы Флойда со Стейнбергом.

Можно и пресвятого Флойда использовать. Верхний ряд - обычный режим без/с Флойдом, нижний ряд - новый режим (я обозвал его HAM):

https://www.dadither.com/img/AgatHAM2.png

avivanov76 пишет:

Изменения палитры можно сохранять просто как массив из 32 элементов по 24 байта

Ок, сделал.

На выходе FIL файл размером 9256 байт:

-заголовок - 44 байта.
-непосредственно пиксели - 8192 байта. Первые четыре строки используют нижние восемь цветов палитры, следующие четыре используют верхние восемь цветов палитры, следующие четыре снова используют нижние восемь цветов, и т.д.
-палитра, состоящая из 32 блоков - 768 байт. Каждый блок состоит из 8 цветов, записанных последовательно: R0, G0, B0, R1, G1, B1, R2, G2, B2, ...
-футер 252 байта в специальном формате (с) garnizon. В качестве кода палитры используется недокументированное значение 0xE.

Конвертер. Он может не только создавать FIL файлы, но и открывать их для импорта. Также FIL графику можно смотреть с помощью плагина для TotalCommander.

avivanov76 пишет:

Совместить режим 128x256 со сменой палитр вряд ли получится.

Ок, а что по поводу гигаскрина 128x128?

87

Re: Утилита DaDither: конвертация изображений

Dec пишет:

Ок, а что по поводу гигаскрина 128x128?

Гигаскрина с платой палитр? Технически, там та же проблема, что и с режимом 128x256 - поскольку переключение страниц надо делать каждую телевизионную строку, а прерывания приходят только раз в 8 строк, то длительности надо мерять программно. И необходимость подгонки по числу тактов съедает время, которое нужно для обновления палитры. В результате тактов не хватает.

Вообще, мне кажется, режим HAM интереснее. Технически тут так же доступно до 256 цветов, как и с гигаскрином. Но этот режим должен быть более совместим с эмуляторами. И на реальном железе картинка не должна мерцать.

И еще хотел спросить, а что делает параметр Extra lines? Я вижу, что он влияет на формирование палитры, но хотелось бы знать точнее.

88

Re: Утилита DaDither: конвертация изображений

avivanov76 пишет:

Гигаскрина с платой палитр? Технически, там та же проблема, что и с режимом 128x256 - поскольку переключение страниц надо делать каждую телевизионную строку

Я не совсем понимаю, для чего делать переключение страниц надо делать каждую телевизионную строку. Режим 128x256 сам по себе - это аппаратный режим, или программный?

avivanov76 пишет:

И еще хотел спросить, а что делает параметр Extra lines?

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

89

Re: Утилита DaDither: конвертация изображений

Dec пишет:

Режим 128x256 сам по себе - это аппаратный режим, или программный?

Это программный режим.
Аппаратные режимы Агат-7: 64x64 и 128x128 16 цветов и 256x256 ч/б.
Аппаратные режимы Агат-9: 128x128 16 цветов, 256x256 4 цвета, 256x256 ч/б и 512x256 ч/б. Плюс режим Apple HGR.

Dec пишет:

Extra lines определяет кол-во дополнительных строк сверху и снизу от текущего блока, пиксели которых участвуют в формировании палитры.

Спасибо!

90

Re: Утилита DaDither: конвертация изображений

avivanov76 пишет:

Это программный режим.

Теперь понял, вопрос снят.

91

Re: Утилита DaDither: конвертация изображений

И все таки я хочу понять до конца проблему совмещения гигаскрина и нового HAM режима в размере 128x128. DaDither готовит фреймы и располагает в них пиксели в расчете на то, что каждый фрейм будет отображаться ровно один кадр и требует смены отображаемого фрейма только в начале кадра. И мне не понятно, для чего менять страницы каждую строку?

92

Re: Утилита DaDither: конвертация изображений

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

Скорее всего, из-за размера пикселя. Даже если взять режимы 256x256 на Агате и 256x192 на Спектруме, то агатовский пиксель будет на треть шире. У Агата видимая часть строки отображается за 48.8 мкс. У Спектрума - за 36.6 мкс. То есть, на одном и том же мониторе или телевизоре ширина картинки Спектрума будет 75% от ширины картинки Агата.

А в случае режима 128x128 площадь агатовского пикселя получается в 5.33 раза больше, чем спектрумовского.

Кроме того, по моим подозрениям, тут еще и наличие бордера на Спектруме влияет. Дело в том, что у кинескопных мониторов и телевизоров размер картинки зависит от её яркости. Грубо говоря, если на черном фоне нарисовать белым цветом прямоугольник без заливки внутренней части, то его видимый размер будет меньше, чем такого же прямоугольника с заливкой.

Величина этого изменения зависит от тока лучей кинескопа и скорости реакции выходного каскада строчной развертки. А ток лучей зависит от яркости картинки.

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

Короче, вертикальные края у реальной картинки на кинескопе всегда немного волнистые. Насколько я помню, к телевизорам даже есть требование, чтобы изменение размера от яркости не превышало 5%.

И когда страницы переключаются, эти "волны" могут совпадать не точно. Как результат, и пиксели из разных фреймов могут совпадать неточно. Причем, это расхождение растет по краям экрана и исчезает в центре.

Вот тут бордер на Спектруме может улучшать ситуацию: во-первых, из-за него картинка находится дальше от края экрана где расхождение пикселей меньше. А во-вторых, поскольку бордер всегда одинаковый и занимает 25% строки, то уменьшается разность среднего тока лучей между соседними строками. В результате меньше меняется размер картинки.

Ну и возвращаясь к Агату: когда в режиме 128x128 фреймы переключаются на каждой телевизионной строке, то в два раза снижается площадь пикселя, а средняя яркость по двум строкам получается одинаковой для соседних кадров.

Надеюсь, объяснение не было слишком заумным :)

Да, ну и у ЖК мониторов этих проблем с размером просто не существует. Думаю, там переключение кадров работает лучше, хотя сам не видел.

93

Re: Утилита DaDither: конвертация изображений

Ок, все понял, спасибо за объяснение.