Diplomová práce

Transkript

Diplomová práce

Západočeská univerzita v Plzni
Fakulta aplikovaných věd
Katedra kybernetiky
Diplomová práce
Implementace animace tváře v prostředí
projektu ArtiSynth
Plzeň, 2007
Jakub Vondrák
Prohlášení
Předkládám tímto k posouzení a obhajobě diplomovou práci zpracovanou na
závěr studia na Fakultě aplikovaných věd Západočeské univerzity v Plzni.
Prohlašuji, že jsem předloženou diplomovou práci vypracoval samostatně s použitím odborné literatury a pramenů, jejichž úplný seznam je její součástí.
V Plzni dne . . . . . . . . . . . .
.................
podpis diplomanta
Poděkování
Rád bych touto cestou poděkoval panu Zdeňku Krňoulovi za konzultace a cenné
rady. Dále členům vývojového týmu ArtiSynth za ochotnou pomoc na emailové
konferenci tuna-developer [at] ece.ubc.ca a také svým blízkým za jejich podporu.
Abstrakt
Cílem diplomové práce bylo prostudovat projekt ArtiSynth a navrhnout a implementovat metodu animace tváře. ArtiSynth je framework naprogramovaný
v jazyce Java a vyvíjený na University of British Columbia. První část práce
presentuje význam a výhody vizuální syntézy řeči a dále stručné shrnutí technik
a přístupů, které se v této oblasti používají. Mezi tyto techniky patří MPEG-4,
X3D, FACS, SMIL, FML, ArtiSynth framework a další. Druhá část práce potom obsahuje detaily týkající se analýzy a vlastní implementace mluvící hlavy.
Implementace vychází z již vyzkoušených konceptů na oddělení umělé inteligence Západočeské univerzity v Plzni, které v mnohých aspektech vylepšuje a
rozšiřuje. Implementace je provedena modulárně za použití rozhraní a továren.
Mezi použité technologie patří X3D, XML, PCA, interpolace kubickými splajny
a další.
Key words: animace tváře, ArtiSynth, koartikulace, PCA, OpenGL, JOGL,
Java, X3D
Abstract
The goal of this diploma thesis is study of ArtiSynth framework, developed on
University of British Columbia and implementation of talking head in framework
environment. First part of work presents motivation and theoretical aspects for
face visualization and related techniques. Such techniques are MPEG-4, X3D,
FACS, SMIL, FML, ArtiSynth framework and others. Second part explains details of analysis and implementation of talking head. Talking head is based on
proven concepts from Artificial section department on University of West Bohemia and is enhanced in numerous aspects. Implementation is done in modular
way using interfaces and factories. Configuration of model was done using XML
and X3D for geometry data. Other used techniques involve PCA for state space
reduction and spline interpolation.
Key words: face animation, ArtiSynth, coarticulation, PCA, OpenGL, JOGL,
Java, X3D
Obsah
1 Úvod
3
2 Vizuální syntéza tváře
2.1 Význam tváře v komunikaci . . . . . . . . . . .
2.2 Neřečové informace . . . . . . . . . . . . . . . .
2.3 Využití vizuální syntézy tváře . . . . . . . . . .
2.4 Historie počítačové syntézy tváře . . . . . . . .
2.5 Přístupy k audiovizuálnímu zpracování řeči . .
2.5.1 Audio syntéza řeči . . . . . . . . . . . .
2.5.2 Vizuální syntéza řeči . . . . . . . . . . .
2.5.3 Video syntéza . . . . . . . . . . . . . . .
2.5.4 3D model – parametrický . . . . . . . .
2.5.5 3D model – fyziologický . . . . . . . . .
2.6 Technologie pro animaci tváře . . . . . . . . . .
2.6.1 SMIL . . . . . . . . . . . . . . . . . . .
2.6.2 VRML a X3D . . . . . . . . . . . . . . .
2.6.3 MPEG-4 . . . . . . . . . . . . . . . . .
2.6.4 Animace tváře s prostředky v MPEG-4
2.6.5 MPEG-4 XMT formát . . . . . . . . . .
2.6.6 Facial Action Coding System (FACS) .
2.6.7 Formáty pro uložení výrazu tváře . . . .
2.7 ArtiSynth . . . . . . . . . . . . . . . . . . . . .
2.7.1 Java . . . . . . . . . . . . . . . . . . . .
2.7.2 Simulační jádro . . . . . . . . . . . . . .
2.7.3 Java API for OpenGL binding (JOGL)
2.7.4 Probes . . . . . . . . . . . . . . . . . . .
2.7.5 Uživatelské rozhraní . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
7
8
8
9
9
9
10
10
10
11
12
12
14
15
16
20
21
22
22
23
23
3 Realizace mluvící hlavy
3.1 Použité algoritmy . . . . . . . . . . . . . . . . . . . .
3.1.1 Modelování koartikulace . . . . . . . . . . . .
3.1.2 Stav modelu a analýza hlavních komponent .
3.1.3 Interpolační algoritmus . . . . . . . . . . . .
3.2 Provedená vylepšení ArtiSynthu . . . . . . . . . . .
3.2.1 Sestavovací systém Apache Ant . . . . . . . .
3.2.2 Implementace algoritmu pro výpočet splajnu
3.2.3 Balíček pro čtení a zápis prostorových dat . .
3.3 Konfigurační soubory a vstupní data . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
25
26
28
30
30
31
31
32
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
OBSAH
3.4
3.3.1 3D model . . . . . . . . . . . . . . . . . .
3.3.2 Kontrolní body . . . . . . . . . . . . . . .
3.3.3 PCA . . . . . . . . . . . . . . . . . . . . .
3.3.4 Kontrolní objekty . . . . . . . . . . . . .
3.3.5 Stavy . . . . . . . . . . . . . . . . . . . .
Programové zpracování . . . . . . . . . . . . . . .
3.4.1 Stav – parametrizace . . . . . . . . . . . .
3.4.2 Plánovač . . . . . . . . . . . . . . . . . .
3.4.3 Dekodér hlavních komponent . . . . . . .
3.4.4 Kontrolní objekty . . . . . . . . . . . . .
3.4.5 Ovlivnění geometrie . . . . . . . . . . . .
3.4.6 Předzpracování textového vstupu . . . . .
3.4.7 Uživatelské rozhraní a možnosti ovládání
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
34
35
35
36
37
38
39
40
41
42
42
4 Shrnutí
45
4.1 Zhodnocení programu . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Možná vylepšení . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2
Kapitola 1
Úvod
Oddělení umělé inteligence při katedře kybernetiky se již dlouhou dobu zabývá
syntézou i rozpoznáváním řeči. Do této problematiky spadá i vizuální syntéza
řeči v podobě mluvící hlavy. Cílem této diplomové práce je navázat na dosavadní
poznatky v problematice vizuální syntézy řeči a provést vlastní implementaci
mluvící hlavy v prostředí frameworku ArtiSynth, naprogramovaného v Jave a
vyvíjeného na kanadské univerzitě University of British Columbia (UBC). Důvod pro výběr ArtiSynthu jako základny pro novou implementaci bylo navázat
užší spolupráci s UBC, prezentovat koncepci dosavadního přístupu a vyzkoušet
schopnosti ArtiSynthu.
Pro splnění tohoto cíle bylo nutné, seznámit se s obecnými principy vizuální
syntézy promluvy, naučení se základům počítačové grafiky, konkrétně OpenGL
a seznámit se s dosavadními výsledky pracoviště umělé inteligence. Dále nastudovat principy a fungování ArtiSynthu a ve spolupráci s vývojovým týmem
domluvit koncepci jeho rozšíření. Konečným a nejnáročnějším bodem byla samotná implementace modelu a numerických algoritmů. Implementace si kladla
za cíl využít poznatků z objektově orientovaného programování, návrhových
vzorů a osvědčených postupů, aby byl výsledný model dobře dekomponován a
připraven pro případné další rozšíření nebo zkoušení nových přístupů.
Samotná implementace bude vycházet z koncepce parametrického modelu
mluvící hlavy, již fungujícího a implementovaného v jazyku C++ na oddělení
umělé inteligence. Analýza bude ale probíhat nezávisle na stávajícím řešení a
snahou bude nalézt a odstranit případné nedostatky. Dále budou do modelu
zahrnuta některá vylepšení, která stávající implementace neobsahuje.
Všechny výše uvedené body se v implementaci podařilo dodržet a mluvící
hlava, jako jeden ze simulačních modelů, se stala součástí ArtiSynthu. Implementace probíhala ve vlastním balíku, ale části kódu, které se jevily použitelné
i pro jiné modely, byly integrovány přímo do příslušných částí ArtiSynthu a tak
zpřístupněny dalším vývojářům. Konkrétně se jednalo o řešení, umožňující načítat geometrická data a jeho implementace pro formát X3D. Dále implementace
numerické metody prostorových splinů a nakonec úprava a přidání souborů pro
umožnění sestavovat projekt pomocí sestavovacího systému Apache Ant.
3
Kapitola 2
Vizuální syntéza tváře
2.1
Význam tváře v komunikaci
Výraz tváře je velmi bohatý zdroj informací. Lidský mozek je přizpůsoben informace z tváře vnímat a integrovat s okolním kontextem a získávat tak další
vodítka, užitečná nejen pro porozumění promluvy, ale i pro získání úplně nových
informací.
Každý člověk, byť si to možná neuvědomuje, vnímá tvář mluvícího člověka,
což mu pomáhá porozumět promluvě. Konkrétně se jedná o pozici rtů, jazyka,
zubů, tváří a dalších artikulačních orgánů. Vizuální informace zvyšuje úspěšnost
rozpoznání řeči, pokud je zvukový signál špatně zřetelný.
Vizuální řeč také umožňuje porozumět mluvené řeči neslyšícím. Schopnosti
odezírání ze rtů, je ale třeba se naučit a její spolehlivost závisí na velkém množství faktorů. Ve zvukové složce je při promluvě obsaženo mnohem více informací
a tak velkou úlohu při odezírání hraje kontext promluvy, umožňující si chybějící
informace domyslet. Je mnoho rozdílů vnímaných ve zvukové složce, které ve vizuální není možné postřehnout. Některé artikulační orgány, jakým je například
jazyk nebo měkké patro jsou totiž odezírajícímu skryty (Strnadova, 2001).
Provázanost zpracování slyšitelné a viditelné složky promluvy lidským mozkem, lze potvrdit pomocí McGurk efektu (McGurk – MacDonald, 1976). Ten
spočívá ve vnímání rozdílné promluvy ve vizuální a audio složce, což způsobí unikátní interpretaci prezentovaných informací. Pokud přehrajeme zvukovou stopu
s promluvou „baÿ a vizuální stopu se záznamem „gaÿ, bude většina lidí vnímat
„daÿ. Náš mozek tedy integruje sluchovou a zrakovou informaci a vytvoří úplně
novou slabiku. Existují i další možnosti kombinací, při kterých převáží zraková
nebo sluchová část.
Nalezneme i další důkazy důležitosti vizuální informace při promluvě. Například B. Goff a kolektiv (Goff et al., 1994) ukázali závislost porozumění promluvě
na stupni okolního šumu. Rozdíl v úspěšnosti, kdy měl testovaný subjekt k dispozici vizuální složku k zašuměné promluvě, byl značný. Při odstupu užitečného
signálu od šumu (Sound to Noise Ratio – SNR) o velikosti kolem -16 (dB) ve
zvukové složce, byla už úspěšnost porozumění bimodální informaci téměř dvojnásobná. Úspěšnost porozumění bimodálnímu vnímání, není prostým součtem
úspěšností vizuální a zvukové složky, ale je vyšší (Goff et al., 1994, s. 3). Z grafu
na obrázku 2.1 lze vidět závislost porozumění promluvě na množství a kvalitě
4
KAPITOLA 2. VIZUÁLNÍ SYNTÉZA TVÁŘE
vnímaných informací. Se zvyšující se úrovní šumu se úplně ztratila možnost porozumění pouze audio signálu, zatímco při bimodálním vnímání vizuální řeči,
byla úspěšnost mnohem vyšší.
Obrázek 2.1: Úspěšnost porozumění v závislosti na šumu při různě dostupných
informacích (Goff et al., 1994, s. 3)
2.2
Neřečové informace
Kromě vnímání vizuální řeči, lze z tváře získat množství neřečových informací,
které nám mohou říci v jaké je člověk náladě, jestli mluví pravdu, atp. Výraz
tváře nelze ale vnímat samostatně vytržený z kontextu. Například z fotografie nelze poznat, co přesně výraz znamená. Kontext, který souvisí s výrazem
tváře může být například řeč, čas, místo, osobnost řečníka a další souvislosti.
Ekman vysvětluje výraz tváře pouze jako externí manifestaci interního stavu
z různých domén (Ekman, 1997). Stejný výraz tváře tedy slouží pro vyjádření
různých informací podle toho, z jaké pochází domény. Ekman specifikuje sedm
domén, které se mohou manifestovat v podobě výrazu tváře a tedy existuje
sedm interpretací každého výrazu.
Domény, z kterých může pocházet výraz tváře:
1. Bezprostřední události
2. Myšlenky, vzpomínky, očekávání, plány
3. Fyzický stav
4. Metafora
5. Co hodlá udělat v následující chvíli
6. Co chce, aby příjemce výrazu udělal
7. Emoce
5
Uvedeme zde příklad, který je převzat taktéž z (Ekman, 1997). Představte si,
že se na vás dívá člověk s hlavou vystrčenou mírně dopředu, sníženým obočím,
které je stlačeno mírně k sobě a rty přitisknutými k sobě. Bez dalších informací
si lze tento výraz vysvětlit mnoha různými způsoby:
• Osobu někdo urazil nebo vyprovokoval
• Plánuje zaútočit na osobu, která jí toto způsobila
• Vzpomíná, jak ji naposledy někdo vyprovokoval
• Cítí se napjatě
• Zuří
• Někoho v nejbližší chvíli napadne
• Chce, aby osoba, která ji provokuje přestala
Pro správné zařazení stavu k příslušné doméně je tedy nutné znát kontext.
Ekman dále zavádí rozdělení výrazů tváře na volní (vědomě řízené) a mimovolní
(nelze ovládat vědomím), přičemž výraz obličeje vyjadřující emoci zařazuje do
mimovolních (Ekman, 1997, s. 5). Obličejové svaly jsou tedy ovládány jak volně,
tak mimovolně. Mimovolní výrazy lze sice potlačit, ale skoro nikdy úplně, čehož
lze využít např. při rozpoznávání lží. Ekman při svém výzkumu nalezl jedince,
kteří jsou schopni lež odhalit téměř vždy (Gladwell, 2002). Při tomto výzkumu
narazil na fenomén, který pojmenoval mikrovýrazy. Jedná se o konfiguraci obličejových svalů, která trvá pouze desetiny sekundy a které nelze vůlí potlačit.
Z výše uvedeného je vidět, že význam vizuální informace v komunikaci je
značný. Lze jej využít nejenom k lepšímu porozumění vyslovované promluvy, ale
i získat mnohem hlubší informace o skutečných záměrech řečníka.
2.3
Využití vizuální syntézy tváře
Většina lidí vnímá vizuální syntézu tváře jen jako doplněk syntézy řečové v zábavním průmyslu. Vizualizace výrazů tváře nebo vizualizace promluvy, má ale
mnohem širší využití. Například je možné s detailním modelem, postaveným
na reálných datech, zkoumat produkci řeči u člověka a lépe tak pochopit její
skutečné fungování. Tímto se zabývá mnoho pracovišť, vyvíjejících anatomicky
přesné modely, založené na fyzikálních zákonech, které se ale pro svoji složitost
nehodí k použití v reálném čase. Několik modelů vyvinutých ve frameworku
ArtiSynth je takovým příkladem.
Další využití nachází mluvící hlava jako doplňek pro znakující postavu, která
může zajišťovat automatické znakování k jakémukoli zvukovému výstupu. Tak
lze odstraňovat bariéry pro neslyšící nebo sluchově postižené. Typicky se může
jednat o televizní vysílání nebo rádio přijímané pomocí počítače.
Výukové programy jsou další doménou pro nasazení mluvící hlavy. Uživatel
programu se bude výslovnosti učit mnohem lépe, pokud skutečně uvidí správnou artikulaci. Takový program byl zkonstruován například týmem (Massaro –
Light, 2004).
6
Pravděpodobně uvidíme mluvící hlavy také v mobilních telefonech. Například pomocí dříve uložených obrazových a geometrických dat a s použitím koartikulačního modelu, lze vizualizovat virtuální hlavu, která přečte přijatou SMS
(Short Message Service) zprávu. Již dnes se ale používá telekonferencing, při
kterém je přenášena hlava mluvící osoby i na linkách s nízkou propustností.
To je možné při použití pokročilých kompresních algoritmů, jakým je například
MPEG-4, který má speciální podporu pro kompresi videa mluvící hlavy. Technologie je v tomto ohledu napřed před možnostmi hardwaru. Největší problém
dělá zřejmě nízká životnost baterií, která brzdí zrychlování procesorů i velikost
operační paměti (Nystedt – Zhang, 2005).
Nemalé využití nacházejí systémy vizualizace obličeje a jeho výrazů v zábavním průmyslu. Ať už se jedná o filmy nebo hry. Lze říci, že toto odvětví
jde zvláště v posledních letech, se zvyšujícím se výkonem počítačů, rychle dopředu. Hry se narozdíl od filmů vyznačují vizualizací v reálném čase, což ale
také znamená, že nemůžou dosáhnout kvalit offline zpracování, kdy je na výpočet libovolné množství času.
Vizualizovaná lidská hlava bude s rostoucím výkonem počítačů nacházet
uplatnění také jako běžná součást programového vybavení. Bude nám dělat
průvodce i rádce. Zvyšující se interaktivita je neustálý trend, který bude dále
pokračovat. Mnoho velkých firem vyvinulo nebo vyvíjí technologie pro vizualizaci nebo vytvoření virtuální postavy. Například výzkumné oddělení společnosti
Microsoft vyvinulo software, který je schopný sestavit 3D virtuální model hlavy
z videosekvence obyčejné webové kamery (Zhang, 2001).
2.4
Historie počítačové syntézy tváře
Člověk se o výrazy a obličej začal zajímat nejprve z biologického a psychologického hlediska. Za počátek moderního pohledu na vnímání výrazu tváře lze
považovat Darwinovu knihu The Expression of the Emotions in Men and Animals, vydanou v roce 1872.
Dalším velkým krokem v poznání informační hodnoty tváře, bylo navržení
komplexního klasifikačního systému pro člověkem rozpoznatelné elementární výrazy, nazvaného Facial Action Coding System (FACS), za kterým stojí Paul
Ekman a Wallace Friesen. Tento systém byl poprvé publikován v roce 1976 a
jeho poslední verze pochází z roku 20021 .
Za první 3D počítačovou animaci tváře je považována práce Parkeho z roku
1972. V roce 1974 navrhnul Frederick I. Parke parametrizovaný 3D model tváře.
Parametrizovaný model umožnil měnit výrazy tváře pouze za pomoci malého
množství parametrů a nevyžadoval ruční změny celé geometrie.
Počátkem let 1980 byl vyvinut první model založený na fyzikálním modelu
svalů, který vytvořil Platt. Další model, který vyvinul Brennan, umožňoval simulovat karikatury tváře. Roku 1985 byl vytvořen krátký animovaný film „Tony
de Peltrieÿ2 , produkovaný Lachapellem, který se stal milníkem v animaci tváře.
Poprvé byl totiž příběh založen na výrazu tváře animované postavy, kterou lze
vidět na obrázku 2.2. Na obrázku lze pro srovnání vidět také výstup z komerčního softwaru Face Robot firmy SoftImage, určeného pro animaci tváře v 3D
programech. Verze 1.5 tohoto softwaru byla vydána v roce 2006.
1 http://face-and-emotion.com/dataface/facs/new_version.jsp
2 http://www.fondation-langlois.org/flash/f/index.php?NumPage=292
7
Obrázek 2.2: Vlevo: Ukázka z krátkého filmu Tony de Peltrie (1972); Vpravo:
Výstup z animačního programu Face Robot firmy SoftImage (2006)
Koncem 80. let vytvořil Keith Waters nový fyzikální model založený na dynamické simulaci deformovatelné tkáně, obsahující svaly přichycené k lebce a
oddělenou čelist. Ve stejné době probíhal výzkum v oblasti synchronizace řeči,
vedený Lewisem a Hillem.
V průběhu 90. let začal rozmach animačních metod a technik zabývající se
tváří. V University of Californie, Santa Cruz Perceptual Science Laboratory,
vyvinul Cohen a Massaro vizuální řečový syntetizátor, který zajišťoval i koartikulaci.
V polovině 90. let se stala počítačově založená syntéza tváře běžnou součástí
filmů a byly na ni založeny celé příběhy. Prvním filmem, kde mimika hlavní
postavy byla kompletně vytvořena počítačovou animací, byl Casper z roku 1995.
V roce 2005 bylo uvedeno nové zpracování King Konga, které využívá FACS
systém, implementovaný Markem Sagarem, na kterém budou založeny zřejmě i
další filmy.
V roce 1998 byl vydán MPEG-4 standard, který obsahuje část věnovanou
čistě animaci tváře. Tato patentovaná technologie by mohla nahradit v současné
době používaná nestandardní řešení, často vytvořená pro jeden daný účel a tudíž
příliš nerozšiřitelná.
Tyto historické informace byly čerpány z Wikipedia (2007a); Eptamedia
(2000).
2.5
Přístupy k audiovizuálnímu zpracování řeči
Audiovizuální, neboli bimodální syntéza řeči zajišťuje zprostředkování jak zvukové, tak obrazové složky řeči. Tato práce se orientuje hlavně na obrazovou
animaci řeči, a proto bude audio syntéze věnována jen krátká část shrnující
základní přístupy a dosavadní výsledky.
2.5.1
Audio syntéza řeči
Cílem audio syntézy řeči, je produkovat řeč v kvalitě nerozlišitelné od lidského
řečníka. Přístupy k audio syntéze řeči lze rozdělit do tří kategorií.
• Formantová syntéza
• Konkatenační syntéza
8
• Artikulační syntéza
Formantová syntéza modeluje zjednodušeným způsobem hlasový trakt a simuluje tak způsob vytváření řeči člověkem. Ve formantové syntéze se řeč vytváří
pomocí průchodu buzení soustavou filtrů, které představují hlasový trakt. Buzení dělíme na znělé a neznělé. Znělé představuje zvuk generovaný hlasivkami a
neznělé buzení pak zvuky vznikající u frikativních fonémů. Základní tón hlasového traktu se označuje jako nultý formant F0 . Formantová syntéza nedosahuje
velké přirozenosti.
Konkatenační syntéza funguje na principu řetězení předzaznamenaných jednotek řeči. Program analyzuje vstupní text s prozodií, a podle toho vybírá z databáze řečové jednotky, které minimalizují určité kritérium. Délka řečových jednotek závisí na použití. Například pro syntézu celého možného spektra slov se
často používají tzv. trifóny nebo difóny. Například trifón je foném, s určitým
pravým a levým kontextem, tvořeným jinými fonémy. Konkatenační syntéza
je dnes nejpoužívanější a dosahuje vysoké přirozenosti. Nevýhodou ale zůstává
kolísající kvalita, která je způsobená řetězením nevhodných jednotek.
Artikulační syntéza vytváří řeč pomocí přesného matematicko-fyzikálního
modelu hlasového traktu. Tento přístup klade velké nároky jak na dobrou anatomickou znalost hlasového traktu, tak i na výpočetní výkon. Mnoho parametrů
hlasového traktu se prozatím nedaří dobře měřit a ani výkon běžných počítačů
není dostačující pro artikulační syntézu v reálném čase. Artikulační syntéza tak
zůstává možnou syntézou budoucnosti.
2.5.2
Vizuální syntéza řeči
Vizuální syntézu můžeme rozdělit podle přístupu na video a 3D syntézu. 3D
syntézu lze dále rozdělit na parametrickou a fyzikálně orientovanou. Těmto přístupům se budeme věnovat v samostatných kapitolách níže. Dalším možným
rozdělením vizuální syntézy by mohlo být na realtime a offline. Realtime syntéza nachází použití ve výukových aplikacích nebo ve hrách. Offline syntéza je
používáná pro filmy a vyznačuje se vyšší obrazovou kvalitou, které je možné
dosáhnout pokročilými renderovacími technikami.
2.5.3
Video syntéza
Video syntéza je založena na podobném principu jako konkatenační přístup v audio syntéze. V databázi je uloženo množství předzaznamenaných video sekvencí,
které program vybírá a řetězí podle potřeby. Uplatňují se zde techniky morfování, ale i z části 3D přístup. Video lze totiž mapovat na 3D tvář a tak zvýšit
dojem prostorovosti. Video syntézy mohou dosáhnout vysoké realističnosti.
2.5.4
3D model – parametrický
Prostorový 3D model je založen na počítačové vizualizaci geometrických dat,
která jsou řízena množinou časově proměnných parametrů. Prostorová vizualizace je řešena buď pomocí realtime renderovacích technik, jakými je například
OpenGL nebo DirectX nebo pomocí náročných offline renderovacích technik,
dávající realističtější výsledky.
9
Množství a funkce parametrů modelu se různí. Buď můžeme využít existující
přístupy jako jsou MPEG-4 FAPs nebo FACS, a nebo si navrhnout vlastní. Jednou z možností je aplikovat postupy pro redukci parametrů, jako je například
metoda označovaná jako analýza hlavních komponent, dále jen PCA (Principal Component Analysis) a redukovat tak množství parametrů potřebných pro
řízení.
Parametry modelu mohou řídit hustou 3D síť přímo, nebo nepřímo. Při
nepřímé aplikaci je parametry ovlivňována kanonická, jednodušší síť, která následně ovlivňuje konečnou hustou síť. Tento přístup má výhodu ve snažší manipulaci s jednoduchou sítí (ušetření výpočetního času) a zároveň umožňuje měnit
konkrétní viditelnou 3D síť. Například lze vyměnit obličej řečníka nebo použít
různě hustou síť v závislosti na výkonu počítače.
2.5.5
3D model – fyziologický
Fyziologický model se od parametrického liší způsobem modifikace geometrie
3D sítě. Fyziologický model bere v potaz anatomickou podstatu lidské tváře,
jako jsou svaly, kůže a další části, které mají být simulovány. V případě svalů
se tedy většinou jedná o dynamický systém popsaný diferenciálními rovnicemi.
Fyziologický model se skládá většinou ze tří částí. Z modelu lebky, ke které
jsou příchyceny svaly, ze svalů a z vrstvy kůže. Kůže může mít navíc několik
vrstev, které z různou intenzitou přenášejí deformace na poslední viditelnou
vnější vrstvu.
Z popisu fungování je zřejmé, že fyziologický model je výpočetně velice náročný a běžnými PC v reálném čase nerealizovatelný. Dalším problémem fyziologického modelu je většinou nedostatečná znalost přesné anatomie a dynamiky.
Ta často nejde dobře změřit kvůli nedostupnosti daného místa měřícím prostředkům. Jedná se například o jazyk nebo hlasivky. V případě, že by ale tyto
problémy byly vyřešeny, dával by fyziologický model realistické výsledky.
2.6
2.6.1
Technologie pro animaci tváře
SMIL
Synchronized Multimedia Integration Language (SMIL) je technologie, za kterou stojí World Wide Web Consorcium a první verze se stala doporučením už
v roce 1998. Technologie umožňuje tvorbu multimediálních prezentací ve standardizovaném formátu. Autorovi umožňuje časování, pozicování, animaci, přechody, vkládání médií a další. SMIL je implementován převážně na mobilních
zařízeních, ale je možné jej přehrát i na PC pomocí Apple QuickTime Player3 .
Podmnožina SMIL funkcí je dnes známa pod názvem Multimedia Messaging Service (MMS). Ve SMIL je možné reprezentovat 3D scény a protože v MPEG-4
XMT formátu je možné SMIL použít, je uveden i zde.
SMIL dokument je strukturálně podobný běžnému HTML. Obsahuje části
<head> a <body>. V hlavičce jsou obsaženy informace o rozvržení (layout) a
v těle jsou obsaženy časovací informace. Ty lze rozdělit do dvou skupin na
paralelní <par> a sekvenční <seq>. Multimediální objekty jsou z těla odkazovány
pomocí URL (Wikipedia, 2007e).
3 http://www.apple.com/quicktime
10
Momentální platná specifikace, verze 2.1, se skládá z několika modulů. Každý
modul pokrývá určitou oblast použití. Například animace, rozložení, linkování,
časování atp. SMIL obsahuje tři varianty s různě velkým „slovníkemÿ. Jedná
se o plnou formu, formu pro mobilní zařízení a rozšířenou formu pro mobilní
zařízení. Tyto tři formy jsou specifikované svým DTD schématem. (W3C, 2005).
Ukázka SMIL4
<!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 1.0//EN"
"http://www.w3.org/TR/REC-smil/SMIL10.dtd">
<smil>
<head>
<layout>
<root-layout width="160" height="160"
background-color="white"/>
<region id="r1" top="0" left="0" height="80" width="80" />
</layout>
</head>
<body>
<par>
<img src="objekt.png" begin="1s" dur="5s" region="r1" />
<seq>
</seq>
</par>
</body>
</smil>
Příklad v ukázce zobrazí dva obrázky objekt.png za jednu sekundu po spuštění
a další obrázek v sedmé sekundě.
2.6.2
VRML a X3D
Virtual Reality Modeling Language (VRML) a jeho nástupce Extensible 3D
(X3D) je standardní formát pro uložení virtuálních světů. Standard podporuje
animaci, interaktivitu s uživatelem a specifikuje i formát uložení dat do souboru.
Informace o standardu byly čerpány z (Zara et al., 2004, s. 530).
Virtuální svět ve VRML se skládá ze scény, která je tvořena hierarchickou
– stromovou strukturou objektů. To zajišťuje skládání transformací a vytváření objektů, respektive jejich podstromů. Tělesa jsou popsána pomocí vrcholů
a hran, tvořících plošky, na které lze mapovat statické nebo pohyblivé textury.
Scéna může obsahovat běžné prvky jako jsou zdroje světla, předdefinované polohy a charakteristiky kamer. VRML sám o sobě není programovací jazyk, ale
za pomocí JavaScriptu nebo Javy, lze měnit parametry objektů ve scéně obsažených. VRML bylo navrženo pro použití v síti, a tak lze části výsledné VRML
scény získat z různých souborů. Interakce s uživatelem zajišťují tzv. senzory,
4 Ukázka
SMIL formátu převzata z http://www.tvorba-webu.cz/xml/smil.php
11
které mohou reagovat na vstupní zařízení, jakým je např. myš. Interakce lze
použít pro synchronizaci událostí.
Nástupce VRML, standard X3D, reaguje na požadavky, které v průběhu používání VRML vznikly. X3D umí nově využívat křivky a plochy typu NURBS a
modelovat pomocí FFD. Dále obsahuje speciální podporu pro geografická data,
jakou je například neortogonální soustava souřadnic. X3D je rozděleno na několik tzv. komponent, které se dělí podle rozsahu, jaký lze pomocí nich reprezantovat. Například existuje komponenta pro mobilní zařízení, která neklade vysoké
nároky na hardware. Napříč komponentami existují tzv. profily, které definují
další omezení na prvky scény, jako např. maximální rozměr textur nebo počet
vrcholů ve scéně. Soubory X3D mohou být ukládány do různých formátů jako
např. binární, textový nebo XML.
2.6.3
MPEG-4
MPEG-4 je standard určený pro kompresi digitálních, interaktivních multimediálních dat. Standard vytvořila v roce 1998 skupina Moving Picture Expert Group (MPEG) a byl označen jako ISO/IEC 14496. Jeho předchůdci byly
MPEG-1 (1991), který umožňil zprostředkovat VHS kvalitu obrazu a MPEG-2
(1994), který našel uplatnění v DVD. MPEG-4 standard je určen pro použití v široké škále přehrávačů – od počítačů po mobilní zařízení. Narozdíl od MPEG-1 a
MPEG-2 je tedy velice mnohostranný a pokrývá širokou škálu kvality i formátů
obrazu.
Standard MPEG-4 se skládá celkem z 23 částí (parts), která se každá věnuje
specifické problematice a některé části podléhají patentům. MPEG-4 definuje
vlastní kontejner nazývaný MP4 (ISO 14496-14), který může obsahovat rozličné
druhy médií. Kromě audio a video objektů také tzv. bohatý obsah (Advanced
Content – Rich Media). Bohatý obsah může obsahovat taktéž audiovizuální objekty, ale navíc i syntetické scény (3D scény založené na VRML/X3D), textová
data, obrazová data a data pro správu práv, duševního vlastnictví a licenčních informací (DMR). Všechny tyto objekty mohou být obsaženy v datovém
MPEG-4 proudu a mohou interagovat mezi sebou nebo i s uživatelem. Soubor
těchto objektů v datovém proudu se nazývá scéna (scene graph) a lze jej reprezentovat pomocí binárního formátu BIFS (Binary Format for Scenes) nebo
vznikajícího textového formátu XMT (Extensible MPEG-4 Textual Format).
Jednotlivým datovým objektům, či proudům se říká elementární proudy (Elementary Streams) a jejich datová reprezentace je definována pomocí Object
Descriptor Framework (OD). Ten popisuje již výše zmíněné umístění objektu
ve scéně a jeho interakce. OD Framework taktéž definuje proud pro MPEG-J,
což jsou Java programy nazývané MPEGlets, a správce pro ochranu duševního
vlastnictví (Property Management and Protection DCMI) (Kim – Wood, 2006;
Wikipedia, 2007d).
Dále se budeme zabývat pouze částí MPEG-4 specifikace, kterou je 3D scéna,
konkrétně animace tváře, která má ve standardu samostatnou podporu.
2.6.4
Animace tváře s prostředky v MPEG-4
I když se rychlost počítačových sítí stále zvyšuje, existuje potřeba pro standard,
který by zajistil plynulou animaci tváře i v sítích s nízkou propustností, jako
12
Obrázek 2.3: MPEG-4 feature points
Identifikátor
1
2
3
4
5
6
7
8
9
10
Počet FAPs
2
16
12
8
4
5
3
10
4
4
Ovlivňuje
vizémy a výrazy
čelist, bradu, vnitřní ret, koutky a střed rtů
oční bulvy, zornice, výčka
obočí
tváře
jazyk
rotaci hlavy
vnější ret
nos
uši
Tabulka 2.1: Skupiny a příslušný počet FAP
jsou například mobilní telefony. Tento problém řeší MPEG-4 a nabízí nástroje
k animaci tváře a efektivní kompresi pro proud dat.
Technologie funguje tak, že nejprve přenese data potřebná pro konstrukci
trojrozměrného obrazu a poté už jen posílá vektor modifikací známých parametrů. Prostorový obraz je definovaný za pomocí Facial Definition Parameters
(FDP) a obsahuje geometrii lidské hlavy, texturu (obvykle fotku z čelního a bočního pohledu) a výchozí stav. Následuje vytvoření 3D scény, při které se mapují
textury a nastavuje výchozí stav. Po tomto kroku již stačí posílat pouze Facial
Animation Parameters (FAP) – parametry, které modifikují vytvořený model
v čase. Konečný obraz hlavy se tedy vizualizuje za pomoci klientského zařízení
a parametrů, což výrazně šetří přenosovým pásmem. Datový tok animačních
parametrů (FAP), lze navíc ještě komprimovat pomocí DCT a huffmanova kódování a tím zajistit další úsporu v přenesených datech.
Aby bylo možné pomocí časových značek s tváří pohybovat, musí být na
tváři známé kontrolní body (Feature Points), ty lze vidět na obrázku 2.3. Těchto
kontrolních bodů je celkem 84 a byly vybrány tak, aby pomocí nich bylo možné
co nejlépe reprezentovat jakýkoli výraz.
13
Kontrolních bodů je využíváno ve FAP, které stojí nad kontrolními body a
umožňují provádět různé animační akce. Každý FAP tedy specifikuje množinu
kontrolních bodů a jakým směrem se mají posunout vzhledem k neutrálnímu
výrazu. Konstrukce množiny možných FAP akcí byla zkonstruována na základě
studia výrazů, které lze rozpoznat a úzce se tedy vztahují k akcím svalů. FAP
se dělí do následujících skupin.
Hodnoty ve FAP nejsou specifikovány absolutně, ale jako poměr k určité
části obličeje. To přináší možnost aplikovat stejné FAP na různé obličeje se stejným efektem. Tato relativní jednotka je nazvána FAPU (Face Action Parameter
Unit) a standard jich specifikuje celkem šest.
Obrázek 2.4: MPEG-4 FAPU
Identifikátor
IRISD
ES
ENS
MNS
MW
AU
Název
průměr duhovky (iris diemeter)
vzdálenost očí (eye separation)
vzdálenost špičky nosu od roviny očí
(eye – nose separation)
vzdálenost špičky nosu od roviny úst
(mouth – nose separation)
šířka úst (mouth width)
úhlová jednotka
Základní j.
IRISD0/1024
ES0/1024
ENS0/1024
ENS0/1024
MNS0/1024
10−5 rad
Tabulka 2.2: MPEG-4 FAPU
Obdobný princip existuje i pro animaci lidského těla. Definiční parametry se
zde ale nazývají Body Definition Parameters (BDP) a animační parametry Body
Animation Parameters (BAP). Informace o MPEG-4 byly čerpány z (Tekalp –
Ostermann; [email protected]; Bitto).
2.6.5
MPEG-4 XMT formát
Extensible MPEG-4 Textual format (XMT) je specifikace umožňující textovou
reprezentaci scény formátu MPEG-4. Takto připravenou scénu lze přeložit do
různých formátů, jak je vidět na obrázku 2.5. Standardně je scéna popsaná
v MPEG-4, uložena v BIFS (Binary Format for Scenes), který je určen pro
14
Obrázek 2.5: XMT návaznost na ostatní technologie
distribuci již hotového obsahu. Binární formát přináší řadu nevýhod, jako nemožnost scénu jednoduše editovat, spolupracovat na scéně s více autory nebo
modifikovat už jednou vytvořenou scénu. Tyto všechny problémy odstraňuje
textový formát pro popis scény – XMT. Má zajistit integraci FDP a FAP na
SMIL nebo X3D/VRML. XMT je založený na XML a může mít dvě podoby:
XMT-A a XMT-Ω (XMT-O).
Formát XMT-A se snaží co nejblíže přiblížit BIFS a nabízí tedy prostředky
pro textovou reprezentaci všech vlastností a objektů, z kterých se BIFS skládá.
Popis scény pomocí BIFS má velmi blízko k X3D, a proto nástroje pracující
s X3D umí zpracovat i XMT.
Formát XMT-Ω je zaměřen hlavně na snadné použití autory a popisuje objekty a proudy na vyšší úrovni než XMT-A. Tento formát se snaží reprezentovat
scénu takovým způsobem, aby byl její zápis kompatibilní se SMIL. Informace
čerpány z (Kim – Wood, 2006).
2.6.6
Facial Action Coding System (FACS)
Facial Action Coding System (FACS) je ucelený přehled všech vizuálně rozpoznatelných pohybů tváře, založený na anatomickém zkoumání. FACS byl
publikovaný roku 1978 a navazuje na svého předchůdce Facial Affect Scoring
Technique (FAST) (Ekman et al., 1971) a jeho hlavním cílem je dát k dispozici prostředky pro popis výrazů tváře souvisejících s emocemi. Nicméně FACS
je vhodný i jako nástroj pro další odvětví vyžadující systém pro popis výrazů
tváře. Narozdíl od mnoha dalších pracovišť, která vyvíjela metody popisující
pouze určitou část výrazů, vztahujících se k jejich konkrétnímu výzkumu, se
FACS snaží být univerzální a je vybudován nezávisle na jekékoli interprataci
významu akčních jednotek (Ekman et al., 2002).
Za vývojem FACS stojí psychologové Paul Ekman a Wallace Friesen. FACS
se skládá z 64 tzv. Action Units (AU), což je nejzákladnější pohyb popsatelný
FACS, vyvolaný kontrakcí nebo relaxací jednoho nebo více svalů. Kombinací
těchto základních pohybů lze simulovat všechny pozorovatelné výrazy tváře. Na
pohyby tváře připadá 46 AU a ostatní jsou věnovány pohybům hlavy nebo očí.
Vybrané AU lze vidět v tabulce 2.3 a 2.4. Přehled AU převzat z (Wikipedia,
2007b).
Pomocí FACS lze tedy zaznamenat jakýkoli výraz tváře přiřazením intenzit
15
Č. AU
1
4
6
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
39
42
44
46
název
Inner Brow Raiser
Brow Lowerer
Cheek Raiser
Nose Wrinkler
Nasolabial Deepener
Cheek Puffer
Lip Corner Depressor
Chin Raiser
Tongue Out
Neck Tightener
Lip Tightener
Lips part
Mouth Stretch
Jaw Thrust
Jaw Clencher
Cheek Blow
Cheek Suck
Lip Wipe
Nostril Compressor
Slit
Squint
Wink
Č. AU
2
5
7
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
41
43
45
název
Outer Brow Raiser
Upper Lid Raiser
Lid Tightener
Upper Lip Raiser
Lip Corner Puller
Dimpler
Lower Lip Depressor
Lip Puckerer
Lip stretcher
Lip Funneler
Lip Pressor
Jaw Drop
Lip Suck
Jaw Sideways
Lip Bite
Cheek Puff
Tongue Bulge
Nostril Dilator
Lid droop
Eyes Closed
Blink
Tabulka 2.3: Přehled vybraných AU, používajících obličejové svaly (Wikipedia,
2007b; Ekman et al., 2002)
Č. AU
51
53
55
57
61
63
65
název
Head turn left
Head up
Head tilt left
Head forward
Eyes turn left
Eyes up
Walleye
Č. AU
52
54
56
58
62
64
66
název
Head turn right
Head down
Head tilt right
Head back
Eyes turn right
Eyes down
Cross-eye
Tabulka 2.4: Ostatní AU (Wikipedia, 2007b; Ekman et al., 2002)
k všem rozpoznaným, aktivním AU. Intenzity jsou obvykle označovány písmeny
od A, které znamená pouze náznak, až po E, které značí absolutní proveditelné
maximum. Akční jednotky označují pouze ustálenou podobu (apex), nikoli náběh (onset) nebo návrat do původní pozice (offset). Dále může být u akční
jednotky ještě rozlišováno, zda se jedná o její pravou (R), levou (L) nebo obojí
(Bi) realizaci.
U dětí je situace trošku jiná, protože ještě nemají dostatečně vyvinuté některé obličejové svaly jako dospělí. Některé AU tedy nedokáží realizovat (Corel
Corp., 2005?).
FACS je používán pro svojí ucelenost, která umožňuje zaznamenat téměř
16
jakýkoli výraz. Systém byl nedávno implementován ve filmovém průmyslu a byl
použit například ve filmu King Kong z roku 2005 (Wikipedia, 2007a).
2.6.7
Formáty pro uložení výrazu tváře
Většina formátů pro uložení výrazu tváře využívá XML. Je to dáno jeho rozšířením, které zajišťuje dostupnost parserů a také samopisnými vlastnostmi XML
formátu, zajišťující srozumitelnost.
Virtual Human Markup Language (VHML)
Virtual Human Markup Language si klade za cíl umožnit přirozenou interakci
mluvící hlavy nebo celé postavy, skrze webové stránky nebo aplikaci, s člověkem.
Návrh poslední specifikace jazyka pochází z roku 2001 a snaží se stavět na
stávajících standardech. Specifikace se skládá z následujících částí:
• EML Emotion Markup Language
• GML Gesture Markup Language
• SML Speech Markup Language (založeno na W3C SSML5 )
• FAML Facial Animation Markup Language
• BAML Body Animation Markup Language
• XHTML eXtensible HyperText Markup Language
• DMML Dialogue Manager Markup Language (založeno na W3C Dialogue
Manager6 nebo AIML7 )
Obrázek 2.6: Struktura jazyka VHML z jeho dílčích částí
Jak je vidět z přehledu VHML částí a z obrázku 2.6, je rozsah použití VHML
značně široký. Lze v něm zaznamenat emoce, gesta, prozodii a vysokoúrovňové
akce tváře a těla. Informace čerpány z (Gustavsson et al., 2001).
Ukázka VHML:
5 Speech
Synthesis Markup Language: http://www.w3.org/TR/speech-synthesis/
and Overview of W3C Speech Interface Framework: http://www.w3.org/TR/
voice-intro/
7 Artificial Intelligence Markup Language: http://en.wikipedia.org/wiki/AIML
6 Introduction
17
<vhml>
<person disposition="angry">
First I~speak with an angry voice and look very angry,
<surprised intensity="50">
but suddenly I~change to look more surprised.
</surprised>
</person>
</vhml>
Ukázka SML:
<sml>
<p>
<neutral>
Detectives investigating the brutal <emph_GST 2 4 1000/>
<r_roll 2 3 1000/> murder of Sarah Payne, have received
<hr 2 4 800/><nod 2 3 800/><r_roll 2 3 800/> two hundred fresh
calls from <hl 2 5 900/><l_roll 2 6 900/><emph_GST 2 7 900/>
the public.
This comes after <2b 2 9 700/> an appeal to locate a lorry
driver, who <hr 2 4 800/><r_roll 2 5 800/><nod 2 4 800/>
might have seen Sarah’s <hl 2 4 800/><l_roll 2 5 800/>
<nod 2 4 800/> killer.
</neutral>
</p>
</sml>
Face Modeling Language (FML)
Specifikace FML vznikla za přispění University of British Columbia a Simon
Fraser University. Jedná se o XML formát, který má postavit vysokoúrovňovou
abstrakci nad MPEG-4 Face Animation parameters (FAP). Ty jsou rozděleny
do následujících tří kategorií (což lze ověřit v tabulce 3.1):
• vizémy
• výrazy
• nízkoúrovňové pohyby
V FML jsou jsou vizémy zpřistupněny skrze <talk> element. FML procesor
konvertuje vstupní text na fonémy a vizémy kompatibilní s MPEG-4 standardem. FML výrazy tváře jsou opět nadefinovány tak, aby byly plně kompatibilní
s MPEG-4. Pro ostatní animační parametry tváře může být použit nízkoúrovňový FAP element.
Vzhledem k této kompatibilitě mohou být FML dokumenty snadno převedeny do MPEG-4 proudu dat, což dělá z FML kandidáta pro použití s MPEG-4
Textual Format (XMT) frameworkem.
18
Ukázka FML:
<fml>
<model> 
<model-info-item>
</model>
<story> 
<act>
<time-container>
<move-item>
<...>
</time-container>
<...>
</act>
<...>
</story>
</fml>
Základní myšlenky FML jsou:
• Reprezentovat animaci tváře hierarchickým způsobem
• Definovat časové okamžiky interakcí mezi akcí tváře a vnějšími událostmi
• Definovat možnosti a vzory chování
• Zachovat kompatibilitu s MPEG-4 XMT a FAP
• Zachovat kompatibilitu s XML a souvisejícími webovými technologiemi
Informace o FML byly čerpány z (iMediaTek, 2005).
19
2.7
ArtiSynth
ArtiSynth je framework vyvíjený na kanadské univerzitě UBC sloužící primárně
pro vývoj a testování přístupů související s artikulační syntézou. Jeho dlouhodobým cílem je umožnit vývoj artikulačního syntetizéru, který by produkoval
přirozeně znějící řeč. ArtiSynth framework by měl posloužit výzkumným pracovištím sdílet a testovat své modely bez přílišné námahy na vývoj vlastní kostry
aplikací (Fels et al., 2005). ArtiSynth je živý projekt, který vznikl zřejmě v roce
2005 a na kterém v současnosti pracuje kolem sedmi hlavních vývojářů a dále
množství pracovišť z celého světa, které jej využívají jako platformu pro testování vlastních přístupů.
ArtiSynth umožňuje nejen zvukový výstup a prostorovou vizualizaci, ale
dává vývojářům k dispozici poměrně širokou paletu již hotových numerických
metod potřebných pro simulaci dynamických modelů a dalších používaných výpočtů. Vývojář se tedy může více soustředit na svůj problém a nemusí se zabývat
implementací základní funkcionality.
Obrázek 2.7: ArtiSynth
Grafické uživatelské rozhraní ArtiSynthu je vytvořeno ve Swingu a o 3D
výstup se stará OpenGL, ke kterému je z Javy přistupováno pomocí knihovny
JOGL, využívající Java Native Interface (JNI). ArtiSynth dále obsahuje nativní
knihovny pro numerické a maticové výpočty a možnost spouštět Python skripty
za pomocí Python implementace Jython.
Na obrázku 2.7 můžeme vidět základní strukturu uspořádání komponent
ArtiSynthu. Jádro, na které jsou navázány všechny ostatní komponenty je tvořeno simulátorem – plánovačem, o kterém bude řeč v samostatné kapitole. Blok
„Numericsÿ představuje hotové třídy a nativní knihovny, které lze z prostředí
ArtiSynthu používat pro numerické výpočty. Blok „Resultsÿ znázorňuje možnost exportu výsledků do souboru. Bloky „Audioÿ, „Render Audioÿ a „Render
Graphicsÿ představují zvukové, respektive grafické výstupy. Zvukový výstup využívá knihovnu JASS8 a grafický knihovnu JOGL, o které ještě bude řeč. Část
obrázku označená jako „Workspace/GUIÿ představuje grafické uživatelské rozhraní a o něm bude také řeč dále. Další informace o ArtiSynthu lze nalézt na
stránkách www.artisynth.org.
8 Java
Audio Synthesis System: http://www.cs.ubc.ca/spider/kvdoel/jass/
20
2.7.1
Java
ArtiSynth je napsaný v jazyce Java. Jedná se o objektový jazyk vyvíjený firmou
Sun Microsystems. Dnes patří k velice populárním jazykům hlavně v serverových
aplikacích, ale čím dál více se začíná objevovat i v desktopových RCP aplikacích.
Svou syntaxí je podobný jazyku C++ s několika zjednodušeními.
Mezi hlavní přednosti Javy patří její přenositelnost, robustnost, obsáhlá
knihovna předpřipravených tříd pojmenovaná Java Foundation Classes (JFC),
bezpečnost a multithreading.
Přenositelnost Javy znamená, že je možné jednou zkompilovaný program
spouštět na všech počítačích a operačních systémech, které obsahují běhové
prostředí Javy, tzv. Java Runtime (JRE). To je zajištěno kompilací ne přímo do
nativního kódu dané platformy, ale do pseudokódu nazvaného Java byte code,
který je určen pro spouštění v JRE. Tento fakt má krom pozitiv také negativum
způsobené sníženou výkonností. Ta je dnes představována hlavně časem potřebným pro spuštění běhového prostředí (JRE). Samotný vykonávaný kód je již
posléze ve většině běhových prostředí zkompilován Just in Time compilerem do
nativní podoby a běží tedy stejně rychle jako nativní aplikace. Princip je tedy
stejný jako u platformy .NET. Jinou otázku je grafické uživatelské rozhraní vytvořené pomocí Swingu nebo AWT. Tyto technologie jsou velmi propracované a
součástí Javy, ale protože grafické objekty Javy (widgets) nepoužívají systémové
grafické objekty, jsou pomalejší.
Pokud je z nějakého důvodu potřeba volat nativní funkce nebo knihovny
z Javy, je to možné za použití technologie Java Native Interface (JNI).
Předpřipravené třídy Javy (JFC), které jsou k dispozici ve všech běhových
prostředích, jsou rozděleny do mnoha balíků a obsahují implementaci téměř
všech základních algoritmů, které programátor běžně využívá. Jedná se o přístup
k I/O rozhraním, k síti, třídy potřebné pro práci s kolekcemi, kryptografické
nástroje, databázová rozhraní, XML parsery, třídy pro práci s textem, obrázky,
zvukem, různé pomocné třídy a balíky pro tvorbu GUI – Swing a AWT.
Kromě standardních JFC je možné získat další rozšíření většinou určené pro
konkrétní použití. Například J2EE pro vývoj Java Enterprise aplikací, J2ME
pro vývoj mobilních aplikací a mnohá další.
Java se snažila vždy řešit i problém nasazení (deploy) aplikací a proto obsahuje technologie jako Java Archive (JAR), který umožňuje zabalit celou Java
aplikaci do jediného souboru s příponou .jar a ten dále distribuovat. Další technologií usnadňující nasazení aplikací jsou, dříve velice oblíbené, Java applety.
Jednoduchost tohoto nasazení se měla rovnat nasazení webových stránek, ale situaci komplikovaly různé verze Javy na počítačích uživatelů. Java applety byly
taktéž omezené co do přístupu k systémovým prostředkům počítače. Běhové
prostředí pro Java applety je proto označováno jako sandbox. Nejnovější technologií pro nasazování aplikací je Java Web Start (JWS), které řeší všechny
nevýhody appletů a umožňuje pomocí jednoho kliknutí spustit plnohodnotnou
Java aplikaci.
Dalším specifickým rysem Javy je její automatická zpráva paměti. Java tedy
obsahuje stejně jako většina dnešních objektově orientovaných jazyků tzv. garbage collector, který z paměti automaticky odstraňuje objekty, na které neexistují reference. Tato procedura je výpočetně náročná a proto nevhodná konfigurace garbe collectoru může aplikaci zbytečně brzdit.
21
2.7.2
Simulační jádro
ArtiSynth jako program umožňující simulaci dynamických modelů, které mezi
sebou mohou navzájem interagovat, obsahuje simulační jádro tvořené plánovačem. Ten může obsluhovat řadu modelů, které spolu mohou komunikovat a
vytvářet závislosti. Model je třída implementující specifické rozhraní, s kterým
může následně pracovat plánovač. Pro usnadnění práce jsou tato rozhraní již
implementována abstraktní třídou, kterou stačí oddědit a překrýt jen potřebné
metody. Pro standardní model je vhodné oddědit třídu ModelBase.
Obrázek 2.8: UML diagram s rozhraními modelů
V modelu je třeba překrýt metodu advance(), kterou volá plánovač a pokud
chceme realizovat nějaký grafický výstup, tak potom taktéž metodu render().
Třída dědící od ModelBase ale není samostatně spustitelná jako hlavní model
v plánovači. Aby bylo možné model či skupinu modelů spustit a simulovat, je
nutné vytvořit ještě jeden zastřešující model, do kterého vložíme ostatní modely
a který je následně celý spuštěn simulačním jádrem. Taková třída musí dědit od
abstraktní třídy RootModel.
Na třídě dědící od RootModelu je možné nastavit omezení mezi jednotlivými modely simulace. Dále je možné překrýt metody attach() a detach() a
zobrazit uživateli vlastní grafické ovládání modelu.
2.7.3
Java API for OpenGL binding (JOGL)
Knihovna JOGL tvoří nedílnou součást ArtiSynthu a zajišťuje hardwarově akcelerované vykreslování 3D grafiky. Knihovna je vyvíjena a udržována Game
Technology Group, která spadá pod Sun Microsystems. Knihovna implementuje JSR-231 (Java Community Request) se jménem Java Bindings for OpenGL
API. To je tvořeno obálkou nad nativními OpenGL knihovnami, ke kterým lze
s použitím této knihovny přímo přistupovat. Od verze Java SE 6.0, je možné
používat JOGL spolu s Java2D a využít možnosti 3D v jakékoli Swing kom-
22
ponentě. Vývojář zvyklý pracovat s OpenGL se bude hned orientovat, protože
veškeré pojmenování zůstalo a zůstal i procedurální koncept. V ArtiSynthu byla
použita verze JOGL 1.0.0. Distribuce obsahovala i nativní knihovny pro různé
operační systémy.
Alternativu k JOGL tvoří Lightweight Java Game Library (LWJG). Narozdíl
od JOGL, zahrnuje LWJG podporu také pro zvuk (OpenAL) a herní zařízení.
2.7.4
Probes
Probes, nebo-li sondy, je mechanismus ArtiSynthu pro čtení a zápis proudu dat,
kterými je model řízen, respektive které model produkuje. Sondy tedy umožňují
buď číst nebo zapisovat časově závislá data. Tato data (samply, uzly – knots) ale
nejsou spojitá a z toho důvodu sonda zajišťuje jejich interpolaci. Typ interpolace
lze vybrat ze tří již připravených – skokovou, lineární a kubickou. Sondy lze
vizualizovat v uživatelském rozhraní, což uživateli umožní interaktivně měnit
její parametry.
Obrázek 2.9: UML diagram sond
Údaje ze sondy se vizualizují v okně s časovou osou, jak lze vidět na obrázku
2.10 vpravo. Každá sonda je aktivní jen ve specifickém časovém úseku a údaj
začátku a konce je tedy jedním z jejich základních parametrů. Při vizualizaci
se zobrazí jednotlivé uzly čtverečkem a tenkou čárou mezi nimi je znázorněna
interpolace.
Aby sonda mohla data zobrazovat, je nutné navázat ji na konkrétní parametr určitého modelu. Tímto navázáním řekneme, že chceme, aby byl sondou
parametr modelu řízen nebo čten. Jedna sonda může řídit nebo číst jeden nebo
více parametrů.
Na obrázku 2.9 lze vidět hierarchii sond a využití dědičnosti Nejdůležitější
třídy jsou NumericInputProbe a NumericOutputProbe, které se dají použít pro
zobrazení vstupních, respektive výstupních numerických dat z modelu. Další
informace lze najít v dokumentaci ve verzovacím systému ArtiSynthu.
2.7.5
Uživatelské rozhraní
Uživatelské rozhraní ArtiSynthu se skládá ze dvou částí. Jednou je okno zobrazující pohled na 3D scénu a druhou částí je časová osa. Kromě těchto dvou
oken, lze zobrazit u každého modelu navíc okno vlastní, o jehož vzhled se stará
tvůrce modelu a může pomocí něj poskytnout speciální ovládácí prvky.
23
Okno s OpenGL výstupem představuje hlavní ovládací prvek, který po zavření ukončí celý program. V tomto okně, které lze vidět na obrázku 2.10, lze
provádět základní operace jako je načtení modelu nebo dat a dále lze se zobrazeným modelem interaktivně manipulovat. Otáčet, zvětšovat, případně pokud
to model podporuje, tak přímo měnit jeho specifické vlatnosti, po kliknutí na
nějakou jeho aktivní část.
Okno s časovou osou obsahuje ovládací prvky, pomocí kterých lze spustit
nebo zastavit simulaci a dále obsahuje seznam stop (tracks), které představují
sondy (probes) v modelu. Sona může zobrazovat buď vstupní data, která za běhu
mění parametry modelu, nebo výstupní data, která model za běhu generuje. Oba
dva případy lze vidět na obrázku 2.10 vpravo.
Obrázek 2.10: ArtiSynth GUI; vlevo OpenGL výstup; vpravo: časová osa se
zobrazenou vstupní (nahoře) a výstupní sondou
24
Kapitola 3
Realizace mluvící hlavy
3.1
3.1.1
Použité algoritmy
Modelování koartikulace
Velká část systémů pro vizuální syntézu mluvené řeči se musí potýkat s problémem, jak do sebe prolnout jednotlivé stavy, které reprezentují daný foném nebo
vizém v jeho konečné podobě. Vizémem (z anglického „vizemeÿ) označujeme
jednotlivé rozlišitelné unikátní nastavení artikulačních orgánů tváře. Vizém je
tedy viditelná jednotka řeči, stejně jako je foném slyšitelná jednotka řeči.
Koartikulace je vzájemné ovlivňování hlásek v jejich spojité promluvě. Hlásky
se mohou ovlivňovat až tak, že některé zaniknou. V promluvě se tak děje často
u souhlásek, které jsou výrazně ovlivněny nebo úplně potlačeny samohláskami.
Koartikulace je složitý proces, který se algoritmicky těžko postihuje. Záleží
totiž na mnoha faktorech, jakým je např. pravý a levý kontext, který může
ovlivňovat cílovou hlásku i několik hlásek nazpět nebo naopak dopředu. Dále na
jazyku, do které promluva spadá. Každý jazyk má své specifické charakteristiky,
kterými se odlišuje od ostatních. V některých jazycích se například projevuje
výrazněji pravý nebo naopak levý kontext (Cohen – Massaro, 1993, s. 4). Dalším problémem je, že neexistuje univerzální návod pro správnou koartikulaci.
Záleží také velice na rychlosti promluvy. Dále bude popsána metoda výpočtu
koartikulace, kterou vyvinuli Cohen – Massaro (1993).
Metoda spočívá v dopočítání průběhu cílového nastavení daného fonému
v závislosti na čase, pravém a levém kontextu a na několika parametrech, které
musí být správně natrénovány. Cílovým stavem (target) se myslí poloha bodu
nebo bodů tváře v prostoru, který může být dán například fonémem uloženým
v databázi. Metoda s použitím parametrů α, Θ+ a Θ− potom dopočítá tzv. dominanci, což je vlastně číslo, které říká, jak moc se cílový stav projeví. Grafický
průběh lze vidět na obrázku 3.1.
V našem případě modelu mluvící hlavy, je cílový stav (target) představován
násobičem hlavních komponent (bude vysvětleno později). Pro každý násobič
v každé sekci je tedy tedy spočítána dominance. Pokud stav představuje foném,
musí tedy obsahovat navíc u každé hlavní komponenty všechny parametry potřebné pro výpočet. Těmito parametry jsou Θ− , Θ+ , které udávají ovlivnění dominance zpětnými, respektive dopřednými hláskami, a parametr α, který udává
velikost ovlivnění.
25
KAPITOLA 3. REALIZACE MLUVÍCÍ HLAVY
Obrázek 3.1: Ukázka výstupu při změně parametru Θ. Na horním grafu je vidět průběh dominance pro dvě realizace cíle, které jsou vidět na dolním grafu.
Obrázek převzat z (Cohen – Massaro, 1993)
Vzorce pro výpočet dominance, převzaté z (Cohen – Massaro, 1993, s. 2). Vzorec
pro výpočet dominance pro τ ≥ 0
Dsp = αsp e−Θsp− |τ |
Vzorec pro výpočet dominance pro τ < 0
Dsp = αsp e−Θsp+ |τ |
Vzorec pro výpočet τ
τ = tc
sp
+ t0
sp
−t
t označuje čas, t0 sp je offset vzhledem ke středu segmentu s, který má mít
maximální dominanci. Vzorec pro výpočet tc sp , označující střed segmentu
durations
(3.1)
2
Vzorec pro výpočet výsledného stavu pomocí váženého průměru přes všechny
parametry
tc
sp
= tstart s +
PN
Fp (t) =
3.1.2
s=1 (Dsp (t) × Tsp )
PN
s=1 Dsp (t)
(3.2)
Stav modelu a analýza hlavních komponent
Stav tváře byl navržen tak, aby se dal reprezentovat co nejmenším objemem
informací a přitom byla zachována možnost dobře aproximovat všechny možné
výrazy. Pro tento účel byla tvář rozdělena na jednotlivé části nazvané sekce. Na
každou sekci poté byla aplikována analýza hlavních komponent1 (PCA). Tímto
1 Úvod
do PCA lze nelézt v (Lindsay – Smith, 2002)
26
způsobem bylo dosaženo plně nezávislého pohybu různých částí tváře. Redukované hodnoty stavu dále budeme nazývat jako násobiče hlavních komponent
(PC násobiče). Označení pochází z anglického „PC multipliersÿ.
Každá sekce byla reprezentována množinou bodů v prostoru, které byly vybrány tak, aby pomocí nich bylo možné simulovat co největší škálu pohybů
(Krnoul – Zelezny, 2004). Tyto odpovídaly svým umístěním některému místu
na povrchu tváře. Na hlavě byly zvoleny následující sekce: rty, brada, jazyk, oči
a obočí. Pro každou sekci byl vybrán z PCA různý počet hlavních komponent.
Obrázek 3.2: Přehled kontrolních bodů modelu a obrázek 3D sítě.
Sekce
lips
chin
tongue
eyes
brows
Kontrolní body
lipsCornerLeft, lipsCornerRight,
upperLipMiddle, upperLipLeft,
upperLipRight, lowerLipMiddle,
lowerLipLeft, lowerLipRight
chin
tongueRoot, tongueMid, tongueTip
leftLid1, leftLid2, leftLid3, leftLid4, rightLid1,
rightLid2, rightLid3, rightLid4
leftBrow1, leftBrow2, leftBrow3, rightBrow1,
rightBrow2, rightBrow3
Bodů
8
Počet PC
3
1
3
8
1
3
2
6
2
Tabulka 3.1: Přehled sekcí, jejich bodů a počet hlavních komponent (PC)
V tomto návrhu odpovídaly body z každé sekce jednomu splinu. Není to ale
podmínkou a je možné vytvořit sekce se sdílenými body atp. Všechny spliny,
které interpolují body z dané sekce lze vidět na obrázku 3.2.
Data a provedená PCA analýza, byla získána z oddělení umělé inteligence
na katedře kybernetiky. PCA redukuje naměřená data takovým způsobem, aby
27
zachovala jen složky s největší variancí. Pro dobré fungování metody je tedy
třeba mít dostatečné množství kvalitních dat.
3.1.3
Interpolační algoritmus
Pro realističtější ovlivnění husté 3D sítě, bylo nutné kontrolní body interpolovat
křivkou, která by poté sama zajišťovala ovlivnění geometrie. Interpolaci kontrolních bodů je možné vidět na obrázku 3.2. Bylo nutné vybrat takovou metodu,
která by procházela zadanými body a dávala pěkné výsledky. Těmto kritériím
odpovídá kubický spline, který zajišťuje plynulost C 2 . To znamená, že první
dvě derivace této křivky jsou spojité funkce. Kromě kubického splinu existuje
množství dalších modifikací. Například b-spline, který ovšem neprochází zadanými body a místo toho je využívá jako řídící body. Podobně fungují i NURBS
křivky, které se dnes v počítačové grafice hojně používají.
Spline je křivka, skládající se z množiny polynomů třetího stupně. Pro nalezení koeficientů těchto polynomů, je třeba řešit soustavu lineárních rovnic, jejíž
předpis je ve vzorci 3.5. Obecný předpis polynumu lze vidět ve vzorci 3.6. V případě kubického splinu leží polynom vždy mezi dvěma interpolovanými body.
V těchto bodech začíná a končí a první a druhé derivace končícího a začínajícího polynomu si je rovna. Zde uvedený postup výpočtu je založen na algoritmu,
popsaném v (Prykryl – Brandner, 2000, s. 45). Další informace o spline křivkách
lze najít například v (Zara et al., 2004, s. 193).
Vstup do algoritmu tvoří jednotlivé body f (xi ), i = 0, . . . , N , které chceme
interpolovat a které mohou být vektory obecně v n-dimenzionálním prostoru.
Prvním krokem je spočítání vektoru vzdáleností všech bodů v prostoru – tedy
euklidovy vzdáleností mezi sousedními body.
Euklidova vzdálenost sousedících bodů:
hi =
q
0
(f (xi+1 ) − f (xi )) × (f (xi+1 ) − f (xi )) ,
i = 0, 1, . . . N
(3.3)
Dále spočítáme vzdálenosti od prvního bodu. Tyto vzdálenosti tvoří jakousi imaginární osu x. Můžeme tedy psát f (xi ) = f (bi ), protože xi neznáme. Označení
písmenem b, pochází z anglického breaks.
b0 = 0
bi = bi−1 + hi−1 ,
i = 1, 2, . . . N
Spočtení parametrů pro soustavu rovnic 3.5
hi−1
hi−1 + hi
= 1 − λi−1
λi−1 =
µi−1
gi−1 =
6
hi−1 + hi
f (xi+1 ) − f (xi ) f (xi ) − f (xi−1 )
−
hi
hi−1
28
,
i = 1, . . . , N − 1
Dále je nutné nastavit počáteční podmínky podle toho, zda je spline uzavřený nebo otevřený. Pokud je otevřený, položíme druhé derivace rovné nule a
dostáváme přirozený spline. Pokud je uzavřený, musíme zajistit, aby byl přechod plynulý a upravit příslušné koeficient M0 , M1 a g1 , gN −1 . Přechod bude
plynulý, pokud si budou odpovídat druhé diference v počátečním a koncovém
bodě. Druhou diferenci lze spočítat podle (Prykryl – Brandner, 2000, s. 122).
f (x + h) − 2f (x) + f (x − h)
h2
A určíme počáteční podmínky
f 00 (x) =
(3.4)
M0 = f000
00
M N = fN
g1 = g1 − λ1 f000
00
gN −1 = gN −1 − µN −1 fN
Sestavíme soustavu lineárních rovnic







2M1
λ2 M1
..
.

µ1 M2
2M2
µ2 M3
..
..
.
λN −2 MN −3
.
2MN −2
λN −1 MN −2
µN −2 MN −1
2MN −1

g1
g2
..
.
 
 
 
=
 
  gN −2
gN −1







(3.5)
A vyřešíme soustavu rovnic. Lze ji řešit optimalizovaným algoritmem, protože
se jedná o pásovou matici. Pomocí získaných M0 , . . . MN vypočítáme koeficienty
pro polynomy, které jsou ve tvaru
ϕi (x) = ai + bi (x − xi ) + ci (x − xi )2 + di (x − xi )3
(3.6)
ai = f (xi )
f (xi+1 ) − f (xi ) 2Mi + Mi+1
hi
−
hi
6
ci = 0.5Mi
Mi+1 − Mi
di =
6hi
bi =
Nyní máme, pro každý úsek mezi vstupními body, k dispozcici jeden polynom se známými parametry a je možné interpolovat požadovaná data. Pro
interpolovaný bod je jen nutné najít vhodný polynom. K tomu lze užít vektor
b, kde jsou uloženy vzdálenosti kontrolních bodů. Vybereme takový polynom,
do jehož intervalu interpolovaný bod patří.
29
3.2
Provedená vylepšení ArtiSynthu
Kromě drobných oprav chyb, bylo do ArtiSynthu při práci na modelu přidáno
několik nových částí. Jednalo se vždy o obecnější záležitosti, ze kterých mohou
těžit ostatní vývojáři. Konkrétně se jedná o integraci sestavovacího systému Ant,
implementaci numerického algoritmu pro výpočet n-dimenzionálních splinů a
vytvoření balíčku pro čtení a zápis prostorových dat.
3.2.1
Sestavovací systém Apache Ant
ArtiSynth si klade za cíl být multiplatformní nástroj, ale přesto využíval k sestavování projektu pouze příkazu make, který je běžně dostupný jen na operačním
systému GNU/Linux. Kromě toho nebylo možné pomocí make vytvořit standardní balík pro distribuci v Java archive (.jar) formátu. To mělo zase za
následek, že bylo spuštění hotového programu na novém počítači zdlouhavější a
nebylo možné použít technologie jako Java Web Start, jejíž použití se již plánuje.
Apache Ant je standardní a uznávaný sestavovací nástroj pro Javu, který je
volně šiřitelný a spravovaný Apache Software Foundation. Samotný Apache Ant
je napsaný v Jave a je tudíž přenositelný na všechny platformy, pro které existuje
běhové prostředí Javy. Ant je také možné dále rozšiřovat o vlastní funkcionalitu.
Pro integraci Antu do ArtiSynthu bylo zapotřebí napsat soubor, popisující požadovaný sestavovací proces, který je standardně nazýván build.xml. Soubor
se skládá z jednotlivých cílů (targets), které lze z vnějšku spouštět. Pro účely
ArtiSynthu bylo vytvořeno šest standardních cílů: clean, compile, distrib,
help, jar a javadoc. Nejkomplexnější cíl distrib v sobě zahrnuje všechny
ostatní kroky. Nejdříve se vyčistí všechny soubory, které mohly zůstat z minulého sestavování, následně se celý ArtiSynth zkompiluje a zabalí do Java archivu
a vygeneruje se dokumentace s pomocí Javadocu. Nakonec se .jar soubor i dokumentace zabalí do zip souboru a distribuce je tím připravena.
Další vlastností Antu, je možnost konfigurovat průběh sestavování pomocí
nastavení, uvedených ve zvláštním souboru. Těch může být několik, ale základní
se standardně nazývá build.properties. Soubor je ve standardním formátu,
jaký je používán pro ResourceBundly2 . Každý řádek tedy obsahuje vlastnost
a její hodnotu. Tímto způsobem lze například jednoduše změnit verzi nebo
používané knihovny a není třeba procházet mnohem delší a složitější build.xml.
Výhoda těchto „propertiesÿ souborů spočívá také v jejich možnosti překrývání, respektive spíše nepřekrývání. Vlastnost, která je jednou nadefinovaná,
si udrží svojí hodnotu, i kdyby existovala v dalších konfiguračních souborech.
Toho bylo využito pro definici cesty ke knihovnám. Ve verzovacím systému byl
vytvořen obecný „propertiesÿ soubor s hodnotami jako verze, název programu a
dalšími. Pokud chce vývojář testovat chování při změně těchto výchozích parametrů, měl by si vytvořit soubor build-dev.properties. V něm může překrýt
jakoukoli vlastnost z build.properties a tato se projeví při sestavování, protože v build.xml je soubor s konfigurací vývojáře načítán jako první. Pro správnou funkci sestavování by si každý vývojář měl překrýt proměnnou libraries
a zadefinovat do ní správně cestu ke všem potřebným knihovnám.
2 ResourceBundle je označení standardního souboru s lokalizací. Více na http://java.sun.
com/docs/books/tutorial/i18n/resbundle/propfile.html
30
3.2.2
Implementace algoritmu pro výpočet splajnu
Protože ArtiSynth neobsahoval numerický algoritmus pro výpočet interpolace
pomocí n-dimenzionálního splajnu, byl tento algoritmus implementován do balíčku artisynth.core.numerics. Požadavkem na implementaci byla rychlost a
obecná použitelnost v celém ArtiSynthu. UML diagram třídy s veřejnými metodami, lze vidět na obrázku 3.3.
Obrázek 3.3: UML diagram třídy řešící výpočet n-dimenzionálního splinu
Objekt, který realizuje výpočet splinu je třeba nejdříve naplnit daty, které se
mají interpolovat. K tomu lze použít přetížené metody setInputData(). Data
mohou být n-dimenzionální a zadávají se standardně jako pole polí, kde první
index značí index pole, které obsahuje souřadnice bodu. Data jsou tedy tvořena
jednotlivými body (knots), přes které se má interpolovat. Po nastavení vstupních
dat je nutné provést výpočet parametrů rovnic pro interpolaci pomocí metody
recompute(). Tento výpočet stačí provést jednou pro zadaná data a poté je
možné interpolovat jakékoli množství bodů pomocí interpolate() metod.
3.2.3
Balíček pro čtení a zápis prostorových dat
Při tvorbě modelu hlavy bylo nutné načítat geometrická data z X3D formátu.
Datová struktura, do které měla být načtená geometrická data nahrána byla součástí ArtiSynthu, a proto bylo vhodné vytvořit jeho rozšíření, které by geometrickou datovou strukturu bylo schopné naplnit z jakéhokoli datového formátu.
Po diskuzi vznikl balíček maspack.geometry.io, který funkcionalitu zajišťuje pomocí rozhraní. Ty lze vidět na obázku 3.4. Návrh logiky fungování byl proveden
tak, aby byl jednoduchý a snadno rozšiřitelný o další formáty. Při konstrukci
byl využit vzor továrna (Bloch, 2002; Wikipedia, 2007c).
Balíček se skládá z výčtu formátů, které jsou podporovány (GeometryFileFormat), dále z rozhraní specifikující metody pro načítání (PolygonalMeshReader) a ukládání (PolygonalMeshWriter) a nakonec z továren (PolygonalMeshWriterFactory, PolygonalMeshReaderFactory), která vytváří instance rozhraní (čtečku nebo zapisovač) pro daný formát.
Pro účely modelu hlavy byla provedena implementace jen pro čtení formátu
X3D s omezenou funkčností. Formát X3D je totiž poměrně komplikovaný a im31
Obrázek 3.4: UML diagram tříd pro balíček maspack.geometry.io
plementovat všechny jeho vlastnosti by si vyžádalo mnoho času. Změny by totiž
bylo nutné provést i v používaných a sdílených částech ArtiSynthu, na kterých
jsou závislé ostatní modely. Jedná se hlavně o možnost reprezentovat hierarchickou geometrii. Úpravy ArtiSynthu, které by toto měly zajistit se plánují do
budoucna.
3.3
Konfigurační soubory a vstupní data
Vstupní data pro model mluvící hlavy jsou tvořeny pěti soubory. Jedná se o geometrii modelu hlavy ve formátu X3D a o další čtyři XML soubory s konfigurací
kontrolních bodů, PCA, kontrolních objektů a stavů.
Vrstva starající se o konfiguraci mluvící hlavy byla navržena tak, aby se při
změně konfiguračních souborů, nemuselo zasahovat do samotné logiky mluvící
hlavy. Pro tento účel byl vytvořen objekt Context (kontext), který využívá návrhový vzor jedináček (singleton) (Bloch, 2002) a funguje jako prostředník mezi
objekty s aplikační logikou mluvící hlavy a konfiguračními soubory.
Jako úložný formát pro konfigurační soubory byl zvolen XML a to ze dvou
důvodů. Jednak kvůli své samopopisné schopnosti a jednak kvůli univerzálnosti.
V budoucnu se tedy mohou stejné konfigurační soubory použít bez problémů
v jiné aplikaci.
Při navrhování struktury souborů jsem se snažil udělat soubory dostatečně
obecné a vyhnout se tak nutným úpravám v budoucnu. Soubory z části odpovídají datovým strukturám v programu, ale to je jen souhra náhod a ne záměr.
Při jejich načítání se neplní datové struktury přímo, ale procházejí konfigurační
vrstvou, kde jsou z konfiguračních dat tyto objekty sestavovány.
Pro všechny vlastní konfigurační soubory byla vytvořena XSD schémata3 pro
zajištění konzistence a před samotným načtením dat se provádí nejprve jejich
3 XSD (XML Schema Definition) je instance XML Schematu, definujícího omezení na strukturu a data ukládaná do XML. Jazyk XML Schema je specifikovaný World Wide Web Consorciem a disponuje silnějšími možnostmi, než starší DTD (Document Type Definition). Další
informace lze najít na http://www.w3.org/XML/Schema
32
Obrázek 3.5: UML diagram tříd znázorňující konfigurační logiku
validace. XSD soubory jsou obsaženy ve zdrojových kódech ArtiSynthu.
3.3.1
3D model
Pro uložení prostorových dat modelu hlavy byl zvolen formát X3D. Zejména
kvůli své otevřenosti a tedy snadné dostupnosti. X3D je standard pro ukládání
3D modelů vyvíjený Web3d konsorciem. X3D je nástupcem známého VRML97
a pro uložení dat lze mimo jiné použít XML. Web3d konsorcium doporučuje
používat X3D namísto VRML97.
Ve starší verzi mluvící hlavy byl model uložen ve VRML97 a tak bylo nutné
provést konverzi. Ta byla provedena pomocí konvertoru Vrml97ToX3dNist4 , vyvinutého v NIST.
3D model uložený v XML souboru ve formátu X3D musí obsahovat šest
prostorových objektů a dále informace o mapování textur. Objekty musí být
pojmenovány podle předem dohodnutých pravidel, aby na ně z programu bylo
možné přistupovat a dále s nimi pracovat.
Geometrie objektu je ve formátu X3D uložena za pomocí dvou struktur.
Pole vrcholů – 3D bodů a pole trojůhelníků, které jsou z těchto vrcholů tvořeny.
Každý trojúhelník v poli obsahuje tři indexy do pole 3D bodů, které tvoří jeho
vrcholy.
Každý X3D objekt má navíc přiřazen materiál, který udává vlastnosti jako
barvu odraženého světla, intenzitu nesměrového globálního osvětlení, intenzitu a
barvu odlesku a průhlednost. Kromě vlastností materiálu může definice objektu
obsahovat informace o textuře a jejího UV mapování. Mapovací informace přiřazují každému vrcholu objektu určitý bod na 2D obrázku. Textura pro použití
v OpenGL musí být čtvercová a délka její strany v pixelech musí být mocni4 http://ovrt.nist.gov/v2_x3d.html
33
Název
tvář
levé oko
pravé oko
jazyk
dolní patro zubů
horní patro zubů
označení
face
lefteye
righteye
tongue
lowerteeth
upperteeth
Tabulka 3.2: Přehled nutných objektů v X3D
nou dvou. Pro určení pozice bodu při UV mapování se nepoužívá souřadnice
vyjádřená v pixelech, ale hrana textury se vždy normuje na délku jedna. Tímto
způsobem se dají jednoduše vyměňovat různě detailní textury a mapování zůstane zachováno.
3.3.2
Kontrolní body
Nejjednodušším konfiguračním souborem je soubor s množinou kontrolních bodů.
Kontrolní body jsou prostorové souřadnice, ke kterým je přiřazen název. Na
tento název se pak odkazuji v ostatních konfiguračních souborech.
Každý kontrolní bod koresponduje s konkrétním místem na povrchu modelu
hlavy. Pro mluvící hlavu bylo nadefinováno 28 kontrolních bodů, umístěných
na přesně určených místech modelu hlavy. Z 28mi bodů připadá 8 na rty, 3 na
bradu, 3 na jazyk, 4 na každé oko a 3 na každé obočí. Přehled lze vidět v tabulce
3.1.
Ukázka ze souboru kontrolních bodů control-points.xml:
<controlPoints>
<point name="lipsCornerLeft">-0.02513 -0.005987 0.1064</point>
<point name="lipsCornerRight">0.02286 -0.005619 0.1063</point>
</controlPoints>
3.3.3
PCA
Konfigurační soubor pro PCA obsahuje transformační matice pro všechny sekce,
na které byla PCA použita. Navíc obsahuje informaci o mapování výsledků
transformace na konkrétní kontrolní body. Každá sekce odpovídá určité množině
kontrolních bodů, na které bylo rozumné PCA aplikovat.
Ukázka ze souboru mapování PCA pca-mapping.xml:
<pca-point-mapping>
<section name="tongue">
<transformMatrix>
0.22 0.33 0.835;
0.47 0.85 -0.37;
.
.
.
34
</transformMatrix>
<mapping>
<point name="tongueRoot" />
<point name="tongueMid" />
<point name="tongueTip" />
</mapping>
</section>
</pca-point-mapping>
3.3.4
Kontrolní objekty
Soubor s definicí kontrolních objektů definuje pro každý kontrolní objekt sadu
parametrů, která se v modelu využívá. Těmito parametry jsou název a typ
objektu, zóna ovlivnění, zóna exkluzivního ovlivnění, počet interpolačních bodů,
3D objekty které se mají ovlivňovat a seznam kontrolních bodů, kterými je
objekt řízen. Každý bod v seznamu kontrolních bodů může mít nastavenou
svou vlastní oblast ovlivnění i exkluzivního ovlivnění. Mezi různými hodnotami
ovlivnění se poté provede lineární interpolace.
Ukázka ze souboru kontrolních objektů control-objects.xml:
<controlObjects>
<object
name="facechin"
type="cubicSpline"
affectArea="0.03"
affectExclusively="0.001"
interpolationPoints="50" >
<affectMesh>
<mesh name="face" distanceCalculation="euclidean" />
</affectMesh>
<point name="jawPinLeft" />
<point name="chin" />
<point name="jawPinRight" />
</object>
</controlObjects>
3.3.5
Stavy
Stavy tváře, představující fonémy nebo výrazy jsou uloženy v samostatném
souboru. Informace o stavu obsahuje název stavu, typ stavu a seznam sekcí.
Každá sekce potom obsahuje příslušné násobiče hlavních komponent.
Stav může být dvojího typu. Buď foném nebo výraz. Rozdělení na tyto dva
typy bylo dáno potřebou ukládat pro foném doplňkové informace, které jsou
později využity pro výpočet koartikulačních jevů.
Ukázka ze souboru stavů states.xml:
<states>
<initialState>
<section name="lips"
35
featureVector="0.0 0.0 0.0 "
/>
</initialState>
<state name="!" type="phoneme" symbol="!" textMapping="">
<section name="chin"
featureVector="-18.0 "
thetaMinus="8.64171 "
thetaPlus="9.07133 "
alpha="0.01756 "
/>
<section name="lips"
featureVector="44.0 -12.0 0.807125 "
thetaMinus="8.64171 22.30308 42.50847 "
thetaPlus="9.07133 21.87637 29.82321 "
alpha="0.01756 0.49474 0.72084 "
/>
</state>
</states>
3.4
Programové zpracování
Obrázek 3.6: Znázornění interakcí mezi modelem, uživatelem a ArtiSynthem
Implementace celého modelu je značně rozsáhlá a čítá přes 60 tříd. Proto
zde uvedu jen základní principy, podstatné pro pochopení fungování modelu.
Detaily lze dohledat na přiloženém CD, které obsahuje Javadoc dokumentaci.
Model mluvící hlavy nazvaný „Musslap Headÿ je na ArtiSynth pevně navázán ve dvou bodech. Jednak využívá objekt pro reprezentaci a renderování 3D
dat a jednak musí být navázaný na plánovač simulačního jádra třídou modelu.
Na obrázku 3.6 je znázorněno navázání na ArtiSynth a interakce s uživatelem. Jak model mluvící hlavy, tak ArtiSynth dává uživateli k dispozici ovládací
grafické prvky.
36
3.4.1
Stav – parametrizace
Obrázek 3.7: UML diagram tříd představující stav modelu; čárkovaná čára odděluje rozhraní od implementace
Stav tváře, nebo-li polohy bodů trojrozměrné sítě tvořící model, je plně dán
hodnotou násobičů hlavních komponent (PC násobičů) všech definovaných sekcí
tváře. Tento stav je obsažen v aplikační třídě PCState, který je znázorněn na
obrázku 3.7. Kromě samotného pole sekcí s příslušnými hodnotami PC násobičů,
obsahuje ještě pojmenování stavu a dvě metody pro ulehčení výběru konkrétní
sekce. Tento základní stav je dále specializován pomocí rozhraní na dva základní
typy: výraz a foném.
Rozhraní výrazu Expression zde slouží jen jako tzv. marker, pro označení,
že daný stav je výraz a ne foném.
Foném, kterému odpovídá třída Phoneme na rozdíl od výrazu obsahuje několik dalších informací a specializací. Ta se týkájí překrytí metod pro výběr
sekcí, které vrací sekce i s informací o koartikulaci. Foném taktéž obsahuje informaci potřebnou pro jeho mapování na běžný text. Tuto informaci využívá
preprocesor, který převádí běžný český text na sekvenci fonémů.
Stavy jsou implementovány ve třídách StateImpl a PhonemeImpl. Po spuštění modelu jsou k dispozici všechny dostupné stavy z konfiguračních souborů
prostřednictvím továrny na stavy StateFactory. Tu lze získat z kontextu a kdekoli s ní pracovat. Prostřednictvím továrny lze získat buď všechny dostupné
stavy nebo si vyžádat pouze konkrétní stav k zadanému jménu. Kromě stavů
lze z továrny získat také počáteční offset pro multiplikátory hlavních komponent,
který je třeba pro výpočet konkrétních poloh bodů 3D sítě.
Implementace továrny je zde provedena pro použití s XML konfiguračním
souborem, ale vzhledem k použití rozhraní a kontextu je možné implementaci
v případě potřeby zaměnit třeba za továrnu, která bude stavy vybírat z databáze
nebo je získávat úplně jiným způsobem.
37
3.4.2
Plánovač
Plánovač na svém vstupu přiřazuje čas stavům (výrazům nebo fonémům) a
na svém výstupu vrací pro konkrétní čas hodnotu všech PC násobičů. Stavem
je myšlen buď výraz nebo foném, kterému odpovídá množina PC násobičů.
Plánovač je specifikovaný svým rozhraním.
Obrázek 3.8: UML diagram plánovače; čárkovaná čára odděluje rozhraní od
implementace
Plánovač se skládá ze dvou stop, které má za úkol „mixovatÿ. Jedna stopa
je určena pro výrazy a druhá pro fonémy. Plánovač je taktéž místem, které se
integruje na GUI za pomocí sond a umožňuje uživateli měnit časově proměnné
parametry tváře (PC násobiče). Sonda je obsažena v každé stopě pro každou
sekci, takže uživatel vidí dvojnásobné množství stop, než je definováno sekcí.
Data ve stopách lze uživatelsky příjemným způsobem editovat.
Obě stopy jsou taktéž specifikovány svým rozhraním. Tvar určitého fonému
je závislý na vyjadřované emoci a z tohoto důvodu musí být stopě plánující
fonémy stopa s výrazy zpřístupněna.
Uživatel plánovače nemá na stopy přímý přístup, ale může použít metody
plánovače pro přidání výrazu nebo fonému, který se postará o umístění do korektní stopy.
Hodnotu PC násobičů lze z plánovače získat v podobě reference na pole.
Řádky pole obsahují jednotlivé sekce a sloupce jednotlivé PC násobiče příslušné
sekce. Kontrakt, který specifikuje rozhraní pro metodu vracející pole PC násobičů předepisuje, že řádky s jednotlivými sekcemi musí být seřazeny podle
jména sekce. Seřazením si udržujeme informace o umístění sekce, aniž by to
bylo v sekci samotné explicitně řečeno. To nám umožní použít jednoduchá pole.
Implementace stopy pro výrazy je prostá. Pouze skládá jednotlivé výrazy za
sebe a pomocí sondy jsou tyto výrazy interpolovány.
38
Koartikulace
Jednotlivé stavy, z kterých se v modelu skládá promluva jsou diskrétní v čase.
Pro plynulost a srozumitelnost, je zapotřebí provést buď interpolaci nebo použít
jinou metodu, lépe aproximující skutečné chování řečníka – koartikulaci. Její
průběh záleží na levém i pravém kontextu, který musí být uvažován často až za
hranice slova.
Obrázek 3.9: Ukázka časové osy v GUI modelu mluvící hlavy, která zobrazuje
průběh PC násobičů rtů, při použití kubické interpolace (nahoře) a nebo koartikulace
Implementace stopy pro fonémy zajišťuje výpočet koartikulace pomocí Cohen a Massaro přístupu, který byl vysvětlen v kapitole 3.1.1. Implementace
pracuje tak, že spočítá průběh stavu pro zadanou promluvu a jeho průběh naplánuje s malým krokem do zvláštní stopy. Tento průběh je pak navíc za pomoci
sondy lineárně interpolován. Zobrazení průběhu PC násobiču při použití koartikulace a nebo kubické interpolace je možné vidět na obrázku 3.9.
3.4.3
Dekodér hlavních komponent
Obrázek 3.10: Průběh zpracování dat v jednom cyklu vykreslovací smyčky
Dekodér hlavních komponent ze vstupu, v podobě hodnot multiplikátorů
hlavních komponent, spočítá výslednou absolutní pozici kontrolních bodů. Vstupem dekodéru jsou hodnoty multiplikátorů všech sekcí. Tyto hodnoty jsou ale
relativní, to znamená, že představují pouze pohyb bodu, tedy rozdíl mezi jeho
klidovým – počátačním stavem a novým stavem. Dekodér si tedy musí pamatovat počáteční pozice kontrolních bodů, ke kterým přičítá pohyb. Dekodér navíc
obsahuje korekci počáteční pozice v podobě offsetu, který se přičítá ke každé
vypočtené poloze. Toho lze využít k jemnému doladění počáteční pozice.
39
Pohyb je zde myšlen ve smylu rozdílu mezi počátečním stavem a novým
stavem. Pokud je tedy vstup v podobě PC násobičů nulový, je i výstup nulový
a kontrolní body jsou ve výchozí pozici.
Dekodér je stejně jako všechny hlavní komponenty mluvící hlavy specifikován svým rozhraním. Implementace dekodéru zajišťuje průměrování kontrolních
bodů, pokud je bod ovlivňován více sekcemi.
Kontrolní body jsou vráceny jako reference na pole. Každý řadek odpovídá
jednomu bodu a každý rádek tedy obsahuje hodnoty pro x, y a z souřadnici
v prostoru. Řádky jsou seřazeny takovým způsobem, aby názvy příslušných
kontrolních bodů v řádcích, odpovídaly abecednímu pořadí názvů kontrolních
bodů.
Pro samotné dekódování sekcí používá dekodér pomocný objekt, představující PCA na dané sekci, který provede transformaci souřadnic. Jeden kontrolní
bod tedy může být bez problémů řízen více sekcemi. Typicky se to ale nestane,
protože jedna PCA sekce odpovídá jednomu řídícímu objektu a řídící objekty
nesdílejí kontrolní body. Tento případ by mohl například nastat, pokud by dva
řídící objekty na sebe v některém bodě navazovaly.
3.4.4
Kontrolní objekty
Kontrolní objekty společně se správcem kontrolních objektů ovlivňují samotný
vzhled. Kontrolní objekt má velice obecné rozhraní (ControlObject), se kterým
umí pracovat správce kontrolních objektů. Svou funkcí odpovídá kontrolní objekt svalu nebo kosti, která působí na pokožku tváře. Kontrolní objekty mohou
mít různé druhy vstupů i výstupů, tedy různý způsob fungování. Každý kontrolní objekt si vytváří kopii vrcholů 3D sítě (ObjectControlledVertex) a do nich
si ukládá informace o síle jeho ovlivnění. Správce kontrolních bodů poté kombinuje dílčí pohyby od všech kontrolních objektů ovlivňujících daný vrchol a
přičte je ke klidové hodnotě vrcholu.
V programu byl implementován kontrolní objekt SplineControlObject, který
na svém vstupu dostane množinu kontrolních bodů, které interpoluje kupickým
splinem. Po spuštění se poté spline pohybuje podle kontrolních bodů a ovlivňuje
své blízké okolí svým vlivem, který se vzdáleností klesá.
Při spuštění programu proběhne nejprve inicializace kontrolního objektu,
která se skládá ze dvou kroků. Nejprve se spline „otiskneÿ do 3D sítě. Otisk
musí splňovat dvě podmínky. Otisk musí na síti tvořit spojitou cestu a musí být
splinu co nejblíže. Pro splnění těchto požadavků, byl využit algoritmus Dijkstra
pro nalezení nejkratší cesty v síti (Holenda – Ryjacek, 2000). Po otisknutí se
prochází všechny vrcholy cesty a z každého se do jeho okolí zanese informace
o síle ovlivnění aktuálním vrcholem cesty. Síla ovlivnění klesá se zvyšující se
vzdáleností po hranách 3D sítě podle následujícího vzorce.
cos((x/z)π) + 1
2
Proměnná z udává oblast ovlivnění od kontrolního bodu a proměnná x vzdálenost po síti. Proměnná w je výsledná váha v bodě. Oblast ovlivnění lze u každého kontrolního bodu zadat samostatně.
Pokud síla ovlivnění klesne pod určitou mez, přestane se z daného vrcholu
informace o ovlivnění šířit. Protože se ovlivnění šíří ze všech bodů otisknuté
cesty, ovlivňuje každý bod v okolí cesty několik řídících bodů. Implementace
w=
40
Obrázek 3.11: UML diagram zjednodušeně zachycující rozhraní a třídy balíku
kontrolních objektů
rozhraní ObjectControlledVertex nazvaná BaseObjectControlledVertex pracuje
tak, že si setřídí sílu ovlivnění od největší po nejmenší a podle nastavené kvality
bere při výpočtu v potaz jenom N nejdůležitějších řídících bodů. Počet bodů,
které bere objekt v potaz lze nastavit metodou setSmoothness(). Výsledná poloha se potom spočítá jako vážený průměr ovlivnění z uvažovaných kontrolních
bodů.
P
(b · wi )
b= P
(3.7)
(wi )
Proměnná b značí vrchol – bod sítě a w váhy od jednotlivých bodů kontrolního objektu.
3.4.5
Ovlivnění geometrie
Ovlivnění 3D sítě modelu hlavy je posledním krokem k vizuální změně modelu.
Tuto činnost zajišťuje manažer kontrolních objektů (ControlObjectsManager),
který řeší jejich interakce, spravuje všechny kontrolní objekty a zastřešuje jejich
funkce.
Před samotnou prací manažeru kontrolních objektů probíhá inicializace,
která může řešit kolize kontrolních objektů. Řešení kolizí lze řešit pomocí parametru exkluzivního ovlivnění, který je uváděn společně s běžným ovlivněním
v konfiguračním souboru. Stejně jako běžné ovlivnění, může být i exkluzivní
ovlivnění nastaveno pro každý kontrolní bod kontrolního objektu samostatně.
Exkluzivní zóna představuje přichycení pokožky ke svalu nebo kosti. V takovém
41
Obrázek 3.12: UML diagram s třídou správce kontrolních objektů
místě je pokožka řízena pouze daným svalem respektive kostí a další objekty
by na ní neměly mít vliv. Navíc by tato oblast neměla být prostupná pro šíření
vlivu z jiného kontrolního objektu.
Po inicializaci už může probíhat samotné ovlivňování od kontrolních bodů.
Nejprve se tedy přečte hodnota PC násobičů z plánovače, ty vstupují do dekodéru, výstup dekodéru jde do kontrolních objektů, ty ovlivní své virtuální
3D sítě a následně je z virtuálních 3D sítí spočten vážený průměr a přičten ke
klidové hodnotě 3D sítě modelu hlavy.
3.4.6
Předzpracování textového vstupu
Obrázek 3.13: UML diagram tříd: textový preprocesor
Program umožňuje uživateli zadat vstupní text, který hlava následně „řekneÿ.
Pro správné fungování bylo třeba vyřešit předzpracování vstupního textu, o kterém se předpokládá, že je v českém jazyce. Problematika předzpracování textu,
ať už pro hlasovou nebo vizuální syntézu, je poměrně rozsáhlá. Je potřeba vzít
v potaz například konverzi čísel, dat, jednotek, zkratek a cizích slov na fonémy.
Základní funkcí textového preprocesoru je tedy převést posloupnost písmen na
posloupnost fonémů.
Pro zajištění funkcionality textového preprocesoru bylo navrženo rozhraní,
které lze vidět na obrázku 3.13. Cílem této práce ale nebyl sofistikovaný textový
preprocesor, a proto implementace tohoto rozhraní řeší jen základní případy.
Například nahrazení mezery, zohlednění začátku a konce věty a nahrazení jednoho nebo skupiny písmen jeho příslušným fonémem.
O instancializaci rozhraní se stará kontext, jak je vidět na obrázku 3.5, a
proto není problém napsat novou, pokročilou implementaci a jednoduše ji začlenit do programu.
3.4.7
Uživatelské rozhraní a možnosti ovládání
Po spuštění samotného ArtiSynthu, lze model mluvící hlavy Musslap Head spustit po kliknutí na menu „Modelsÿ a vybrat model „Musslap Headÿ. Pro ovládání
42
modelu mluvící hlavy bylo naprogramováno vlastní ovládací okno, zpřístupňující veškeré funkce modelu, jak je vidět na obrázku 3.14 vpravo. Pomocí ovládacího panelu lze ovlinit parametry renderování a zapínat nebo vypínat jednotlivé
objekty nebo vlastnosti. Příklad zapnutí zobrazení interpolačních křivek a kontrolních objektů lze vidět na obrázku 3.2.
Dále lze pomocí táhel nastavovat ručně hodnoty PC násobičů a sledovat
jak se změny projevují na modelu. Ručního nastavení je poté možné využít
např. pro úpravy uložených fonémů. V záložce „Statesÿ jsou uloženy všechny
dostupné stavy modelu (fonémy a výrazy). Nastavené hodnoty PC násobičů
i předzaznamenané stavy lze jednoduše plánovat do časové osy, která je na
obrázku 3.2 vidět vlevo dole. Poslední záložka nazvaná „Text inputÿ umožňuje
uživateli zadat textový vstup z klávesnice a nechat si jej automaticky zaplánovat
a syntetizovat.
Časová osa „Timelineÿ modelu obsahuje celkem devět stop. Každá stopa
odpovídá jedné sondě. První čtyři stopy jsou svázány se stopou výrazů v plánovači. Následující čtyři stopy jsou pak navázány na stopu řeči, z čehož první dvě
ukazují pouhou kubickou interpolaci stavů, zatímco spodní dvě zobrazují průběh stavu po aplikaci koartikulační metody. Porovnání obou stop je lépe vidět
z obrázku 3.9. Která z těchto dvou stop bude skutečně ovlivňovat stav tváře lze
volit přepínačem v ovládacím panelu.
43
Obrázek 3.14: GUI modelu mluvící hlavy; vpravo je vlastní ovládání modelu
mluvící hlavy
44
Kapitola 4
Shrnutí
4.1
Zhodnocení programu
Program, který je představován modelem mluvící hlavy v prostředí ArtiSynthu
se skládá z více jak 60ti rozhraní a tříd. Byl navržen modulárně, a proto lze
jeho jednotlivé části jednoduše přepracovat nebo vylepšit. Zdrojové kódy dodržují domluvené konvence ArtiSynthu a je odstraněna většina varování, která
hlásí překladač. Kód a hlavně rozhraní jsou bohatě dokumentovaná v anglickém
jazyce. Při programování byly dodržovány doporučené postupy pro vývoj Java
programů a byly využity programové návrhové vzory. Pro logování byl použit
Java Logging.
Náročnost programu nijak nevybočuje za rámec výkonu, který nabízejí dnešní
počítače PC. Program byl testován a vyvíjen na počítači s procesorem Intel Pentium M 1.7 GHz, 1 GB RAM a grafickou kartou ATI Mobility 9700, který měl
dostačující výkon. Protože se jedná o Java aplikaci, jsou standardně vyšší nároky
paměťové nároky a minimálně je třeba mít 512 MB RAM.
Geometrická data mluvící hlavy byla převzata z oddělení umělé inteligence a
byla převedana z VRML97 do X3D formátu. Pro ostatní konfigurační data byly
navrženy XML soubory a jejich validace byla zajištěna pomocí XML Schema.
Pro automatizovanou konverzi dat byl napsán konvertor také v jazyce Java.
Pro chod programu bylo třeba implementovat algoritmus pro výpočet kubického splinu a algoritmus Dijkstra pro výpočet nejkratší cesty v grafu. První
uvedený byl proveden na obecné úrovni mimo balíček modelu.
Program uživateli umožňuje v reálném čase měnit všechny parametry modelu a ty poté plánovat na časovou osu. Pro plánování je možné také využít soubor předzaznamenaných stavů, jejichž parametry lze ručně editovat.
Fonémy a výrazy s jejich aktuálním nastavením lze uložit do souboru. Uživateli
je dále umožněno přepínat mezi syntézou řeči pomocí implementované koartikulační techniky nebo syntézou realizovanou jen pomocí prosté interpolace stavů
fonémů. Uživatel má dále úplnou kontrolu nad časovým průběhem stavu tváře,
kterou může z časové osy jednoduše měnit.
45
KAPITOLA 4. SHRNUTÍ
4.2
Možná vylepšení
Větší výrazový prostor
Stávající model trpí malou artikulační schopností. Nelze například vytvořit příliš
věrohodný úsměv nebo stáhnout koutky úst dolů. Taktéž některé hlavní komponenty nereagují s řídícími body symetricky jak by měly. Tento problém byl
zřejmě způsoben zašuměnými daty, které vstupovaly do PCA. Zlepšení by bylo
možné dosáhnout naměřením nových, přesnějších dat nebo ruční opravou dat
stávajících. Malý výrazový prostor modelu by bylo možné vylepšit použitím
více hlavních komponent z PCA. Pokud by toto nestačilo, bylo by vhodné přidat další kontrolní body. Vhodným kandidátem na umístění nového bodu jsou
například tváře, které by zachytily chybějící pohyb a nafukování.
Vyjadřování emocí
V návrhu modelu se počítá s vyjadřováním emocí, ale to je velice omezené. Hlava
artikuluje pomocí posunu kontrolních bodů od absolutní pozice. Pokud tuto
pozici přemístíme, rty se nemusí dovírat nebo naopak nastane kolize geometrické
sítě. Je tedy možné ručně nastavit například úsměv a nechat hlavu artikulovat
promluvu, ale výsledek nebude ideální.
Je zřejmé, že vizuální tvar fonému by měl záviset na aktuální emoci, kterou
tvář vyjadřuje. Tento fakt je podchycen v návrhu modelu a v rozhraních. Prozatím ale nejsou k dispozici naměřená data, která by obsahovala tvary fonémů
pro předem známé emoce. Taktéž není k dispozici souhrnný výčet emocí, které
lze vyjádřit. Pokud by tyto dva body byly vyřešeny, je možné provést novou
implementaci.
Přenositelnost artikulačních dat
Artikulační data, tj. pozice kontrolních bodů pro jednotlivé fonémy nejsou jednoduše přenositelné na jinak tvarované tváře. Tento nedostatek by mohl být
odstraněn, zavadením relativních jednotek vzhledem k parametrům tváře. Tedy
použítím stejného přístupu, který používají hodnoty FAP v MPEG-4.
Věrnější koartikulace
Věrnější koartikulace by bylo možné dosáhnout skutečně daty řízenou koartikulací. Tvar fonému by se mohl vybírat v závislosti na jeho okolí z nějaké databáze.
Tento přístup by mohl být použit i pro řešení problému s vyjadřováním emocí.
Bylo by jen třeba naměřit mnohem více dat.
Podpora pro audio syntézu
Stávající model nepodporuje synchronizaci s audio syntézou, což ale ani nebylo
cílem práce. Nicméně je tento bod důležitý pro reálné nasazení mluvící hlavy.
Do rozhraní plánovače by tedy měl být zahrnut způsob předání časování pro
jednotlivé fonémy. Časování by mělo být pravděpodobně na jemnější úrovni, než
jen začátek a konec fonému. Například pro explozivní fonémy by bylo vhodné
mít obraz i zvuk dobře synchronní v místě exploze, protože zde je nesoulad
dobře vnímatelný.
46
KAPITOLA 4. SHRNUTÍ
Detailnější grafické zpracování
Pro reálněji vypadající výsledky by bylo vhodné použít detailnější geometrickou
síť a to zvláště v kritických místech jako jsou rty nebo oči. Taktéž detailnější
textura by modelu přidala na věrnosti. Kvalita geometrické sítě i ostatních použitých dat, je ovlivněna hlavně dostupností vhodných snímacích a měřících
zařízeních.
Spolupráce s jinými modely
Vzhledem k modularitě ArtiSynthu, je možné implementovaný model mluvící
hlavy propojit s jinými modely a tak zajistit jejich spolupráci. Model lze tedy
použít například jako doplněk pro jiný model, který by řešil znakující postavu
nebo audio syntézu řeči. Propojení lze zajistit nejenom prostředky ArtiSynthu,
ale i použitím vysokoúrovňového rozhraní mluvící hlavy, které pro tento účel
v modelu existuje. Rozhraní lze rozšířit o metody, které hlavě budou dávat
příkazy typu „otoč se vlevoÿ, „řekni větuÿ, atp.
4.3
Závěr
V diplomové práci byla provedena implementace mluvící hlavy v prostředí ArtiSynth, jejíž koncept vycházel z ověřeného přístupu, používaného na oddělení
umělé inteligence, Západočeské univerzity v Plzni. Tento přístup byl ale rozšířen
a vylepšen. Byla například použita redukce parametrů pomocí analýzy hlavních
komponent. Data byla převedena do přehlednějších struktur v XML formátu a
také přístup k ovlivňování bodu kontrolním objektem se liší. Pro ovládání bylo
vytvořeno GUI, umožňující ovládat téměř všechny aspekty modelu. Největším
přínosem je ale modularizace a zprůhlednění celého modelu.
Při realizaci bylo využito návrhových vzorů a doporučení pro vývoj v objektově orientovaných jazycích. Taktéž byla zohledněna specifika frameworku ArtiSynth, který byl v některých ohledech rozšířen. Byl nasazen sestavovací systém
Apache Ant, navržen balíček pro načítání geometrických dat a implementována
numerická metoda pro řešení kubické interpolace.
ArtiSynth i zdrojové kódy modelu jsou dostupné ve verzovacím systému na
University of British Columbia. Kromě úspěšné implementace modelu mluvící
hlavy, byly nastítěny body pro její další rozšiřování. Model je také možné využít
ve spolupráci s jiným modelem, jakým by mohla být například znakující postava
nebo audio syntéza řeči.
47
Seznam obrázků
2.1
Úspěšnost porozumění v závislosti na šumu při různě dostupných
informacích (Goff et al., 1994, s. 3) . . . . . . . . . . . . . . . . .
2.2 Vlevo: Ukázka z krátkého filmu Tony de Peltrie (1972); Vpravo:
Výstup z animačního programu Face Robot firmy SoftImage (2006)
2.3 MPEG-4 feature points . . . . . . . . . . . . . . . . . . . . . . .
2.4 MPEG-4 FAPU . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 XMT návaznost na ostatní technologie . . . . . . . . . . . . . . .
2.6 Struktura jazyka VHML z jeho dílčích částí . . . . . . . . . . . .
2.7 ArtiSynth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 UML diagram s rozhraními modelů . . . . . . . . . . . . . . . . .
2.9 UML diagram sond . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10 ArtiSynth GUI; vlevo OpenGL výstup; vpravo: časová osa se zobrazenou vstupní (nahoře) a výstupní sondou . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
Ukázka výstupu při změně parametru Θ. Na horním grafu je vidět průběh dominance pro dvě realizace cíle, které jsou vidět na
dolním grafu. Obrázek převzat z (Cohen – Massaro, 1993) . . . .
Přehled kontrolních bodů modelu a obrázek 3D sítě. . . . . . . .
UML diagram třídy řešící výpočet n-dimenzionálního splinu . . .
UML diagram tříd pro balíček maspack.geometry.io . . . . . . . .
UML diagram tříd znázorňující konfigurační logiku . . . . . . . .
Znázornění interakcí mezi modelem, uživatelem a ArtiSynthem .
UML diagram tříd představující stav modelu; čárkovaná čára odděluje rozhraní od implementace . . . . . . . . . . . . . . . . . .
UML diagram plánovače; čárkovaná čára odděluje rozhraní od
implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ukázka časové osy v GUI modelu mluvící hlavy, která zobrazuje
průběh PC násobičů rtů, při použití kubické interpolace (nahoře)
a nebo koartikulace . . . . . . . . . . . . . . . . . . . . . . . . . .
Průběh zpracování dat v jednom cyklu vykreslovací smyčky . . .
UML diagram zjednodušeně zachycující rozhraní a třídy balíku
kontrolních objektů . . . . . . . . . . . . . . . . . . . . . . . . . .
UML diagram s třídou správce kontrolních objektů . . . . . . . .
UML diagram tříd: textový preprocesor . . . . . . . . . . . . . .
GUI modelu mluvící hlavy; vpravo je vlastní ovládání modelu
mluvící hlavy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5
8
13
14
15
17
20
22
23
24
26
27
31
32
33
36
37
38
39
39
41
42
42
44
Literatura
BITTO, L. Zpracování videa - MPEG-4 [online]. [cit. 15. 4. 2007]. Dostupné z:
http://www.cgg.cvut.cz/~apg/apg-tutorials03/ch03s90.html.
BLOCH, J. Java efektivně: 57 zásad softwarového experta. Vyd. 1. Praha :
Grada, 2002. Přeložil Karel Voráček z orig. Effective Java – Programming
Language Guide. ISBN 80-247-0416-1.
COHEN, M. – MASSARO, D. Modeling coarticulation in synthetic visual speech, 1993. Dostupné z: http://mambo.ucsc.edu/psl/geneva.ps.
Corel Corp. Description of Facial Action Coding System (FACS) [online]. 2005?
[cit. 3. 11. 2006]. Dostupné z: http://face-and-emotion.com/dataface/
facs/description.jsp.
EKMAN, P. – FRIESEN, W. V. – TOMKINS, S. S. Facial affect scoring technique (FAST): A first validity study. 1971. Dostupné z: http:
//face-and-emotion.com/dataface/facs/guide/FACSIV1.html. 37-58.
EKMAN, P. Should We Call it Expression or Communication? Innovations
in Social Science Research. 1997, Vol. 10, No. 4, s. 333–344. Dostupné z:
http://www.paulekman.com/pdfs/should_we_call_it_exp.pdf.
EKMAN, P. – FRIESEN, W. V. – HAGER, J. C. FACS Investigator’s Guide:
Chapter 1. 2002. Dostupné z: http://face-and-emotion.com/dataface/
facs/guide/FACSIV1.html. ISBN 0-931835-01-1.
Eptamedia. Facial Animation Backround [online]. 2000. [cit. 23. 4. 2007].
Dostupné
z:
http://www.eptamedia.com/faceanim/en-doc/
en-faceanim-c-background.htm.
FELS, S. et al. ArtiSynth: An extensible, cross-platform 3d articulatory speech synthesizer. 2005. Dostupné z: http://hct.ece.ubc.ca/publications/
pdf/fels-etal-AVSP2005.pdf.
GLADWELL, M.
The Naked Face: Can you read peoples thoughts
just by looking at them? [online]. 2002. [cit. 2. 11. 2006]. Dostupné
z: http://www.fondation-langlois.org/flash/e/index.php?NumObjet=
15571&NumPage=694.
GOFF, B. et al. Real-time analysis-synthesis and intelligibility of talking faces,
1994. Dostupné z: http://citeseer.ist.psu.edu/31887.html.
49
LITERATURA
GUSTAVSSON, C. et al.
VHML: working draft v0.3 [online]. 2001.
[cit. 3. 4. 2007]. Dostupné z: http://www.vhml.org/downloads/VHML/vhml.
pdf.
HOLENDA, J. – RYJACEK, Z. Lineární algebra II. Úvod do diskrétní matematiky. ZČU, 2000. ISBN 80-7082-638-X.
iMediaTek. Face Modeling Language (FML) [online]. 2005. [cit. 4. 3. 2007].
Dostupné z: http://ivizlab.sfu.ca/research/iface/fml.html.
KIM, M. – WOOD, S. XMT: MPEG-4 Textual Format for Cross-Standard
Interoperability [online]. 2006. [cit. 7. 2. 2007]. Dostupné z: http://www.
research.ibm.com/mpeg4/Projects/XMTInterop.htm.
KRNOUL, Z. – ZELEZNY, M. Realistic Face Animation for a Czech Talking
Head. In Conference on TEXT, SPEECH and DIALOGUE, TSD 2004, Brno,
Czech republic, 2004.
LINDSAY – SMITH. A tutorial on Principal Components Analysis [online].
2002. [cit. 10. 2. 2007]. Dostupné z: http://csnet.otago.ac.nz/cosc453/
student_tutorials/principal_components.pdf.
MASSARO, D. – LIGHT, J. Improving the vocabulary of children with hearing
loss, 2004. Dostupné z: http://mambo.ucsc.edu/pdf/hearingloss.pdf.
MCGURK, H. – MACDONALD, J. Hearing lips and seeing voices. Nature.
1976, Vol. 264, s. 746 – 748. Dostupné z: http://www.faculty.ucr.edu/
~rosenblu/VSMcGurk.html.
NYSTEDT, D. – ZHANG, Y.-Q. Interview: Microsoft’s Ya-Qin Zhang seeks
power [online]. 2005. [cit. 3. 2. 2007]. Dostupné z: http://www.infoworld.
com/article/05/06/27/HNinterviewzhang_1.html.
PRYKRYL, P. – BRANDNER, M. Numerické metody II. Vyd. 1. Plzeň :
Západočeská univerzita v Plzni, 2000. ISBN 80-7082-699-1.
SHAPIRO, L. G. – STOCKMAN, G. C. Computer Vision. Prentice-Hall, 2001.
ISBN 0-13-030796-3.
[email protected].
FAP Generation Page [online].
[cit. 16. 4. 2007]. Dostupné z: http://www.cs.technion.ac.il/~gip/
projects/s2002/Dmitry_Vadim_MPEG4/FAPGeneration.htm.
STRNADOVA, V. Hádej co řıikám. Vyd. 2. [s.l.] : ASNEP, 2001. ISBN
80-903035-0-1.
Sun Microsystems. JavaTM 2 Platform Standard Edition 5.0: API Specification
[online]. c2004. [cit. 30. 11. 2006]. Dostupné z: http://java.sun.com/j2se/
1.5.0/docs/api/.
TEKALP, M. – OSTERMANN, J.
Face and 2-D Mesh Animation in MPEG-4 [online]. [cit. 15. 4. 2007].
Dostupné z:
http://www.chiariglione.org/mpeg/tutorials/papers/icj-mpeg4-si/
08-SNHC_visual_paper/8-SNHC_visual_paper.htm.
50
LITERATURA
W3C.
Synchronized Multimedia Integration Language (SMIL 2.1) [online]. 2005. [cit. 16. 4. 2007]. Dostupné z: http://www.w3.org/TR/2005/
REC-SMIL2-20051213/.
Wikipedia. Computer Facial Animation [online]. 2007a. [cit. 23. 4. 2007]. Dostupné z: http://en.wikipedia.org/wiki/Computer_facial_animation.
Wikipedia. Facial Action Coding System [online]. 2007b. [cit. 3. 11. 2006].
Dostupné z: http://en.wikipedia.org/wiki/Facial_Action_Coding_
System.
Wikipedia. Factory method pattern [online]. 2007c. [cit. 7. 2. 2007]. Dostupné
z: http://en.wikipedia.org/wiki/Factory_method_pattern.
Wikipedia. MPEG-4 [online]. 2007d. [cit. 17. 4. 2007]. Dostupné z: http:
//en.wikipedia.org/wiki/MPEG-4.
Wikipedia. Synchronized Multimedia Integration Language [online]. 2007e.
[cit. 16. 4. 2007].
Dostupné z: http://en.wikipedia.org/wiki/
Synchronized_Multimedia_Integration_Language.
ZARA, J. et al. Moderní počítačová grafika. Computer Press, 2004. ISBN
80-251-0454-0.
ZHANG, Z.
3-D Talking Heads On the Horizon [online]. 2001.
[cit. 4. 5. 2007]. Dostupné z: http://research.microsoft.com/~zhang/
Face/3-D%20Talking%20Heads%20On%20the%20Horizon.htm.
51

Diplomová práce

Transkript

Podobné dokumenty