PIC (Koala Microillustrator)
From Atariki
Format pliku graficznego stosowany w programie Koala Microillustrator. Jest to, obok formatu Micropaintera (.MIC), najpopularniejszy standard zapisu (kolorowej) grafiki używany na 8-bitowym komputerze Atari.
Dotychczas ukazało się kilka artykułów na temat tegoż formatu zapisu (m.in. w Megazinie oraz Abbuc Magazin, jednak w pierwszym przypadku informacje te były niekompletne, zaś w drugim były pewne przekłamania i nieścisłości.
W tym artykule opisano poprawnie budowę pliku Koali, a w szczególności jego nagłówka (jako że właśnie o nim były podane błędne informacje), opierając się na wiadomościach z m.in. dwóch powyższych źródeł.
Format zapisu Koali powstał w 1983 roku w firmie Koala Ware. W tej lub lekko zmodyfikowanej wersji jest (był) także używany na innych komputerach, np. C64, Apple (!). W formacie tym można przechować grafikę w większości trybów graficznych i przy różnych rozmiarach ekranu. Na Atari używa się jednak (standardowo) tylko trybu Graphics 15.
Spis treści |
Nagłówek
Początek pliku to specjalny nagłówek, w którym zawarte są najważniejsze informacje o obrazku, tzn. jego szerokość, wysokość, kolory itd. W tabeli poniżej jest dokładny opis nagłówka pliku .PIC:
| Typ | Nazwa | Opis |
|---|---|---|
|
OFFSET=0 (4 bajty) |
identyfikator formatu KOALI |
Oznaczenie formatu Koali. Są tu zawsze wartości = 255,128,201,199. |
|
OFFSET=4 (2 bajty) |
headln |
Długość nagłówka. Przeznaczone sa na to dwa bajty, ale zwykle jest tu wartość 27, tzn. tyle bajtów ma nagłówek (27=$1b). |
|
OFFSET=6 (1 bajt) |
revision |
Numer wersji programu względnie formatu obrazka. Normalnie jest to wartość $01. |
|
OFFSET=7 (1 bajt) |
typcprs |
Rodzaj kompresji:
|
|
OFFSET=8 (1 bajt) |
antic-mode |
Podaje tryb grafiki obrazka według trybów ANTIC. |
|
OFFSET=9 (2 bajty) |
scrwidth |
Szerokość obrazu w bajtach. Zwykle jest tutaj wartość 40. |
|
OFFSET=11 (2 bajty) |
scrheight |
Wysokość obrazu w bajtach. Zwykle jest tutaj wartość 192. |
|
OFFSET=13 (5 bajtów) |
colors |
Kolory obrazka - nagrywane w takiej kolejności jak w pamięci, 708..712. |
|
OFFSET=18 (2 bajty) |
picln |
Ogólna długość obrazka (samego, bez nagłówka) w bajtach. |
|
OFFSET=20 (2 bajty) |
unused |
Zawsze wynosi 0. |
Od OFFSET+22 są 4 pola zarezerwowane na tekst dla tytułu rysunku, autora i pozostałych uwag. Każda taka komórka tekstowa może mieć maksymalnie 40 znaków i musi być zakończona kodem EOL ($9b, 155 dec). Przeważnie znaleźć można tutaj wartość 155 powtórzoną cztery razy. Wpisując w to miejsce jakiś tekst trzeba go zakończyć EOL-em i zwiększyć odpowiednio długość nagłówka w komórce "headln" (tzn. podać nową wartość długości nagłówka, liczonej razem z "komentarzem").
Nagłówek kończy tzw. "spare byte" (zapasowy bajt). Jego wartość wynosi zazwyczaj 162 ($a2), chociaż popularny XL-Art, nagrywając w kompresji Koali wstawia tu wartość $a5.
Okno
Według Bewesofta mogą być ładowane pliki z tylko częścią ekranu - ponoć oryginalny program Koala MicroIllustrator potrafi je wczytać. Pozycja i rozmiar tzw. "okna" zdefiniowane są w nagłówku przez pola "scrwidth" i "scrheight". Te 4 bajty określają początkową pozycję X (w bajtach, a nie w pikselach!), końcową pozycję X obrazu (pierwszą pozycją PO obrazku), początkową pozycję Y obrazu i końcową pozycję Y.
Kolory
Kolory nagrywane są w kolejności takiej jak w pamięci (708-712), czyli licząc od OFFSET+13 jest nagrywanych pięć bajtów. Wszystkie kolory można dowolnie ustawić w jakimś programie graficznym i ich wartości pojawią się w komórkach "colors" nagłówka. Problem może być jedynie z ustawieniem koloru inwersji ($02c7), który można zmienić tylko w edytorach do logosowania grafiki. Jednakże to nieistotne, gdyż inwersja ważna jest tylko w grafice znakowej. W każdym razie wartość, jaką można zwykle zastać (dla rejestru $02c7) w nagłówku, to albo $00, albo $46.
Rozszerzenia
Bajt 20. z nagłówka ("unused") został przeznaczony przez twórców formatu na przyszłe użycie. Pozwoliło to Hermesowi (autorowi viewera "ShowPIC v2.0") bardzo pożytecznie wykorzystać pierwszy bajt z pary "unused". Mianowicie został on użyty do przechowywania informacji dla GTIA o jej trzech dodatkowych trybach (tj. Graphics 9, Graphics 10, i Graphics 11). Pozwala to na wczytywanie skompresowanej grafiki również w tych trybach graficznych, co oczywiście zaoszczędza miejsce na dysku. Oto jak zostało to zorganizowane
Dwa najmłodsze bity pierwszego nieużywanego bajtu "unused" zawierają informację o trybie graficznym jak następuje:
- 00 = zwykły tryb ANTIC-a (Graphics 8)
- 01 = 16 jasności tego samego koloru (Graphics 9)
- 10 = 9 dowolnych kolorów z palety 256 (Graphics 10)
- 11 = 16 kolorów o jednakowej jasności (Graphics 11)
Pozostałe bity z tego bajtu oraz drugi wolny bajt są przez viewer "ShowPIC v2.0" nieużywane. Powyższe wykorzystanie bajtu "unused" jest nazwane przez jego pomysłodawcę "PIC v2". Pomysł Hermesa jest świetny, lecz do tej pory spotkać się można z jej zastosowaniem tylko w "ShowPIC v2.0".
Inne uwagi
Dużym problemem jest to, że większość tzw. viewerów, showerów, czy loaderów (programów wyświetlających format Koali) potrafi ładować pliki .PIC tylko ze standardową długością nagłówka, wynoszącą $1b (27) bajtów. Tymczasem nagłówek może mieć zmienną długość, np. gdy doda się jeszcze komentarz do obrazka od komórki OFFSET+22. Co więcej, większość loaderów odczytuje z nagłówka tylko jedną rzecz - dane kolorów. Zauważył to już Bewesoft. Taki sposób działania tych programów można wytłumaczyć tylko jednym: lenistwem autorów tychże programików.
Jeśli zechcesz sobie np. dodać komentarz do rysunku, umieszczając go w nagłówku pliku, w odpowiednim miejscu, wiedz, iż na palcach można będzie policzyć programy, które to poprawnie odtworzą. Z testów wynika, że uda Ci się to tylko w:
- loaderze BeweSofta z ABBUC Magazine
- ShowPIC v2.0 Hermesa
- oryginalnym programie Koala MicroIllustrator
Z "eliminacji" odpadły natomiast loadery w takich programach, jak: GRAPH VIEW z CrisisSoft, GRAPH.COM Souseda, XL-Art, RAMbrandt (!), BIT CONVERTER Bartmana oraz paru innych.
Problem ignorowania sobie wartości z nagłówka wynika również z innej, bardziej praktycznej (od wstawiania komentarzy do obrazków) rzeczy - przykładowo XL-Art przy zapisie .PIC-a "zapomina" o zapisaniu w nagłówku Koali informacji o długości samego obrazka (nie wstawia nic do bajtów "picln" w nagłówku obrazka). Jako że większość loaderów również nie sprawdza bajtu "picln", wszystko jest OK... do czasu, aż napotkasz jakiś program, którego twórca spodziewał się, że są jeszcze dobrze napisane procedury obsługi kompresji Koali i... w tymże programie nie zapomniał o tym bajcie. Wtedy zaczynają się kłopoty, bo program sprawdzający np. bajt "picln", po prostu nie wczyta takiego .PIC-a, który nie ma tam żadnej wartości (czyli "picln" = $00,$00). Po sprawdzeniu braku odpowiedniej wartości w nagłówku po prostu przerwie odczyt. Do tej pory można zauważyć dwa takie przypadki - w niezłym programie graficznym (dla trybu Graphics 15) "Pixel Artist De Luxe v1.3" (swoją drogą jest on pomocny dla posiadaczy tabliczki graficznej) oraz w basicowym programie do wydruku obrazków "PICPRINT", zamieszczonym w jednym z wydań magazynu "OHAUG"... Obydwa programy "buntowały się" przy próbiw wczytania jakiegoś .PIC-a z XL-Art, ale przyczyna okazała się prozaiczna - brak tego jednego, jedynego bajtu, na który zwracały uwagę. Zatem aby do nich wczytać taki obrazek, należy wpisać do nagłówka odpowiednią wartość w bajtach "picln" za pomocą jakiegoś monitora (dyskowego). Można też wczytać obrazek w postaci .MIC do "Pixela..." i tam zgrać go jako .PIC. Zostanie on zapisany w rzadziej spotykanej poziomej kompresji. Na szczęście nie będzie już kłopotów z ładowaniem tak poprawionego obrazka w drugą stronę, tzn. w np. XL-Art, bo on bajty "picln", jak już wcześniej wspomniano, ignoruje.
Kompresja
Wypadałoby na koniec podać jednak budowę samej kompresji KOALI. W użyciu może być jeden z trzech typów kompresji (7. bajt nagłówka):
- wartość $00 oznacza brak kompresji w obrazku czyli, że reszta pliku (po nagłówku) zawiera tylko same dane zrzucone wprost z pamięci ekranu.
- wartość $01 - najczęściej używana metoda, tzw. kompresja pionowa. Oznacza ona spakowane dane, które zostaną umieszczone na ekranie w "pionowym" uporządkowaniu: najpierw bajty w liniach parzystych 0,2,4,6, itd. potem bajty w liniach nieparzystych 1,2,5,7 itd. Po rzędach "idą" w ten sam sposób kolumny ekranu.
- metoda $02 również zawiera spakowane dane, ale będą one umieszczone na ekranie tak samo jak w metodzie $00 (poziomo).
Same dane obrazka (tzw. mapa bitowa) są skompresowane prostym algorytmem RLE (redukcja powtarzających się elementów). Kiedy np. pięć razy, jeden za drugim wystąpi w obrazku wartość "0", nagrane zostaną jako "5x0". Obrazek jest umieszczony w poszczególnych blokach. Są dwa typy bloków użytych w kompresji KOALI:
- Dane niespakowane. Pierwszy bajt (jako znacznik) ma ustawiony bit 7 (128 dec), reszta tego samego bajtu stanowi długość bloku danych (maksymalnie 127 bajtów). Jeśli ta długość wynosi zero, to jest wtedy jeszcze o dwa bajty więcej - informują one o aktualnej długości (2-bajtowa wartość, więc będzie długi, niespakowany blok!). Następnymi bajtami są już same niespakowane dane.
- Dane spakowane. Pierwszy bajt w takim bloku ma wyzerowany siódmy bit, reszta zaś jest długośćią bloku - tak samo, jak opisana wyżej. Tu jest tylko jeden bajt danych, który wypełni swą wartością wszystkie bajty w bloku. Po prostu informuje on o tym, jaka wartość jest skompresowana, a ze znacznika (pierwszego bajtu w bloku, informującego o statusie i długości całego bloku) wynika, ile razy trzeba go powtórzyć. Tu także może wystąpić długi, spakowany (tym razem) blok składający się z 3 bajtów "informujących" i jednego bajtu danych - zasada jest podobna jak w bloku niespakowanym.
To tyle o budowie pliku w formacie Koali. Mimo, że efektywność kompresji w opisany sposób jest raczej kiepska (szczególnie przy dużych i skomplikowanych obrazkach), to zapis .PIC jest bardzo popularny, zapewne głównie przez prostotę jego realizacji (format podobny do .PIC stosuje np. edytor CIN, Trzmiel, RGB Shower, czy XL-Paint...). Jakby jednak na to nie patrzeć, (prawie) zawsze obrazek trochę się skróci i raczej w wyjątkowych przypadkach opłaca się trzymać plik .MIC zamiast .PIC-a.
(Artykuł pochodzi z magazynu "ENERGY #2", autorem jest Dracon/Taquart)
