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

A 4D vector. While it is 4D, it can have different interpretations depending on the node that uses it. It can be treated as a 2D vector with the last two components ignored, for instance, the Vector input of the Displace node is treated as a 2D vector. It can be treated as a 3D vector with the last component ignored, for instance, the Vector input of the Seperate XYZ node is treated as a 3D vector. It can be treated as two consecutive 2D vectors. For instance the Velocity Pass as expected by the Vector Blur node is assumed to have the 2D Previous Velocity in the X and Y components of the vector and the 2D Next Velocity in the Z and W components of the vector.

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)

The following example demonstrates implicit conversion between a color type and a float type, since the Math Node expect float inputs.

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.

The Alpha Over node currently does not support changing the domain priority for its inputs, so as a workaround, one can use a Mix node to achieved the desired behavior, noting that the first Image input in the Mix node has the highest domain priority, as shown in the following figure.

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

The compositor only supports a single active output target, that is, only one of the Group Output nodes or Viewer nodes in the node tree will be considered active and the rest will be ignored. In particular, the compositor searches the Active Node Tree Context and falls back to the Root Node Tree Context if no active output was found in the active node tree context. The active node tree context is the node tree of an expanded node group, that is, when the user selects a node group node and edits its underlying tree, while the root node tree context is the top level node tree without any expanded node groups.

The compositor searches for the active Group Output node, if none was found, it searches for the active Viewer node. If none was found, the compositor doesn’t run altogether. Consequently, note that adding a Viewer node will have no effect on the viewport render if there is a Group Output node, since the priority is given to Group Output nodes.