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

[izzx]

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

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

[Dec]

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

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

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

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

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

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

[tae1980]

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

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

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

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

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

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

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

[izzx]

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

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

[Dec]

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

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

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

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

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

[tae1980]

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

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

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

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

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

[Advertiser]

[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]

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

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

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

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

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

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

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

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

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

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

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

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

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

[izzx]

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

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

[Dec]

Как напомнили мне выше, как минимум для того что бы разместить в нем палитру.

NEO SPECTRUMAN описал ULAPlus файлы. Какую палитру ты хочешь добавлять к стандартным SCR файлам?

Не "читателя", а "программиста".

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

Не понимаю почему это плохо.

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

Для формата SCR на "не родных" машинах/режимах, нужно всего лишь написать разбор перед выводом. Чем это отличается от вывода BMP формата?

Тем, что для bmp не нужно знать аппаратных особенностей той платформы, на которой он был создан.

Ты бредишь!

Ок, позиция ясна.

Но ни где это не использоваться.

То, что ты или условный фотошоп не используют сжатие в bmp не обозначает, что эта возможность нигде не используется.

И создать из BMP уродца, которого не сможет прочитать ни одна из существующая программ

Что так привязался к bmp? Я ведь тебе пишу "cоздай нормальный продуманный формат", а не "непременно используй bmp". "Так и хочется спросить, ты чужие сообщения вообще читаешь?"
Твой новый формат (точнее планируемое тобой расширение) точно также не сможет прочитать ни одна из существующая программ.

Различать файлы исключительно через их размер - каменный век.

А каков на данный момент алгоритм, позволяющий отличить grf файл от случайного набора байт?

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

Можно просто добавить еще один костыль дополнительный флаг в файл.