GMX Pic View

[izzx]

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

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

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

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

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

[Advertiser]

[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, так как точки в нём хранятся побайтно, их по сути их нужно просто правильно прочитать.

[Максагор]

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

Даю информацию по формату файлов мультиколорных картинок АТМ под режим аппаратного мультиколора 640x200. Формат создавался в начале 90-х под написанный тогда же под ATM-версию CP/M по заказу "МикроАРТ" графический редактор GRAF. И там данные картинки имели расширение BLK. Позже я под OS TASiS написал вьювер этих картинок GRFVIEW.COM. Но так как в TASiS еще со времен iS-DOS расширение BLK зарезервировано за драйверами дисковых устройств (типа BLK - блочное устройство) и, чтобы избежать путаницы, здесь им было присвоено "свободное" расширение GRF - производная от названия редактора GRAF. А далее, собственно, о формате.


Только замечу, что у вас несколько неточные представления о заголовке. Он имеет фиксированную длину в 0084hex (или, соответственно, 132dec) байта. Вообще "удивлен удивлением" вас, ибо в том же стандартном факле картинок BMP также заголовок и данные о палитрке помещены в начале (хотя и не так, как в BLK/GRF, что естественно).

                ФОРМАТ BLK(GRF)-ФАЙЛА
                =====================

   Смещение     Кол-во                     Значение
 ============  ========                  ============
    #0000      #30(16x3)    Палитра. Представляет собой 16 троек
                            значений GRB-цветов  (именно в таком
                            порядке), представленных в виде сим-
                            волов ASCII:

                            "0"(#30) - цвет (G,R или B) выключен
                            "1"(#31) - цвет низкой интенсивности
                            "2"(#32) - цвет в режиме BRIGHT 0
                            "3"(#33) - цвет в режиме BRIGHT 1
                            Любое другое значение приравнивается
                            утилитой GRFVIEW к "3".

    #0030(*)   #03          Метка "GRF" -  означает,  что за ней
                            следуют два значащих байта

    #0033(*)   #01          Рекомендуемые атрибуты (INK & PAPER)
                            заднего фона,  на который налагается
                            изображение. Актуально для картинок,
                            по размеру меньших 640x200.

    #0034(*)   #01          Рекомендуемый цвет бордюра (#00-#0F)
                            Может быть актуально при использова-
                            нии нестандартной палитры.

    #0035      #4B          Не  используется.  Может быть забито
                            любым мусором.

    #0080(**)  #01          X-координата (0-79)  левого верхнего
                            угла выводимой картинки,  измеряемая
                            в столбцах  (1 стлб= 8 пикс= 1 байт)

    #0081(**)  #01          Y-координата (0-199) левого верхнего
                            угла выводимой картинки,  измеряемая
                            в строчках (1 стр = 1 пиксель)

    #0082      #01          WIDTH -  ширина  картинки в столбцах
                            (от 1 до 80)

    #0083      #01          HIGH -  высота  картинки  в строчках
                            (от 1 до 200)

    #0084   WIDTH*HIGH      Растр    монохромного   изображения.
                            Представляет  собой   последователь-
                            ность   слева  направо  столбцов  от
                            1 до x   (x = WIDTH),  состоящих  из
                            y байтов  каждый (y = HIGH),  считая
                            сверху вниз.

#84+WIDTH*HIGH #nnnn        Растр  атрибутов.   Полная  аналогия
                            растра  монохромного  изображения по
                            структуре,  с той лишь разницей, что
                            он прилагается  в упакованном по ме-
                            тоду RLE виде. То есть, представляет
                            из себя последовательность двухбайт-
                            ных слов,  первый  байт в  каждом из
                            которых означает количество  (1-255)
                            последовательно   идущих  одинаковых
                            байтов атрибутов,  а  второй  байт -
                            собственно, само значение атрибута.

----------------------------------
Примечания:

*) НОВОВВЕДЕНИЕ специально  для  утилиты GRFVIEW.  В оригинале -
неиспользуемый участок. Может быть забит любым мусором.

**) Необязательные параметры X и Y картинки, особенно для утили-
ты GRFVIEW, где изображение автоматически центрируется,  в соот-
ветствии со своими габаритами.

Теперь, что касается палитры: если конвертировать ТОЛЬКО в данные режим, можно подбирать любую адаптивную палитру - на PROFI такая картинка, если будет полноразмерная может не влезть целиком в экран по ширине (зато с избытком поместится по длине ибо 640х200 на ATM против 512x240 на PROFI). Но если задача сделать так, чтобы картинка нормально смотрелась и на GMX и на АТМ, значит надо конвертировать в спектрумовскую палитру. А она в этом заголовке будет выглядеть так (далее подразумеваются не цифры, а символы ASCII цифр):

000 - черный
002 - синий
020 - красный
022 - фиолетовый
200 - зеленый
202 - голубой
220 - желтый
222 - белый
000 - снова черный
003 - ярко-синий
030 - ярко-красный
033 - ярко-фиолетовый
300 - ярко-зеленый
303 - ярко-голубой
330 - ярко-желтый
333 - ярко-белый

При конвертации картинок надо помнить, что как и в GMX, пиксели по горизонтали "сплюснуты" в два раза по сравнению со спектрумовским режимом.

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

- На АТМ похоже формат столбиками, а не линейный.

Именно так. Причем сначала идут столбики биткарты, а затем столбики атрибутов, которые к тому же упакованы (метод описан выше). Сам формат байта атрибутов аналогичесн атрибуту в режиме спектрум-экрана, за исключением того, что бит флэш-мерцания заменен на отдельную яркость для INK и PAPER (в случае стандартной спектрумовской палитры, естественно. А по сути - это четвертый бит для выбора одного из 16 цветов). Итого получаем:

Биты:
0,1,2 - цвет для INK
3,4,5 - цвет для PAPER
6 - яркость для INK
7 - яркость для PAPER

- В новом формате нужна чёткая метка что за версия формата. А то не отличить АТМ от Профи.

Можно для отличия использовать поиск надписи "GRF" в заголовке (три байта по смещению 0030hex), и так определять, что это АТМ. Если попадется древний файл из CP/M, который этих букв не содержит (так как это моя модификация заголовка, не мешающая просмотру картинок СТАРТЫМИ вьюверами и редактором 90-х), то их можно вставить через любой HEX-редактор,а число картинок с модифицированным заголовком давно уже в разы превысило "древние" картинки.

- Наверно и палитра нужна, без неё не выйдет.

Собственно, формат палитры в заголовке я описал. А если конвертировать палитру с современных картинок (предварительно ужав до 16 цветов одновременно), переводя 24-битный цвет (где кажая компонента RGB имеет значение от #00 до #FF), то так как палитра АТМ имеет глубину цвета в два бита, то можно или просто в PC-палитре отбрасывать бладшие 6 битов каждо компоненты (и тогда RGB будут иметь только значения #00,#40,#80, #C0), а лучше брать усредненные значение - #00,#55,#AA,#FF - как показывает практика, они наиболее адекватны. Я в фотошопе "баловался" с адаптивной палитрой - получалось весьма неплохо.

[izzx]

Максагор, спасибо. Я вот ещё в палитрах ничего не понимаю. В граф. редакторе понятно как выбрать значения RGB и посмотреть что это за цвет. Но
- В заголовке мы описали какие в этой картинке цвета. А в конкретном атрибуте как они кодируются? Так же как обычно в ZX битами 0-5?
- Где почитать как приводить к ZX палитре эти варианты RGB?

О, уже ответил похоже.

[Максагор]

Максагор, спасибо. Я вот ещё в палитрах ничего не понимаю. В граф. редакторе понятно как выбрать значения RGB и посмотреть что это за цвет. Но
- В заголовке мы описали какие в этой картинке цвета. А в конкретном атрибуте как они кодируются? Так же как обычно в ZX битами 0-5?
- Где почитать как приводить к ZX палитре эти варианты RGB?

О, уже ответил похоже.

Тогда специально заострю внимание на спектрумовской палитре:

G R B
=========
#00 #00 #00 - черный
#00 #00 #AA - синий
#00 #AA #00 - красный
#00 #AA #AA - фиолетовый
#AA #00 #00 - зеленый
#AA #00 #AA - голубой
#AA #AA #00 - желтый
#AA #AA #AA - белый
#00 #00 #00 - снова черный (если делать имитацию "ярко-черного" как на некоторых самодельных клонах спектрума, т.е не 15, а 16 цветов, то можно взять значение #55 #55 #55, а в GRF-файле, соответственно, "111")
#00 #00 #55 - ярко-синий
#00 #55 #00 - ярко-красный
#00 #55 #55 - ярко-фиолетовый
#55 #00 #00 - ярко-зеленый
#55 #00 #55 - ярко-голубой
#55 #55 #00 - ярко-желтый
#55 #55 #55 - ярко-белый

P.S. Набор GRF-картинок формата АТМ для экспериментов с вьювером можно взять, например, здесь:
http://atmturbo.nedopc.com/download/...w/grf_pict.zip
Единственное что там мало в какой из них именно спектрумовская палитра - я их почти все конвертировал через работу с адаптивной палитрой в фотошопе. Так что на GMX, где палитру менять нельзя, многие картинки будут выглядеть "неправильно" (но, как минимум, отображение "монохромной" (т.е. без вывода атрибутов) части будет нормальным, и, кстати, монохромные картинки там тоже есть), а вот на PROFI нормальный просмотр цветов возможен.

[tae1980]

им было присвоено "свободное" расширение GRF - производная от названия редактора GRAF

Вывод: 1) это совершенно разные форматы. 2) на мой взгляд, тут допущена ошибка в выборе названия расширения, так как данное уже занято, при чём как минимум с начала 90х.
Теперь уже как есть, придётся усложнять алгоритм разбора заголовка.

в том же стандартном факле картинок BMP также заголовок и данные о палитрке помещены в начале (хотя и не так, как в BLK/GRF, что естественно)

Насколько я понял из анализа имеющейся информации, формат GRF был "позаимствован" на Профи с других машин. Подробностей найти не смог, но сами возможности формата выходят далеко за возможности экрана Профи. И я не пойму откуда вы взяли, что у BMP палитра в вначале. Первыми символами идут "BM", а дальше технические данные о картинке, и только за ними палитра. Более того палитра может имеет переменные размеры. Повторю ещё раз, сама идея помещать в начало файла, информацию которая может иметь переменную длину, лично мне кажется не дальновидной и указывающую на плохую проработку теории. И не важно, что в данный момент на текущем железа палитра стандартна, всегда нужно думать о будущем.

зато с избытком поместится по длине ибо 640х200 на ATM против 512x240 на PROFI

За то Профи он выше, что позволяет разместить 30 строк, а не 25. Может не будем мериться чем либо?
Я не восторге от "войны" форматов в прошлом, и тем более не собираюсь её вести в настоящее время. Нужно как-то выходить из сложившейся ситуации.

Но если задача сделать так, чтобы картинка нормально смотрелась и на GMX и на АТМ

Скажу за себя, я бы хотел выработать единые механизмы и стандарты для просмотра графики на любых расширенных экранах, любых клонов.
Нужно выходить на стандартизацию.

[izzx]

Скажу за себя, я бы хотел выработать единые механизмы и стандарты для просмотра графики на любых расширенных экранах, любых клонов.
Нужно выходить на стандартизацию.

А мы так не придём к тому же bmp? Всеми признанный стандарт.