chris@ncmicro.lonestar.org (Chris Arps) (01/30/91)
Since there is all this interest in JPEG I would like to add my two cents worth. I currently create animations for the PC and would like to share them with others. Unfortunately they can be huge in size and there are several formats for animations (.gl, .fli, amiga deluxe paint iii, atari files, and who knows what else). I assume that JPEG includes a spec for animations/moving video as real-time video processing is its strongpoint. How about the JPEG group developing a standard for animations (with sound) as well as still images? This would allow all the users on the net to view the animations as well as compress them down to a reasonable size. The 150K raytraced animation that I posted to alt.binaries.multimedia originally was about 1.6 meg! I am sure that once a machine independent standard is defined we can write converters for each of the animation file types and bring a whole new animated world to these *nix boxes! -- Chris Arps ***THIS SPACE FOR RENT*** *New Music*SONIC YOUTH*FAITH NO MORE* NC/Scientific Software, Musican, *SOCIAL DISTORTION*PETER HAMILL*YELLO Animator, 4 Dogs,2 Birds,1 cat,1 fish *Old Music*SPIRIT*MMANN*VDGG*HENDRIX Concerning computers - "Anything slower than instantaneous is intolerable!"
ltran@pluton.matrox.com (Linh TRAN) (01/31/91)
chris@ncmicro.lonestar.org (Chris Arps) writes: >I assume that JPEG includes a spec for animations/moving video as real-time >video processing is its strongpoint. How about the JPEG group developing >a standard for animations (with sound) as well as still images? I think MPEG is working on standard for motion picture (animation and sound included). The MPEG uses fundamentally the same algorithm regarding compression scheme (it use Discrete Cosine Transform, follow by Quantization of coefficients and Huffman encoding, for intra frame compression). JPEG mandate is to arrive at photographic resolution compression. -- PHU"O"NG NGUYE^N | --/\\ //---- / /---/ -/ email: ltran@pluton.matrox.com | / \\ // /---/ / I USUALLY KNOW WHAT I AM SAYING | -/----\\/--- / / ....PROBABLY NOT THIS TIME........ | _/ \\____ ---/ --/--
vinsci@nic.funet.fi (Leonard Norrgard) (01/31/91)
In article <277@ncmicro.lonestar.org> chris@ncmicro.lonestar.org (Chris Arps) writes: [...] I currently create animations for the PC and would like to share them with others. Unfortunately they can be huge in size and there are several formats for animations (.gl, .fli, amiga deluxe paint iii, atari files, and who knows what else). [...] Just wanted to point out that the Amiga animation file format is part of the standard IFF file format, and is not Amiga-dependant in any way. Dpaint iii is one of the many, many amiga programs supporting the IFF/ANIM format... I am sure that once a machine independent standard is defined we can write converters for each of the animation file types and bring a whole new animated world to these *nix boxes! You will not get animation with the hardware; if you want to do animation under unix, may I suggest you take a look at the Amiga Unix platform running SysVR4. > Chris Arps ***THIS SPACE FOR RENT*** *New Music*SONIC YOUTH*FAITH NO MORE* >[...] > Concerning computers - "Anything slower than instantaneous is intolerable!" Now apply that to animation... :-)
kdarling@hobbes.ncsu.edu (Kevin Darling) (02/01/91)
(I'll get to the standards discussion; please bear with this first part:) vinsci@nic.funet.fi (Leonard Norrgard) writes: | Just wanted to point out that the Amiga animation file format is part | of the standard IFF file format, and is not Amiga-dependent in any way. Incorrect, for several reasons: The Amiga ANIM format is geared towards separate bit-plane video only; and limited to 8-12 planes. ANIMs using Amiga HAM mode to show more colors are _extremely_ Amiga-dependent. Worst of all, ANIM files created by the Sculpt/Animate 3D programs are usually encoded using a non-public format, _totally_ defeating interchange. However, except for the large number of those last type files (I hate them!), most other ANIMs can be translated to a better form for other systems and played back. I do this on my 68070/VSC-video computer, and a friend does it on his VGA-video IBM clone... both quite different from the Amiga. | You will not get animation with the [other?] hardware; if you want to do | animation under unix, may I suggest you take a look at the Amiga Unix | platform running SysVR4. We can discuss that on comp.unix.amiga... but if you're thinking of the Ami blitter, it's _not_ used on ANIMs. And I don't think unix uses it at all. Amigans have many misconceptions about ANIMs, partly due to the fact that the Amiga _does_ have lots of nice animation production software available. Okay, now that THAT mess is out of the way, the original comment was: > chris@ncmicro.lonestar.org (Chris Arps) writes: > I am sure that once a machine independent standard is defined we > can write converters for each of the animation file types and bring > a whole new animated world to these *nix boxes! I'm all for such a standard, and will be back with more comments later. At this time I just want to note that even existing formats are okay, as long as: 1. The format is publicly available. 2. The format is adhered to exactly (not always true). Any future "independent" format should also support sound/music timing. Sidenote: I've gotten the Microsoft/IBM "RIFF" docs (IFF based); PClone systems will be the overwhelming majority, so it makes some sense to look into using that format. Unfortunately, the MultiMedia Movie file format (MMM) has yet to be released. Perhaps at the Microsoft conference this March?? Anyone know more? - kevin <kdarling@catt.ncsu.edu>
vinsci@nic.funet.fi (Leonard Norrgard) (02/01/91)
In article <VINSCI.91Jan31072228@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes:
You will not get animation with the hardware; if you want to do
animation under unix, may I suggest you take a look at the Amiga Unix
platform running SysVR4.
A remarkable conclusion indeed :-), just ignore the "You will not... ;"
part.
-- Leonardamanda@visix.com (Amanda Walker) (02/03/91)
In article <277@ncmicro.lonestar.org> chris@ncmicro.lonestar.org (Chris Arps) writes: >I assume that JPEG includes a spec for animations/moving video Actually, I believe there's a separate working group for full-motion video, called "MPEG." Last I heard, their standard wasn't as far along, although it uses some of the same techniques (notably DCTs). -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "Truth often suffers more by the heat of its defenders than from the arguments of its opposers." --William Penn, _Fruits of Solitude_
kdarling@hobbes.ncsu.edu (Kevin Darling) (02/05/91)
kdarling@hobbes.ncsu.edu (Kevin Darling) [KD] and
vinsci@nic.funet.fi (Leonard Norrgard) [LN] write:
LN> Just wanted to point out that the Amiga animation file format is part
of the standard IFF file format, and is not Amiga-dependent in any way.
KD> Incorrect, for several reasons: The Amiga ANIM format is geared towards
separate bit-plane video only; and limited to 8-12 planes.
LN> IFF/ANIM is a file format, not a hardware display standard. [...]
The 8-12 planes stuff is changing at the same rate as native frame
Yes, you're right. However, the plane limit still stands for all the
compression formats under ANIM that I know of. If more are added later,
then we're really talking about a new file format <g>.
KD> ANIMs using Amiga HAM mode [...] are _extremely_ Amiga-dependent.
LN> No-one has denied you the right to build a HAM-compatible display.
True. But your original statement was that it "is not Amiga-dependent
in any way" ;-). Sure, you can translate those ANIMs with extra work,
but they're a _long_ way from being in a nicely independent format.
In any case, Amiga ANIMS violate IFF chunk rules... the docs admit that.
LN> There is different hardware and your file format must be able to use
them all, or it will end up in the YAFF (Yet Another File Format) trashcan.
How about support for high-end graphics systems? Perhaps a file format
that provides room for extensions is the only reasonable in the long term.
That seems backwards to me. The file format should be generalized, instead
of having special cases for every piece of hardware made. Did I misread you?
Personally I'm for an IFF-based animation distribution format. Partly because
it's a simple, open file structure. And partly because IBM/Microsoft have
gone the same route with their RIFF multimedia format.
Now, the biggest thing I have against RIFF is that the authors were PC
chauvinists in the extreme, using Intelloid little-Endian byte ordering
even in the headers. Which makes debugging files harder. And the docs
become a bit ludicrous... eg: a "BitMap" file has "MB" instead of "BM".
cheers - kevin <kdarling@catt.ncsu.edu>vinsci@nic.funet.fi (Leonard Norrgard) (02/06/91)
In article <1991Feb5.042435.16823@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes:
kdarling@hobbes.ncsu.edu (Kevin Darling) [KD] and
vinsci@nic.funet.fi (Leonard Norrgard) [LN] write:
[Sorry for breaking the indentation scheme here... I need to hack gnus
a bit or two]
LN> There is different hardware and your file format must be able to use
them all, or it will end up in the YAFF (Yet Another File Format) trashcan.
How about support for high-end graphics systems? Perhaps a file format
that provides room for extensions is the only reasonable in the long term.
That seems backwards to me. The file format should be generalized, instead
of having special cases for every piece of hardware made. Did I misread you?
I think we are dealing with two separate problems here, one being the
already existing variety of hardware, the other being new whiz-bang
hardware featuring things that haven't been thought of yet and thus
are hard to provide for in the standard other than by having extension
hooks (something better preferred) for later use.
For the first part of the problem, it seems there need to be a goal
for the file format. This could be either generality or capability; or
both if you want eternal fame :-). The generality (there must be a
better word...) part is rather easy: as small a subset as usable
across a wide range of platforms. This has its risks; while it would
be easy to transfer animations from system to system, that may not be
what is wanted. I think many are prepared to trade some time/cost to
have a more capable format converted to their system and get a higher
quality animation, rather than having simple/very_fast conversion with
a format that can't do things they'd like it to.
Capability is much harder, the problem being where to stop:
Should the format support blitters [or fast CPU's if that is what a
machine have]? (Think of it as really compressed anims in the case
where only a small part of the pic changes from fram to frame...)
Extra channels? (Why not?)
Should it have support for other scene transitions than "cut"? (I
think so. These animations are going to grow to films...) Then, it
must support more than one source channel so as to be able to display
parts from one or more channels activated in the transition...
How does sound get synch'ed with the animation? SMPTE? In a separate
file?
Personally I'm for an IFF-based animation distribution format. Partly because
it's a simple, open file structure. And partly because IBM/Microsoft have
gone the same route with their RIFF multimedia format.
Now, the biggest thing I have against RIFF is that the authors were PC
chauvinists in the extreme, using Intelloid little-Endian byte ordering
even in the headers. Which makes debugging files harder. And the docs
become a bit ludicrous... eg: a "BitMap" file has "MB" instead of "BM".
Not being an MS (or PC for that matter) developer, where can I get the
RIFF specs? (FTP?)
I suspect that I've begun to reinvent the wheel here; all this must
have been taken care of somewhere already... :-)
cheers - kevin <kdarling@catt.ncsu.edu>
-- Leonardminakami@Neon.Stanford.EDU (Michael K. Minakami) (02/06/91)
In article <1991Feb6.005719.7550@javelin.es.com> gclapp@javelin.UUCP (Glenn Clapp) writes: >I had to get in on the IFF/ANIM brouuhaha. Just an interresting note, >the IBM version of Deluxe Paint Animation can't read Amiga ANIM files >without saving/reading the individual frames. They don't even provide >a converter. Autodesk Animator (the competition) provides a converter >that will convert Amiga ANIMs to the .FLI format. Funny how the >originators can't share data from one system to another but the competition >can. Could someone out there please refer us poor souls who lack Autodesk Animator and Deluxe Paint Animation to a program to convert ANIN to .LFI or maybe grasprt format? Thanks Mike -- ------------------------------------------------------------- - info { id me;
kdarling@hobbes.ncsu.edu (Kevin Darling) (02/07/91)
In <VINSCI.91Feb5213011@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: > [your pardon if I pick out the wrong points :-] > I think we are dealing with two separate problems here, one being the > already existing variety of hardware, the other being new whiz-bang > hardware featuring things that haven't been thought of yet > [...] > For the first part of the problem, it seems there need to be a goal for > the file format. This could be either generality or capability; or both > [...] > I think many are prepared to trade some time/cost to > have a more capable format converted to their system and get a higher > quality animation, rather than having simple/very_fast conversion with > a format that can't do things they'd like it to. Keep the format general, with lots of hints embedded, and it can be converted, and enhanced or degraded, as need be on each machine. This indicates a time/cost tradeoff, so I agree there. > Capability is much harder, the problem being where to stop: > Should the format support blitters [or fast CPU's if that is what a Nope :-). If one machine can play back faster, it shouldn't matter to the file format... as long as there's a time value in there. The point is the exchange of data, not the exact hardware playing it back. Eg: my video chip can realtime display color RLE data... yet I wouldn't want to force everyone to be able to convert from/to my special format. > Extra channels? (Why not?) > Should it have support for other scene transitions than "cut"? (I > think so. These animations are going to grow to films...) [...] > How does sound get synch'ed with the animation? SMPTE? In a separate file? Good points. Exactly what we need to discuss. I believe there's an ANSI committee looking into this, too. Anyone know more about that? > Not being an MS (or PC for that matter) developer, where can I get the > RIFF specs? (FTP?) I'll try to re-find that info. Or call Microsoft... they'll send the docs. A request of my own in turn: since I know nothing about PC anim formats, can someone point me to (or post) some info on popular ones? thanks! best regards, kevin <kdarling@catt.ncsu.edu> (in a rush today - sorry)
niall@c3.PLA.CA.US (Neal Bedard) (03/04/91)
In article <277@ncmicro.lonestar.org> chris@ncmicro.lonestar.org (Chris Arps) writes: >Since there is all this interest in JPEG I would like to add >my two cents worth. [...] >I assume that JPEG includes a spec for animations/moving video as real-time >video processing is its strongpoint. How about the JPEG group developing >a standard for animations (with sound) as well as still images? It's in the works. C Cube hosted a mini-conference last friday (5-1) covering just this topic. If you need further info, contact: Eric Hamiltion C-Cube Microsystems 399-A W. Trimble Road San Jose, CA. 95131 ph: 408-944-6300 -Neal [niall@c3.com]