When an image is dropped onto an MT map, the contents of the image are copied to a file under the
assetcache/ directory. The name of that file is based on the MD5 checksum of the content, resulting in a 32-character filename that consists of hexadecimal characters (0-9 and a-f).
Inside MapTool all references to images are made via that MD5 value (called the MD5Key in the code). When an image is associated with a token, the MD5Key is what is really associated with it, and when the token needs to be drawn the MD5Key is used as an index into a table of all images currently in use (meaning on the current map). Note that the image itself (ie. the content of the JPEG file) is never actually stored on the Token. This is actually quite important because it allows the same image to be referenced from multiple places without complicating the code by having to point "into" the Token object.
Once the file is created in the assetcache directory there's no further need to reference the name of the image. Note that dropping an image onto the map causes a Preference to be checked as to whether the
Token is named "Creature" or is named based on the dropped image, but that's the
Token, not the image itself. Dropping the image causes a new image to be written to the assetcache using its MD5 checksum and a corresponding Token object is simultaneously created that references that same MD5Key.
Anytime the map is panned or zoomed or otherwise needs to be refreshed, the position and size of each token is determined and the corresponding MD5Key is looked up and the image retrieved so that it can be blitted to the map buffer before being sent to the screen.
(Most of the above is pretty typical for a graphics-oriented application. The MT-specific parts are the storage of the graphical elements in the assetcache directory and the use of the MD5 checksum as the key.)
When a campaign is saved, each map is retrieved one at a time. From within the map, all tokens are retrieved and written in XML. Those tokens will contain MD5Key XML elements inside them. When all tokens have been written, then all images referenced by the map are also retrieved and they are written to the campaign file (using no compression) into the
assets/ subdirectory of the ZIP file.
When a campaign is loaded, ALL assets from the assets directory are copied to the assetcache even if the campaign's XML doesn't reference them (so editing the XML isn't enough to delete graphical assets; the campaign must be saved and then reloaded again, with the save being the only time that the campaign's assets are determined). The reason all assets are copied to the assetcache has to do with both consistency in regards to how the campaign is saved, but also because it isn't worthwhile to search the ZIP directory for each MD5 key over and over when the 99% case is going to be that all assets will be needed anyway.
Whew. Hope that helps.