А вот в старшей тетраде следующего байта ($07 смещение в секторе) - очень бы подошло хранить указатель палитр.
Кажется что лучше иметь место для всех 4 палитр агат-9, тогда можно этим байтом пользоваться при указании палитр для других режимов (в соотв с таблицей выше).

Еще думается что Можно отдельно указывать что картинка создана для "колокольчика". Это важно так как у Агата оттенки серого через разъем "видеосигнал" совершенно иные чем должны быть серые оттенки соответствующих цветов. Считай как еще одна палитра.
На это страничке есть таблица, там в колонке "Grey color" видно что например зеленый темнее красного.
http://agatcomp.ru/agat/Hardware/Monic.shtml

0 - палитра 1 агат-9 (по умолчанию которая)         
1 - палитра 2 агат-9
2 - палитра 3 агат-9
3 - палитра 4 агат-9                   
4 -                       
5 -                   
6 -                 
7 -
8 - палитра 1 агат-9 (оттенки серого через "видеосигнал")
9 - палитра 2 агат-9 (оттенки серого через "видеосигнал")               
A - палитра 3 агат-9 (оттенки серого через "видеосигнал")
B - палитра 4 агат-9 (оттенки серого через "видеосигнал")
C -
D -
E -
F - таблица палитр в байтах R - $08...$0F, G - $18...$1F, B - $28...$2F. Т.е. рисунок для ячейки палитр.

Позвольте узнать, в связи с чем у вас интерес к этому вопросу?

В своем конвертере для режима 256х256 color я позволяю пользователю выбрать палитру из трех палитр: черный+RGB,  белый+RGB или 4096. Если для последнего все понятно, то для первых двух возникает неоднозначность при отображении. Хотелось бы конкретики.

По вашей спецификации младшая тетрада байта "режим" свободна. Следующий байт также свободен. Можно в эти байты писать код палитры.

Можно наверное выделить байт под это, и возможно, там же указывать под какой монитор рисовалось (для девятки это актуально, они почти все с "колокольчиками", и картинки в основном рисовались с расчетом на три оттенка серого а не RGB).

Позвольте узнать, в связи с чем у вас интерес к этому вопросу?

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

Предлагаю вам, как автору спецификации, добавить в спецификацию кодирование палитры в том виде, в котором вам это видится наиболее правильным.

- Смещение в секторе $04, $05 - сигнатура хвоста (VideoRam).

***

- $06 : РЕЖИМ

В старшей тетраде сообщается режим отображения:

0 - резерв ( или нестандартный режим "АГАТ"? например конкретика в младшей тетраде этого байта)         
1 - 256х256 b/w МГВР
2 - Т32
3 - Т64                   
4 - 64х64                       
5 - 128х128                   
6 - 256х256 color ЦГВР                 
7 - 512х256  МГДП
8 - резерв
9 - 280х192 HiRes               
A - T40
B - T80
C - 40х48 LoRes
D - 80x48 Double LoRes
E - 140x192 Double Hires color
F - 560x192 Double Hires b/w

***

- char_set - $10...$17 актуально только для текстовых режимов.

Имя загружаемого знакогенератора, использованного для создания изображения.
Вместо имени могут быть указаны стандартные ЗГ:

АГАТ7 - расширенный зг Агат-7 (256 знаков)
АГАТ9 - стандартный зг Агат-9 (256 знаков)

***

- Цвета для платы палитр. Каждому из 16 Агатовских цветов задается любой из палитры 4096 цветов (12 бит).
По 4 бит на компоненту: R - $08...$0F, G - $18...$1F, B - $28...$2F.
Если все три группы обнулены, то используется стандартная палитра ЭВМ.
Для режимов Агат своя, для режимов Apple своя.

На рисунке выше задана палитра как у Commodore64 ( https://www.c64-wiki.com/wiki/Color )

#000000  Black
#FFFFFF  White
#880000  Red
#AAFFEE  Cyan
#CC44CC  Violet / purple
#00CC55  Green
#0000AA  Blue
#EEEE77  Yellow
#DD8855  Orange
#664400  Brown
#FF7777  Light red
#333333  Dark grey / grey 1
#777777  Grey 2
#AAFF66  Light green
#0088FF  Light blue
#BBBBBB  Light grey / grey 3

Которая на реальном Агате загружается так:

Cx00: 00 0F 08 0A 0C 00 00 0E 0D 06 0F 03 07 0A 00 0B
Cx10: 00 0F 00 0F 04 0C 00 0E 08 04 07 03 07 0F 08 0B
Cx20: 00 0F 00 0E 0C 05 0A 07 05 00 07 03 07 06 0F 0B
Cx38: 00

И еще:
Как известно, в реальной ЭВМ, все режимы отображения подключают для себя цвета из основного (16 цветного) набора:
Монохромные #0 для фона и #F для пера;
ЦГВР #0 для фона и #1, #2, #4 для пера;
HGR #0 для фона и #1, #2, #4, #5, #7 для пера.
Таким образом задавая в соответствующих ячейках цвета, можно изменять палитру этих режимов. 

***

- Область комментария $40...$FF

Любые подробности в свободной форме: дата, автор и т.д.

Эта свободная область в 252 байта все равно таскается с файлом везде, ведь она часть файла. Копировщики агатовские (и дос33с2 кстати) её исправно копируют, графические редакторы не портят при перезаписи картинки. FIL-файлы тоже её носят в полном объеме.

Смещение от начала файла
у 256х256ц, 512х256 и DHIres - $4004,
у 128х128 , 256х256м и HIres - $2004
у Т32, Т64 , 64х64 и DLOres - $0804
у Т40  и LOres - $0404

Вот я и подумал, чем нули таскать туда сюда, можно там хранить что-то полезное.
Мне вот понадобилось хранить что, что я описал выше. Вопрос в том, как грамотней организовать формат этого хвоста, так сказать с оглядкой на будущее.
Учесть всё что может понадобится из инфы и правильно расположить.
Я смогу придерживаться всегда этого стандарта, и потом какой-то софт (если захочет) сможет воспользоваться этой инфой.

Например, какие-то внешние проги, скажем DOS33C2 или FIL Converter смогут самостоятельно выставить (без такой подсказки это невозможно) правильный режим при просмотре, правильную цветность и палитру, для текстовых еще и правильный ЗГ. Или даже показать табличку с комментариями.

Ну или в внутри агата прога типа https://agatcomp.ru/agat/Software/Graphic/Sirius.shtml
может вывести на экран инфу из этой области, что полезно очень.

Т.е. если прога нашла какую-то пометку (типа "VRAM") что этот хвост содержит инфу - хорошо, можно воспользоваться этим. Не нашла - ну значит пусто там, старые файлы все такие.

Почему меня заинтересовало это, я уже наклепал более 100 картинок для текстовых режимов, на многих до сих пор держу некоторые данные прям на экране, (что не всегда возможно):

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

И еще, про старые картинки, я вот время от времени правлю испорченные картинки (ну когда диск при всех стараниях не прочитался нормально), вот тут подробности:
https://agatcomp.ru/agat/PCutils/filConverter.shtml
С удовольствием бы там оставлял в области комментариев что это реставрированная картинка а не полный оригинал, это может потом пригодится. Это только пример из жизни.

Только я не понял: ведь уже написанные программы ничего про этот "хвост" не знают и не ожидают лишних данных. Или предлагается ту длину данных, которая уже в начале файла прописана, не изменять? Или этот "хвост" будет только в новых картинках?

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

Я, например, рисуя текстовые экраны в псевдографике использовал это пространство как информационную область.
Но в таком виде, чтоб удобней было просматривать инфу любым HEX редактором (агатовским или внешним),
так как никаких других средств нет.
Хотя и написать простую прогу, даже на бейсике, наверное не сложно.
Делал это, просто потому что картинок налепил много, а некоторую инфу не засунуть в имя файла и на экране самой картинки не хотелось оставлять.

Сразу после графической инфы писал слово "VR (VideoRam)", чтоб потом отличить свои пометки от мусора и потом всё остальное.

* * *

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

0 - не задан         
1 - 256х256 b/w МГВР
2 - Т32
3 - Т64                   
4 - 64х64                       
5 - 128х128                   
6 - 256х256 color ЦГВР                 
7 - 512х256  МГДП
8 - резерв
9 - 280х192 HiRes               
A - T40
B - T80
C - 40х48 LoRes
D - 80x48 Double LoRes
E - 140x192 Double Hires color
F - 560x192 Double Hires b/w

Те же просмотрщики смогут стразу выставлять правильный режим и т.д.

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

А как вы считаете, что полезно разместить в этом хвосте? И каким образом лучше это сделать?