Img2Grf. Конвертор изображений в файлы формата 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 день (про февраль, вообще молчим), переходом между часами/минутами и прочее.

[Advertiser]

[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 с потерей совместимости с чем либо, я ни как не пойму. Несколько раз спрашивал на прямую, но и ты молчишь.

[izzx]

Я привёл несколько предложений по существу

Я посмотрел, пока возражений нету. Дело это сложное и ответственное. Думаю дату лучше в формате 8 байт, так проще и высчитывать ничего не надо потом.
Расширение в заголовке тоже полезное дело.
Код машины - вот тут скользкая тема. Так можно наплодить вариантов. Модификаций машин же много бывает. Может достаточно версии самого формата картинки.

[tae1980]

Код машины - вот тут скользкая тема. Так можно наплодить вариантов. Модификаций машин же много бывает. Может достаточно версии самого формата картинки.

Данный пункт относиться к формату SCR, который представляет собой просто кусок экранной памяти. Предположительно будут такие форматы:
* стандартный экран ZX.
* расширенный экран Профи.
* экран GMX.
Ну и другие машины со своими экранами. Можно кончено для каждого случая использовать своё расширение (как вариант: szx, spr, sgm) и вообще отказаться от заголовка. Но смысловая нагрузка тут одинаковая, а мой опыт показывает, что такую информацию лучше объединять.

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

Т.е. создание некого универсального формата, основанного на grf? Старое ПО сможет с ним работать?

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

Подобные проблемы есть и под виндой, например далеко не все вьюверы знаю,что tiff может быть много страничным и содержать геоинформацию.

Нужно это или нет? Я думаю, что нужно, особенно на начальном этапе. Да и внедрять новое проще (и правельнее) постепенно, чем переписывать "всё и сразу".
Простой пример. Есть на Профи редактор музыки SM, у него есть возможность загрузить картинку на рабочий стол, но во внутреннем формате. Для перевода картинок во внутренний формат есть специальная утилита, которая в качестве источника использует черно-белые GRF.

[tae1980]

Думаю дату лучше в формате 8 байт, так проще и высчитывать ничего не надо потом.

Замечание. Вычислять что нибуть нужно будет при любой форме хранения. Например, для сравнения двух дат, в случае с 3 байтным хранением, идёт простое сравнение двух чисел, в случае с 8 байтным довольно сложная процедура. То же самое с вычисление разницы между датами и т.п. Единственный плюс 8 битного хранения быстрая подготовка к выводу.

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

А для профи разве достаточно копии экранной памяти? А палитру загрузить? Или в заголовке будет?

Да, точно, совсем забыл про палитру. То есть заголовок нужен.

[Dec]

А вот BMP должен.

Я сейчас глянул на текущие методы сжатия в bmp и обнаружил, что помимо BI_JPEG и BI_PNG, о которых я знал, добавились BI_CMYK, BI_CMYKRLE8, BI_CMYKRLE4. Откроет ли такие файлы условный Фотошоп? Сомневаюсь. Обратная совместимость - это когда старые форматы открываются в новом ПО, а не когда новые форматы открываются в старом ПО.

Ты предлагаешь вариант того же самого GRF, но не совместимый ни с чем.

На самом деле я ни чего не предлагаю. Я лишь критикую текущие решения.

У меня это "унификация всего софта"

Т.е. создание некого универсального формата, основанного на grf? Старое ПО сможет с ним работать?