DMI file format

ID:135103
 
Feb 15 2005, 5:58 am (Edited on Feb 15 2005, 7:54 am)
I'm not exactly sure which forum this goes in but I'm going to call it a query of a BYOND feature :P.

Anyway I'm working on building some functions in C# for loading, editing, and outputing DMI files. So far I've been using Lummox JR's post on the format as a guide([link]). But I'm a bit confused and need some clarification.

4 bytes:  icon ID
          Starts at 2 and goes up
          0 for transparent icons


I'm guessing this is a unique identifier for the icon but if so why is 0 used for transparent icons? My guess is that the transparent icons aren't stored in memory and the 0 ID is just a flag to indicate that I shouldn't bother reading for icon pixel data for this icon. But this is just a guess as it wasn't to explicit in the post. Is the 1 ID reserved for something? If I run into it in an icon file does that mean something is corrupt?

    n bytes:  Length of run (1 byte each)
    y bytes:  Color encoding


Is this a change in notation or am I missing something :P? I'm assuming Lummox JR means 1 byte is for the length of the run and n is the label he's using to refer to the value of the byte. Rather than n being the label refering to the number of bytes needed to represent this as it's explicilty stated that it is one byte anyway. Same with y for the encoding format of the current run.

        x = bits per color (1 for 2-color, 2 for 3-4, 3 for 5-8...)
        y = (n+k)*x/8, where 0<=k<8
        (y must be an integral number of bytes holding an integral number of x-bit values)
        e.g.:
            x=8, n=51: y=51
            x=4, n=51: y=52*4/8=26
            x=3, n=51: y=56*3/8=21
            x=2, n=51: y=52*2/8=13
            x=1, n=51: y=56*1/8=7


I'm lost here on everything but possibly the bits per color which I'm assuming is the number of bits needed to represent a unique palette index along the run. What is k and is y related to the y bytes for color encoding or is this just a clash of labels? Could someone elaborate for me the meaning and relations of these numbers and how they relate to getting palette index for the pixel?

[Edit] Whoops I should have read the subthreads :P. It atleast covers the last block.
[Edit2] Nevermind Flicks explaination doesn't make much sense as it is not RLE and storing n wouldn't make sense as x would be the same for every pixel and thus you already know how much to extract.
Feb 15 2005, 10:53 am
Theodis wrote:
I'm not exactly sure which forum this goes in but I'm going to call it a query of a BYOND feature :P.

Anyway I'm working on building some functions in C# for loading, editing, and outputing DMI files. So far I've been using Lummox JR's post on the format as a guide([link]). But I'm a bit confused and need some clarification.
4 bytes:  icon ID
          Starts at 2 and goes up
          0 for transparent icons
I'm guessing this is a unique identifier for the icon but if so why is 0 used for transparent icons? My guess is that the transparent icons aren't stored in memory and the 0 ID is just a flag to indicate that I shouldn't bother reading for icon pixel data for this icon. But this is just a guess as it wasn't to explicit in the post. Is the 1 ID reserved for something? If I run into it in an icon file does that mean something is corrupt?

You're pretty much right about the 0, I believe. I don't know why 1 isn't used, but you can safely ignore any ID besides 0 there.

    n bytes:  Length of run (1 byte each)
    y bytes:  Color encoding
Is this a change in notation or am I missing something :P? I'm assuming Lummox JR means 1 byte is for the length of the run and n is the label he's using to refer to the value of the byte. Rather than n being the label refering to the number of bytes needed to represent this as it's explicilty stated that it is one byte anyway. Same with y for the encoding format of the current run.

Nope, you're missing something. n and y are the number of bytes for each section here. n is the number of runs, so each of those bytes in the section is the length of a run.

Likewise y, the number of bytes in the color encoding section, is calculated in the following.

        x = bits per color (1 for 2-color, 2 for 3-4, 3 for 5-8...)
        y = (n+k)*x/8, where 0<=k<8
        (y must be an integral number of bytes holding an integral number of x-bit values)
        e.g.:
            x=8, n=51: y=51
            x=4, n=51: y=52*4/8=26
            x=3, n=51: y=56*3/8=21
            x=2, n=51: y=52*2/8=13
            x=1, n=51: y=56*1/8=7
I'm lost here on everything but possibly the bits per color which I'm assuming is the number of bits needed to represent a unique palette index along the run. What is k and is y related to the y bytes for color encoding or is this just a clash of labels? Could someone elaborate for me the meaning and relations of these numbers and how they relate to getting palette index for the pixel?

These aren't labels; they're variables. y is the number of bytes needed for color encoding. k is some number of unused x-bit color values, so that x*(n+k) bits is equal to an exact number of bytes (y).

Lummox JR
Feb 15 2005, 11:34 am
It's been a while since I futzed with this, so I hope I make some sense ;)


Theodis wrote:
I'm not exactly sure which forum this goes in but I'm going to call it a query of a BYOND feature :P.

Anyway I'm working on building some functions in C# for loading, editing, and outputing DMI files. So far I've been using Lummox JR's post on the format as a guide([link]). But I'm a bit confused and need some clarification.

> 4 bytes:  icon ID
>           Starts at 2 and goes up
>           0 for transparent icons
>

I'm guessing this is a unique identifier for the icon but if so why is 0 used for transparent icons? My guess is that the transparent icons aren't stored in memory and the 0 ID is just a flag to indicate that I shouldn't bother reading for icon pixel data for this icon. But this is just a guess as it wasn't to explicit in the post. Is the 1 ID reserved for something? If I run into it in an icon file does that mean something is corrupt?

No idea :P


>     n bytes:  Length of run (1 byte each)
>     y bytes:  Color encoding
>

Is this a change in notation or am I missing something :P? I'm assuming Lummox JR means 1 byte is for the length of the run and n is the label he's using to refer to the value of the byte. Rather than n being the label refering to the number of bytes needed to represent this as it's explicilty stated that it is one byte anyway. Same with y for the encoding format of the current run.

The two bytes previous to the 'n bytes' section tell you how many bytes n will take up. It might make more sense to think of it as 'Lengths of runs'. For example, if the previous two bytes say you have 28 runs, then n will be 28 bytes. Each byte tells how many consecutive pixels will be the same color. The first run byte tells how many pixels to apply the first color entry to.

>         x = bits per color (1 for 2-color, 2 for 3-4, 3 for 5-8...)
>         y = (n+k)*x/8, where 0<=k<8
>         (y must be an integral number of bytes holding an integral number of x-bit values)
>         e.g.:
>             x=8, n=51: y=51
>             x=4, n=51: y=52*4/8=26
>             x=3, n=51: y=56*3/8=21
>             x=2, n=51: y=52*2/8=13
>             x=1, n=51: y=56*1/8=7
>

I'm lost here on everything but possibly the bits per color which I'm assuming is the number of bits needed to represent a unique palette index along the run. What is k and is y related to the y bytes for color encoding or is this just a clash of labels? Could someone elaborate for me the meaning and relations of these numbers and how they relate to getting palette index for the pixel?

x is based simply on how many colors your icon palette contains. k is basically a made up number, used to force the length of the color encoding to the next even byte. y is the same y in 'y bytes for color encoding'.

So, x is your bits per color. n is the length of a section of bytes decribing your 'lengths of runs'. It's value is:
2 bytes:  # of runs for run-length encoding
          This is 0 if not compressed

Using those two, you need to run a little loop to find k.
var/k = 0
while(((n+ k) * x)%8)
  k++


Once you have found k, find y, which is the number of bytes of color encoding. It is not the number of color encoded values, that is going to be the same as your number of runs.
var/y = (n+k)*x/8

You have to do that so your y value isn't a decimal, though I suppose you could just round up if it isn't an integer :)

Basically, the color encoding section is going to be 'n' entries, 'x' bits each, with 'k*x' bits thrown in at the end to round up to the next even byte. Each entry references an entry in your icons color palette, and applies to its positional equivalent in the 'runs' list.


[Edit] Whoops I should have read the subthreads :P. It atleast covers the last block.
[Edit2] Nevermind Flicks explaination doesn't make much sense as it is not RLE and storing n wouldn't make sense as x would be the same for every pixel and thus you already know how much to extract.

Well, my post was referencing a spot of LummoxJR's code which has been changed :P If you look in Green Lime's post, you'll see it used to say:
  Non-compressed:
    Starting in the upper left and moving on by row,
    encode each color, <b>1 byte each</b>

He changed that to 'x bits each'. I sort of went about doing it the hard way, but after a few days of digging in that mess, my brain was a bit strained :P

Every time someone digs this up, it makes me want to work on my colorbook page editor again :) Hope this helps, though I know I'm probably not the best person to explain it. There are still a few situations I haven't quite figured out.

*EDIT* Well, I see the best person to explain this beat me to it :P
Feb 15 2005, 12:04 pm
In response to Flick
Flick wrote:
You have to do that so your y value isn't a decimal, though I suppose you could just round up if it isn't an integer :)

Problem is you can't; if you try to just round up, the count will be wrong. Even though this is a more logical and easier to calculate way of doing things, and it saves space, the DMI format does insist that y bytes be an even multiple of x bits.

Lummox JR
Feb 15 2005, 1:17 pm
I could give you my Research Paper on the .dmi format. Took me 4 weeks to do. Dam I felt stupid when I finished :). But, well Im just evil :) MWHAHAHA.
Feb 15 2005, 5:46 pm
In response to Green Lime
Green Lime wrote:
I could give you my Research Paper on the .dmi format. Took me 4 weeks to do. Dam I felt stupid when I finished :). But, well Im just evil :) MWHAHAHA.

Post eet on BYONDscape!
Feb 15 2005, 7:06 pm
I was doing some forensics on the DMI files in a hex editor, and here's what I've found.

Yes, the icon ID is 0 when the icon is entirerly index 0, but it still saves the icon! I don't know why, but it has the RLE encoding for the solid color.

As for that 'n' and 'y' thing, I'll illustrate.
Say you have a 2-bit pallete.
Mask = 00 (Binary)
White = 01
Grey = 10
Black = 11

The file told you that the icon is RLE compressed, with say 50 runs.

For the next 50 bytes, it will be defining the length of each run, in pixels.

32, 1, 30, 1, 32, etc...

Then for next 50 * ([the number of bit in the pallete] / 8) bytes (rounded up), it will define the colors of each run.

1001 1011 &nbsp; 0000 0011 etc.

Now remember, for each byte, it will read this bit stream RIGHT TO LEFT. So the first color is 11 (Black), then 10 (Grey), 01 (White), 10 (Grey), 11 (Black), 00 (Mask), and so on.

Before I go on, here's something else to note, the bits sort of wrap to the next byte, if it has to. For example, say this uses a 5-bit pallete.

1110 0000 &nbsp; 1000 0011

First was 00000, then 111111, see how the 11111 was cut off on the 4th bit, and started on the next byte?

OK, now we have the run count, lengths, and color indexes. Let's draw that icon.

First we have a run of 32 black pixels. This will put a black line allong the TOP of the icon. Next we have 1 grey pixel, which will be right below the black, and on the left side. Then is 30 white, with is right after that last grey pixel. Next is another single grey pixel. Then 32 blacks, followed by a lot of masks. So it sort of looks like this...

11111111111111111111111111111111
23333333333333333333333333333332
11111111111111111111111111111111

Get the picture?


Almsot forgot to mention. If the icon is NOT compressed, you'll still be counting color indexes the same way, you just won't be counting the length of each run, it will always be 1.
Feb 16 2005, 11:11 am
In response to Hell Ramen
Hell Ramen wrote:
Green Lime wrote:
I could give you my Research Paper on the .dmi format. Took me 4 weeks to do. Dam I felt stupid when I finished :). But, well Im just evil :) MWHAHAHA.

Post eet on BYONDscape!

Why O.o
#1. DanTom are probley going to change the dmi format soon.
#2. Its one of the easiest formats too figure out. Well with the help of Lumox Jrs. post.
#3. Gughunter wouldn't post it.
Feb 16 2005, 1:33 pm
In response to Green Lime
Green Lime wrote:
Hell Ramen wrote:
Green Lime wrote:
I could give you my Research Paper on the .dmi format. Took me 4 weeks to do. Dam I felt stupid when I finished :). But, well Im just evil :) MWHAHAHA.

Post eet on BYONDscape!

#1. DanTom are probley going to change the dmi format soon.

True, but BYOND 4.0 was due to come out about 2 years ago. I think that you're using "soon" too loosely here.

#2. Its one of the easiest formats too figure out. Well with the help of Lumox Jrs. post.

A clear, concise article would help alot of people understand it better.

#3. Gughunter wouldn't post it.

As long as it's well-written, then he would most definately accept your article.