rfc: image format

ok, I went and put the tool for the image format online:
http://bgb-sys.sourceforge.net/2005-05-12_pdtx.zip

on the site:
http://bgb-sys.sourceforge.net/

for any that might be interested in looking at/messing with it.
this format is more intended for my personal use than anything else, though
I tried to keep complexity low for what it does.

rough:
imo, comprable to jpeg in terms of both filesize and quality (I have not
been able to clearly identify if one is strictly better than the other).
imo, the only real good point is that it has alpha channels, but this may be
enough (other formats are either: somewhat larger than jpeg, don't have
alpha channels, or are not supported well enough to make it worth the
bother).

note:
I am presently using an algo for generating the quantizer tables.
first: it dct transforms all the image;
it makes a pass over the blocks gathering the energy distributions;
it uses these distributions along with the quality level to compute the
quantizer values.

f=e/te;
if(f<0.00001)f=0.00001;
g=(1.0-q);
f=10*g*g*g/f;

I am not sure if this is a good approach, the images look different than
with my original algo (based on combining "factors", eg: constant, square
root, linear, quadratic). just, I couldn't figure a good way to generate a
"quality level" from the previous one.


the fileformat is, poor, but I had felt that implementing something better
(eg: IFF or a png like container) would be more work. as a result, the
fileformat may change (I may but in the work needed to at least build a
basic IFF style format).

I had also considered making it as a variation of the BMP format, but
figured this would make no notable difference (and go against ms's idea of
registering all tags).

other ideas had revolved around using a fixed header (like that of pcx or
tga). but, were not taken as they could not really be justified.

the next variation will probably be IFF based, eg:
FORM PDTX {
LIST IMG {
hdr    //header
data   //encoded data
}
}

with header being a glob of properties, eg:
{
u16 tag;
u16 len;
byte data[len];
}

I will reason then that likely the header will be being generated in a
buffer, and thus lengths are less of a hassle (since no sing is needed,
and the structure is flat).

I could also do something like:
{
byte tag;
byte len;
byte data[len];
}

why: because there are probably not enough header tags anyways to use this
space, and if needed I could add in a few "extension" types (a larger
tagspace/...).

or such...