Compositor-system

Data

Dimensionalitet

Compositing-noder hanterar data som antingen är en bild eller ett dimensionslöst enskilt värde. Till exempel matar Levels-noden ut ett enda värde, medan Render Layers-noden matar ut en bild. Nodeingångar som förväntar sig ett enda värde antar ett standardvärde om en bild ges och ignorerar bilden helt, till exempel förväntar Transform-noden enkla värden för sina ingångar och kommer att anta standardvärden om bilder ges till dessa ingångar. Standardvärdena är de som betraktas som identitet och därmed inte har någon effekt på utdata, så för Transform node kommer ingångarna X, Y och Angle att ha ett standardvärde på noll, medan ingången Scale kommer att ha ett standardvärde på ett. Å andra sidan, om nodinmatningar som förväntar sig en bild ges ett enda värde, kommer det enda värdet att antas täcka hela compositing-rymden. Till exempel förväntar sig Filter-noden att dess Factor-ingång ska vara en bild, men om ett enda värde anges kommer det att antas vara detsamma för alla pixlar.

Typ

Det finns tre typer av data, som alla lagras i halvprecisionsformat:

Flytande

Ett signerat tal med flytande kommatecken. Integerdata lagras också som flyttal eftersom det inte finns någon heltalstyp.

Vektor

En 4D-vektor. Även om den är 4D kan den ha olika tolkningar beroende på vilken nod som använder den. Den kan behandlas som en 2D-vektor där de två sista komponenterna ignoreras, t.ex. behandlas Vector-ingången i Displace-noden som en 2D-vektor. Den kan behandlas som en 3D-vektor med den sista komponenten ignorerad, till exempel behandlas Vector-ingången i Seperate XYZ-noden som en 3D-vektor. Den kan behandlas som två på varandra följande 2D-vektorer. Till exempel Velocity Pass som förväntas av Vector Blur-noden antas ha 2D Previous Velocity i X- och Y-komponenterna i vektorn och 2D Next Velocity i Z- och W-komponenterna i vektorn.

Färg

En 4D-vektor som lagrar färgens röda, gröna, blå och alfa. Färgen är fri och överensstämmer inte med en specifik färgrymd eller alfa-lagringsmodell, istället kommer lämpliga noder att ha inställningar för att styra representationen av deras utdata och noder finns för att konvertera mellan de olika representationerna.

Implicit konvertering

Om en nodinmatning får data av annan typ än sin egen typ, utförs följande implicita omvandlingar:

Källa	Mål	Konvertering
Flytande	Vektor	f => Vektor(f, f, f, 0)
Flytande	Färg	f => Färg(f, f, f, 1)
Vektor	Flytande	(x, y, z, w) => Genomsnitt(x, y, z)
Vektor	Färg	(x, y, z, w) => Färg(x, y, z, 1)
Färg	Flytande	(r, g, b, a) => Luminans(r, g, b)
Färg	Vektor	(r, g, b, a) => Vektor(r, g, b, 0)

Följande exempel visar implicit konvertering mellan en färgtyp och en floattyp, eftersom Math-noden förväntar sig float-ingångar.

Ett exempel som visar implicit konvertering mellan en färgtyp och en floattyp, eftersom Math-noden förväntar sig float-ingångar.

Compositing-utrymme

Bilddomän

Compositorn är utformad på ett sådant sätt att den möjliggör compositing i ett oändligt compositingutrymme. Följaktligen representeras bilder inte bara av sin storlek, utan också av sin transformation i det utrymmet, ungefär som 3D-objekt har transformationer. En identitetstransformation representerar en bild som är centrerad i rymden. Det rektangulära område som upptas av en bild i detta utrymme och som definieras av dess transformation och storlek kallas för bildens domän. I figuren nedan visas domänerna för två exempelbilder.

Domänerna för två exempelbilder illustreras på compositing-ytan. En av bilderna är centrerad i utrymmet och den andra är nedskalad och translaterad så att den ligger i den övre högra kvadranten av utrymmet. Lägg märke till att båda bilderna har liknande storlek i pixlar, men att deras skenbara storlek är olika.

Bilder kan transformeras med hjälp av noder som Transform, Translate och Rotate.

Drift Domän

Compositor Nodes arbetar med ett specifikt rektangulärt område i compositing-rymden som kallas Operation Domain. Noderna beaktar endast det område av indatabilderna som överlappar operationsdomänen och ignorerar resten av bilderna. Om en inmatningsbild inte helt överlappar operationsdomänen kommer resten av operationsdomänen för den inmatningen att antas vara ett nollvärde, en nollvektor eller en transparent nollfärg beroende på typ.

I figuren nedan illustreras t.ex. ett fall där en nods operationsdomän är det stora blå området och domänen för en inmatningsbild är det lilla röda området. I det fallet överlappar inte indatabilden operationsdomänen helt och hållet, så resten av det blå området för den indatabilden antas vara noll.

Ett exempel där en nods operationsdomän visas i blått och domänen för en inmatad bild visas i rött. Eftersom indatabilden inte helt täcker nodens operationsdomän antas resten av det blå området för den indatabilden vara noll.

Den föregående illustrationen är en representation av ett verkligt exempel där man använder Alpha Over-noden för att lägga över en liten logotyp på en bild, som visas i figuren nedan. I det fallet täcker operationsdomänen hela vyport — som senare kommer att demonstreras, men logotypen täcker bara ett litet område av den, så resten av området antas vara en noll transparent färg, vilket är bekvämt för användningsfallet.

Ett exempel från verkligheten där Alpha Over-noden används för att lägga över en liten logotyp på en bild. Logotypen täcker bara en liten del av operationsdomänen, som i det här fallet är hela visningsfönstret, så resten av området antas vara en nolltransparent färg.

Interpolation av spak

Om en inmatad bild till en nod inte är helt i linje med nodens operationsdomän eller har en annan storlek i pixlar, behöver noden vanligtvis göra en process som kallas interpolering, där den inmatade bilden läses in vid de exakta positionerna för pixlarna i operationsdomänen. Detta kan göras med hjälp av olika interpoleringsmetoder, t.ex. närmaste granne-, bilinjär- och bikubisk interpolering. Dessa interpoleringsmetoder demonstreras i följande Wikipediagalleri <https://en.wikipedia.org/wiki/Comparison_gallery_of_image_scaling_algorithms>`__. Transformationsnoder som noderna Transform och Rotate innehåller ett interpoleringsalternativ för att ange hur de föredrar att deras utgångsbild ska läsas och interpoleras.

Fastställande av operationsområde

Frågan kvarstår om hur noder bestämmer sin operationsdomän. Olika typer av noder kan ha olika mekanismer för att bestämma sin operationsdomän. Men i allmänhet finns det tre klasser av noder när det gäller mekanismen för att bestämma operationsdomänen, och var och en av dem presenteras i ett av följande avsnitt.

Ingångsnoder

Operationsdomänen för ingångsnoder som Image-noden är en domän med en identitetstransformation och samma storlek som deras utgångar, så för Image-noden kommer operationsdomänen att vara den domän vars storlek är bildens storlek och vars transformation är en identitetstransformation.

Utgångsnoder

Operationsdomänen för utgångsnoder som Viewer-noden är en domän med en identitetstransformation och samma storlek som den slutliga compositor-utgången. För viewport compositing skulle den storleken vara viewportstorleken, och för final render compositing skulle den storleken vara scenens renderstorlek.

Andra noder

Om inte annat anges i deras respektive dokumentationssidor, använder alla andra noder följande mekanism. En av nodernas ingångar betecknas som nodens Domäningång, och nodens operationsdomän är identisk med domänen för den angivna ingången. För många noder kan domäningången intuitivt identifieras som nodens huvudingång, till exempel är domäningången för Filter-noden Image-ingången. Men det finns några varningar att notera, vilket kräver en djupare förståelse av mekanismen.

Varje ingång i noden har den så kallade Domain Priority-egenskapen, nodens operationsdomän är domänen för den ingång som inte har ett enda värde med den högsta domänprioriteten. Så till exempel har Filter-noden två ingångar, domänprioriteten för Image-ingången är högre än för Factor-ingången, och det finns fyra möjliga konfigurationer:

• Både Image- och factor-ingångarna är kopplade till bilder. I det här fallet är Image-ingången domäningången eftersom den har högsta prioritet och är kopplad till en bild.

• Ingången Image är kopplad till en bild, men det är inte ingången Factor. I det här fallet är Image-ingången domäningången eftersom det är den enda ingången som är ansluten till en bild oavsett prioritet.

• Ingången Image är inte kopplad till en bild, men ingången Factor är det. I detta fall är Factor-ingången domäningången eftersom det är den enda ingången som är ansluten till en bild oavsett prioritet.

• Varken Image- eller Factor-ingångarna är kopplade till bilder, i det här fallet finns det ingen domäningång eftersom noden utvärderas på enskilda värden.

Överväganden

Den ovan beskrivna mekanismen för att bestämma operationsområdet har ett antal konsekvenser som måste beaktas eftersom de kan vara oönskade, och var och en av dem beskrivs i ett av följande avsnitt.

Klippning

Nodernas utdata kommer intuitivt att klippas till operationsdomänen, eller snarare domänen för domäninmatningen. Om t.ex. Foreground-ingången är större än Background-ingången i Alpha Over-noden, kommer utdata att klippas till Background-ingången eftersom det är domäningången, vilket visas i följande figur.

Inmatningen Foreground är större än inmatningen Background i noden Alpha Over, så utmatningen är intuitivt klippt till inmatningen Background eftersom det är domäninmatningen.

Alpha Over-noden stöder för närvarande inte ändring av domänprioriteten för dess ingångar, så som en lösning kan man använda en Mix node för att uppnå önskat beteende, och notera att den första Image-ingången i Mix-noden har den högsta domänprioriteten, vilket visas i följande figur.

Arbeta med att kringgå klippningsbeteendet för Alpha Over-noden med hjälp av en Mix-nod, och notera att den första Image-ingången i Mix-noden har den högsta domänprioriteten

Utdata

Kompositören stöder endast ett enda aktivt utgångsmål, det vill säga endast en av Composite-noderna eller Viewer-noderna i nodträdet kommer att betraktas som aktiv och resten ignoreras. I synnerhet söker kompositören i Active Node Tree Context och faller tillbaka till Root Node Tree Context om ingen aktiv utgång hittades i den aktiva nodens trädkontext. Den aktiva nodträdskontexten är nodträdet i en expanderad nodgrupp, det vill säga när användaren väljer en nodgruppsnod och redigerar dess underliggande träd, medan rotnodträdskontexten är nodträdet på högsta nivån utan några expanderade nodgrupper.

Compositor söker efter den aktiva Composite-noden, om ingen hittades söker den efter den aktiva Viewer-noden. Om ingen hittades körs inte compositorn alls. Observera därför att om du lägger till en Viewer-nod kommer det inte att ha någon effekt på renderingen av vyport om det finns en Composite-nod, eftersom Composite-noder prioriteras.