#Decrease .FLC file?
13 messages in this thread
Anyone,
Is there any way I can decrease a .FLC file size, keeping the file a
FLC file.
And is it possible to go from a 256 color .FLC to a 64 color .FLC?
Any suggestions appreciated.
Thanks,
Mike C.
/* Is there any way I can decrease a .FLC file size, keeping the file a FLC
file. */
Hi Michael; The way this question is phrased, I could have fun and say "Why
yes, delete all the frames except two and save the file. It will still be an
FLC." <g> Somehow I have a feeling though that this is not what you meant.
In general, is there a way to decrease a flic _without_ changing it– no.
Some common ways flic filesizes can be reduced though:
1> frame reduction : either by macro or POCO routine… in the same vein that
an existing flic can be doubled, tripled etc, by using macros or a POCO routine
you can take out every nth frame, etc and cut the filesize down. This does chop
the flic up though and may have skips depending on the animation.
2> palette squeezing : by reducing the amount of colors in each frame over time
and applying one palette, the amount of overlapping colors used in a flick
increases, thereby reducing the delta between frames and reducing the size of
the flic. The price; color degredation. If you're good with palette cropping
though, it's amazing how few colors are necessary to keep an image decent. But
this sweet spot is not found through formula since it is image dependent.
3> re-assemblies : some flics are generated from smaller pieces and can be
pieced together again using macros and still images. For example, if your flic
involved a cel being applied to a moving background, all that is essential to
reconstructing the entire animation would be the cel, the background image and
possibly a macro to reproduce it or a text file to remind you how it was put
together. I've been able to save 20MB animations down to 50K using this
technique. No, it wouldn't be a FLC file, but in essence it has the potential
within a relatively small amount of time, to be created back into one. The
ultimate compression scheme if it applies.
4> format conversions: if you're familiar with JPEG files, you know that the
compression of a file can be controlled at a price of image degredation. If you
take a flic and NUMPIC it out to JPEGs, increas the compression of each image
and then re-assemble using NUMPIC into a flic, your size will also decrease.
The flic will be degraded as a whole though. Sidenote, NUMPIC doesn't have JPEG
option, but if you go out to GIF first, then automate conversion using ANI's
JPEG driver, automate JPEG compression change, convert back to GIF and
re-assemble, this works. Well I might add. If you program, POCO can automate
this entire process easily. JPEG driver is available in the forum Animator Pro
library
5> resolution change : by using ANICONV, the resolution of a flic can be
reduced to something smaller. The price is pixelation, but depending on the
purpose of the animation, 640×480 may be sufficient at 320×200, 640×480 may be
sufficient for 1024×768, etc. Filesize results from number of pixels, so this
type of reduction is typically scalar.
6> single palette : depending again on how the animation was generated, if
frames have such different deltas that each frame carried its own palette, you
might try reducing all frames to a common palette, reducing thepalette delta.
These are just a few of the many ways reductions can be done. In my own work,
re-assemblies tend to be the most beneficial, but you really have to keep your
P's and Q's crossed on the procedure to rebuild things correctly.
Keep in mind that a lot of the alternatives depend on where the animation is
being generated from. If you're a 3D Studio user for example, the 3DS file
alone (or Project file set) can always re-create the animation with time. If
ANI generated them, you can keep track of the creation process and save ther
process rather than the final animations. How are you generating your
animations?
/* And is it possible to go from a 256 color .FLC to a 64 color .FLC? */
Sure. Bone up on ANI's palette functions big time. -dave
Thanks for the reply.
My question will be changed somewhat. I am creating an animation which should
be able to run in Windows 3.1X using the standard "VGA" driver which comes with
Windows and is usually installed as a default when Windows is installed. I
believe that this "VGA" driver is only 16 colors. So, is there some way I can
import this Windows VGA color palette into, say, Animator Pro, and then take a
256 color .FLC and convert it to use the 16 color palette?
Or, is it possible to render in 3D Studio to the 16 color palette that comes
with Windows?
Thanks again,
Mike C.
PMJI. Since you've got 3DS, check out the FLIC-COLORS parameter on page 57 of
the Installation Guide. It lets you specify the maximum # of colors in your
output palette — designed specifically for Windows. If you've already rendered
a flic, you can convert in in 3DS by assigning it as a background with no
geometry, and then rendering the blank scene. Should convert pretty fast. As an
alternative to using FLIC-COLORS, you could design your own palette and use
Custom Palette to convert an existing flic — or render a new flic to a limited
palette.
– Jack
Jack,
It says in Installation Guide to use 236 colors for flics under Windows. Is 236
colors for if you are using a 256-color driver for Windows or for the "VGA"
driver (default when installing); or are they the same? If not, how many colors
should I use for the "VGA" driver? I thought it was 16 colors, but I'm not
sure. (Maybe 64). Whatever it is, do I need to get that particular palette from
Windows?
Thanks,
Mike C.
I think message #141231 has most of the answers for you on this.
Windows steals as many as 20 colors for its interface in a 256-color
display. Hence, the recommended 236 number. Most VGA display handle
256 colors. At any rate, a 3D rendering isn't going to look very
presentable in a 16-color palette — though you're welcome to try it.
This is for a screen saver, by the way. I tried a 236 color flic, and
changed my Windows driver to "VGA". It looks fine in Animator Pro,
but does not look good as a screen saver (It seems like the problem
is in the colors, not enough).
It's been so long since I've worked with VGA…
Straight VGA is only going to give you 256 colors a 320×200
resolution. Since Windows requires 640×480, the VGA driver is only
going to get you 16 colors, which are not really enough for a 3D
animation (unless you plan _very_ carefully). I'm not sure what your
goal is, but if you're planning on sending screen savers to others,
you should simply require a 256-color Windows display and design
accordingly. Most people can display 256-colors at 640×480 on Windows
these days.
– J
You may also take a note of the files installed with WINPLA.EXE in our forum
here. You get a AAVGA.DLL – you could get your screensaver (depending on how
you're implementing it) to start up our player, and that would allow you to run
a 320x200x256 screen saver full screen. I think this is done with the "Wicked
Windows" screen saver as well as the Kamyan and other screen savers here in the
forum.
/* My question will be changed somewhat. I am creating an animation which
should be able to run in Windows 3.1X using the standard "VGA" driver which
comes with Windows and is usually installed as a default when Windows is
installed. I believe that this "VGA" driver is only 16 colors. So, is there
some way I can import this Windows VGA color palette into, say, Animator Pro,
and then take a 256 color .FLC and convert it to use the 16 color palette? */
Sure. Depending on the Windows driver you're working towards, it is possible to
shrink the palette down to 236 (leaving the first 10 and last 10 registers
blank), 64, or 16 (understanding that the flic color degredation follows). If
you capture a Windows screen (PrntScrn) to a BMP and import it into ANI, take a
look at the pallet and you'll see how many colors are being used to be sure.
/* Or, is it possible to render in 3D Studio to the 16 color palette that comes
with Windows? */
3DS can use a custom palette created in ANI (which controls how many colors are
reserved for Windows), or you can be specific by setting the parameters file
FLIC-COLORS variable to 236, 64 or 16. -dave
Dave – great stuff!
I mentioned Ed Kellerman's tricks with BIR06.Zip and TILE64.ZIP in my response
to Michael. I tried your suggestion about the JPEG idea, and have 2 comments.
I did not see a file improvement when I took MRNUMO.FLC and ran numpic -> JPEG.
Here's some tests:
MRNUMO FLC 50,914 (The original, 320×200)
MRNUMJPG FLC 418,618 (Numpic outputting JPG files, then inputting them
into a flic)
MRNUMJP1 FLC 389,030 (Running One Palette on MRNUMJPG.FLC)
MRNUMO01 FLI 43,384 (Saving original as an FLI)
Of course, this is a very skewed example – higher res images might benefit.
Finally, a comment about NUMPIC not including JPG conversion. If you have the
file JPEG.DRV in your resource directory, you might modify the NUMPIC.POC file
to include the JPG conversion (after backing up NUMPIC.POC of course).
Using EDIT, load NUMPIC and (S)earch for "Macintosh" minus the quotation marks
to bring you into the section of NUMPIC.POC you need to modify. You can see
the word Macintosh there. added the "JPEG" in front of the word Macintosh so
it would show up on the choices menu there. Right below that section I added
the name of the JPG driver (JPEG.DRV) and the file extension (.JPG), each in
front of the Macintosh section. I saved the file and it worked! I'm going to
use my new NUMPIC instead of the original.
There may some repercussions about having done this, related to the fact that
JPG files can be 24 bit, but I think there's a place in the NUMPIC.POC I can
modify if that's the case.
Code snippet:
char pdr_prompt[] = "Please select output format:";
char *pdr_choices[] = {"GIF", "PCX", "TIFF", "Targa", "JPEG", "Macintosh Pict",
"Windows Bitmap", "Cancel"};
char *pdr_names[] = {"GIF.PDR", "PCX.PDR", "TIFF.PDR", "TARGA.PDR",
"JPEG.PDR", "PICT.PDR", "BMP.PDR"};
char *pdr_suffixes[] = {".GIF", ".PCX", ".TIF", ".TGA", ".JPG", ".PCT",
".BMP"};
/* Of course, this is a very skewed example – higher res images might benefit.
*/
You're right, Nik. The re-assembly is larger using the ANI JPEG driver. But
check out the filesizes of the original FLC with the combined resultant JPG
files! 🙂 In other words, for many animation, the sum of individual frames is
smaller than the combined flic. These can always be re-assembled into the flic
again. I wasn't very clear about this (this is what happens when you try to do
support after midnight <grin>):
"4> format conversions: if you're familiar with JPEG files, you know that the
compression of a file can be controlled at a price of image degredation. If you
take a flic and NUMPIC it out to JPEGs, increas the compression of each image
and then re-assemble using NUMPIC into a flic, your size will also"
There are various compression routines out there (I like the freeware
GIF2JP.ZIP in GRAPHSUPP Lib 4-controls quality, quickly) to shrink the JPG
files sizes down. The ANI JPG driver doesn't have quality control (nice option
though, wouldn't it be?) but again there are utilities to take existing JPGs to
different qualities. I made a big assumption here that "if you're familiar with
JPEGs" the user would immediately understand how quality compression would
shrink file size.
"decrease. The flic will be degraded as a whole though. Sidenote, NUMPIC
doesn't have JPEG option, but if you go out to GIF first, then automate
conversion using ANI's JPEG driver, automate JPEG compression change, convert
back to GIF and re-assemble, this works. Well I might add. If you program, POCO
can automate this entire process easily. JPEG driver is available in the forum
Animator Pro library"
The step I did not get specific on here was JPG to smaller JPG quality change.
Using POCO or NUMPIC, JPGs can be re-assembled into flic again, but if they are
saved as a series of images, filesize decreases. Sometimes techniques cause us
to re-think the way we visualize a "flic". Here, I'm seeing a "flic" as a true
series of images, saving them as such (which can take 25% or less of the
original flic size) knowing that, like an earlier method described where things
are broken down into pieces, the final flic can be re-assembled if needed.
By the way… great job on the rewrite of NUMPIC. I did this as soon as the JPG
driver became available, never had a need to rewrite it to import JPG since
JPG2GIF and GIF2JPG can take a series of GIFs, quality control them to JPGs and
then convert them back to GIFs for NUMPIC re-assemble.
Did you guys ever check out PWRCEL? 🙂 -dave
Looks as though you already have some good suggestions. Check out some works
by Ed Kellerman – they may MIND BOGGLE, so beware!
File Info for BIR06.ZIP
Section: Autodesk Animator Contributor: 71532,3255 Size: 36276
Submitted: 6/9/94 Type: Binary Accesses: 99
Title: One-frame Animation? By Ed K.
Keys: KELLERMAN ONE FRAME COLOR CYCLING BIRDS 1024X768 FLC ANIPRO
An example of how to use color cycling to create animations. The other
example is "Color Cyc. How To" (TILE64.zip).
It will help you understand why, for color-cycled animations, you only need to
create one frame; and how the effect of motion is achieved by reusing that
frame with different palettes.
After following the simple instructions, you will convert this one-frame FLC
into
an animation of dozens of birds flying across the sky.
Ed Kellerman
[download time at 2400 baud: 3 min]
File Info for TILE64.ZIP
Section: Autodesk Animator Contributor: 71532,3255 Size: 12299
Submitted: 1/10/94 Type: Binary Accesses: 78
Title: Color Cyc. How To. By Ed Kellerman
Keys: ANIPRO FLC COLOR CYCLING KELLERMAN
Follow the simple instructions given in this one-frame FLC to create a very
interesting 32-frame color-cycled animation.
The final FLC is actually encoded in the one frame you download. You simply
make 31 more identical frames and apply color cycling.
The 640×480 FLC you create would require about 9 Meg (instead of about
150K), if done without color cycling.
Comments appreciated. Ed Kellerman.
(Approximate download time at 2400 bps using CIS B: 0:41)