Om GEM:s .IMG-filer.
Om GEM:s .IMG-filer.
-------------------------------------
.IMG-filerna är ett hårdvaruoberoende sätt att lagra bilder under GEM. Bilder gjorda med GEM Paint på en IBM PC kan sålunda användas på en ST och tvärtom, åtminstone i teorin. I praktiken är det få program som utnyttjar .IMG-filernas möjligheter; ofta kan inte ens bilder flyttas mellan ST:ns olika upplösningar. En annan svaghet är avsaknaden av palettdata.
16-bitarstalen i headern lagras som Motorola-tal, dvs i "rätt" ordning. ST-programmeraren har alltså inga problem, men de som använder 8086 eller Z80 får stuva om dem. Det är intressant, eftersom de flesta inbyggda GEM- funktioner (font-definitioner t ex) använder Intel-tal, där minst signi- fikanta byten kommer först, en ständig källa till glädje för ST- användare!
Filen består av en header och ett bilddatablock. Headerns format är som följer:
Ord Byte-nr Innehåll
0 0-1 Versionsnummer för .IMG-formatet
1 2-3 Header-längd. Kan öka i senare versioner, så kolla!
2 4-5 Antal färgplan (ST:n har ett i högupplösning, två i
medel- och fyra i lågupplösning).
3 6-7 "Pattern"-längd (se nedan)
4 8-9 Pixelbredd i Êm
Lågupplösning: 338 Êm
Medelupplösning: 169 Êm
Högupplösning: 372 Êm
5 10-11 Pixelhöjd i Êm
Lågupplösning: 372 Êm
Medelupplösning: 372 Êm
Högupplösning: 372 Êm
6 12-13 Bildbredd i pixels
7 14-15 Bildhöjd i pixels (antal linjer) Storleksangivelserna för ST:n är hämtade från filer genererade av bl a SNAPSHOT.ACC. För den monokroma SM124-monitorn är de något optimistiska; de verkar räkna med hela skärmytan, inklusive den svarta ramen. Med färgmonitor blir det ännu roligare: av bekvämlighetsskäl har man räknat med en monitor på c:a fem tum... Nåja, huvudsaken är ju att förhållandet längd/bredd blir rätt.
Bilddataformatet
Varje rad inleds med en radantalsangivelse. Den talar om hur många rader som ska se ut enligt efterföljande pixeldata. Praktiskt om flera rader är precis likadana, t ex ett stort enfärgat fält. Formatet för radantalsangivelsen är:
Byte-nr Innehåll
0 Alltid 0x00
1 Alltid 0x00
2 Alltid 0xFF (FFh)
3 Antal rader Efter följer bilddata för alla färgplanen i tur och ordning. Nya färgplan börjar alltid på en byte-gräns, även om antalet pixels per rad inte är jämnt delbart med åtta.
Pixeldata kan lagras på tre sätt. Låt oss ta dem i tur och ordning:
"solid_run"
är vanlig enkel "run length coding" liknande den som används i Degas Elite .PCn-filer. Pixeln (av eller på, 1 eller 0, eftersom vi tar ett plan i taget) placeras i mest signifikanta biten (bit 7) av en byte. Antalet bytes (ej pixels!) som ska fyllas med pixeln läggs i de sju minst signifikanta bitarna. Eftersom det är byte-orienterat måste en "solid_run" alltid börja och sluta på en bytegräns (dvs pixel 0, 8, 16, 24 osv).
Två bytevärden är reserverade: 0x00 och 0x80. Eftersom båda anger löplängden noll bytes, vilket är föga användbart, används de istället till att inleda "pattern_run" respektive "bit_string".
"pattern_run"
är ett system för att effektivisera kodning av mönstrade ytor. I ord 3 i headern angavs "pattern"-definitionslängden, dvs hur många bytes som ska definieras åt gången. På ST:n är mönstrade ytor oftast gjorda med GEM:s egna rutiner, där ett mönster är 16 bitar brett. Alltså är 2 ett vanligt värde. Bilder av annat ursprung kan ha andra optimalvärden, t ex 4.
En "pattern_run" har följande format:
Byte-nr Innehåll
0 Alltid 0 (för att signalera "pattern_run")
1 Antal gånger mönstret ska upprepas
2-.. (pattern length) stycken bytes med mönsterdata (en bit/pixel)
"bit_string"
tas till om inget annat hjälper. Det är det minst optimerade formatet - varje bit i strängen representerar en pixel, precis som i Doodle- och Neochrome-bilder. Formatet är:
Byte-nr Innehåll
0 Alltid 0x80 (80h) (för att signalera "bit_string")
1 Antal bytes i bitsträngen
2-.. (antal bytes) stycken bytes med bilddata (en bit/pixel) Ska man skriva .IMG-filer själv är bitsträngarna ett sätt att komma lindrigt undan - programmeringsarbetet är snabbt överstökat, men filerna kommer bli onödigt stora. è andra sidan kan en överambitiös komprimeringsrutin göra programmet allt för långsamt. Ett program som tar alla möjligheter i beaktande kommer kunna räkna i dagar och veckor om det erbjuds en oregelbunden, invecklad bild, såsom t ex en digitaliserad, brusig videobild. Man måste alltså kompromissa. Inte bara skrivningen av filerna saktas ner av överdriven optimeringsnit, även uppackningen tar längre tid, skillnaden blir bara inte lika dramatisk.
Notera också att det inte finns någon som helst koppling mellan färgplanen vad gäller kodningssätt. Det första färgplanet kan mycket väl vara kodat med enbart "solid_run"-definitioner, det andra som en serie "bit_string":s och det tredje som en lång "pattern_run".
/MSj
Källa: "In the picture", en artikel av Andy Redfern i PCW, juli 88 (inhandlad i en Pressbyråkiosk i Boden, där de försökte pracka på mig "Military Technology" när jag frågade efter "Music Technology"), och diverse egna iakttagelser, nattlig forskning etc.
/* C-definition av headern */
/* WORD är 16-bitars integers - definieras i portab.h om sådan finnes,
skriv annars int (short i Lattice). */
struct img_hdr
{
WORD version; /* Currently 1 */
WORD hdr_len; /* Currently 8 */
WORD planes;
WORD pattern_len;
WORD pixel_width;
WORD pixel_height;
WORD width;
WORD height;
}; 
