GMX Pic View

[izzx]

Всем привет.
Сделал вьювер изображений для экрана Scorpion GMX и сконвертировал несколько картинок к нему.
Всего картинок 19, больше на диск и не влезет без сжатия. Каждая весит 32768 байт.
Выкладываю вьювер и конвертер к нему. Конвертер кушает только специально подготовленные в GIMP по размеру и цвету картинки.

Была мысль сделать поддержку формата GRF.
На АТМ и Профи есть похожий графический режим с байтом цвета на байт пикселей, то есть 2 цвета на строчку 1*8 пикселей. Есть коллекция картинок в формате GRF, конвертеры, вьюверы.
Но я пошёл своим путём, потому что у них больше цветов.
На АТМ экран 640*200 2 цвета на байт из палитры 64. Профи 512*240, 2 цвета на байт из палитры 256. А на GMX только 16 стандартных цветов.
В общем, смотрим только своё, родное.




2020 09 19 GMXPV and GMXCSA.zip

Новые версии с поддержкой GRF:
2020 10 06 GMXPV v1.1b.zip
2020 10 07 GMXPV v1.1c.zip
2020 10 13 GMXPV v1.2.zip

Upd.
Самые свежие версии тут
Или здесь

Понимает форматы:
- Свой формат (32768 байт, копия экрана GMX)
- GMX #0f - свой формат (16128 байт, копия атрибутов)
- GRF Profi mono (ч.б.)
- GRF Profi 16c
- GRF Profi 256c (16 из палитры 256)
- GRF (BLK) ATM 64c (16 из палитры 64)
- ZX 6144, 6912, 6913
- Font 2048
- IFL - Multicolor (8*2) (9216 байт)
- MLT - Multicolor (8*1) (12288 байт)
- MC - Multicolor (8*1) (12288 байт)
- MCX - Multicolor (8*1) (24576 байт)

Эмулятор Unreal, настроенный на GMX. Запустить, нажать F3 чтобы выбрать образ дискетки. И Enter запустить.

Универсальный конвертер, в том числе в родной формат pic view:
DaDither.

Для Профи:
Img2Grf. Конвертер изображений в файлы формата GRF.
Картинки от Профи.

Для АТМ:
RetroX to GRF v0.1 converter. Утилита для создания цветных GRF картинок.
Картинки от АТМ.

[Advertiser]

[tae1980]

Сделай поддержку GRF. Режим 16 цветов, является стандартным режимом для Профи, а режим с палитрой 16 из 256 цветов - расширенным. Сейчас работаю над добавлением в свой конвертер возможности работать в режиме 16 цветов. Так его можно будет использовать для подготовки изображений под GMX.

Вообще GRF - это универсальный формат, к тому же расширяемый (для Профи есть две версии: для стандартных 16 цветов и с палитрой). Незачем плодить кучу несовместимых. Более того в твоём случае можно поддержать вывод картинок с палитрой. Просто перед выводом нужно пересчитать палитру и привести цвета к ближайшим стандартным цветам. Я это делаю через "серость", пока только на ПС. Все цвета приводим к серому (число 0-255), после чего находим ближайшие значения. Конечно цвета "поплывут" и часть изображения может "пропасть", но это лучше чем ничего. Подобный финт у меня запланирован для моего вьювера под CP/M. Правда могут быть проблемы с форматом хранения цвета, но если что придётся конвертировать на лету.

Небольшое отступление: не знаю как у GMX, но у Профи возможны три режима работы с цветами: 8 цветов+яркость единая для чернил и фона+мерцание, 16 цветов (яркость раздельная для чернил и фона, нет мерцания), палитра 16 из 256. Все режимы аппаратные и не могут быть сразу на одной машине. Режим 16 цветов эмулируется в режиме палитры 256. Режим 8 цветом, считатся "вымершим". Для универсальности формат хранения цвета совпадает с форматом стандартного спекки.

[izzx]

tae1980, спасибо за разъяснения. Попробую сделать GRF, если смогу. Для GMX родной режим "8 цветов+яркость единая для чернил и фона+мерцание", да и то с яркостью мне не понравилось. Лучше только 8 цветов. Ещё и размеры пикселей наверняка разные у разных машин.

- - - Добавлено - - -

Да, поддержка GMX в твоём конвертере будет очень кстати.

- - - Добавлено - - -

В смысле поддержка 16 или лучше 8 цветов. Хотя выключить бит яркости и при просмотре не долго. Так что можно и 16.

[tae1980]

Попробую сделать GRF, если смогу.

Формат очень прост. Вот описание для Профи.
Обращаю внимание, что минимальная длина заголовка 128 байт, но может быть и больше (+8). Но последнее скорее всего для нас не актуально, хотя я рассматриваю возможности внесения изменения. В "+9", хранится признак стандартности, в настоящее время там либо 0 - цвета стандартного спекки, либо 19 - палитра 16 из 256. При чем различий 8 или 16 цветов нет. Но возможно стоит ввести для универсальности, так как 16 цветные картинки начнут моргать, на тех машинах где этот режим не поддерживается. Думаю подобное различия не ввели так как 8 цветные Профи, были крайне не продолжительное время.

Скрытый текст

Формат Profi GRF:
+0 слово DW HSIZE горизонтальный размер картинки в точках
+2 слово DW VSIZE вертикальный размер в строках растра
+4 байт DB BPP бит на точку или точек в байте (в зависимости от AMOD)
+5 байт DB AMOD 1 - цвет на каждую точку, 0 - байт аттрибутов на байт точек
+6 слово DW BPS длина образа одной строки растра в байтах
+8 байт DB HLEN длина заголовка в записях по 128 байт (и 0, и 1 соответствует 128 байт)
+9 байт DB 0 признак стандартного формата ( если формат будет изменяться, изменится и этот байт )
+10 118 х DB 0 резерв
или палитра (при +9=19($13)). 16 байт по 1 байту на цвет в формате GGGRRRBB

BPP AMOD режим хранения информации
--- ---- -----------------------------------------
8 0 PROFI-mono
4 0 PROFI-color (байты точек и аттрибутов чередуются, точки раньше аттрибутов)
2 1 CGA (4 цвета, байт описывает 4 точки)
4 1 EGA (16 цветов, байт описывает 2 точки)
5 1 VGA (32 цвета, байт описывает 1 точку)
8 1 VGA (256 цветов, байт описывает 1 точку)

Причем я встречал вроде картинки только PROFI-color (байты точек и аттрибутов чередуются, точки раньше аттрибутов) и Profi-Mono

[свернуть]

- - - Добавлено - - -

В смысле поддержка 16 или лучше 8 цветов.

8 цветов - единая яркость для чернил и бумаги, 16 цветов - яркость раздельная. Такие названия используются на Профи.
Алгоритмы подбора цветов будут разные.

[izzx]

tae1980, а картинки от АТМ откроются на профи? Или наоборот. Раз уж формат универсальный. И как будут выглядеть, как задумано или с искажениями?

[tae1980]

а картинки от АТМ откроются на профи? Или наоборот. Раз уж формат универсальный. И как будут выглядеть, как задумано или с искажениями?

Сама картинка да. Но насколько я знаю, формат заголовка у них другой. Хотя могу и ошибаться. Уж не знаю зачем и почему, но информацию о палитре на АТМ засунули в начало заголовка. Решения, на мой взгляд, граничит с бредом, так как в конце заголовка есть куча зарезервированного места, а сам заголовок можно "бесконечно" расширять. Но, повторю, я могу ошибаться, так как у меня нет точной информации, только её обрывки. И конечно будут проблемы с пересчётом палитры.

У формата GRF в целом есть как плюсы так и минусы. Это линейной формат, графика в нём храниться линейно, что упрощает навигацию по файлу, а сама картинка не привязана к формату физического экрана, и информацию можно без проблем выводить даже в окно, или картинка может быть больше/меньше физического экрана. Но при выводе нужны дополнительные вычисления, что его замедляет.
В нашем случае он удобнее иных форматов, например bmp, так как точки в нём хранятся побайтно, их по сути их нужно просто правильно прочитать.

[NEO SPECTRUMAN]

нету скриншота с эмулятора
непорядок!


- - - Добавлено - - -

а где нибудь можно увидеть сам алгоритм конвертации?
мне как раз нужен алгоритм конвертации из 16 цветов на пиксель
в такой "аппаратный мультиколор"
а тут на вид результат не плохой

[tae1980]

а тут на вид результат не плохой

Жаль что это всё проявлятся только сейчас, а в 90х каждый тянул одеяло на себя.
Подобная графика была бы тогда бомбой. Физически возможности были уже в начале 90х, а по факту программы способные раскрыть их возможности в полной мере появляются только сейчас.

а где нибудь можно увидеть сам алгоритм конвертации?

На знаю какой именно алгоритм использовал izzx, но у меня лучший результат в 85% случаях даёт такой: просматриваем цвета в байте, находим:
* подсчитываем частоту появления цветов для байта, правого и левого полубайта
* самый темный/светлый цвет для байта, правого и левого полубайта, находим средние значения.
* если в байте 1, 2 цвета, то проблем нет.
* если в байте 3 цвета, берём самый частый и альтернативный ему по серости.
* берём за основу самый частый цвет в байте, определяем он "светлый" или "тёмный" и в каком полубайте этот цвет встречается чаще. Вторым цветом берём самый частый альтернативный цвет из другого полубайта.
* Проверяем оба цвета на идентичность, если они одинаковый - подбираем иной цвет по аналогичной схеме, если цвета в полубайте заканчиваются (например, там все цвета в той же серости, что и основной цвет), переходим в полубайт с первым основным цветом.

Самый лучший результат по резкости даёт аналогичная схема, но когда берут за основу самые светлые и тёмные цвета. Но тут часть базовых цветов может "поплыть", так как самые светлые/темные цвета не обязательно самые частые.
Можно не использовать полубайты, но по моим ощущениям с ними результат на 10-15% лучше.

[izzx]

NEO SPECTRUMAN, у меня довольно простой алгоритм. Сначала в GIMP всё приводится в 16 (15) цветов. Потом в конвертере цвета 0-3 и 8-11 считаются фон, цвета 4-7 и 12-15 считаются пиксель. Затем высчитывается какого цвета из строчки 8 пикселей больше, тот и становится цветом байта, и так же фона.
Приложу код на C#.

2020 09 18 gmxcsa source.zip

Такой код выдаёт 8 цветов. А чтобы было 15 надо раскоментировать две строчки bright=1

А где взял скриншот из эмулятора? Я думал нету эмуляторов на GMX. Без эмулятора трудно ).

[tae1980]

Затем высчитывается какого цвета из строчки 8 пикселей больше, тот и становится цветом байта, и так же фона.

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

Примеры работы алгортимов

[свернуть]