Indhold
Selvom disse rasterbilleder, der udfylder vores computere og liv, oftest bruges til at repræsentere billeder, finder jeg det nyttigt for en CG-kunstner at have endnu et perspektiv - et geekier. Og set fra dette perspektiv er et rasterbillede i det væsentlige et sæt data organiseret i en bestemt struktur for at være mere specifik - en tabel fyldt med tal (en matrix, matematisk set).
Nummeret i hver tabelcelle kan bruges til at repræsentere en farve, og sådan bliver cellen til en pixel, som står for 'billedelement'. Der findes mange måder at kode farver numerisk på. For eksempel (sandsynligvis den mest ligefremme) til eksplicit at definere en nummer-til-farve-korrespondance for hver værdi, dvs. 3 står for mørkerød, 17 for lysegrøn og så videre. Denne metode blev ofte brugt i de ældre formater som .gif, da den tillod visse størrelsesfordele på bekostning af en begrænset palet.
En anden måde (den mest almindelige) er at bruge et kontinuerligt interval fra 0 til 1 (ikke 255!), Hvor 0 står for sort, 1 for hvid, og tallene imellem angiver gråtonerne med den tilsvarende lysstyrke. På denne måde får vi en logisk og elegant organiseret måde at repræsentere et monokromt billede med en rasterfil.
Udtrykket 'monokrom' tilfældigvis er mere passende end 'sort og hvid', da det samme datasæt kan bruges til at skildre graderinger fra sort til enhver anden farve afhængigt af outputenheden - ligesom mange gamle skærme var sort-grøn snarere end sort-hvid.
Dette system kan imidlertid let udvides til fuldfarvet etui med en simpel løsning - hver tabelcelle kan indeholde flere tal, og igen er der flere måder at beskrive farven på med få (normalt tre) tal hver i 0-1 rækkevidde. I en RGB-model står de for mængderne af rødt, grønt og blåt lys, i HSV står de for nuance, mætning og lysstyrke i overensstemmelse hermed. Men hvad der er vigtigt at bemærke er, at de stadig ikke er andet end tal, der koder for en bestemt betydning, men ikke skal fortolkes på den måde.
En logisk enhed
Lad mig gå videre til, hvorfor en pixel ikke er en firkant: Det er fordi tabellen, som er et rasterbillede, fortæller os, hvor mange elementer der er i hver række og kolonne, i hvilken rækkefølge de placeres, men intet om hvilken form eller endda hvilken andel de er.
Vi kan danne et billede fra dataene i en fil på forskellige måder, ikke nødvendigvis med en skærm, som kun er en mulighed for en outputenhed. For eksempel, hvis vi tager vores billedfil og distribuerer småsten i størrelser, der er proportionale med pixelværdier på en eller anden overflade - skal vi stadig danne stort set det samme billede.
Og selvom vi kun tager halvdelen af søjlerne, men beder os selv om at bruge stenene to gange bredere til fordelingen - resultatet vil stadig principielt vise det samme billede med de korrekte proportioner, kun mangler halvdelen af de vandrette detaljer.
'Instruktioner' er nøgleordet her. Denne instruktion kaldes pixelformat, som beskriver forskellen mellem billedets opløsning (antal rækker og kolonner) og proportioner. Det giver dig mulighed for at gemme rammer strakt eller komprimeret vandret og bruges i visse video- og filmformater.
Lad os nu tale om opløsning - det viser den maksimale mængde detaljer, som et billede kan rumme, men siger intet om, hvor meget det faktisk har. Et dårligt fokuseret fotografi kan ikke forbedres, uanset hvor mange pixels kamerasensoren har. På samme måde vil opskalering af et digitalt billede i Photoshop eller en hvilken som helst anden editor øge opløsningen uden at tilføje nogen detaljer eller kvalitet til den - de ekstra rækker og kolonner vil bare blive fyldt med interpolerede (gennemsnit) værdier af oprindeligt nærliggende pixels.
På en lignende måde er en PPI-parameter (pixels pr. Tomme, ofte også kaldet DPI - prikker pr. Tomme) parameter kun en instruktion, der fastlægger overensstemmelse mellem billedfilens opløsning og outputets fysiske dimensioner. Og så er PPI stort set meningsløst alene, uden nogen af disse to.
Lagring af brugerdefinerede data
Når vi vender tilbage til de numre, der er gemt i hver pixel, kan de selvfølgelig være hvilke som helst, inklusive såkaldte numre uden for området (værdier over 1 og negative), og der kan være mere end tre numre gemt i hver celle. Disse funktioner er kun begrænset af den specifikke filformatdefinition og bruges i vid udstrækning i OpenEXR for at nævne en.
Den store fordel ved at gemme flere numre i hver pixel er deres uafhængighed, da hver af dem kan studeres og manipuleres individuelt som et monokromt billede kaldet Channel - eller en slags sub-raster.
Yderligere kanaler til de sædvanlige farvebeskrivende røde, grønne og blå kan bære al slags information. Standard fjerde kanal er Alpha, som koder for opacitet (0 angiver en gennemsigtig pixel, 1 står for fuldstændig uigennemsigtig). Z-dybde, normaler, hastighed (bevægelsesvektorer), verdensposition, omgivende okklusion, ID'er og alt andet, du kunne tænke på, kan gemmes i enten yderligere eller de vigtigste RGB-kanaler.
Hver gang du gengiver noget, bestemmer du, hvilke data der skal medtages, og hvor de skal placeres. På samme måde beslutter du i komposition hvordan man manipulerer de data, du besidder, for at opnå det ønskede resultat. Denne numeriske måde at tænke på billeder er af altafgørende betydning og vil gavne dig meget i dine visuelle effekter og bevægelsesgrafik.
Fordelene
Det er vigtigt at anvende denne måde at tænke på dit arbejde på - mens du bruger renderpas og udfører det kompositerende arbejde.
Grundlæggende farvekorrektioner er for eksempel intet andet end elementære matematiske operationer på pixelværdier, og det er ret vigtigt for produktionsarbejdet at se igennem dem. Desuden kan matematiske operationer som addition, subtraktion eller multiplikation udføres på pixelværdier, og med data som Normals and Position kan mange 3D-skyggeværktøjer efterlignes i 2D.
Ord: Denis Kozlov
Denis Kozlov er en CG-generalist med 15 års erfaring inden for film-, tv-, reklame-, spil- og uddannelsesindustrien. Han arbejder i øjeblikket i Prag som VFX-tilsynsførende. Denne artikel blev oprindeligt vist i 3D World-udgave 181.
