[Goober5000]

The original ANI specification should be linked on the Descent Manager site.  What about simply generalizing that to 32-bit color?

[The E]

It can also be found in the wiki.

The main problem with expanding this is that ANI relies on having a single, constant palette that is valid for every frame. Data compression is achieved via RLE. I don't think we can use either of those in 32 bits.

[Nighteyes]

perhaps we can use a different image format? one that is compressed and small, with relatively high quality?(16/32 bit)
this combined with the TLV files can perhaps produce us clatter free, small on space and still much higher quality animations for CBanims...

[Nuke]

what about dxt1. at 4 bpp, thats better compression than the existing 8 bit anis, and you can have 1 bit transparency without making the files bigger. there are some issues:

1. dds files have dimension limitations (they need to be multiples of 4), but the edges can easily be padded out a couple extra lines if needed.

2. power of two requirements (does this only apply to textures or any image in the game loads?) . if they absolutely have to be power of two for hardware rendering, perhaps we can render them in software.

on top of that maybe use a compressed container format. dds files despite having good compression also seem to compress well in zip/rar/7zip archives (of course youd want to use an open source format).

another option perhaps is to use jpeg. jpeg can compress more for less, but probibly wouldnt compress as well in the container.

[mjn.mixael]

compression in a container shouldn't matter... but please not DDS... those aren't easy to batch create.

[Iss Mneur]

APNG or MNG may be a good formats to use.  They are both very similar to PNG.

MNG seems to have fairly good inter-frame compression and also apparently has support for what seems to be pretty much arbitrary animation controls.

APNG doesn't seem to have as good of controls but there seems to be enough to do what we want.  And I have not been able to find any information about the inter-frame compression, though I assume that it does have something based on the description of the tags in the wiki article.

Both formats are supported with a variety of tools including some that can just create the animated file using a string of PNG files.

[Nuke]

compression in a container shouldn't matter... but please not DDS... those aren't easy to batch create.

why not, you can get command line tools for that kinda thing.

Code: [Select]

NVIDIA Texture Tools 2.0 - Copyright NVIDIA Corporation 2007

usage: nvcompress [options] infile [outfile]

Input options:
  -color        The input image is a color map (default).
  -normal       The input image is a normal map.
  -tonormal     Convert input to normal map.
  -clamp        Clamp wrapping mode (default).
  -repeat       Repeat wrapping mode.
  -nomips       Disable mipmap generation.

Compression options:
  -fast         Fast compression.
  -nocuda       Do not use cuda compressor.
  -rgb          RGBA format
  -bc1          BC1 format (DXT1)
  -bc1n         BC1 normal map format (DXT1nm)
  -bc1a         BC1 format with binary alpha (DXT1a)
  -bc2          BC2 format (DXT3)
  -bc3          BC3 format (DXT5)
  -bc3n         BC3 normal map format (DXT5nm)
  -bc4          BC4 format (ATI1)
  -bc5          BC5 format (3Dc/ATI2)


C:\Program Files\NVIDIA Corporation\NVIDIA Texture Tools 2\bin>

just use this in your batch file, should work. no different than what you had to do to create an ani in the first place.

[The E]

The main reason against using dds for this is that even dxt compressed files aren't compressed as efficiently as the correspondent png files would be. In addition, there's no advantage to using dds in that particular scenario.

[Galemp]

APNG or MNG may be a good formats to use. 
Both formats are supported with a variety of tools including some that can just create the animated file using a string of PNG files.

This! More about MNG

MNG includes a number of interesting features:

    * object or sprite-based approach to animation, with commands to move, copy and paste images (rather than replicate them as in GIF)
    * nested loops for complex animations
    * way better compression than GIF animations
    * support for difference (or "delta") images for still better compression
    * integration of both PNG and JPEG-based ("JNG") images
    * support for transparent JPEG images
    * low-complexity and very low-complexity subsets for simpler implementation

Of course, MNG also shares a number of PNG's best features:

    * unambiguous pronunciation (gotta love it)
    * multiple CRCs so that file integrity can be checked without viewing
    * ultra-clever magic signature that can detect the most common types of file corruption
    * non-patented (you betcha!) compression, either completely lossless (PNG) or lossy (JPEG)
    * full alpha support (multi-level transparency) for all image objects
    * gamma and color correction for cross-platform consistency
    * ability to store copyright and other textual info, either compressed or uncompressed
    * full Year 2000 (Y2K) support (good for at least 63 millenia! dang!)

Since we're not concerned about browser portability or code size, MNG looks like the way to go. It's supported by GIMP and if there's a tool to create one from numbered frames like AniBuilder, then we're pretty solid. Its use would be limited to cbanis as it doesn't have the keyframing or indexing complexity that other ANIs require, but that's OK, we can continue using ANI for those applications... unless there were some awesome tool to write keyframe data to a header that only FSO would read.

For the record I would want to stay far, far away from DDS or JPG for CBAnis as the compression artifacts in the individual frames would probably negate any benefits from run-length encoding.

[mjn.mixael]

APNG or MNG may be a good formats to use. 
Both formats are supported with a variety of tools including some that can just create the animated file using a string of PNG files.

This! *reads*

 

[Iss Mneur]

Since we're not concerned about browser portability or code size, MNG looks like the way to go. It's supported by GIMP and if there's a tool to create one from numbered frames like AniBuilder, then we're pretty solid. Its use would be limited to cbanis as it doesn't have the keyframing or indexing complexity that other ANIs require, but that's OK, we can continue using ANI for those applications... unless there were some awesome tool to write keyframe data to a header that only FSO would read.

For the record I would want to stay far, far away from DDS or JPG for CBAnis as the compression artifacts in the individual frames would probably negate any benefits from run-length encoding.

Well Jpg can do compression without any artifacts. Unfortunately most tools are not able to export JPG files that are using only lossless are limited though the ones that you graphics artists should.

Also, because MNG is formatted like PNG, theoretically there is no reason that we cannot implement some proprietary tag that specifies anything the is missing.

[chief1983]

Lossless JPEG is only about 2:1.  Not very good compression.

[JGZinv]

Interesting technical article:
http://www.libpng.org/pub/mng/spec/mng-1.0-20010209-pdg.html

Would like to find out what animation controls MNG actually has, as I'm reading
around in the documentation and not finding clear answers. Seems it's mostly
similar to GIF controls, but it's got a little bit more on top.

Ex.

Images and frames can be given names, allowing authors to mark them for
export outside the scope of MNG, where they can be used for icons or similar purposes.

[Nighteyes]

For the record I would want to stay far, far away from DDS or JPG for CBAnis as the compression artifacts in the individual frames would probably negate any benefits from run-length encoding.

so what you are saying is that the only real option would be to stay with using PNG for CBanims...
this wont make the files smaller, but at least will make a more easier to navigate cbanims folder...
unless im missing something here, as I don't know of other compressed image formats

[Nuke]

The main reason against using dds for this is that even dxt compressed files aren't compressed as efficiently as the correspondent png files would be. In addition, there's no advantage to using dds in that particular scenario.

i just did a test to see what format gets better compression size (not necessarily quality). i took a frame from one of the fs port ani files @660x300, upsampled it to twice its size, did a gaussian blur of 1 and scaled it back to its original size, this is to remove artifacts from being in a paletteized format. from photoshop i saved the file as both bitmap and tga. i reloaded the tga format into photoshop and saved it as a non-interlaced png file. and i closed it. i did the same with dds, saving as dxt1 with no mipmaps. here are the numbers for the file size

bmp (24 bit) = 594,056 bytes
tga (24 bit) = 594,044 bytes
pcx (8 bit indexed) = 159,970 bytes
png (non-interlaced 24 bit) = 159,347 byte
ani (1 frame) = 145,847 bytes
dds (dxt1 no mips) = 99,128 bytes
jpg (maximum quality) =  89,721 bytes
jpg (medium quality) = 25,905 bytes

bmp and tga all store their data as 24 bit in this case, the only file size difference is in headers/footers/formating. dds compression is very predictable (you always get 4bpp with dxt1/a). png as far as i can tell compresses differently based on content, so this format may not always yield the same size depending on the content of the animation. still at about 30fps and 660x300 were still talking 2904 k per second of animation for dds. png is not quite better than pcx indexed color (in terms of size). jpeg seems to give the smallest size file, and the modder can choose the best quality settings for the situation. in the range of 758k-2628k per second at 30fps, depending on quality.

i do not think we need a full 24 bit image format (dds is technically 16 bit), nor do we really need a lossless format. theres a reason the majority of video formats are lossy, and its because the amount of data is huge. dds jpg is the best bet if we just stick single frames into a container. still, i dont think single frame compression formats are the answer. there is no cross-frame compression. so we need a format that can play in a sub window, that has fairly good compression and quality, that supports keyframes and transparency. good luck.

*edits*
added new formats for compairison. edited for sanity.

[Nuke]

APNG or MNG may be a good formats to use.  
Both formats are supported with a variety of tools including some that can just create the animated file using a string of PNG files.

This! *reads*

 

il belive it when you convert one of the anis over to it, and do a size/quality comparison. but i admit it sounds good on paper.

[mjn.mixael]

I'll take jpg too..

[sigtau]

I'll take jpg too..

I remember you mentioning that when you run your cutscenes through After Effects you export them as a JPG sequence and import them into AE frame-by-frame.

[mjn.mixael]

Cutscenes I render as uncompressed AVI. I render the anis as jpg first though.

[Nighteyes]

so are we going with JPG as the prefered format? to be honest I think the quality you get from JPG is more than enough for CBanims, and the file sizes are very small...