Szoftver-környezet, alaprutinok

Személyi számítógépen a képfeldolgozás lépéseit, drága hardver eszközök hiányában, szoftveresen végezhetjük. Ez bizonyosan lassabb futási időt eredményez, de új alkalmazási terület esetén lehetővé teszi a felhasználandó algoritmusok tervezését és tesztelését, gyors, így költség-kímélőbb módosítását. A szoftveres algoritmusok sebessége, bár automatizálásban (pl. osztályozás) nem mindig elegendő, laboratóriumi vizsgálatokra (pl. minőségellenőrzés) elégséges. Az algoritmusok tervezésénél a hatásosságon túl mindvégig szem előtt tartottam a gyors futási időt és a könnyű hardveres adaptálhatóságot. A PC-n futó kezdeti interpreteres nyelvek (basic, Quick Basic, Pascal) után, végre a lefordítható nyelvek (pl. a Turbo család TP, TC, Tasm nyelvei) megjelenése biztosíthatta a kívánt sebességet.

A sebesség igénye és az eszközök gépközeli programozása miatt döntöttem a kellően alacsony szintű, ugyanakkor plattform-függetlennek hirdetett C nyelv mellett (Kerninghan and Ritchie, 1988).

Ennek ára az volt, hogy a legalapvetőbb feladatokat is programozni kellett (menü-kezelés, adatbevitel, file-kezelés, stb.), a plattform-függetlenség pedig eszközök kezelésénél természetesen nem jelent hardver-függetlenséget, hiszen időközben pl. a monochrom, CGA, EGA majd VGA monitor-kártyákból SVGA szabvány lett, szinte minden eszköz kicserélődött, annak kezelése változott. Az interrupt és port alapú eszköz-kezelést csak igen szövevényes assembly és C kóddal lehetett megvalósítani (Úry, 1988, Pethő, 1988). A kipróbált C nyelvjárások közül (MSC, Watcom, Borland, stb.) végül a Borland C++ volt a legdokumentáltabb, legígéretesebb (Benkő, 1992).

A kezdeti nehézségek másik oka az XT-től örökölt 16 bites címzés volt. 15 évig szenvedtek az IBM-Microsoft platformon dolgozó programozók a kompatibilitási okok miatt megtartott szabvány miatt, amíg meg nem jelent a Windows 95®, az első 32 bites Microsoft® operációs rendszer. Addig az MS operációs rendszerek monopol helyzete állta útját más, korszerűbb, 32 bites rendszerek elterjedésének. 16 bites, azaz szegmens-offset típusú címzésnél egy memóriablokk (szegmens) mérete maximum 64 kB lehet, a maximálisan elérhető tartomány pedig 1 MB, amiből a betöltött programok felemésztik az alsó 640 kB nagy részét. 1 MB-ig DOS alatt a Himem.sys, tovább az EMM386.exe driver-programok tették lehetővé a címzést. A 64 kB egy 320x200 felbontású, max.

256 színű kép méretének felel meg, ami messze nem elég a képfeldolgozás igényeinek (pl. a 24 bites színmélység miatt). Ezért utóbbi esetben mind a memóriát, mind a képernyő memóriáját csak un.

lapozással, sőt a memória-hiány miatt legtöbb esetben az EMM386 interrupt-jainak hívásával vagy

saját „swapfile” technikával lehetett kezelni. Lapozásnál külön figyelni kellett arra, hogy a 24 bites (3 byte) képnél, egy a határon lévő pixel adatai két különböző szegmensre eshetnek.

A képernyő-kezelést végül a VESA programozási technika felprogramozásával, a SMALL és LARGE memória-modellek tár-problémáját pedig, az újabb processzorok 32bites PROTECTED módját kiszolgáló DPMI32 kódra való átírással lehetett megoldani (Benkő, 1996).

Az új 32 bites Win9x/Nt operációs rendszerek megjelenésével egyszerre lehetett elfeledkezni a memória-gondokról, hiszen a 32 bites címzés, a rendszer saját memória-kezelése (swap-fájlok) ezt könnyűvé tette, valamint az eszközök port-szintű programozásáról. A hardver-gyártóktól követelménnyé vált a különböző operációs rendszereket és nyelveket támogató illesztő-programok (driver-ek) mellékelése. Azok, illetve az operációs rendszerek, nyelvek hibáinak javítása (patch) a továbbiakban az Ő gondjuk. Ezzel párhuzamosan megfogalmazták a Windows plattformra tervezett nyelvek irányadó technikáit annak előnyeivel (modularitás, standard interface-ek, néhol csak erőltetett objektum orientáltság) és nehézségeivel (nem szekvenciális, üzenet alapú, párhuzamos gondolkozás, operációs rendszer hibáinak öröklése) együtt.

El lehetett dobni az eddigi DOS alapú fejlesztéseket, cserébe kapva a Visual nyelvek magas-szintű kényelmét, a lehetőséget, hogy a fejlesztő az algoritmusokra és ne a részletekre koncentrálhasson.

Pontosabban a programozónak még inkább el kell döntenie, hogy a magasszintű nyelveken kódol kutatási, laboratóriumi célokra alkalmazható programokat, vagy alacsonyszintű nyelveken készít hardveresen adaptálható, valós-idejű, ipari alkalmazásokban is használható algoritmusokat. A programozásban is felerősödött a moduláris, hierarchikus felépítés, többé már nem ezermesterek, hanem team-ek, speciális területekhez értő guru-k munkája. Nem ipari alkalmazásról, hanem kutatásról lévén szó, egy magasszintű, ugyanakkor gyors, jól dokumentált fejlesztői környezetet választottam, a Borland C-Builder-t (Benkő, 1999).

Egy képfeldolgozó szoftver első feladata a kép megnyitása, azaz leképezése a memóriában (DIB).

Ennek legegyszerűbb formája egy, pl. a digitalizáló kártya szoftvere által előzetesen mentett képfájl megnyitása. Itt különböző mentési formátumokra kell felkészülni, mint például:

• Windows vagy OS/2 Bitmap (BMP): 1,2,4,8,24 és 32 bites, általában tömörítetlen

• Zsoft Paintbrush (PCX): 1,2,4,8 és 24 bites, tömörítetlen formátum

• CompuServ Graphics Interchange (GIF): 8 bites, veszteségmentes tömörítés, főként animációra

• Joint Photographic Experts G. (JPEG): 24 bites, veszteséges tömörítés

• Tagged Image File Format (TIF): 24 bites (Lab encoded), veszteségmentes tömörítés

• Truevision Targa (TGA): 24 bites, veszteségmentes tömörítés

A képformátumok listáját természetesen sokáig folytathatnánk, de az említettek fordulnak elő leggyakrabban a képfeldolgozás gyakorlatában. Az egyes formátumokat, alapvető célfeladatukon kívül, elsősorban a kódolási algoritmusuk különbözteti meg. A legtöbb esetben védett és így messze nem publikus technológia teszi nehézzé egy ilyen egyszerűnek látszó lépés programozását. DOS alatt az összegyűjtött információk alapján magam kódoltam le az egyes formátumok megnyitását, mentését, Win32 platformon DLL-be gyűjtött algoritmusok segítségével oldom meg.

A digitalizáló kártya közvetlen megnyitása lehetővé teszi a képforrás mozgóképének megjelenítését, feldolgozását. A művelet DOS alapú (ill. általában az alacsonyszintű) programozása igen nehézkes volt, portok, memóriacímek, interruptok kezelését igényli. Az ilyen illesztés teljesen hardver-függő, csak konkrét eszközre alkalmazható, a következő AD kártya típus esetén eldobható. A Windows megjelenésével elterjedt gyakorlat az illesztőprogram (driver) készítését a gyártóra bízza, tervezésükhöz csak az interface-t adja. Windows alatt a videó típusú MCI eszközök ilyen szabványos felülete a „Video for Windows” (VfW) (10. ábra).

10. ábra: Fejlesztői rétegek

A VfW felület programozási lehetőségeiről a Borland nyelvekhez mellékelt MMEDIA.HLP ad segítséget. Függvényhívással lehet adott videó eszközt megnyitni, bezárni, a képet ablakhoz rendelni, az eszköz paramétereit lekérdezni, beállítani, az eszköz illesztőprogramjának dialógus-ablakait (forrás, formátum, megjelenés) megnyitni, a „preview” vagy „overlay” megjelenítést indítani, leállítani, az utolsó képet BMP formátumban menteni (grab).

Jóval nehezebb a helyzet, ha preview mozgóképet adott méretben kívánunk megjeleníteni, vagy az úgynevezett frame-eken kell valamilyen műveletet végrehajtani (pl. módosítás, képfeldolgozás, tömörített mentés, „capture”). Az eszköz-illesztő egy, az egyes frame-ek leképezése után meghívott, un. „Callback” függvény használatát kínálja. Szerencsés esetben (hardveres tömörítés nélküli kártya) a függvény átadott paramétere egy, a BGR mátrixot tartalmazó memória-területre mutat, ellenkező esetben a feldolgozandó és kijelzendő képet csak „Vágólap”-on keresztül érhetjük el.

Professzionális alkalmazás készítésére a VfW protokol teljesítménye kevés. Ilyen alkalmazásoknál az eszköz közvetlen kezelése szükséges. Ez rámutat arra, hogy egy képfeldolgozó program írásakor, az algoritmus hatékonyságán kívül, elsőrendű szempont annak sebessége. A második legnagyobb ellenfél a futási idő. Ezt követi csak a hardver-eszközök, operációs rendszerek, fejlesztő környezetek változása által okozott gond.

A vezérlő szoftver, mint szükséges méréstechnikai alap megoldása után végre következhet a képfeldolgozás. A memóriába való leképezést követő első feladat esetünkben a vizsgált objektum szegmentálása. Ez a lépés már meglehetősen cél-specifikus, így gyakorlatunkban használható alapvető módszereit munkám külön fejezetében fogom taglalni.