Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: mjn.mixael on October 06, 2010, 10:35:38 am
-
I've talked a bit with The_E in IRC about this issue and I thought it's time to get the rest of SCP in on the conversation.
As far as nice looking ANIs go.. we kind of have our hands tied. It's either the 256 colors of ANI Builder or littering your cbanims folder with hundreds, if not thousands, of image files.
The best solution is .ogg support for ANIs. I'm mostly thinking about cb_anims, but other ANIs could also benefit.
Another stop-gap method would be to allow FSO to read subfolders within the VPs so that EFFs could be put in data/cbanims/ANINAME, thus organizing the ANIs a bit. But this nothing but a stop-gap and not ideal.
Heck, I would even take ANIs bumped to 512 colors.. but I think that has more to do with ANI Builder than FSO.
I have no idea of the difficulty involved to code these things... thoughts? opinions? tell me to get out?
-
Nice looking, psh. I could care less what they look like. The fact is that FSPort now has over a gigabyte of high-res CB anis and the .ANI file format is far too inefficient for this purpose.
Ideally we would have some new container format that would interlace ANI frames like animated GIFs, minimizing compression artifacts, with 32-bit color support.
-
Myself I'd like to see something along the lines of a format that has some kind of
animation/keyframe controls with it, ex. as actionscript was for Flash. That opens a door to
quite a number of things.
-
I didn't even think about the keyframes.. for things like weapon and ship select ANIs keyframe ability is necessary.
-
/me looks at the EFF description (http://www.hard-light.net/wiki/index.php/EFF#EFF)
/me sees "Keyframe" keyword
-
I do recall having a similar conversation in the past, but there are some open source flash like formats
available. I'd have to go dumpster drive to find the links again... and I've no idea how applicable they might be.
http://osflash.org/open_source_flash_projects
I'm not saying Flash/Alternative is the way to go, just more so trying to get thinking rolling.
@ The E I don't see any controls though related to the use of keyframes there.
It sounds like it's only being used as a marker.
-
/me looks at the EFF description (http://www.hard-light.net/wiki/index.php/EFF#EFF)
/me sees "Keyframe" keyword
I know it has keyframe options.. Thanks. :doubt:
How about pay attention to the topic at hand... if we went with YOUR suggestion of OGG... we would need some sort of keyframe control.
The ONLY problem with EFF.. is that the frames are in no way contained. When you are working with upwards of 50 ANIs that just isn't going to work. That's why it would be nice to get subfolder support so those could be used as a sort of "container".
-
i kinda think using ogg for these kinds of files would be a good idea. were not talking 8 frame interface animations and < 30 frame animated textures and effects, but animations longer that 30 seconds. a 1 minute long animation @ 30 fps 512x256 with dxt1 compression comes out to about 117.9 megs! thats huge! surely a video format could do better than that. surely i wouldn't expect ogg to be used during actual gameplay, eff+dxt1 is more optimal for that kind of usage, but long non-interactive interface animations should use a better suited compression scheme. you dont need to set keyframes for them (not to say that you couldnt). things like icons might be better off using eff+dxt1 or ani formats.
-
It's worse than that. 2_cb_shivorefootage.ani, which is 660x300, 33 seconds long and 15 fps, is over 80 mb.
-
i dont think a container format is the answer. movie formats use cross-frame compression techniques to reduce the amount of data that needs to be stored. only parts of a frame that change drastically over the previous frame need to be stored. individually compressed frames do not do this. it would be more optimal to use ogg i think.
-
Ideally we would have some new container format that would interlace ANI frames like animated GIFs, minimizing compression artifacts, with 32-bit color support.
This. This has been an open question in the SCP for many years, but none of the graphics coders have stepped up to it yet.
And EFF is not usable, for two reasons. One, it's not a container format... command briefing animations (and most animations, actually) should be contained in one file rather than spread through zillions of files that must each be opened, read, and closed. Two, it can't be streamed, and streaming is pretty much a requirement for cbanis.
-
container format only wont reduce the size much. container format with compression might help reduce size, though it might cost some performance and wouldnt be as good as a proper movie format. i still think we need to use a movie format for these kinds of animations. all they do is loop and we dont need anything fancy beyond that.
-
Some play a certain number of frames and then loop... ala 1-25 then back to 15-25 and loop just those last 10. You can't do that with a video file.
-
No, you can't. You can, however, do it with two separate files.
And given how door anis work (for example) you'd need to switch between two videos in an instant anyway (one playing forwards, the other backwards).
-
I'm all for using a video file. It's cleaner, smaller, and can look better than .ANI
-
I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.
This discussion is for a new Command Briefing Animation format, since these are simple looping video files of a relatively high resolution and long length that are unreasonably huge in ANI format.
-
I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.
This discussion is for a new Command Briefing Animation format, since these are simple looping video files of a relatively high resolution and long length that are unreasonably huge in ANI format.
Agreed, so what would it take to get OGG support for cb ANIs?
-
why force ogg? why not use the likes of x264 and stuff.
-
ogg is open source, the codec is already in the code somewhere... and did I mention it's open source?
-
yeah the fact that we already have it goes a long way. And x264 is generally HD vid, and cbanis are generally, not. Not sure if that makes a difference with x264's efficiency or not. We _could_ look into VP8 support to go forward, but OGG would probably work fine here, and if we supported it generically, any video type should be playable there, not just Theora.
-
i'm just saying. if size is any concern at all, i find it doesnt get any better with the quality/size ratio than x264. (well, its not so apparent on short anims and such, but on anything beyond 30-60 seconds or so, it starts to show it power
-
I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.
to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.
-
Just go with what we have already in the code. No reason to bulk it up if what we have works.
-
i'm just saying. if size is any concern at all, i find it doesnt get any better with the quality/size ratio than x264. (well, its not so apparent on short anims and such, but on anything beyond 30-60 seconds or so, it starts to show it power
One problem: There is no h264 implementation that is licence-compatible to FSO.
I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.
to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.
No.
-
I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.
to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.
No.
That is not helpful at all... :doubt:
-
The reason is that I think the last thing FSO needs at this point is a new proprietary format.
-
Agreed.
So.. how bout that .ogg support for cb_anims? :nervous:
-
i'm just saying. if size is any concern at all, i find it doesnt get any better with the quality/size ratio than x264. (well, its not so apparent on short anims and such, but on anything beyond 30-60 seconds or so, it starts to show it power
One problem: There is no h264 implementation that is licence-compatible to FSO.
Good point there.
-
to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.
This is actually the best long-term solution (provided that it is actually a container format, not an EFF which is nothing of the sort). And again, this is an enhancement that has been on the SCP to-do list for a long time.
So.. how bout that .ogg support for cb_anims? :nervous:
I'm not a graphics coder so take this with a grain of salt, but I suspect it would be rather difficult. The current OGG movie player is designed to play full-screen or on a window, and not to be composited on top of some other interface art. By the time you spent the effort required to hack together a modified OGG player, you could have already finished the new container format.
And keep in mind, as karajorma said, that you can already play an OGG movie as a full-screen substitute for a command briefing.
-
Yes, you can play an ogg as a replacement for a CB. What you can't do, however, is to go back and forth between CB stages that way.
And really, a new container format? In the end, that would mean that we'd need a new content creation tool as well. While that might not be difficult to produce, I have to ask if it is really a good idea when we could just as well use a standardized format that can be produced using standard tools and converters that are already freely available.
One problem that a container similar to ani has (which, for those who do not know, is basically a container for a series of pcx files with the individual headers stripped off) is that there is no real video compression going on. As the use of png-based effs proves, these files can become prohibitively large (even anis have that problem; mjn can provide the data here). ogg theora, or other video codecs, would allow us to be way more efficient in that regard.
-
*sigh* even if there's no h264 implementation, there is VP8...specifically, ffvp8, part of ffmpeg, which is LGPL. Sorry if I'm starting to sound like a broken record, but if we _were_ going to add another video format, that seems the way to go to me.
-
well there is a downside in using ogg as cbanims, this way there is no option to use cbanims with alpha channel(as far as i know)...
EFF animation with PNG images produces pretty small animation sizes in terms of mgb IMO
-
well there is a downside in using ogg as cbanims, this way there is no option to use cbanims with alpha channel(as far as i know)...
EFF animation with PNG images produces pretty small animation sizes in terms of mgb IMO
No, it really doesn't.
-
well there is a downside in using ogg as cbanims, this way there is no option to use cbanims with alpha channel(as far as i know)...
EFF animation with PNG images produces pretty small animation sizes in terms of mgb IMO
since when do cbani's actually need alpha maps for... anything?(no, i do not consider interface elements to be normal CBani's in that way, CBani's are the Command Briefing Animations... with a strictly defined space, aka in the command briefs! video's would work nicely there. no keyframing needed, just looping, end of story.)
and to echo what The_E said, no PNG really doesnt produce "small animations", being a lossless format, that produces better compression when there are lots of flat colors, but doesnt do so well with the "typical" data a game might use (varios animations, etc)
PNG might do well for interface elements and such. but using it ingame for explosion effects and the like? waste of RAM and HDD space.
-
Having an Alpha channel in a cb ani is a very good thing, IMHO. The cb anis used in War In Heaven work very well that way.
-
*has forgotten how WiH cbani's looked*
but the point is, they arent 100% neccesary.
-
True.
-
*has forgotten how WiH cbani's looked*
but the point is, they arent 100% neccesary.
yep. those are the cbanims I did btw, now its easy to say its not 100% neccesary, and its true, but its something that works currently and I don't see a reason to implement something take will limit us in any way.
I don't recall saying anything about using PNG animations as effects in game, thats plain stupid and as far as I know only TGA and DDS are supported... for cbanims, using the EFF method of animations, PNG is the best way(please enlighten me if im mistaking), and please don't mention the word ANI... :P
now, back on topic, I don't know if it might be possible at all, but I know some games can read 7zip files, so if we could zip all the frames and eff file into one compressed file, and have the game be able to read it upon request, that can be a nice solution.
-
EFFs do not work well as cbanis. They don't stream, and the game has to open and close one file per frame, which is not good for performance or memory management.
Keep in mind that a new ANI container format would not only be used for cbanis, but also for anything else an ANI is typically used for. You could have animated main halls with more than 8-bit color depth, for example.
-
Goob, please try to stay on topic. Filesize, or indeed color depth, on mainhall animations is not an issue. Having hundreds of megabytes or thousands of EFFs in the cbanis folder IS the issue. We need a format that has video-level compression and low data loss that can loop, that's it. And I think a new proprietary ANI format would be acceptable, honestly.
-
This is on topic. I'm simply pointing out that the benefits of a new ANI format extend much further than just cbanis.
-
Regardless, even if a new ANI format has uses, for these, isn't an existing format acceptable?
-
The existing formats are tolerable. ANI format is incredibly limiting because of the 256 colors issue. EFF doesn't stream and it isn't a container. This isn't a problem until you get to something like FSPort where we have over over 80 hi-res cb_anims alone. Do YOU want to pack a VP with literally THOUSANDS of image files and try to navigate that? Me either. Not to mention the performance issues that Goober mentioned...
The other issues is filesize. Neither of these formats are good for reducing file size. FSPort is passing 1.2 GB of cb_anim data with another 35 ANIs left to hi-res-ify... This means we have FOUR VPs dedicated to nothing but cb anis...
So, to answer the general question.. yes, what we have works. But from an organizational and purely filesize viewpoint, they are hardly ideal.
-
is the fact that EFFs don't stream such a big issue? what kind of performance does a menu screen need? IIRC when the actual mission loads all memory is cleared...(cbanims frames don't count to the total frames allowed to be used in a mission)
I do agree that a new ANI format would be a welcome addition, or even just using compressed video files that can loop... it will kill the alpha channel but even that can be "hacked" by just using the interface background as part of the video
-
Well I meant isn't Ogg capable in some of those situations where streaming is needed. But also, there's this discussion about the EFF container upgrade (http://www.hard-light.net/forums/index.php?topic=66361.0) that's also slotted for an antipodes run, but I don't think it's progressed past draft stage yet.
-
I can't see that link.. must be SCP Internal... care to summarize? Also, who do I need to pay off to get that moving along? :nervous:
-
I can't see that link.. must be SCP Internal... care to summarize? Also, who do I need to pay off to get that moving along? :nervous:
Yes it is in SCP Internal. It is a technical discussion about Flaming_Sword (http://www.hard-light.net/forums/index.php?action=profile;u=2589)'s proposed container for EFF. I would make the proposal link available but I don't know if he wants it spread around. Basically it is a Tag Length Value based file format (same file layout that png uses) that moves all of the current EFF data into one file and allows for streaming.
Flaming Sword would be the one to bribe.
-
EFF still doesn't have any kind of video interlacing, though. Each frame is individually compressed, but if a frame is nearly identical to the one before it, there's no way for it to be reduced in filesize.
-
I would rather have it than nothing... At least with an EFF container we wouldn't have the 256 color limit...
Flaming Sword: name your price...
-
If you need interlacing, why not use Ogg? Leave streaming EFF for instances where that won't matter, if we ever get it.
-
Cause there are a ton of obstacles involved in making OGG (or any movie) work within the FS2 interface.
Provided the new container format can use PNG and DDS, we may find that interlacing isn't that critical. Even more so if it uses run-length-encoding for identical frames.
-
Provided the new container format can use PNG and DDS, we may find that interlacing isn't that critical. Even more so if it uses run-length-encoding for identical frames.
Well, if I recall correctly, PNG is actually a rather stable format from the point of view the pattern of the bits on the disk, which if I am in fact recalling correctly, means that interfame compression would be actually fairly trivial to manage, resulting in something akin to what ANI does to PCX.
-
Cause there are a ton of obstacles involved in making OGG (or any movie) work within the FS2 interface.
Provided the new container format can use PNG and DDS, we may find that interlacing isn't that critical. Even more so if it uses run-length-encoding for identical frames.
I think Goober is missing the point:
What mjn.mixael wants is not an all around support for OGG in the interface, but OGG support for command briefings... or if I take your words literally , then the implementation of *any* windowed playback is hard.
Also chief had a really good suggestion that was ignored by everyone: use ffvp8. It's the closest thing the engine could have to h264 support and since it's Google's baby there's bound to be tons of support for it. He specifically suggested ffmpeg (http://ffmpeg.org/), an LGPL implementation that *can* be used under the SCP license.
Sadly Theora seems to be going the way of the ".ogm" container or the "ungraded" avi once pushed by the makers of Virtual Dub. It's simply not adopted widely enough for there to be support. FFmpeg on the other hand is widely used (even in the acclaimed CCCP), is multi platform and has modern format support.
-
Flaser, the command briefing is part of the interface. :p And note that I said any movie. This includes ffmpeg, ffvp8, and h264.
First of all, you have size restrictions. Theora frames need to have dimensions that are multiples of 16, so right off the bat you won't be getting an exact match to the cbani drawing area. Second of all, you're going to run into trouble painting the movie on top of the interface because it's designed to play on its own, either in a window or full-screen, and you'd have to develop some sort of matte system. Third of all, the movie playing code operates in its own code module with its own drawing routines, which are not going to play at all nicely with the main game code and its drawing routines. Fourth of all, decoding of any movie format is based on the encoded timer, not the timer used by the game loop, so you'd have to keep the movie code in its own separate thread and deal with the huge synchronization can of worms that that opens.
I can tell you right now that your efforts are going to be much better spent developing the next-generation ANI container format. I can't stop someone from going down the movie playing rabbit hole if he really wants to, but I fully expect him to burn himself out proving that it doesn't work, and then we'll have wasted energy, time, and effort that could have been spent more productively elsewhere.
-
I'm actually with Goober on this one. The more we discuss it, the more I like the idea of the EFF container.
-
Good, thanks for actually explaining why it would be difficult to do.
-
Right. Now that Goober explained to us why it'll be difficult to get movie playback more useful, let's get down to the business of making new anis. Does anyone have a design for a new ani format we can use?
-
Wasn't that what was in the draft I linked?
-
TLV files, as explained there, are functionally equivalent to vp files. They do not have any of the video compression features we may want in a hi-colour ani.
-
Ah. Well, knock yourselves out then :)
-
The original ANI specification should be linked on the Descent Manager site. What about simply generalizing that to 32-bit color?
-
It can also be found in the wiki (http://www.hard-light.net/wiki/index.php/ANI_Formal_Definition).
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.
-
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...
-
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.
-
compression in a container shouldn't matter... but please not DDS... those aren't easy to batch create.
-
APNG (http://en.wikipedia.org/wiki/APNG) or MNG (http://en.wikipedia.org/wiki/Multiple-image_Network_Graphics) 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.
-
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.
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 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.
-
APNG (http://en.wikipedia.org/wiki/APNG) or MNG (http://en.wikipedia.org/wiki/Multiple-image_Network_Graphics) 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 (http://www.libpng.org/pub/mng/#history)
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.
-
APNG (http://en.wikipedia.org/wiki/APNG) or MNG (http://en.wikipedia.org/wiki/Multiple-image_Network_Graphics) 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*
:yes:
-
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.
-
Lossless JPEG is only about 2:1. Not very good compression.
-
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.
-
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
-
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.
-
APNG (http://en.wikipedia.org/wiki/APNG) or MNG (http://en.wikipedia.org/wiki/Multiple-image_Network_Graphics) 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*
:yes:
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.
-
I'll take jpg too..
-
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.
-
Cutscenes I render as uncompressed AVI. I render the anis as jpg first though.
-
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...
-
Nothing has been decided yet.
-
EFF container with JPG support? Yes? No?
-
I don't particularly ever want to see jpeg used again...
-
:wtf:
What is your reasoning?
When I get home, I am going to post a side by side comparison of a screen from one of my anis....
EDIT: -------------------------------------------------------------------------
Here is a link to a page on my server with 5 images. I rendered out this frame using JPG - hi quality, PNG, BMP, JPG - low quality and then saved out the frame from the current ANI. I then took each image and flattened the compression into a BMP file so that you couldn't cheat.
http://www.lunardigitalproductions.com/compare.php (http://www.lunardigitalproductions.com/compare.php)
Here are the file sizes of the rendered images...
JPG-HI - 114KB
PNG - 199KB
BMP - 575KB
JPG-LO - 30KB
ANI-FRAME - 195KB
I want you to tell me which ones are which... then tell me why JPG is a bad choice given that a video file format doesn't seem likely.
-
I have no idea which one is supposed to look best, but I would say the top one looks the best and the last one looks the worst.
Although the last one is clearly worse than the others, the other four are nearly identical. The only reason I picked the top is because the colors seem slightly more vibrant with better contrast.
Aside from the bottom one, all of the others seem to have negligible differences.
EDIT: With much staring, the second from the lowest is the second-to-worst. I see no difference between 02 and 03.
-
as a guess as to which formats used:
4. JPEG-LO, appears blocky.
5. ANI-FRAME, made obvious by the limited color pallet, results in banding, may look better with dithering, but that isn't the point of the exercise...
1. 2. 3. are indistinguishable to me, being unable to tell the difference between PNG and BMP is expected, as both are lossless formats. However, 1. appears slightly more vibrant, and due to being the different different one of three, I would expect this one to be JPEG-HI, however, this may just be because of what Rga_Noris has said.
hell, any* 24 bit (32bit? possible transparency suppourt?) image format would be better than what's being used at the moment :\
*hyperbole.
-
:wtf:
What is your reasoning?
When I get home, I am going to post a side by side comparison of a screen from one of my anis....
EDIT: -------------------------------------------------------------------------
Here is a link to a page on my server with 5 images. I rendered out this frame using JPG - hi quality, PNG, BMP, JPG - low quality and then saved out the frame from the current ANI. I then took each image and flattened the compression into a BMP file so that you couldn't cheat.
http://www.lunardigitalproductions.com/compare.php (http://www.lunardigitalproductions.com/compare.php)
Here are the file sizes of the rendered images...
JPG-HI - 114KB
PNG - 199KB
BMP - 575KB
JPG-LO - 30KB
ANI-FRAME - 195KB
I want you to tell me which ones are which... then tell me why JPG is a bad choice given that a video file format doesn't seem likely.
its obvious which one tha ani is. you can tell from the horrific banding. its also obvious where low quality jpeg is. as for the others, youd be hard pressed to find compression artifacts, it would require lots of squinting and even zooming in to fotoshop to be sure. mind you you are looking at these frames for 1/15 or 1/30th of a second during playback, so i think in the end you could do medium compression (by photoshop's scale) and the improvement over ani would be enough use it instead. also since the size of the frame is a fraction of an ani frame, you could double your framerate for an even better animation.
i admit my test should have been done with a 24 bit source image instead of an upsampled 8 bit, so that the compressor would get a full range to work with. but i wanted to show a quick and dirty sampling of what kind of compression you could get with various formats. also i kind of wanted to proove that dxt1 was the optimal choice, but when i put up the numbers for jpeg, i figured the jpeg format would be much better for this application.
-
Mike, try the same thing with one of the tech CB anis we've been rendering. JPG hates wireframes and line drawings but is better at blended areas of color.
-
Galemp: I render out all my ANIs as JPG first already... Everything you've seen committed on SVN was at one point a JPG sequence.
I push for JPG because, believe it or not, professional video studios use it quite frequently. It is a great format for getting rid of picture information we don't need, especially the higher quality versions on the compression.
-
its just dumb.
if your are doing any kind of video post-render editing that isnt just resizeing and similar stuff, you will hit the artefacts barrier horribly.
and if you're going for high quality, then doubly so.
I myself support MNG in this case.
My reccomendation? keep the MNG as-is. keep the eff as a standalone text file alongside the mng in which you can define various keyframing stuff, along with the good old type, fps and frame number...
-
its just dumb.
if your are doing any kind of video post-render editing that isnt just resizeing and similar stuff, you will hit the artefacts barrier horribly.
and if you're going for high quality, then doubly so.
:wtf:
In all my video production experience... nevermind.. it's not worth it...
-
if mng works, it can support jpeg compression, so i would guess that the size would be about the same, it also gives you the option of lossless, and transparency. but il believe it when i see it.
using container-stored jpegs. post render editing would best be done by rendering to a lossless format, do your editing, then batch convert to jpeg for the final product. you never do editing to your lossy compressed images, its just bad practice. you produce your master set and then convert to your distribution format. its the same way i go about texturing.
-
:wtf: You people are going backwards in the discussion it seems.
Since FSO already supports DDS, JPG, PNG, TGA, ANI, BMP, PCX, all those are irrelevant. Discussion about JPG is irrelevant because it's already supported. What should be discussed is addition of a container. MNG itself is a container like GIF and ANI, yet supports both PNG and JPG compression.
So unless you want to go with a container format that can hold all supported image file formats, you're better off with just getting MNG support done. Either solution leaves the choice of compression type to the modders, so the question is which one is easier to implement? I'd say MNG because specification already exists.
-
:wtf: You people are going backwards in the discussion it seems.
Since FSO already supports DDS, JPG, PNG, TGA, ANI, BMP, PCX, all those are irrelevant. Discussion about JPG is irrelevant because it's already supported. What should be discussed is addition of a container. MNG itself is a container like GIF and ANI, yet supports both PNG and JPG compression.
So unless you want to go with a container format that can hold all supported image file formats, you're better off with just getting MNG support done. Either solution leaves the choice of compression type to the modders, so the question is which one is easier to implement? I'd say MNG because specification already exists.
Hmmm... seems you are right... Thanks.
-
Since someone's going to bring this up anyway, I should add that MNG does not address one of the issues a container format should. Namely effects and maps. Both require a container that can hold DDS. But I doubt this is of any real concern, because eventually FSO engine should advance beyond using such inefficient method for displaying animated effects and maps. And since both are loaded to RAM on mission load anyway, I doubt container for effects and maps have any practical advantages beyond cleaner effects and maps directories.
I'll leave explanation of animated effects and maps in modern games to those who know the technical implementation better.
-
Actually a container or an upgrade for .eff that would allow things like playing only certain frames, attaching a different -glow, -shine, -normal etc maps (right now if you want the same -glow on more then one effect the -glow has to be copied and loaded twice) would be welcome as well. So it's not just about a clean directory (which I'm all for).
-
i would only worry about animated interface graphics for now. mainly because effects and the like should be handled with a material system proper.
-
its just dumb.
if your are doing any kind of video post-render editing that isnt just resizeing and similar stuff, you will hit the artefacts barrier horribly.
and if you're going for high quality, then doubly so.
:wtf:
In all my video production experience... nevermind.. it's not worth it...
yes, because you are right by default now? you make relatively good anims. doesnt mean they are perfect, good enough or that you actually know the right and proper way how to do it. so drop the elitism already, and stop supporting a format that shouldnt EVER be used for anything animated or in-game.
-
Knock it off. He argued his point well by providing shots that most agree are all comparable in quality. You came up with "its just dumb." and very little else.
He isn't right by default, he's right by evidence.
-
Knock it off. He argued his point well by providing shots that most agree are all comparable in quality. You came up with "its just dumb." and very little else.
He isn't right by default, he's right by evidence.
thank you for not reading my post.
if your are doing any kind of video post-render editing that isnt just resizeing and similar stuff, you will hit the artefacts barrier horribly.
and if you're going for high quality, then doubly so.
-
Enough of this. Any further off-topicness will be dealt with.
Now, back on track. MNG seems like the way to go here as far as I am concerned, so it has my vote.
-
MNG has mine as well. I'll see what needs to be done to add it in with the existing PNG system we have.
As for maps/etc. Unless nVidia get's layered DDS out to the market before we get a materials system, a basic container that can house DDS for the existing animated glow-maps might be nice.
-
Nice, but unnecessary, I think.
-
a container format might serve as a precursor for a material format, at the very least. at some point you might want a container for maps, shaders, settings, etc which can be used as if it were a texture by its file name like an eff. most of us could and would use containers as it stands.
-
Wrong. As I said before, the last thing we need is a new proprietary format. If we do a material format, it will (hopefully) take the form of a simple text file, like this:
example.mat
$Texture: example.dds
$Texture: example2.dds
... (include further textures as needed; will be handed off to the shader as uniform samplers of the form "uniform sampler2D texture1"
$Numeric Argument: 1
... (arguments are passed as uniform ints or floats, using "integer1", "integer2".... etc naming
$Timer: YES (means the current timer is passed as an argument as well)
$Vertex Shader: example-v.sdr
$Fragment Shader: example-f.sdr
-
We should not just invent a new format, we should use an existing one that's designed for our intended purpose.
- A perfect example of why we shouldn't do that is the font files. That app isn't cross platform, and very few people have successfully used it.
Standards exist for a reason - we should use them.
That way we get editors for free, a standards document to work with and examples to test against.
- If we invent our own, we get none of those things. So you get bugs due to incorrect implementation at both ends, and bugs due to mistakes in the format.
So I would say MNG or OGG.
Given the previous information, MNG looks to be by far the best bet unless someone wants to re-write the movie player.
A materials system is a different kind of usage, so should be handled in another way.
- It also shouldn't be a container because there's a lot of data there that would be shared between materials.
For example, almost every ship in a mission would use the same shader with very different textures. You don't want to have to load and compile that many times from many containers 'just in case' one is different - the code should be able to detect "Ship classes 1..10 use Shader X, ship classes 11..20 use shader Y" and just load shaders X and Y.
-
its just dumb.
if your are doing any kind of video post-render editing that isnt just resizeing and similar stuff, you will hit the artefacts barrier horribly.
and if you're going for high quality, then doubly so.
:wtf:
In all my video production experience... nevermind.. it's not worth it...
yes, because you are right by default now? you make relatively good anims. doesnt mean they are perfect, good enough or that you actually know the right and proper way how to do it. so drop the elitism already, and stop supporting a format that shouldnt EVER be used for anything animated or in-game.
Please find a way to make your points that does not involve personal attacks. Thanks.
-
Since this thread is getting a bit too long and rambling I recommend we start a new one solely for discussing implementation of MNG support.
-
Agreed.