Как корректно декомпрессировать файл используя zlib?

Question

[PGSky]

Здравствуйте. Необходимо декопрессировать файл в формате .binfont. Как видно из названия, это шрифт, при том из относительно малоизвестной игры. У меня нет опыта в этом, но пообщавшись с некоторыми людьми, выяснил, что этот файл, по сути bitmap, который сжат с использованием zlib. Первое изображение, которое прикладываю, это то, что люди мне отметили с пометкой, что сжато дважды. Собственно, тут видно, что zlib-компрессия (78 9C)



Используя offzip, я декомпрессировал файл. Пришлось это сделать дважды, т.к. во втором случае, файл тоже сжат. Ну, это ожидаемо

В конечном итоге я получил два файла. Один весом 5кб, а второй 128кб (финальный). И вот этот финальный файл, у меня вызывает большие вопросы. Ведь вроде это не bitmap.



В общем, нужна помощь, т.к. для меня это всё темные дебри и вожусь с этим уже более суток, ничего не добившись

Answer 1

[Daemon23RUS]

Слегка похоже на RAW RGBA
первые три байта цвет (черный) и прозрачность, но кусочка скрина недостаточно. так что это предположение.
PS . RAW RGBA дает такую картину, но что то мне кажется что разрядность альфаканала или порядок байт еще не верен, да и цвет должен черным быть, а синего по краям быть не должно, в

Image.frombuffer("RGBA", (256, 256), data, "raw", "RGBA;4B", 0, 1)

Может коллеги подскажут ...

Comments

[PGSky]

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

spoiler

[Daemon23RUS]

PGSky, Скриншот добавляет баллов к моему предположению

[Daemon23RUS]

PGSky, Попробуй кажый 4й байт рассматривать как битмап, при разных соотношениях(ширина х высота, может что и удастся "увидеть"

[PGSky]

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

[Daemon23RUS]

PGSky, А такой вопрос, а во всем файле каждые 3 байта в 0, паттерн по всему файлу 00 00 00 хх подходит ?

[PGSky]

Daemon23RUS, нет, паттерн не подходит.


Я прошелся по каждому 4му байту с помощью такого кода (разрешение условное, но ведь где-то же оно должно храниться):

from PIL import Image

data = open("0000000c.dat", "rb").read()
img = Image.frombuffer("RGBA", (256, 256), data, "raw", "RGBA;4B", 0, 1)
img.save("0000000c.PNG")

И получил такой результат

[Daemon23RUS]

PGSky, ну это тогда точно RGBA - 32 бита битмап, 24 бита на цвет и 8 бит на прозрачность. Поздравляю Вы на правильном пути !!!

[PGSky]

Daemon23RUS, спасибо) Но как это все преобразовать в удобоваримый вид, вообще не представляю. Повторюсь, для меня это темный лес, даже то изображение, что выше приложил, удалось получить только следуя Вашим советам и поиску способа преобразования RAW RGBA в изображение в сети. И это еще не касался обратной стороны, ведь нужно будет всё потом как-то обратно запаковать, чтобы игра воспринимала

[Daemon23RUS]

PGSky, img = Image.frombuffer("RGBA", (256, 256), data, "raw", "RGBA;8B", 0, 1) что покажет ?

[PGSky]

Daemon23RUS,
ошибка

[Daemon23RUS]

PGSky, Файлик бы в облако закинул, может кто в теме, что дельное и подсказал. Визуально формат виден, как его конвертнуть во что то годное, еще тот вопрос, RGBA/RGBX, на скрине, синего быть не должно, по крайней мере на первых байтах исходя из предположения должно быть все в ч/б
с "RGBA;8B" - нет такого кодека, тупанул, но нужный -не помню ...

[PGSky]

Daemon23RUS, да мне бы самому разобраться, ведь дальше с этим файлом работать. Но да, согласен, синего не должно быть. Да даже по тем же FF и 00, это видно

[PGSky]

Daemon23RUS, прогнал через C#, как более привычный мне ЯП и получил такой результат. Правда параметры ширины и высоту подбирал на свой взгляд, а не проводил расчеты (128x256px, в иных случаях результат либо искажается, либо дублируется)

[Daemon23RUS]

PGSky, очень похоже на 32битный bmp, XRGB без сжатия, создай подходящий по размеру файл, отрежь заголовок (около 0x46 или 70 байт) и прилепи в начале к своему файлу, есть ньюанс, не все графические пакеты адекватно открывают 32 XRGB, Но редактировать а потом конвертить уже можно будет (убирая заголовок)

[PGSky]

Daemon23RUS, а что это конкретно даст? Я ведь могу и BMP отредактировать, потом конвертировать его в RAW и дальше. Тут скорее вопрос в другом. Сейчас я пытаюсь каким-то образом выяснить размер (именно ШИРИНАxВЫСОТА) изображения. Я подумал, что можно взять количество байтов и поделить на 4, ведь мы проходим по каждому байту и каждый байт соответствует 1 пикселю, но так я получу только общее количество пикселей, а не соотношение сторон

[Daemon23RUS]

PGSky, Общее колво пикселей поделить на например на 8 - будет высота, и если с таким размером (8х высота) получится вертикальная простыня с символами, то соотношение сторон верное. А проще говоря - ширина кратна 8 (может это будет другое число, но такое, чтобы символы в вертикаль выстроились)

[Daemon23RUS]

PGSky, и 1 пикселю соответствует 4 байта (3 цвет и 1 прозрачность)

[PGSky]

Daemon23RUS, текущий мой код, если width != 128 или height != 256, искажает изображение. Использую Bitmap C#. Если ширина выше 128, то начинается дублирование контента. Если ниже, то обработка массива байтов выходит за пределы и выдает ошибку

[Daemon23RUS]

PGSky, и тут соотношение сторон хорошее, есть ньюанс в том что в центре символов цвет должен быть черный, что видно по байтам, а он белый, а вот края символа (для черного) - ок (антиалиасинг)

[PGSky]

Вернее не дублирование, а искажение. Видимо 128x256px правильные значения для высоты и ширины. Другое дело, что я дальше не представляю, как игра с этим шрифтом работает. Файл имеет приписку 12x15. Я предполагаю, что игра разбирает это изображение на меньшие (Tiles если правильно помню). Только вот при ширине 12 пикселей на один элемент шрифта, в некоторых случаях в одном тайле получается два символа или части других включая первый символ

[Daemon23RUS]

PGSky,

екущий мой код, если width != 128 или height != 256, искажает изображение

64х512
32х1024
16х2048
....

[PGSky]

Daemon23RUS, я же прохожусь строго по байтам. Все 4 позиции rgba, соответствует байтам последовательно. Для себя я сделал 4й байт (прозрачность) равным 255

[Daemon23RUS]

PGSky,

Файл имеет приписку 12x15.

по факту не бьется с тем, что видим в битмапе, возможно движок добавляет padding по 2px

[PGSky]

Daemon23RUS, при WxH, если W меньше 128, то программа не работает. При H выше 256, я это проверял сделав 4й байт 255, не важно какое значение 128 (за исключением, что должно быть равно или больше 128), появляется пустой пространство в документе. Т.е. если установить 256x1024, то во-первых, изображение станет как бы сжатым (и дублированным), а во вторых, внизу появится пустое пространство. Прикладываю результат при параметрах 256x1024, как демонстрация

spoiler

[PGSky]

Daemon23RUS, по факту так и есть. По факту то, что мы видим в результате, какие параметры для разбивки не задавать, никак не собрать tilemap адекватный, с равными значениями, т.к. особо и всматриваться не надо, чтобы понять что в одной строке больше символов чем в другой. Из чего я начал подозревать, что этот шрифт в игре и не используется, либо там какой-то другой способ его использования. Ну, либо я неправильно сформировал изображение (что вряд ли)

[Daemon23RUS]

PGSky,

если W меньше 128, то программа не работает.

Это странно, просится 8х4096

[Daemon23RUS]

PGSky, хотя ... 15 символов, не 16 ... странно

[PGSky]

Daemon23RUS,

Это странно, просится 8х4096

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

[PGSky]

Daemon23RUS,

хотя ... 15 символов, не 16 ... странно

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

[PGSky]

По 15 в строке

[Daemon23RUS]

PGSky, возможно, 128х256 - истинный размер, из которого движок дергает тайтлы произвольного размера по смещению от верхнего правого (любого) угла

[Daemon23RUS]

PGSky,

По 15 в строке

8х4096 - при таком раскладе, не вариант.

[PGSky]

Daemon23RUS, тогда локализовать вряд ли получится

[Daemon23RUS]

PGSky, Почему, корявенько вписать - вполне, а еще поле пустое виднеется, может движок какие символы и оттуда потянет, да и если тайтлы переменного размера, должна быть инфа по ширине высоте для каждого кода ascii + координаты

[Daemon23RUS]

PGSky, вот то что 128 на 15 не делится, это странно, как то все не логично выглядит

[PGSky]

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

[Daemon23RUS]

PGSky, + символы по верхнему значимому пикселю ровняются, а это + к вариативному тайтлу. С локализацией варианты есть, надо движок глубже колупать, файл шрифта по формату Вы победили (почти 100%)

[PGSky]

Daemon23RUS, в том то и дело, что в игровых файлах, а не вижу ничего что как-нибудь бы помогло в этом вопросе. Возможно есть в исполняемых файлах, то там прям нужно углублять в реверс-инжиниринг. К тому же, это игра для Nintendo Switch (вернее порт с NDS на NSW). И тут почему-то они решили изменить структура шрифта. В оригинальной игре 5 видов шрифтов было (один из них чисто под японскую версию). Здесь же, всего 1 шрифт

[PGSky]

В крайнем случае, и это конечно некрасиво, можно заменить английский шрифт на русский, а весь русский текст преобразовать в соответствующие символы, грубо говоря Привет на на русском станет BCDFG, но это прям в крайнем случае и явно некрасивый метод

[PGSky]

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

[PGSky]

В итоге сейчас проблема в том, что я не могу обратно запаковать файл, чтобы игра его воспринимала. С помощью offzip смог распаковать. Там вообще, до 78 9C есть еще значения и они обрезаются. Т.к. файл два раза компрессирован изначально, я его также два раза декомпрессировал, чтобы получить raw rgb

И вот, при обратной запаковке, используя python и zlib.compress(), я получаю файл, который дальше не грузится. Забавно, что если удалить HEX значения до 78 9C в исходном файле, 7Zip его не открывает. Если добавить новому файлу, не оригинальному, эти значения, 7zip открывает. Я думал, что это мусорные значения, но у меня есть подозрения, что возможно там хранится что-то важное, в том числе и offset для разбора шрифта игрой

[PGSky]

Хотя конечно мне это ничего не дает, а Вам наверное и тем более