energy.scene.pl

autor: dracon

Format zapisu KOALI MICRO ILLUSTRATORA (PIC) jest obok MICropaintera, najpopularniejszym standardem zapisu grafiki na 8-bitowych komputerach Atari.

Dotychczas ukazało się kilka artykułów na temat tegoż formatu zapisu ( m.in. w MEGAZINE i ABBUC MAG), jednak w pierwszym przypadku informacje te były niekompletne, zaś w drugim były pewne przekłamania i nieścisłości. Poza tym być może nie wszyscy mają te magazyny...

W tym artykule chciałbym opisać POPRAWNĄ 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 dwóch powyższych źródeł oraz własnych spostrzeżeniach.

Format zapisu KOALI MICROILLUSTRATORA 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 i Apple (!). Format ten rozpoznaje większość trybów graficznych oraz różne wielkości ekranu. Na Atari używa jednak (standardowo) tylko trybu gfx #15 z rozdzielczością ekranu 160 x 192 piksele.

Początek pliku w formacie Koali to specjalny nagłówek, w którym zawarte są najważniejsze informacje o obrazku, tzn. jego szerokość, wysokość, kolory, itd. W tym miejscu pozwolę sobie zaprezentować tabelkę z dokładnym opisem wszystkich bajtów nagłówka pliku .PIC :

------------------------------------
 Offset  |     |        |
(odl. od |dłu- | nazwa  | znaczenie
 począt. |gość |        |
 pliku)  |     |        |
 ------------------------------------
    0    |  4  |identyf.| oznaczenie
         |bajty|formatu | formatu Koali.
         |     | Koali  | Jest tu zawsze:
         |     |        | 255,128,201,199
 ------------------------------------
    4    |  2  | headln | podaje długość
         |     |        | nagłówka ( tu
         |     |        | miejsce jest w 2
         |     |        | bajtach, ale zwykle
         |     |        | jest wartość = 27,
         |     |        | tzn. tyle bajtów ma
         |     |        | nagłówek (27=$1b)
 ------------------------------------
     6   |  1  |revision| Nr wersji programu
         |     |        | względnie formatu
         |     |        | obrazka. Norm=$01
 ------------------------------------
     7   |  1  |typcprs | rodzaj kompresji:
         |     |        | 0 = nieskompres.
         |     |        | 1 = kompr. pionowa
         |     |        | 2 = kompr. pozioma
 ------------------------------------
     8   |  1  | antic- |podaje tryb grafiki
         |     | mode   |obrazka wg trybów
         |     |        | ANTICa
 ------------------------------------
     9   |  2  |scrwidth| szerokość obrazu
         |     |        |w bajtach. Norm = 40
------------------------------------
    11   |  2  |scrheight| wysokość obrazu
         |     |        |w bajt. Norm = 192
------------------------------------
    13   |  5  | colors | kolory obrazka -
         |     |        |nagrywane w takiej
         |     |        | kolejności jak w
         |     |        |pamięci -> 708-712
 ------------------------------------
    18   |  2  | picln  | ogólna długość
         |     |        |(samego, bez nagł.)
         |     |        | obrazka w bajtach
------------------------------------
    20   |  2  | unused | zawsze wynosi 0
 ------------------------------------

To jeszcze nie wszystko o nagłówku... Od adresu OFFSET+22 są 4 komórki 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). Oczywiście żaden program nie używa tych komórek "tekstowych". Dlatego znaleźć można tutaj normalnie 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). Wynosi on zazwyczaj 162 ($a2), chociaż popularny XL-Art, nagrywając w kompresji Koali, wstawia tu wartość $a5.

Jest sporo do skomentowania odnośnie powyższej tabelki...

Wg Bewesofta mogą być ładowane pliki z tylko częścią ekranu - ponoć oryginalny program KOALA M. potrafi je wczytać... Pozycja i rozmiar tzw. "okna", czyli części obrazu do wczytania, zawarte są w komórce "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 nagrywane są w kolejności takiej, jak w pamięci (708-712), czyli w kolejne bajty od OFFSET+13 jest nagrywanych pięć wartości - wg "standardu" XL-Arta, powiedziałbym o nich tak: ciemny, jasny, biały, inwers ($2c7) i tło... Dlaczego je w ten śmieszny sposób określiłem ?! Po prostu tak je widzę większość czasu, z racji tego, że używam głównie monochromatycznego monitora... :-)))

Kolor (TV) włączam tylko wtedy, gdy muszę podkolorować obrazki... ;-))))

Wracając do kolorów... Wszystkie kolory, można dowolnie ustawić w jakimś programie graficznym i ich wartości pojawią się w komórce "colors" nagłówka KOALI. Jedynie może być problem z ustawieniem koloru inwerji ($2c7), który to można zmienić tylko w jakiś edytorach do logosowania grafiki... Ale to nieistotne, gdyż inwersja ważna jest tylko w grafice znakowej... W każdym razie wartość, jaką można zwykle zastać (dla koloru rejestru $2c7) w nagłówku KOALI, to albo $00, albo $46...

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 samą pamięć ekranu. Wartość $01 jest najczęściej używaną metodą. Oznacza ona spakowane dane, które zostaną umieszczone na ekranie w "pionowym" uporządkowaniu: najpierw bajty z linii 0, 2, 4, 6, itd., potem bajty z linii nieparzystych - 1,3,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).

Bajt 20-ty z nagłówka (nazwany "unused") został słusznie 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 przechowania informacji dla GTIA o jej trzech dodatkowych trybach (tj. gfx #09, #10, #11). Pozwala to na wczytywanie skompresowanej grafiki również w w/w trybach graficznych, co oczywiście zaoszczędza miejsca na dysku... Oto jak zostało to zorganizowane...

Dwa najmłodsze bity pierwszego nieużywanego bajtu "unused" zawierają informację o powyższych trybach graficznych w następującej kolejności:

- 00 = zwykły tryb Antica (gfx #08);

- 01 = 16 jasności tego samego koloru (gfx #09);

- 10 = 9 dowolnych kolorów z palety 256 (gfx #10);

- 11 = 16 kolorów o jednakowej jasności (gfx #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ę jako "PIC v2". Idea Hermesa jest zaiste genialna, lecz do tej pory spotkałem się z jej zastosowaniem tylko w "SHOWPIC v2.0"... Warto byłoby ją upowszechnić...

Dużym problemem jest to, że większość tzw. Viewerów, Showerów, czy loaderów (programów odtwarzająch 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 być teoretycznie zmienny, np. gdy dodasz jeszcze komentarz do obrazka od komórki OFFSET+22 !!! 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 przeprowadzonych przeze mnie testów wynikło, że uda Ci się to tylko w:

- loaderze BeweSofta z ABBUC Magazine

- SHOWPIC v2.0 Hermesa

- oryginalnym KOALA MICROILLUSTRATOR

( te trzy powyższe programy można ogólnie spokojnie uznać za najlepsze - dotąd - loadery dla formatu Koali )...

Z "eliminacji" odpadły natomiast loadery KOALI w takich programach, jak: GRAPH VIEW z Crisis Soft, GRAPH.COM Souseda, XL-ART, RAMbrandt (!), BIT CONVERTER Bartmana oraz w paru innych, o których akurat zapomniałem...

Problem "olewania" 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 info 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 (od razu) 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 spotkałem się z dwoma takimi przypadkami - w niezłym programie graficznym (dla trybu gfx #$15) "Pixel Artist De Luxe v1.3" (swoją drogą jest on niezły dla posiadaczy tabliczki graficznej...) oraz w basicowym programie do wydruku obrazków "PICPRINT", zamieszczonym w jednym z wydań zinu "OHAUG"... Obydwa programy "buntowały się", gdy chciałem wczytać jakiś .PIC 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 jego 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 "przerobionego" obrazka w drugą stronę, tzn. w np. XL-Art, bo on bajty "picln", jak już wcześniej wspominałem, ignoruje.

Wspomnę jeszcze o pewnym przykrym zdarzeniu, które spotkało mnie stosunkowo niedawno... Pracując pod XL-Art, nagrałem jako .PIC niemal skończony obrazek i spokojnie skasowałem ten program. Jakież było moje zdziwienie i rozczarowanie, gdy później okazało się, że XL-Art "dowcipnie" 'skopał' mój obrazek... Po prostu źle go nagrał - pominął przy zapisie standardowe bajty w nagłówku KOALI (licząc od pozycji OFFSET = 0) od 23 do 26 (są to bajty: $9b, $9b, $9b, $a5 - czyli info o komórkach "tekstowych" w nagłówku plus tzw. "spare byte") i zaraz po bajcie 22 (OFFSET+22, czyli jedna wartość $9b) wpakował od razu bajty spod bajtu 27 (OFFSET+27) aż do końca, tzn. do końca pliku .PIC... Po wczytaniu tak 'zdeformowanego' obrazka pojawiły się oczywiście straszne śmieci... Nie bardzo chciało mi się rysować od nowa prawie skończony obrazek, dlatego postanowiłem odzyskać plik, korzystając z wiedzy o budowie pliku KOALI.

Zrobiłem to następująco: Przeniosłem fragment obrazka (używając bardzo dobrego programu "Mini Copy" H.Cygerta) z 23. bajtu do końca pliku NA 27. bajt do końca pliku i wtedy powstałą wolną przestrzeń uzupełniłem brakującą zawartością, tzn. wpisałem od 23. bajtu nagłówka do 27. bajtu następujące potrzebne (w tym wypadku) wartości: $9b, $9b, $9b, $a5.

Dzięki temu udało mi się uratować plik .PIC... Być może ktoś kiedyś miał lub spotka podobny "kawał" ze strony programu graficznego, dlatego myślę, że przytoczenie powyższych wskazówek przyda się... Choć nie zawsze może to tak wyglądać, nieraz trzeba pogodzić się ze stratą obrazka... :-x

Wypadałoby na koniec podać jednak budowę samej kompresji KOALI... Oto, jak to mniej więcej wygląda...

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 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 DOSYĆ długi niespakowany blok !). Następnymi bajtami są już same niespakowane dane.

- spakowane dane. Pierwszy bajt w takim bloku ma wyzerowany siódmy bit, reszta zaś jest długością 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 byłoby tyle w temacie budowy pliku w formacie KOALI MICROILLUSTRATORA. Mimo, że efektywność kompresji w oferowany przez KOALĘ sposób jest raczej kiepska (szczególnie przy dużych, 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.

Mam nadzieję, że zamieszczone tu informacje przydadzą się szczególnie koderom, spośród których może ktoś wreszcie napisze jakiś porządny viewerek do szybkiego przeglądania obrazków w kilku(nastu) formatach graficznych (np. PIC, PIC v2, GED, CIN, DigiPaint, RGB, INT...).