Info Guide #13
01 апреля 2021

GFX - Фотореализм: способы передать ненасыщенные цвета, присущие реальным фотографиям

<b>GFX</b> - Фотореализм: способы передать ненасыщенные цвета, присущие реальным фотографиям
        Фотореализм 
Alone Coder 

  На  обычном  атрибутном экране довольно 
непросто передать ненасыщенные цвета, при─ 
сущие реальным фотографиям. 
  В середине 90-х многие пытались исполь─ 
зовать для этого мерцание трёх экранов (R, 
G,B),но выглядело это неприятно для глаза. 
Был  также вариант с мерцанием двумя экра─ 
нами (2-color, если предыдущий вариант на─ 
зывать  3-color, а  всю идею - X-color). В 
том числе его разновидности с чередованием 
экранов чересстрочно ("gigascreen" по наз─ 
ванию устройства SchemeMan'а ) или волнами 
(демонстрировалось на демопати Forever ). 
  Отдельно  можно  рассматривать мерцание 
двумя экранами с мультиколором (например,в 
Eye Ache 2, с понтами названное 2048-цвет─  
ным). 
  Был  и вариант от Volga Soft (демо Free
Art ),где картинка строилась чередующимися  
строками трёх цветов. 
  В  8 color editor был компромиссный ва─ 
риант - чересстрочное  мерцание трёх экра─ 
нов, то есть из трёх цветовых составляющих 
каждый раз  не видна  только  одна. На это 
можно  было хотя бы  смотреть без боли, но 
картинка получалась слишком тёмная,а зани─ 
мало это почти всё время процессора. 
  Каждый  может себе представить, сколько 
различных комбинаций могут породить разные 
комбинации  числа экранов, размеров пиксе─ 
ля, шага мультиколора и конкретных ограни─ 
чений на атрибуты. Например, в ZX-Guide #2 
я их насчитал 44, и это были не все вариа─ 
нты. Но  какая из этих комбинаций наиболее 
эффективно передаёт реальный цвет? 

           1. Набор оттенков

   Мерцание тремя экранами даёт в среднем,
безусловно, все  цвета, но  каждый пиксель
может быть окрашен только одним из станда─
ртных восьми. Возможность генерировать от─
дельные  атрибуты  для  каждого знакоместа
каждого из кадров рассматривалась, в част─
ности, на коммодоровской сцене, но вряд ли
кто-то видел практические результаты.
   В итоге gigascreen может дать более ре─
альные цвета,несмотря на все его ограниче─
ния. Но  проблема  gigascreen'а  и  прочих
способов мигания двумя экранами - невозмо─
жность  стандартизировать результат смеше─
ния цветов.
   Дело  в  том, что  на  Pentagon яркости 
BRIGHT=0  и 1 отличаются примерно вдвое, а 
на фирменных машинах - весьма незначитель─
но.А соответствие комбинации чёрный+цвет -
конкретной  яркости немигающей сетки этого
цвета - зависит  не только от гамма-харак─
теристики и времени послесвечения, но даже
от текущих настроек монитора.
   Долгое  время использовался согласован─
ный  с  Diver'ом (он  использовал на своём
"Скорпионе" соотношение неяркий = 50% сет─ 
ка  яркого, что особенно видно на картинке
"Alone" )стандарт,что чёрный+яркий равняе─ 
тся неяркому цвету.Этот стандарт,тоже наз─
ванный  Alone, даёт минимум цветов - всего
83, зато  предсказуемых, если пользователь
настроит  свой  экран с его учётом (обычно
хватало ручек яркости и контраста). Журнал
Info Guide для фотографий всегда использу─ 
ет именно этот стандарт, ещё с тех времён,
когда редактировался на реальном "Пентаго─
не". Проблема  в  том, что позже сам Diver 
отказался  от этого стандарта в пользу па─
литры Pulsar. Под неё сейчас рисуются кар─
тинки на демопати,показываемые в эмуляторе
без мерцания и также (исторически некорре─
ктно) называемые "gigascreen". Разумеется,
эта  палитра  не  соответствует фирменному
железу, причём неизвестен даже разброс его
характеристик.
   То есть, как ни крути, но  используя 2-
color  общего вида, вы не можете рассчиты─
вать,что зарубежные пользователи (основной
потребитель  продуктов  "48K only" и "128K
only" ) увидят вашу картинку правильно. 
   Можно  ли как-то ограничить 2-color для
большей совместимости? Безусловно.
   Простейший выход - отказ от использова─
ния  яркости  и разделение картинки на два
слоя с известными характеристиками. Допус─
тим,слой цвета и слой ч/б.Перспективно для
цветных чанков, но бесперспективно для фо─
тографий - именно из-за проблемы в заголо─
вке: мы ограничены всего шестью плоскостя─
ми в цветовом кубе, в которые даже не впи─
сывается телесный цветопереход.
   Другой  вариант  использовался  в Crazy
Love - выбираем  конкретные  два  цвета на 
чёрном  фоне  и конвертируем в них. Но это
опять ограничивает число оттенков. Даже не
получится классическая комбинация цианотип
+ сепия (именно  это  называлось в истории
кинематографа термином "мультиколор"), ра─
зве что заменить оранжевый на красный или,
допустим, желтый - но  во втором случае вы
останетесь без белого.
   Можно  использовать три цвета с мульти─
колором,как упомянутые Volga Soft. Или че─
тыре, как  у  нас  на кубике в интро (оно,
кстати, работает  и на фирменном 48K ). Но
надо  учесть, что отдельные цветовые линии
могут  фильтроваться кодировкой. В том ку─
бике цвета были еле видны после проектора,
когда мы его тестировали на "Дне космонав─
та" в 2019 году. 
   Интерес представляет R-Mode (под 128K )
- вариация  4 цветовых слоёв, где атрибуты
не фиксированы, но нет яркости и допустимо
только несколько цветовых комбинаций (один
слой  использует  только атрибуты 0B и 0Y,
другой  только  0R  и  0C, третий 0G и 0M,
четвёртый  всегда  0W, атрибуты  выводятся 
push'ем в  верхнем бордере). Этот  режим я 
пытался пробивать  ещё  во времена  ACNews
#59, но  до сих пор не вышло ни одного ре─ 
лиза с его использованием.Возможно,потому,
что gfx maker'ы,специализирующиеся на кон─
версиях в 6912, беспомощны в других видео─
режимах, а художники, которые рисуют сами,
пасуют  начинать  без  специализированного
удобного инструмента.

           2. Видимые дефекты

   В  случае  фотографий  замазать границы
знакомест планированием рисунка не получи─
тся. Поэтому все дефекты выбранного метода
в плане использования квадратов будут вид─
ны. В  частности, конвертированный 2-color
всегда содержит видимые квадраты,а мульти─
колор или MCX (мультиколор на 2 экранах) -
видимые полоски. Причём полоски эти - ран─
домные, так  что  вопреки  интуиции R-Mode
выглядит лучше, чем MCX, несмотря на огро─
мные  ограничения  и огромную же  экономию
процессорного  времени! Можете легко срав─
нить MCX и R-Mode  в конверторе Con18 - не
знаю  других конверторов с этими режимами,
так что ссылаюсь на свой.
   Видимые дефекты бывают и из-за упомяну─
той проблемы несоответствия палитры (соот─
ношение   яркостей,  гамма-характеристика,
кривая  послесвечения) у автора картинки и
у пользователя.
   Бывают  и  другие проблемы, связанные с
границами знакомест.Известна,например,беда
"Пентагона"  с  показом последовательности 
знакомест  ink N (paper не важен), paper N
(ink  не  важен), где соседствуют пиксели,
казалось бы, одного цвета, но в реальности
между ними палка.
   Известны  также нелинейные искажения на
границах  цветов. Например, первое время у
нас в журнале картинки мерцали через атри─
бутную  сетку 8x8, и это выглядело на реа─
льном "Пентагоне" лучше, чем мигание спло─
шными  атрибутами - из-за  того, что кадры
меньше  отличались друг от друга на глаз и
не  приводили  к  разному  масштабированию
строки на CRT из-за разной яркости. Но по─
том  выяснилось, что у некоторых пользова─
телей  сетка  только ухудшает вид, так что
от неё пришлось отказаться.
   Конечно, сейчас  уже не принято ставить
себе  мониторы  с  искажениями на границах
цветов  и масштабированием и сдвигом строк
в зависимости от их окраски,но не зная ре─
ального железа и рисуя или конвертируя под
эмулятор  с аккуратными квадратными пиксе─
лями, gfx maker  рискует скатиться в фейк─
бит и хипстерство.

        3. Динамический диапазон

   Одно из простейших решений в случае ча─
нков  4x4 - наложить  один  яркий  цвет на
другой яркий цвет.Это проверенный временем
метод.Его можно отрисовывать чересстрочно,
как  в  Eye Ache 2, Anamnesis  или Stellar
Contour, таким  образом  исключить  адское 
мигание  за счёт потери тактов. Можно даже
чередовать  яркие и неяркие строчки - нес─
мотря на несовместимость уровней, в данном
случае никто почти не заметит разницы. По─
чему? Потому  что  цветов  будет всего 64,
все они "значимые", без каких-либо штрихо─
вок  и  прочих  цветопереходов.
   Но  попробуйте сконвертировать фотогра─
фию  в  64  стандартных цвета (такая опция
есть в Photoshop'е) без штриховки.Годится?
Никуда не годится!Даже упомянутый вариант,
когда  второй  слой - ч/б, выглядит лучше.
Потому  что там есть хоть какая-то регули─
ровка яркости. Даже чёрно-белая фотография
со штриховкой и то красивее!
   Так мы постепенно подходим к выводу,что
живость  фотографии обеспечивается динами─
ческим  диапазоном, или, во всяком случае,
он сильно влияет на результат.
   В  одной клетке 4x4 помещается всего 16
пикселей - это  17  уровней яркости. И это
большая  клетка, на  ней мы теряем детали.
Если  использовать  сетку  4x4  на клетках
меньшего  размера, мы  всё равно будем те─
рять детали. Если использовать распростра─
нение  шума  типа  Floyd-Steinberg, мы всё
равно будем терять детали, хоть и меньше.
   А теперь скажите - вы видели ZX-Stag?

     4. Нет, мы приличные мальчики

   Так  вот - когда  чередуется  несколько
картинок с разными фазами штриховки, недо─
статки  этих  штриховок  компенсируют друг
друга. Глаза,мозги и прочая требуха каким-
то образом вычисляют среднюю яркость. При─
чём вычисляют её на протяжении целой секу─
нды или около того,судя по моим экспериме─
нтам.И ещё несколько результатов этих экс─
периментов. Чем  чаще  меняются  картинки,
тем лучше результат. Чем менее заметно ци─
клы, тем лучше результат. Чем картинки бо─
лее похожи, тем лучше результат. Чем лучше
выглядит  каждая  картинка в отдельности -
тем лучше результат.
   Сразу  отметаем хранение 16 независимых
картинок для каждой фазы штриховки 4x4. На
128K  буржуйского  ОЗУ  каждый килобайт на 
счету.(Хочешь Спектрум без проблем - поку─
паешь АТМ. ) Поэтому будем штриховать про─
граммно.
   Чтобы  штриховать программно, нам нужен
образ  картинки с глубиной цвета 4 бита на
пиксель и в удобном формате.
   Формула штрихования:

pixel = pixture[y][x] > chunkpixelnumber 
            [(y+yshift)&3, (x+xshift)&3];

   Где:

int chunkpixelnumber[4][4] = { 
 {0x0, 0xc, 0x2, 0xe},
 {0x8, 0x4, 0xa, 0x6},
 {0x3, 0xf, 0x1, 0xd},
 {0xb, 0x7, 0x9, 0x5} 
}; 
x, y = 0..3; 
xshift, yshift  зависят  от  номера кадра. 
Допустим, скачут ходом коня. 

   Но если мы будем возиться с каждым пик─
селем, то картинка будет обновляться слиш─
ком медленно. Поэтому найдём самые популя─
рные группы по 4 пикселя (если отличие в 1
уровень  яркости - считаем, что совпало) и
выводим так:

       pop bc ;4pix + 4pix
       ld l,c
       ld a,(hl) ;%abcd0000
       inc h
       ld l,b
       or (hl)   ;%0000efgh
       ld (de),a
       inc e
       pop bc ;4pix + 4pix
       ld l,b
       ld a,(hl) ;%0000efgh
       dec h
       ld l,c
       or (hl)   ;%abcd0000
       ld (de),a
       inc e 
;47 t/b (чуть больше 4 фреймов весь экран) 
;Таблицы = 16*2*256 = 8K. 
;Образ картинки = 12K. 

   Так  что эта программа вместе с данными
помещается  даже в 48K. Даже в Timex с ап─
паратным  мультиколором при разлиновке ме─
тодом Volga Soft. Но практика показала,что
разлиновка по три строки сильно портит де─
тали, да  и  Таймексы  нынче  непопулярны.
(Можно  ли  вывести эти атрибутные полоски
на  оригинальном 48K? Можно, я писал такой
код, но  он очень жирный, да и времени под
эффект не остаётся)

    5. Как же мы раскрасим картинку?

   Понятно,что видеорежимы,пожирающие про─
цессорное время, не годятся для такого ин─
теллектуального вывода. Так что в качестве
видеорежима  возьмём  R-Mode.  Con18 умеет
выгружать  не только сам R-Mode (пиксели с
атрибутами), но и 8-битные модели его сло─
ёв, а мы выбросим пиксели  и воспользуемся
только атрибутами и этими моделями слоёв.
   Разрешение каждого слоя - 96x256, всего
4 слоя, так что образ картинки займёт 24K.
Это  всё ещё в допустимых пределах размера
нижней  памяти и огрызка 7-й страницы, где
лежит один из используемых экранов.
   Надо только покрасивее уместить отрисо─
вщик в 224 такта, выделенных на одну стро─
ку, ведь  каждую  строку  надо переключать
номер экрана. Пишем так:

mcpush1q 
       if PENT
       ds 1
       else
       ds 11 ;10=глюк справа вверху на +3
       endif 
mcnoisepicH=$+2 
       ld sp,repic 
mcnoisescraddrH=$+2 
       ld de,0x4000 
curchunkH=$+1 
       ld h,rebyte1/256 
mcloop0 
;max +122 (119-1,120-1 или 126-1 (ld h,N)) 
        exx
        out (c),d ;screen change at +138
        exx 
;+142 
       pop bc ;4pix + 4pix
       ld l,c
       ld a,(hl) ;%abcd0000 ;slowmem
       inc h
       ld l,b
       or (hl)   ;%0000efgh ;slowmem
       ld (de),a ;slowmem 
;+185 
       pop bc ;4pix + 4pix
       ld l,b
       ld a,(hl) ;%0000efgh ;slowmem
       ld l,c 
;+210 
        pop bc ;4pix + 4pix ;!!!!!!!!!
       inc e
       dec h
       or (hl)   ;%abcd0000 ;slowmem 
;+235 = +7 
       ld (de),a ;slowmem (write at +16) 
;+16 
       inc e
       ld l,c
       ld a,(hl) ;%abcd0000 ;slowmem
       inc h
       ld l,b
       or (hl)   ;%0000efgh ;slowmem 
;+48 
       ld (de),a ;slowmem (write at +55) 
;+56 
       pop bc ;4pix + 4pix 
;+66 
       inc e
        nop ;!!!!!!!!!!!!!!!
       ld l,b
       ld a,(hl) ;%0000efgh ;slowmem
       dec h
       ld l,c
       or (hl)   ;%abcd0000 ;slowmem 
;+104 
       ld (de),a ;slowmem (write at +111) 
;+112 
;----------------- 
        inc e
        exx
        out (c),e ;screen change at +132
          ;(nowait),нельзя сдвинуть назад
        exx 
;+136 
       pop bc ;4pix + 4pix
       ld l,c
       ld a,(hl) ;%abcd0000 ;slowmem
       inc h
       ld l,b
       or (hl)   ;%0000efgh ;slowmem
       ld (de),a ;slowmem
       inc e ;47 
;+183 
       pop bc ;4pix + 4pix
       ld l,b
       ld a,(hl) ;%0000efgh ;slowmem
       ld l,c 
;+208 
        pop bc ;4pix + 4pix
       dec h
       or (hl)   ;%abcd0000 ;slowmem 
;+229 = +1 
       ld (de),a ;slowmem (write at +8) 
;+8 
       inc e
       ld l,c
       ld a,(hl) ;%abcd0000 ;slowmem
       inc h
       ld l,b
       or (hl)   ;%0000efgh ;slowmem 
;+40 
       ld (de),a ;slowmem (write at +47) 
;+48 
       pop bc ;4pix + 4pix 
;+58 
       inc e
        nop ;!!!!!!!!!!!!!!!
       ld l,b
       ld a,(hl) ;%0000efgh ;slowmem
       dec h
       ld l,c
       or (hl)   ;%abcd0000 ;slowmem 
;+96 
       ld (de),a ;slowmem (write at +103) 
;+104 
       if PENT
       ds 3
       endif
       inc e
        jr nz,mcloop0 ;+120 
;+115 
       inc d 
;+119 
   И аналогично ещё 3 строки.Дальше повто─
ряется.
   Разные задержки - для разных машин (+2/
+3/Pentagon) . ATM считаем Пентагоном. 

   Как и ожидалось, на некоторых картинках
это  выглядит лучше голого R-Mode. Во вся─
ком случае, более живо. И всё ещё остаётся
возможность  выводить  чёрно-белые спрайты
поверх картинки.
   Кому как, а мне кажется,что хоть в паре
дем это надо использовать хотя бы для ути─
рания носа коммодорщикам, которым даже па─
мяти не хватит на такой фокус :)
   Примеры в приложении,конвертор тоже,ис─
ходники  тоже, а я это написал и перешёл к
другим проектам!



Другие статьи номера:

Help - Об оболочке журнала

Editor - От редактора

Scene - ZX Spectrum в 1997 году: создание Спектрумовского клуба (в Питере)

Scene - ZX Spectrum в 1998 году: хакерская деятельность в отношении Черного Ворона

Scene - ZX Spectrum в 1999 году: трейдеры перестали покупать софт

Scene - ZX Spectrum в 1999 году: никаких трейдеров в Хакасии не осталось, да и не было практически

Scene - ZX Spectrum в 2000 году: можно со спокойным сердцем завязывать со Спектрумом и уходить на РС

Scene - ZX Spectrum в 2001 году: А много ли вообще пользователей Спpинтеpа?

Code - этюды по программированию на ZX Spectrum

Code - эффекты ротаторов и ротозумеров

Code - О туннелях и небоскреба

Code - 3D движок для Elite

GFX - Фотореализм: способы передать ненасыщенные цвета, присущие реальным фотографиям

GFX - Подготовка графических ресурсов при создании игр на ZX Spectrum

Music - софтовый движок OPL синтеза для AY (часть 1)

Music - софтовый движок OPL синтеза для AY (часть 2)

Music - Bintracker: в поисках идеального трекера для создания биперной музыки

Системки - NedoOS истоки: История NedoOS уходит корнями в далёкие 90-е годы.

Системки - NedoOS истоки: в 2007 Fido фактически умерло и я перешёл в Интернет

Системки - NedoOS истоки: 2 октября 2018 года наконец вышел первый релиз графического редактора gfxed

Системки - Разработка с помощью NedoOS

Hard - 8 битный порт Kempston джойстика с 3 дополнительными кнопками

Wild - тетрис в 256 байт и змейка размером 55 байт

Games - Войти в геймдев: переизобретение текстовых игр

Games - устройство игры Super Mario Bros от Gogin

Games - Marsmare устройство игры и самописный инструментарий: ассемблер, редактор спрайтов, редактор карт, IDE

Games - Смесь игр Twins и Tetris

Games - Глюки с ULAplus: несколько игр, сделанных в AGD устанавливают неправильную палитру ULAplus

Mail - errata: игры из СССР

Mail - Отзывы на Info Guide #12

Mail - Авторы журнала


Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
12TK info - О защиты игры 12 тайный книг-миссия.
Спектрум - обзор прессы.
Handling global variables in Evo SDK - we shall expand Evo SDK possibilities again
Обмен опытом - Game Making 2: всевозможные методы вывода спрайтов (по мотивам игры Full Shit).
Рек-тайм - Реклама и объявления ...

В этот день...   6 декабря