PGC Portfolio Graphics Compressed File Specification ---------------------------------------------------- by Don Messerli, Software Vineyard Revision 01 1/4/91 Introduction ------------ The PGC spec allows graphic files on the Portfolio (formerly called PGF files) to be compressed to save disk (RAM Card) space. We all know how much RAM cards cost! A little background ------------------- The Portfolio's screen is 240 x 64 pixels when in graphics mode. Being monochome, it only takes 1 bit to represent a single pixel. Therefore, 8 pixels per byte. A PGF ends up being 64 rows of 30 bytes each for a total of 1920 bytes. PGF files could simply be copied from video ram to disk and vice-versa. This was pretty simple. All PGF files were 1920 bytes no matter how complex the picture. A real space waster in most cases. Compression became a logical next step. What will compression do? ------------------------- Compression can save quite a bit of space. Typically from 20 to 80% depending on the file. However, because of the compression algorithm I have chosen, it is also possible for a file to become larger. This happens with files that have a lot of random dots on the screen with little repetition. Digitized photos are the culprits. Fortunately, because of the small size of the Portfolio screen, we probably won't be seeing too many of them. PGC File Format --------------- Header - The first 3 bytes of the file are the PGC header. This is the only way to tell if the file is a PGC file or not. This should always be checked when reading PGC files. Your decoder routines could take a quick trip into never-never land if you try to decode a spreadsheet file. The three bytes that make up the header are the ASCII codes for 'P' and 'G' followed by the revision number in hex. These three bytes should be: "\x50\x47\x01" P G 01 Data - The picture data is made up of repeating sets of single index bytes followed by data bytes. The index byte tells the decoder how to handle the data that follows. The key is whether the high bit (\x80) is set or not. The maximum number of data bytes following an index byte is 127. High Bit Set ------------ If the high bit is set, it indicates that the data is a string of identical bytes. The low 7 bits indicate how many times to repeat the following byte (maximum is 127). Example: 86 FF index data byte High bit of index byte is set, low 7 bits = 6. Repeat data byte (FF) 6 times. High Bit Not Set ---------------- If the high bit is NOT set, it indicates that the data following is a string of unique bytes and should be copied as is. The low 7 bits indicate how many bytes to copy (max is 127). Example: 0A FF 01 10 09 1A BB CE D0 FF 1A index data bytes High bit of index byte is NOT set, low 7 bits = 10. Copy next 10 bytes as is. Where do we go from here? ------------------------- Writing a decoder is fairly straightforward. The following is the general algorithm: do { get a byte from PGC image if high bit is set index = byte - 128 get data byte write data byte, index times else index = byte copy next index # of bytes } while less than 1920 bytes written Writing an efficient compressor is a little more difficult. I plan to upload a library of functions in the near future. If you encounter difficulty writing a compressor, please contact me via electronic mail. What are these other files? --------------------------- I have included a few PGF files to give your compressors and decoders a real workout. BEST.PGF - This is a pure black image. It should compress down to 35 bytes. WORST.PGF - This image is made up of runs of 2 identical bytes alternated with single unique bytes. It should end up being larger as a PGC file (2524 bytes) than as a PGF file (1920 bytes). All decoders should be able to handle this file. In Closing ---------- I hope this information is helpful for those writing graphics applications for the Portfolio. It is my sincere wish that the PGC format is widely supported in the Portfolio arena and that it promotes compatibility between graphics applications on the Portfolio. My sincere thanks to BJ Gleason for including PGC support in PBASIC. That is a major step in making my wish come true. Please support the PGC format whenever possible. If your application must output PGF files, because you're trying to write the world's smallest TSR (or something) and you can't commit to the overhead required by a compressor, that is unavoidable. The PGF files can later be compressed with PGCOMP (my compressor). It is still preferable to store files that end up larger as PGC files as PGC files anyway. This means software only has to worry about reading the PGC format. Versions of PGEDIT greater than 1.10 will read either PGF or PGC files. However, they will only save in PGC format. BJ Gleason has indicated that PBASIC 3.1 will only read and write PGC files. If you have any questions, comments, or kind words, please send me electronic mail: Don Messerli Compuserve 72500,1671 GEnie DMESS