[Flaming_Sword]

Does anyone know of any way to get imagemagick to export the palette from a pcx, then convert a bunch of other files to pcx using that palette for the purposes of creating an ani? Or save a bunch of images using a single palette?

[Snail]

I'm trying to do the same thing (in GIMP) but to no avail.

[Flaming_Sword]

I've done it in gimp (though it's annoying, and happened a while ago), I just want to do it through imagemagick so I can make my interface templates easier to work with. For now, it just converts the frames for the loading screen animation to pcx, but the palettes for some of the frames are different, so putting straight into anibuilder gives bad results.

EDIT: I'd settle for script-fu for gimp if it came down to it, or even something that required GAP, which I should probably play around with more.

[Retsof]

It's pretty simple to do it in GIMP.  Just get an image with the pallete you want, then paste your other ones on top of it as layers.  Then delete the old one and save the rest.

[Flaming_Sword]

It's pretty simple to do it in GIMP.  Just get an image with the pallete you want, then paste your other ones on top of it as layers.  Then delete the old one and save the rest.

Tested with GIMP 2.4.5 - this doesn't work. The last frame (all parts lit up) has a significantly different palette to start with, and gets messed up. The first frame (no parts lit up) only works because the part of the palette used matches the rest.

EDIT: So far the only method I have is opening palettes screen, importing one of the frames, taking the rest of the frames, then converting to RGB, then back to indexed using the new palette and saving.

Any other ideas?

[Retsof]

It's pretty simple to do it in GIMP.  Just get an image with the pallete you want, then paste your other ones on top of it as layers.  Then delete the old one and save the rest.

Tested with GIMP 2.4.5 - this doesn't work. The last frame (all parts lit up) has a significantly different palette to start with, and gets messed up. The first frame (no parts lit up) only works because the part of the palette used matches the rest.

EDIT: So far the only method I have is opening palettes screen, importing one of the frames, taking the rest of the frames, then converting to RGB, then back to indexed using the new palette and saving.

Any other ideas?

Oh right, I forgot that you have to convert the ones you are pasting to RGB.

[Flaming_Sword]

*smacks forehead*

The frames started off as tgas.

So, alternative method (with tga frames):

1. Open frame with best palette
2. Convert to indexed, letting GIMP work out the optimum palette
3. Open the other TGA frames as layers (they get automatically converted to indexed)
4. Open layers screen, then turn off every layer except the frame to be saved
5. Save as pcx, and export when GIMP complains about not being able to save properly
6. Repeat steps 4 and 5 for all frames

All frames will now be saved with a single palette, ready for making ANIs.

Compare with (pcx frames):

1. Open palette screen and import frame with best palette
2. Open another frame
3. Convert to RGB, convert back to indexed, using the new palette, then save
4. Repeat for all frames (I found it easier to have hotkeys assigned for step 3)

I think the second series of steps is easier, though it may be because I've used it and I've got hotkeys assigned.

That might be what's going into the GIMP instructions for the interface templates, unless anyone else can figure out a better method.

[pecenipicek]

why are you using pcx and ani instead of dds and eff?

[Flaming_Sword]

why are you using pcx and ani instead of dds and eff?

I wish I could use EFF, but currently, only ANI can be used for things like command briefings and the loading screen progress bar. DDS may work, but you run into quality issues with compression (eg. DXT1), or large file sizes without RLE compression if using something like 8888 DDS. Performance of DDS over TGA doesn't matter too much in the interfaces, I don't think. In any case, imagemagick can convert from DDS, but not to DDS (as far as I know), which means a modder will have to use an alternate means of converting the 963 interface images to DDS, which I don't see happening.

[Flaming_Sword]

I've been given an easier way to do all this.

1. Ensure the pcx files are named in a form that can be used to create anis
2. Swap the filenames of the first frame and a frame with the best palette
3. Create an ani with anibuilder using default options (adapt to 1st frame, command briefing/techroom animation)
4. Save the frames from the ani (will all be saved with the same palette)
5. Swap the filenames back in the saved frames
6. Create the ani again (with the correct settings will have frames in the right order this time)

No additional steps with GIMP or other software required other than creating the pcx files in the first place.

[Herra Tohtori]

why are you using pcx and ani instead of dds and eff?

(...) DDS may work, but you run into quality issues with compression (eg. DXT1), or large file sizes without RLE compression if using something like 8888 DDS.

Those issues can be controlled surprisingly well if one knows what they're doing. Zacam knows a lot about DDS file format and how to use it to it's full extent with minimal quality loss from compression; choosing the right format is the first step, the second is managing the conversion and compression so that quality loss is minimized... I myself don't know much about it; if nvDXT can't produce a good quality version, I usually just resort to u888 or u8888 DDS files if I' just fooling around with things, but their large filesize isn't feasible for distribution... For example, Zacam helped a lot in making a high quality DXT5 compressed version of my blue nebula skybox texture, while my compression tools kept butchering the quality quite atrociously.

Performance of DDS over TGA doesn't matter too much in the interfaces, I don't think. In any case, imagemagick can convert from DDS, but not to DDS (as far as I know), which means a modder will have to use an alternate means of converting the 963 interface images to DDS, which I don't see happening.

In a case where you cannot use compressed DDS files for some reason, you should prefer uncompressed DDS files (u888 for files without alpha channel, u8888 for ones with alpha channel) over TGA files because DDS files will be handled better by the game than TGA files due to the fact that they are designed for gaming graphics use. Even uncompressed DDS will have some performance benefits over TGA files.

As to how to convert multiple files into DDS - batch conversion FTW! You can use for example NVidia's DDS Tools, which has a command line utility called nvDXT and it is used in this fashion:

C:\ImageDirectory>nvdxt -file <files to be converted, for example file1.tga,file2.tga or *.tga, or file****.tga> <DDS compression format; DXT1c, DXT3 and DXT5 are the ones most often used in FS2_Open; then there are u888 and u8888 and DXT5nm... but the last one is a bit special case> <compression quality> <mipmap filter> <other assorted stuff; read the introductions>


Example for converting all frames in a directory into DXT1c compressed DDS files with Gaussian filtered mipmaps would be

nvdxt -file *.* -dxt1c -quality_highest -gaussian

then it will do it's magicks and you'll end up with the frames.

Of course, mipmaps are more or less ballast on the interface static images, and you would probably be able to detach them from the files and only use the primary resolution layer, reducing the filesize even further...

I'm not sure if tools like IrfanView can deal with conversion to DDS files, haven't really used that one very much myself but it might be worth checking out if you prefer graphical user interface to command line (I myself don't really see reason to do that unless you get a high quality preview window of the resulting file with given settings...)

[Flaming_Sword]

1. When it comes to DDS, I'm one of those people who don't know what they're doing, especially on 963 different image files that may require individual tweaking. I should probably take a look at those tools in the future, though.

2. Does DDS have that significant a performance advantage over TGA in, say, the weapons loadout screen? I'm trying to do the basics for creating interfaces from templates, with as much automation as possible. Further conversion to DDS may be done by the modder using the templates.

Expect a beta release soon.

[Herra Tohtori]

1. When it comes to DDS, I'm one of those people who don't know what they're doing, especially on 963 different image files that may require individual tweaking. I should probably take a look at those tools in the future, though.

Individual tweaking... well there's not that much to tweak with conversion to DDS, once you find good settings you should use same settings for all frames and the resulting animation should maintain it's cohesion. Of course, if the conversion is successful, the quality loss should be minimal anyway and thus the resulting frames will not be too different from the originals.

Of course the need to individually edit the files beforehand has nothing much to do with conversion to DDS; make the tweaks, put the to-be-converted files in a single directory, and type in the command line to convert them. Then take a look at the end result to make sure you didn't do anything wrong.

2. Does DDS have that significant a performance advantage over TGA in, say, the weapons loadout screen? I'm trying to do the basics for creating interfaces from templates, with as much automation as possible. Further conversion to DDS may be done by the modder using the templates.

Expect a beta release soon.

Well, TGA's are usually RLE compressed and the CPU will need to generate the actual texture into the RAM from the file before it can transfer it to the GPU's VRAM, whereas with a DDS file - be it uncompressed or compressed - the CPU can dump the file straight into the GPU's memory and the graphics card will be able to process it on it's own, which means that in interfaces' case mostly the loadout times are improved. Static images will stay static once they are loaded into the VMem.

And as far as interface performance goes, loadout times are perhaps the one and only thing that can be improved with DDS file format - aside from the 3D components of the interface like the loadout's weapon model view or ship screen in Tech room, the frames-per-second performance of the interface itself will be mostly irrelevant, and most of the time the loadout times are pretty long anyway, but the times don't need to be made any longer by poor practice in interface file formats. The performance of 3D-rendered parts will depend on the individual models and their textures, of course, and thus isn't exactly a part of the interface.

A suggestion, though - as graphical templates, you should release them in uncompressed format (for convenience, TGA would be the best choice) so that if people want to play around with them and use them for further stuff, there is no accumulated quality loss from being previously compressed. However, I would suggest you also include ready-to-use versions of the interface template with readily converted files as well as instructions on how to convert the uncompressed files to proper format once they are done with their alterations.

[Flaming_Sword]

The templates are in TGA, and once used result in 124mb of uncompressed TGA textures (some with alpha channel, some without). Optionally, they may be converted to 20mb of pcx (it's there because I could do it in imagemagick, and in case a modder was paranoid about file size and doesn't mind risking quality reduction).

Just did a quick test and yes, DDS textures work. If only EFF could be used in the interface.

I'll play around with nvdxt and see what happens.

EDIT: AAAAAND... nvdxt refuses to convert (to uncompressed dds) the first 38 files complaining that they're not multiples of 4. Hell, I'm surprised the rest even got converted given the power of 2 warnings.

Converted textures weigh in at 164mb.

EDIT2: I stand corrected. DDS seems to have a noticeable performance advantage when switching between screens, at least on my machine.

EDIT3: Me beings stupid again, 124mb DDS, as I remembered to turn off mipmaps this time.