PICS File Format Erik Neumann Daniel Sadowski PICS History Visual Information Inc. originally came up with a very simple way of passing frames of animation between applications. At the Spring 1988 Macintosh Developers Conference, several graphics and animation developers (specifically Aegis, MacroMind, Silicon Beach, and Visual Information) agreed to support this file format. This document describes the PICS format as it stands today. PICS File Format % File Type: PICS (capital letters) This file type has now been registered by MacroMind with Apple for this usage. MacroMind is proposing using the following icon (based on the PICT icon from MacDraw). It would probably be a good idea to use a standard icon across all our applications so that users can come to feel familiar with PICS documents. % File Creator: This can be your own creator type, so that users can enter your program by double-clicking on a PICS icon. Or if your program only supports PICS output, you can use the creator type of another program that supports PICS input (for example MacroMind Director creator type is MMDR) % The file is composed of many PICT resources starting at number 128, and continuing for as many frames as desired. The numbering must be contiguous (no gaps), i.e. 128, 129, 130, 131, etc. Note that the number of frames is equal to Count1Resources('PICT'). % PICT resource 128 describes the complete first frame of the animation. The picFrame rectangle of this first PICT specifies the complete screen size for this animation. This means that all subsequent frames will be drawn within the coordinates specified by this rectangle. % Each additional PICT describes an additional frame. So PICT 129 specifies frame 2, PICT 130 specifies frame 3, etc. These additional PICT's can be either: A. complete frames with the same picFrame rectangle as PICT 128 B. an update to the previous frame of a smaller area. In this case, the rectangle of the update is specified through the picFrame rectangle, and must be within the rectangle of PICT 128. C. if there is no change in the animation during a frame, a PICT with a null picFrame can be created (top, left, bottom, right are all zero). % There may optionally be a resource of type INFO number 128 formatted as follows: BWColor: integer: 0 if black & white PICTs, 1 if color PICTs. Depth: integer: 1,2,4,8,16 preferred color depth. Speed: integer: 1 to 200 preferred speed in frames per second; for a slide presentation a negative value will mean seconds per frame (example: -5 means each frame is shown for 5 seconds). Version: integer: 0 = version number. Currently version number is zero. Creator: longint: Signature of the creator application (eg. 'MMDR' for Director). Largest: longint: If non-zero this is the size of the largest frame in bytes (for preflighting). Note that the length of the INFO resource may increase in the future, so be sure to check the length of the resource before accessing information in it. % There may be other application specific resources but these will be ignored by most other programs. For the user's convenience these should be preserved if possible by other applications that edit an existing PICS document. Comments about PICS This is not intended to be the best possible file format for animation. Instead it is something that we can all easily support today, and allow our users to exchange data between our various programs It's main purpose is as a file interchange format since it will obviously not be very space or speed efficient. However, if Apple ever gives us compression for pixmaps that are built into PICTs then this format could become fairly efficient for certain animations, especially if you use XOR mode copybits on the PICTs 129 and up. If additional versions become necessary in the future (for example, coming up with our own compression scheme for compressing PICT's), then we can change the version number to the INFO resource (files using the new format will then be required to have an INFO resource; files without an INFO resource would be assumed to be version zero). The number 128 was chosen because in the Resource Manager chapter of Inside Macintosh it is stated that "0 through 127 [are] used for other system resources" and the range "128 through 32767 [is] available for your use in whatever way you wish". Note that Visual Information was previously using zero for the first PICT, but Eric Popejoy has agreed to using 128 instead. It is, however, recommended that you use the ROM calls OpenRFPerm, Count1Resources and Get1Resource from I.M. volume IV so that there are no conflicts while reading in the PICT resources. Palettes are assumed to be stored in the PICT's themselves. A program can choose to use the palettes in these PICT's or translate them to it's own palette. Status of PICS As of today, MacroMind Director, VideoWorks II Accelerator, SuperCard, Super 3D Enhanced, Swivel 3D 1.1, and Showcase FX are able to read in and write PICS documents. Visual Information's soon to be released Dimensions may add the ability to read and write PICS documents. Summary There are now two solutions to the problem of moving sequences of images (animation files) between applications in the Macintosh environment: Scrapbook Files: PRO: An existing file format that most people already understand. Many tools exist for creating/editing scrapbooks now. Simple and easy to use. This file format can work equally well for print (high-res) or screen (low-res) orientation. CON: Limit of 256 frames. Each frame must be full screen size, so files can become very large very quickly. PICS Files: PRO: No limit to number of frames. Frames can be "partial updates" so files can be much smaller than corresponding Scrapbook file. CON: Unfamiliar new file format. Not many applications support it yet. This is screen-oriented format only (because the partial updates must be done into a buffer, whereby the PICT's all become bitmap type data). We at MacroMind are recommending the following: Scrapbook Files: This is the preferred way of transferring small (50 frames or less) sequences of images. Applications that do not display animation but can generate sequential images should export scrapbooks. Examples of applications that would benefit from an export scrapbook feature are: 3D Graphics, Illustrator's "tweening" capability, or LetraStudio's Text manipulation. Please see the notes below about how such scrapbooks should be prepared. PICS Files: This is the preferred way of transferring large numbers of frames (above 100) between animation programs because of the great savings in file size. For example, an application that wants to send a large number of frames to the VideoWorks Accelerator should use this format. Notes % MacroMind Director exports and imports both types of files, Scrapbook and PICS. We are, however, emphasizing Scrapbooks for importing into MacroMind Director because we feel most users will be moving small (below 50) numbers of images at a time. % When creating Scrapbooks, please make sure that the picFrame of the PICT images is such that each successive image is correctly "registered" with respect to the next image. When you create a PICT, you are performing quickdraw calls into a port. Pretend that the port you are drawing into is visible on the screen. Don't draw into some arbitrary place in the port, but put the image where it would make sense in relation to the previous image (this is called "registration"). % MacroMind Director ships with a "Scrapbook FKEY" which grabs images off the screen directly into a Scrapbook (similar to the Capture* FKEY). This can greatly simplify the process of importing images into Director. Any comments on the PICS file format can be sent to: Erik Neumann MacroMind, Inc. 410 Townsend Street, Suite 408 San Francisco, CA 94107 AppleLink D3431