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

[Dec]

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

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

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

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

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

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

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

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

[Advertiser]

[tae1980]

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

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

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

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

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

[izzx]

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

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

[tae1980]

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

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

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

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

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

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

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

[izzx]

Данный пункт относиться к формату SCR, который представляет собой просто кусок экранной памяти. Предположительно будут такие форматы:
* стандартный экран ZX.
* расширенный экран Профи.

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

[Dec]

Данный пункт относиться к формату SCR, который представляет собой просто кусок экранной памяти

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

Да и внедрять новое проще (и правельнее) постепенно, чем переписывать "всё и сразу".

Вот только твой эволюционный путь от текущего grf формата к некому идеальному формату приведет к тому, что этот формат будет набором костылей. Я тебя спросил "А как мне различить, что файл создан для 8 цветной (общая яркость + мигание) или 16 цветной (яркость раздельная, мигания нет) машины?". Твой ответ - "Ни как. GRF это не предусматривает. Назначаем для "+9" новое значение и различаем по нему." Т.е. просто берем и добавляем еще один маленький костылек. И в конце развития твой формат превратиться в кучу этих костылей.

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

[tae1980]

А для чего вообще пихать дампы памяти в какой-то контейнер?

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

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

Не "читателя", а "программиста". И много я говоря не просто про эфемерную "совместимость", а про совместимость "среды ZX" в целом. При чём прозрачно для пользователя.
Примером этого служит возможность просмотра картинок подготовленных для Профи на GMX и на оборот. Или возможность просмотра картинок под стандартный экран на расширенном экране Профи. Не понимаю почему это плохо. Для формата SCR на "не родных" машинах/режимах, нужно всего лишь написать разбор перед выводом. Чем это отличается от вывода BMP формата?

Назначаем для "+9" новое значение и различаем по нему." Т.е. просто берем и добавляем еще один маленький костылек.

Ты бредишь! "+9" это признак не стандартного формата, то есть расширения. Это же в инструкции написано "черным по белому". Ты понял, что заголовок у GRF может быть любой длины, а не только 128 байт? У тебя не возникло вопроса "а за чем это понадобилось?", при столь "лаконичном" заголовке?

Что за двойные стандарты? Ты в курсе, что BMP может содержать упакованные данные? Но ни где это не использоваться. Наличие такой возможности - это костыль?
И создать из BMP уродца, которого не сможет прочитать ни одна из существующая программ, ни на одной плат форме - это не "использовать костыли"?

Подобный образ мысли преобладает у группы "НЕДО"что угодно. Из-за чего итоговый результат их работ "немножко с душком".

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

к которому по моему тоже пришлепывают палитры
только уже сзади а не в заголовках

Заголовок - это больше чем просто наличие палитры. Различать файлы исключительно через их размер - каменный век.

*****е экраны от профей и гмх-ов

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

[izzx]

Я думаю для начала можно добавить метку стандартных цветов ZX. Которые с общей яркостью. Чтобы как выше писали, отличалось от 16 цветов. Такое и на гмх можно будет просто открыть и на стандартном экране.

upd. Но правда не решён вопрос с разными пропорциями пикселей.

[NEO SPECTRUMAN]

Данный пункт относиться к формату SCR,

к которому по моему тоже пришлепывают палитры
только уже сзади а не в заголовках

A 6912 byte .SCR file contains a standard Spectrum screen.

A 6976 byte .SCR file contains a standard Spectrum screen followed by 64 colour registers.

A 12288 byte .SCR file contains a Timex hi-colour screen.

A 12352 byte .SCR file contains a Timex hi-colour screen followed by 64 colour registers.

A 12289 byte .SCR file contains a Timex hi-res screen.

A 12353 byte .SCR file contains a Timex hi-res screen followed by the hi-res colour information that was dumped from port 255, followed by 64 colour registers.

и детектитсо все по длине размерам

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

так что может можно хранить *****е экраны от профей и гмх-ов в обычном scr и не морочить голову
(ну кроме тех неотличимых вариантов с 8\16 цветами)

[tae1980]

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

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

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

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

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