Probably the one thing I dislike most about Captivate is the bloat in file size. There have been times when I seriously considered ditching Captivate and developing my own Flash-based capture template in the Flash IDE (presumably with a library containing all of the objects that Captivate has (callouts, hotspots, etc) and using a workflow like this: Snagit to capture individual screens during the ‘capture’ process, import the screen captures into Flash and then tween the mouse between them. But then I started playing more with Captivate with the sole purpose of getting file size down to a minimum. Here’s what I came up with:
I capture at 1024×768 but then reduce down to as small as I need. One time. Yeah – resizing projects is alleged to be a bad idea, but I’ve found that *reducing* size once is fine, so long as it isn’t too far down. I also have abandoned all Captivate-generated skins, playback controls, etc. They are bloated and certain things are annoying about them to me. Like the components that ship with Flash 8, they are usually a dead-end waiting to bite you in the behind if you go that route and the client wants a feature that that component can’t do.
Also, I advise the following:
Set your video quality to your Captivate ’slides’ to Standard. Why in the world they default to “High Quality” is a debate for another day. I have found there is no degradation if reduced to Standard quality.
Anytime I import images into Captivate I always, if possible, merge it into the background. This started as a practical way to avoid having to worry about the timeline in regards to imported images, but it also helps with filesize.
Speaking of images…..BMP is the way to go. EDIT: I just did a test with Captivate 3 and it seems when importing things make sense now – jpg’s and gifs are preferrable in terms of filesize. But still, copying and then pasting directly into Captivate (which is how people often insert images), for some unknown reason bitmaps still often result in a lower file size in the library than a jpg. I just did a test to verify in CP3 and here is a screenshot of the resulting library:
Audio is a killer. Whenever practical I avoid using audio unless I know bandwidth is not an issue. Keep in mind that most corporate users are in cubicles and don’t have headphones. They shouldn’t/won’t annoy their neighbors with droning voiceovers anyway : )Â But, if I do use audio, I keep in mind that it is not necessary to have “FM” or high quality settings for voiceovers. I always set a custom bitrate of 32kbps and sometimes even go down to 24kbps, at 22khz.
It’s also important to prepare the source properly, like reducing color depth if possible, avoiding recording hi-res desktop wallpapers and the like.
8 Comments
Do you know of a way to force the Captivate SWF file to stream (without importing into Flash)?
By “importing into Flash” I assume you either mean:
a. Importing the Captivate source file (.cp) into Flash.
or
b: Wrapping the Captivate-generated swf with a Flash IDE generated swf via loadMovie(), MovieClipLoader, etc.
I always opt for option b unless I want to just use the built-in Captivate navigation.
I *never* import a .cp into Flash because I don’t see the point. I’ve never seen a convincing argument/reason for doing so. I’m sure there is, but I haven’t seen one yet!
Now, if all you want to do is stream the Captivate-generated swf directly on a page then just embed it using swfobject or something like that.
can you elaborate on why bmp is the way to go? What are the benefit of using BMP than other formats? size? quality?
Why would import a huge BMP instead of JPG if it’s a photo?
Thanks,
I just did a test (it’s been a couple of versions since I last tested and revised my entry on this in accordance with the test – basically, when copying and pasting into Captivate, BMP files result in a smaller filesize over jpg’s. But importing works as one would expect. See the screenshot.
Oh – in case you were wondering…the same exact jpg file was used as the source for both the importing and the pasting. Likewise for the bitmap.
If you record at 1024 x 768, what are your final dimensions?
As to the reason why BMPs are preferable to JPGs I would offer the following information from my experience using other capture tools such as SnagIt. My suspicion is that when you paste a screenshot into Captivate as a BMP (and you can see it as a BMP listed under Images or Backgrounds in the library), when Captivate publishes out using Standard quality it turns it into a GIF file. I have noticed that with Standard quality settings you get only 256 colours…same as GIF. If your screenshot is of a software interface, and it doesn’t happen to have lots of fancy gradients, then 256 colours is likely to be plenty to render it perfectly. A BMP image of the same screen will usually be about ten times the filesize of a 256 colour GIF, and may look identical. The reason is the algorithm that GIF uses to compress the data. GIF compression works in lines of pixels and basically says: “Repeat this colour for the next n pixels until it changes.” GIF is especially efficient in compressing images that have large areas of flat colour (e.g. software screens), whereas JPG compression is designed to be more efficient where you have lots of gradients (e.g. photos). The overall effect is that if you use GIF for a screenshot the edges of the onscreen text will be nice and crisp and sharp. But if you use JPG the edges will appear “fuzzy” because JPG is trying to average out the differences between pixels.
I found that using .jpg files as the background image dramatically increases the file size of the .swf output. The above comment about a bmp algorithm explains what I found. I also found that resizing the C3 project dramatically increases the .swf output – my guess is that it also affects a compression algorithm. I downsized from 1014X713 to about 10% smaller (don’t recall exact dimensions) and the .swf output doubled in some cases (ex: 1.5 MB to 3.02; 1.42 to 2.46 MB; 1.89 to 3.25 MB). Thankfully I made copies of most of the .cp files before I resized so I was able to revert to the original size.