There are some unknow images, which I would like to decode to
RRGGBBAA format. It was a really hard work, but at the moment I can somewhat understand, that which part of the binary is responsible for what. But I'm stuck at the end, and I have no idea how to continue it. This is what I've found out:
I know, that the size of the first image is a 9*3.
There is some kind of table at the begining of the file:
0x08 0x08 0x10 0x08 0x08 0x08 0x00 0x00 0x00 0x10 0x10 0x18 0x18 0x18 0x20 0x10 0x14 0x18 0x08 0x08 0x10
And this is the image data:
0x09 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x0c 0x00 0x00 0x00 0x00 0x01 0x03 0x09 0x01 0x01 0x02 0x11 0x01 0x01 0x02 0x02 0x01 0x0f 0x0f 0x03 0x0a 0x03 0x08 0x05 0x08 0x04 0x08 0x03 0x09 0x00 0x09 0x00 0x0c 0x00 0x02
The number of elements in the table can be divided by three, so I think it is some kind of RRGGBB palette.
But I have no idea, how to decode the imagedata. It's size is not 9*3, so It may be compressed. It is a really small image, and I think that this is why the compression made the binary bigger than it was before.
I've uploaded this file here: Download file
I've colored it, to better understand it's structure.
The first part of the file:
- The red section is just some kind of file signature.
- The brown part is the file length in bytes. (1107)
- The green shows, how many images are stored in the file (currently one)
- The blue part shows, where the table begins ( 0x60 = at the 96th byte)
- The grey part shows, how long the content in the table is. Currently it's 7, so the table has 7*3 = 21 bytes, the other values are
- The table is marked with purple
The second part of the file:
- The blue part is the header of the image.
- The yellow part shows, how long the image is (51bytes)
- The red is the image width, and the brown is the height (3*9)
- The 8 zero bytes (selected with green) are the same in each file.
I've uploaded two more files.
The bigger file has a resolution of 800*600 And I suspect it is this one (screenshot):
At the beginning (from
3C0), only the the first two or three bytes are set in each 4 byte group. From
0xD28, I cannot recognise any pattern.
Spektre's code works with most of the files. But there are some small icons, with transparency, which look distorted.
For example this icon: Download
And this is how it looks like, over a brownish background:
In this case, the scanlines are not fixed-width. And the unknown
252 flags at the beginning of each scanline, and
254 flags after every 32bytes are also different.
I can recognise patterns and symmetry in the binary, but I haven't figured out yet, how it works.
I've colored the scanlines of the icon's imagedata, to have a better overview:
Many of them starts with, and all of them ends with
I uploaded some images, with screenshots:
I uploaded two more images, which I found distorted. The first is an icon, which is almost perfect. And the second one is a dragon, which is barely recognisable. Unfortunately I cannot provide screenshots for this two: Download
I implemented the core algorithm ( from Spektre's answer ) in JS. It can be found, and edited online here: JSFiddle link
I've made some progress with the mountain, and the dragon.
I think, that the first 7 bits of the flag byte shows, on which x coordinate the line starts ( ´xstart = flag>>1;´ ). The least significant bit is a switch, which marks, that the line has this offset or not. You can try/edit the current code here: JSFiddle link
The result is this:
The expected result would be similar to this (which is not far):
The distorted parts around the mountain are shadow/transparency, but I still wasn't be able to find any marks/flags about where the blocks with alpha values start and end.
I think, I've found a pattern in the mountain image. After the flag byte, the next byte may show, (
flag2>>1), how many
(Color, Alpha) blocks are at the beginning of the line.
The left side of the mountain looks slightly better now:
Unfortunately this change breaks the other images
0x388-0x38Bpoints everywhere to
0x3C0. The integer from
0x38C-0x38Fshows, where the image data ends. The 16bit integers at
0x3C2are width and height again. And the bytes from
0x3C4-0x3C7are always zero. As I see, only the
0x37C-0x383part - which is still unknown - is different in almost every image.