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

[tae1980]

это интересно когда?

Я не умею ванговать. Так что не знаю когда это наступит.

не надо плодить очередные rsid-ы и psid-ы под одним расширением

GRF имеет чётко выраженную структуру хранения данных. Моё мнение, всё что в неё вписывается должно иметь общее расширение и различаться по заголовку.
Мне например нужны, GRF с двумя и более палитрами, для создания палитровых эффектов и иных издевательств над палитрой. И таких форматов может быть много.
В заголовок можно внести дополнительные поля, например автора, дату создания, редактирования и прочее. А так же иные данные, например иконку, или даже превъющку.
Можно выводить текст поверх картинки.
Всё это будет вписываться в структуру формата GRF.

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

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

ну а патчить картинку чтоб она соответствовала новому стандарту он ее тем более не будет

Вот тут не понял. Зачем нужно патчить картинку если она соответствует стандарту? Не нужно делать плохой стандарт и вначале думать, это да.

[Advertiser]

[Dec]

В заголовок можно внести дополнительные поля, например автора, дату создания, редактирования и прочее. А так же иные данные, например иконку, или даже превъющку.
Можно выводить текст поверх картинки.

А чем это будет лучше, чем, например, tiff?

[tae1980]

А чем это будет лучше, чем, например, tiff?

А почему оно должно быть лучше или хуже?
В чем особенность GRF от других форматов? В его ориентированность на байтовое хранение данных и чередование данных графики-цвет. Всё.
Много это или мало? Достаточно, что говорить о нём как о самостоятельном формате.

Я пищал от восторга когда разбирался с GIF, все думают это графический формат в котором можно хранить анимацию. Но это не более 1% от его возможностей. По сути сам файл контейнер, в котором могут быть блоки совершенно любого назначения, в них может быть даже выполняемый код. Например, он может можно не просто хранить отдельные кадры, а кадры произвольного размера, можно указывать в какое место экрана их выводить, с какой задержкой, можно вывести текст поверх изображения и менять его. Можно проиграть музыку. Можно просто хранить внутри кусок текста, например описание или инструкцию. И т.п. При этом любая программа просмотра GIF возьмёт из него только то что её нужно, проигнорируя не нужные или не известные для неё данные.

Вот GIF я бы и брал за основу.

[Dec]

Просто куча спектрумовских форматов напоминает такую картинку:



Чем условный bmp был плох для хранения растровой графики? В BITMAPINFOHEADER есть чудненькое поле Compression. Делов то было - выбрать свое значение, которое будет использоваться внутри zx-комьюнити. 1000h - multicolor с раздельным хранением точек/цветов, 1001h - с последовательным хранением, и т.д. Но в жизни каждого разработчика стоит великая цель - разработать свой самый лучший и удобный формат хранения данных.

[izzx]

У меня просмотрщик GRF на расширение файла не смотрит, только по заголовку или размеру определяет тип файла. Поэтому идея с разными расширениями мне не нравится ).

[tae1980]

Чем условный bmp был плох для хранения растровой графики?

Идеология BMP - описываем один пиксель, от 1 до 4 байт. Может и есть что-то внутри, но это уже костыль. И не факт что при использовании этого костыля, сохраниться обратная совместимость.

На самом деле на спектруме два формата с которым я имел дело в 99.9%? это grf и файлы в формате стандартного экрана (в CP/M - *.ctr). Был ещё pcx, как первый источник для формирования grf.

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

Использование форматов с иных машин (с того же IBM PC), так же упирается в то что в своей основе они организованы с оглядкой на пиксельное хранение данных. Так же не стоит забывать про то что у нас железные ограничения значительно выше чем на других машинах, как по объёму памяти и работе с ней, так и по скорости проца. А значит прямой перенос готовых решений как правило невозможен. Тот же bmp при прочих равных, будет грузиться у нас в 2-4 раза дольше. Вернёмся к этому вопросу когда у нас появится видеокарта.

Я планирую использовать следующие форматы:
grf - для хранения одиночных картинок. Но возможны множественные палитры.
scr - данные в формате физических экранов. Так же планируется заголовок по которому можно будет определить для какой машины этот файл. Для Профи 32кб.
xx1 - формат похожий на gif, но способный хранить несколько картинок. Возможно тут можно использовать grf с хитрым заголовком.
xx2 - формат открытки. Интерактивный формат. Отличие от xx1 в том что тут уже может быть музыкальное оформление и минимальное взаимодействие с пользователем (например, ожидание нажатия любой клавиши). Возможно это стоит объединить с xx1 или даже grf.

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

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

уточнение формата - 3 байта - содержит расширение, во избежании.
целевое железо - 3 байта - для какой машины создавался файл, будет иметь значение для железо-зависимых данных, для остальных информационное.
дата создания - 8 байт - формат ддммгггг.
время создания - 6 байт - формат ссммчч.
дата редактирования - 8 байт - формат ддммгггг.
время редактирования- 6 байт - формат ссммчч.
автор - 16 байт - текст
примечание - 32-64 байт - текст, комментарии и т.п.
Или так, единое поле автор.примечание - 32-64 - разделитель "0". Снимает ограничение на длину поля "автор", правда за счёт длины поля "примечание". Минус 1 байт на разделитель.

Даты можно хранить в 3 байтах и сохранять сколько прошло дней с Рождества Христова, на сегодня это 737763 дней. Или выбрать иную дату, поближе, тогда можно уложиться в 2 байта, их хватит примерно на период в 179 лет.
Время так же можно хранить в 3 байтах и сохранять число секунд прошедших с полуночи, максимальное значение 86400.
Эти форматы удобны тем, что для переход между дата/временем, нужно просто прибавить или вычесть нужное значение. Нет проблемы высокостных годов, месяцев 30 или 31 день (про февраль, вообще молчим), переходом между часами/минутами и прочее.

[Dec]

Идеология BMP - описываем один пиксель, от 1 до 4 байт

Повторюсь, внутри bmp может все что угодно, метод кодирования описан в поле Compression.

И не факт что при использовании этого костыля, сохраниться обратная совместимость.

Обратная совместимость с чем?

Тот же bmp при прочих равных, будет грузиться у нас в 2-4 раза дольше

За счет чего произойдет увеличение, если данные внутри bmp ничем не будут отличаться от обычных данных обычных спектрумовских файлов?

Так как grf был первым, придется взять его за основу

Не вижу причинно-следственной связи между "был первым" -> "придется". У grf даже сигнатуры файла нет, что бы определить, что файл действительно grf.

[tae1980]

Обратная совместимость с чем?

С иными програмами, в том числе на иных платформах.
Сделать можно "что угодно", и на назвать это "как угодно". Но что от этого измениться?
Тут всё просто, проводим натурный эксперимент. В чём смысл использования чужих стандартов? Получить совместимость. Если её не будет, за чем городить огород?
Для проверки теории нужно вручную подготовить один BMP в котором информация хранится по байтно. И давайте пробуемым открыть этот файл в разных программах. Например, в том же Фотошопе. Откроется - я готов рассмотреть этот вариант, нет - не вижу смыла даже говорить о нём.
Касаемо GRF, мы имеем совместимость со всеми программами под CP/M и как минимум две под Тырдос. Тогда как для работы с предлагаемым форматом BMP, нет ни одной программы (как минимум на Профи).

А чем формат BMP с по байтным хранением данных будет отличаться от GRF? Только заголовком? Как ты собираешься хранить данные о графике и цвете?

Не вижу причинно-следственной связи между "был первым" -> "придется". У grf даже сигнатуры файла нет, что бы определить, что файл действительно grf.

Это было предложение, не так нет. Смысл предложения в стандартизации, если GRF выпадает, значит предложение распространяется на оставшиеся форматы.

[Dec]

И давайте пробуемым открыть этот файл в разных программах. Например, в том же Фотошопе

Так и grf не откроется в Фотошопе.

Схему с использованием bmp я описал как вариант, который я бы использовал (много лет назад), если бы у меня была необходимость создать новый формат хранения растровой графики для zx. Насколько это актуально сейчас - я не знаю.

Как ты собираешься хранить данные о графике и цвете?

Если поле Compression = N+0, то сначала линейно идут все байты точек, затем идут все байты цвета.
Если поле Compression = N+1, то линейные байты точек и цвета чередуются.
Если поле Compression = N+2, то сначала по столбцам идут все байты точек, затем идут все байты цвета.
Если поле Compression = N+3, то байты точек по столбцам и цвета чередуются.

Я бы сделал как то так.

Это было предложение, не так нет.

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

[tae1980]

Так и grf не откроется в Фотошопе.

А GRF должен в нём открываться? А вот BMP должен.

На самом деле, если ты хочешь что-то сделать на основе grf - то делай.

То же самое могу сказать про несовместимый ни с чем BMP. Будет время и желание - поддержу, но пока его нет.
Сейчас есть два графических редактора которые работают с GRF, один с исходниками. Несколько вьюверов, набор разных утилит и прочее.
Ты предлагаешь вариант того же самого GRF, но не совместимый ни с чем. В чём логика? В том что "ты хочешь это сделать"? Но тогда при чём тут другие?

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