Thanks dude, I got the right file size now, but it is not seen in FRED. Are you sure FRED can recognise dds background images, as most of the planets and nebulas you use in FRED are bitmap i think. I have put my file (Mars2.dds) in the tables and copied the file (in dds format) into my mods data/effects and freesspace data/effects and freespace data/models folders just to be sure but it still isn't being recognised.
FRED2_Open does recognize DDS textures as far as I know. After all, I think it uses the same rendering engine as FS2, but in a mission builder environment.
The way I started getting my planets into FS2 to see how they looked was as follows: I made a mod that simply replaced one of the planets used in retail FS2 mission (usually Surrender, Belisarius!) and the file name was planeta.*
When I later learned about making a modular planet-str.tbm file, I started using that, but for getting the game to see the planet, making sure it's in a correct format without black border around it and without being all-round transparent, a replacement mod is the single most easiest and fastest way to do it. I still do that occasionally if I can't be bothered to make a table, since renaming an image file to planetA.dds is a lot faster than making a modular table that adds it to the game. Not a good solution for anything you release, but for WIP it works smashingly.
As far as formats go, you should use DDS, or possibly in work-in-progress phase TGA if you don't want to bother with DDS conversion. Important thing is that you work in lossless formats (PSD, XCF, TGA, bitmap) and only when you have it ready, try converting it into a DXT compressed DDS file. It will lose some of the quality, but usually so little that it's better to use a compressed rather than non-compressed DDS file, although the latter is an option for certain image types (usually stuff with a lot of smooth gradient transitions rather than sharp, abrupt changes).
Also, it's important to realize that DDS is not as much a format as it is a container that can hold several types of image formats. In addition to uncompressed DDS files (rarely used, but very useful in certain conditions where the DXT compression doesn't work favourably), FS2_Open can use DXT1, DXT3 and DXT5 compressed formats. DXT1 should be used when the image file does not need transparency or uses additive blending (ie. black is transparent). This kind of things would be the sun bitmaps, nebula bitmaps and most if not all diffuse textures (with the exception of those that have cockpit glass texture integrated into them).
DXT3 and DXT5 are compression formats that include alpha channel, and should be used whenever you need alpha blending for the image file. This means stuff like planets where you want the planet NOT to be transparent, but the edges and atmosphere should be so. You also need an alpha channel in shinemaps (assuming you want to control environmental reflectivity, which you usually do) and most definitely in normal maps, at least the way it's being dealt with now. The only difference between DXT3 and DXT5 compressions is the way they deal with the alpha channel; if I remember correctly, DXT3 alpha is better suited for more abrupt changes (like nameplates where the text is opaque and has quite sharp borders) and DXT5 alpha is better suited for things that aren't as clearly defined - like, maybe, an atmosphere that has more gradient shift from opaque to transparent.
DXT compression typically reduces the memory footprint of a texture to either 1/6th (DXT1) or 1/4th (DXT3, DXT5). It's important to notice that even if you can have much smaller
file size with PCX or JPG, or even run-length encoded TGA files, the
memory requirements for all of these are the same regardless of the file size.
This is because the graphics processing unit can not deal with PCX, JPG or TGA files directly and needs them converted into uncompressed bitmap format, which takes a fixed amount of memory depending on amount of channels and resolution. In other words, a PCX file with resolution of 512^2 takes the exact same amount of memory as a TGA file of same resolution (although if there's an alpha channel involved, TGA takes a third more of memory).
DDS, or Direct Draw Surface, is different because the GPU can use them directly from the hard disk drive with no need for any conversion. Therefore, video ram is significantly saved.
Another reason why you should be using DDS format is that it offers a way to include mipmaps in the texture, which (although increasing the file size) reduces the need for processing cycles used to create mipmaps in the fly, so to speak. So, even if you end up unable to use DXT compression, you should still use DDS format (u888 for RGB files, u8888 for RGBA files) because of the mip maps.
