PICTs are funny beasts, for what it's worth. A common misconception is that they're a bitmap image format only; they're not - they can also contain vector information, animation, and probably a load of other stuff that virtually no-one knows about. What you should know is that PICT is the format you need to use for all your M-related artwork. (There's usually a few folk asking if you can use JPEGs in terms, etc - and the answer is still no. This doesn't mean you can't take advantage of JPEG compression though, if you wish, as you'll see below.)

Don't worry that this is a fairly full explanation of how compression works in PICTs. It's not really pitched at complete beginners to graphics, but I hope that anyone with a bit of prior knowledge will find this useful. In practice, you'll probably find it easiest if you try a variety of methods for saving your artwork in different ways and comparing the results both for file size and for picture quality; and for how efficiently the saved file Stuffs/Compacts (since this is an important consideration when you come to distribute the finished result over the internet). What this text does (apart from make you aware of all the options) is provide the sort of information that might help make it easier for you to decide which options are most worth trying, and what the potential pitfalls may be. In practice though, nothing beats actual experimentation, and do remember it's all for a 'good cause' - i.e. saving all our bandwidths! : )

PICT files (assume I'm always referring to bitmap PICTs) can use 2 types of compression:

1. RLE Compression (this gets used automatically by default)
This is a simple form of lossless compression. It compresses the image line-by-line, looking for runs of identical values which can be encoded more efficiently, e.g:

say it encounters the following values (a simple binary string): 0000011100000000

RLE would describe this as '5 zeros [followed by] 3 ones [followed by] 8 zeros'. It's sort of like writing a formula to describe the data mathematically, rather than writing all the data itself. The way this works here means that RLE is very good at compressing large areas of identical color, since lots of areas of identical colors means lots of areas of identical data.

BTW, note that because RLE work on a horizontal line-by-line basis, an image made up of horizontal bands compresses more efficiently than one of similar bands running vertically! e.g:

(The above images were 128x128 pixels, RGB, and made up of alternating black and white lines - the only difference was in the direction of the lines. The raw size of each was about 50KB, so as you can see, you won't actually get any compression if you don't have any horizontal runs of solid color present!)

PICT files using only RLE compression can have any color depth - 1-bit bitmap, 2/4/8-bit grayscale, 8-bit indexed, 16-bit (thousands) color, 24-bit (millions) color. This gives you more flexibility with color depths than the alternative JPEG compression. Bear in mind that your final file size will depend on a combination of bit-depth (the more bits you have, the greater the color depth, but the bigger the file) and the amount of RLE compression applied (very dependent on the contents of your image; it's very efficient with flat graphic images, but poor at photographic-type images).

2. JPEG-compression
Depending on your system software and graphics editing application, you may have the alternative option of using JPEG compression in your PICT files. JPEG compression is supported in PICT files only if you have QuickTime installed (though there must be few Macs these days that don't -I point that out, however, because QT is not a system requirement for running Marathon). The options for selecting the level of compression to use (ranging from slightly lossy, to really appallingly cheesy) are presented when you save the file. JPEG compression is generally best suited to photographic-type images, since the lossy compression means that hard edges tend to get blurry and create artifacts, which means that anything like text and lines can start looking very ugly very fast. BTW, because it's a lossy format, JPEG is a bad choice of format to save images in whilst you are working on them, since each time you save there is more loss and your image will quickly degrade after a few saves (save your working images in a different format, and only save the finished result into JPEG).

Note that as a comparison to RLE encoding, both the above striped images compressed to about 5KB when Maximum quality JPEG compression was used. Do remember though that although JPEG may be a more sophisticated compression format (the vertical lines test obviously didn't faze it one bit), but there are trade-offs - it only works on 24-bit RGB and 8-bit grayscale images, and the lossy compression may affect the image quality adversely.

8-bit indexed (which is recommended for 256-color chapter screens and term art) is not an option with JPEG compression. You could JPEG-compress an image that has been previously indexed down to 8-bit and then set to 24-bit again, but you are unlikely to gain any benefit from this (remember, an 8-bit image will be approximately 1/3 the size of one in 24-bit anyway).

Where and when might you want to use JPEG compression?

First off, it's not any use as far as the Shapes file goes (not really surprising this; though you may be interested to know that sprite collections do make use of RLE). And it's no real use as far as any 8-bit artwork goes since, as noted above, the format does not support 8-bit artwork. This leaves 16/24-bit images in the Images and Map files to consider. Since there is no limitation that requires that '16-bit' PICTs actually need to be in 16-bit color, you may wish to substitute these for 24-bit, JPEG-compressed PICTs instead. Bear in mind that 16-bit displays are limited in the numbers of colors they can actually display; hence, ideally, artwork to be viewed at 16-bit depth should be optimized for this by the artist (to avoid any banding problems) and saved as 16-bit artwork proper. That said, it depends on what your artwork is (banding only really becomes noticeable if you have large areas of low-saturation colors), and most folk probably don't bother to optimize their artwork in any case.

A recommended approach might be to replace the 2xxx PICTs in the Images file (except 2700, which is the HUD graphic) with JPEG-compressed PICTs and remove the 3xxx PICTs altogether. Similarly, the 16/24-bit chapter screens and 16/24-bit term artwork could also be replaced. 8-bit artwork would still be inserted as normal, in order to give best results for those playing in 256 colors.

One could, if wished, remove everything except the '8-bit' artwork from Images and/or Map files, and replace the 8-bit artwork with JPEG-compressed PICTs; however, the results are rarely satisfactory if playing in 8-bit as QuickDraw rarely dithers the artwork cleanly (or at least not as well as the artist could do if preparing 8-bit artwork specifically for the purpose). If you do insist on trying this method, you should try to keep colors used in term PICTs as close to the Marathon Infinity palette as possible (to give QuickDraw a better chance of dithering the image presentably), and for Chapter screens and Images PICTs you should make up a custom CLUT as you would normally (indexing the artwork to 8-bit Adaptive and exporting the CLUT) and paste into the CLUT resource - QuickDraw still needs a suitable CLUT if it's to display presentably in 8-bit.

Is it worth it?

This is an important consideration. Inexperienced folks may automatically assume that because JPEG is regarded as a 'compact format' that it must, therefore, always be a good idea to use it. The problems of using JPEG-compression have already been pointed out above (requires QuickTime; image quality may degrade; not really suitable for use on 8-bit displays). The main reason for considering JPEG-compression, therefore, is whether or not it will reduce file size (and therefore save space) sufficiently to be worth the tradeoffs. Bitmap graphics are horribly large things in themselves, and you don't need all that many of them in a scenario to bloat its size considerably. Obviously, there's an advantage in having files that take up less disk space, but the greater advantage as far as Marathon scenarios go is if you can create something that is small and compact and so makes for a nice quick download (which would you rather download - the map that's 1MB in size, or the same map but at 3MB in size?).

Taking a selected image (this one is borrowed from Michael Hunsley's '13 Group v2.0' map, with thanks) as an example:

 The '13 Group' map is somewhat unusual for a Marathon map in that all the term artwork is 24-bit RGB (there is no separate optimized 8-bit/16-bit artwork as found in most Marathon maps). Aside from the fact that the term art doesn't therefore present very well when playing in 8-bit, it also means the map size is pretty large on account of all the full-color graphics. So the question is, can anything be done to reduce this file size?

As you can see, the image is mainly photographic/continuous tone image which means it's not going to compress too well using the usual RLE compression, although the large area of (mostly) flat black on the right-hand side should compress pretty efficiently whatever the method used.

I tried the following changes to the above image and compared sizes, both before Stuffing and after: 

The file named '24-bit' is the original; as you can see it weighs in at a fairly hefty 171KB, and isn't much smaller even when Stuffed.

The file named '16-bit' is the same image converted to 16-bit depth; it's approximately 2/3 the size of the 24-bit one unstuffed (which you'd expect, since it uses 2/3 the bits to describe each pixel). It also Stuffs somewhat better, probably because there is some flattening out and banding of the image (and areas of identical data always compress more efficiently; like RLE compression, StuffIt compression looks for similar blocks of data that can be written in a more concise fashion).

The file labeled 'jpeg' is the 24-bit original saved using JPEG-compression. As you can see, there is a large difference in the unstuffed file size (smaller even than the 8-bit versions), although since the image is already compressed about as efficiently as it can be, there is no additional compression to be had once Stuffed.

The two remaining files are the 24-bit image down sampled to 8-bit using an Adaptive palette (obviously, this isn't the type of palette you would use if you wanted the artwork to appear correctly on 8-bit displays, but for demonstration purposes it serves just fine; indeed, you could still consider distributing this instead of the 24-bit artwork simply in order to save size). Using dither 'smooths' the indexed image's appearance a little, although this obviously reduces the efficiency of the compression. Without dither, the image looks more obviously banded. Both of these are obviously a good deal smaller than the 24-bit original, so the tradeoff in quality may still be considered worthwhile.

Anyway, looking at the numbers above, you can probably draw your own conclusions. The original 24-bit artwork doesn't score any points as far as file size is concerned. With 17 such PICTs present the complete map file weighs in at almost 3MB (2.2MB compressed)!

The 16-bit artwork is much more compact (especially in its Stuffed form). It doesn't require anything additional to work (ie. doesn't require QuickTime), and in practice often looks quite presentable (and to folks playing in thousands of colors, there's no visible difference between 16-bit artwork viewed at 16-bit and 24-bit artwork viewed at 16-bit anyway). You might be quite happy to go for this option as a result. Working for 16-bit may also allow more advanced artists to produce results that are better optimized for that bit-depth. GraphicConverter is recommended for good 16-bit conversions that reduce ugly visual banding (Photoshop isn't).

The 8-bit artwork is more compact again, although being limited to using 256 colors may mean that if your original artwork contained lots of different colors then you may not be providing the best-looking results for folks playing at 1000s of colors. (This is generally why most folks include both 8-bit and 16-bit artwork, even if it does mean increasing total file size again as a result. That way, you can provide one set of artwork that is optimized for 8-bit displays, and another that is optimized for 16-bits.)

Anyway, in the example above, the JPEG artwork actually looked quite presentable (since it was a mainly photographic image anyway), and was pretty much the most compact. If using this, you'd need to specify QuickTime as a requirement for playing the game (if QT isn't installed, all you'll see is a warning graphic indicating that the image is only viewable if QT is installed).

Of course, for a different piece of artwork, the relative values might come out differently again. There may be some occasions when you find some 8-bit adaptive dithered art to be best choice (for 8-bit use using the Marathon Infinity palette where necessary, or even for 16/24-bit use using an adaptive dither), and where JPEG-compressed artwork looks decidedly inferior. Your best bet is to make up a variety of samples using the different formats and see which gives the best results for the fewest tradeoffs, and then use that. It is well worth experimenting with; especially if it means you halve your upload and download times at the end of it! (e.g. replacing all the 13 Group 24-bit artwork with 24-bit JPEG-compressed artwork cut its actual size to 1.3MB, and its Stuffed size to 920KB - i.e. less than half the original size!).

Adding PICTs to Map/Images file

Finally, the important thing to remember when adding artwork to the Map/Images files is that you have to make sure you paste it in correctly. For 1-bit, 8-bit and 24-bit artwork, you can simply copy and paste directly from your graphics editing program. With 16-bit and JPEG-compressed artwork, however, if you simply copy and paste from the graphics application into ResEdit then your artwork will simply end up as full 24-bit PICTs once again; you cannot copy and paste '16-bit depth' or 'JPEG compression'! To get these into your Map/Images correctly (instead of just wasting your time), you should save the files as PICT resources with the depth/compression options set in the save dialogue. Then open the files into ResEdit and copy and paste the PICT resources directly into your Map/Images files from there; 16-bit depth/JPEG-compression is thus retained.

One other note: if the Map/Images file is intended for use on M2/Win then JPEG-compressed PICTs really aren't such a good idea : ). Stick to tried-and-tested 8-bit and/or 16-bit PICTs and don't do nothing fancy, or else. : )

Upon further reflection:

These days it is not really worth doing both 8-bit and 16-bit images. If you are going to lean one way, lean toward 16-bit and abandon 24-bit finished graphics, converting them in the last process to 16-bit if you insist on working in 24-bit. The blunt reality of the situation is that creating quality 8-bit graphics is extrememly difficult. It seems that there is not much attention (according to what has been released) paid to the difference between 16-bit and 24-bit graphics, often with 16-bit graphics being abandoned (probably inadvertantly) for their 24-bit counterparts.

JPEG compression can work well on images that don't have hard lines or fine text, although there are a few issues with using it. If you use Photoshop, its PICT Resource saving options aren't that great. It lacks the Best ('10' or greater) quality setting that you get when saving as a JPEG (I've not used later than 5, though I doubt it's been improved on - if you have a chance, check). Although... if you could use that setting you'd probably lose any edge you might have had in reducing file size anyway. As it said above already, JPEGs don't stuff as well as other images - sometimes the compressed size can even end up bigger. The bigger problem is that it doesn't do blacks right, however - the darkest you can get is 4 4 4 (equivalent to about 1% grey). You can get around this by adjusting Levels in Photoshop beforehand to lift the black point to this - that way you don't get nasty artifacts where artwork blends into black. You just don't get pure black, that's all, but mostly you don't notice the difference anyway. You do knock quite a chunk off the down load size though. (Remember you can JPEG some term images and index others for added savings. JPEGing the chapter screens will save quite a few megabytes.) Considering the poor quality of images that folks put up with in web browsing, I think it's not unreasonable to cut the corners a little if it can knock a big chunk of Joe User's down load times.

Oh, by the way, GraphicConverter is better for JPEG compression options on PICT Resource files (and can get blacks right too). Unfortunately, the images it produces only look good when viewed at 16/24-bit; at 8-bit they appear horrible. So if a scenario doesn't do 8-bit to begin with then this is probably a good option to explore, otherwise it'd mean having to put in separate 8-bit images as well which kinda defeats the point of cutting those corners again.