News Open Image Denoise: Intels freier Raytracing-Entrauscher für SSE-4.2-CPUs

[estros]

Sorry, aber für mich sieht das so aus, als ob die einfach für die schwarzen Punkte einen Nearest-Neighbour Algorithmus benutzt haben - das entrauschte Bild sieht nämlich an den entrauschten Stellen total verwaschen aus.
Aber gut, ist jetzt nicht mein Fachgebiet, müsste man mal Brecht fragen (Blender 3d).

Achtung: Hier werden keine Rastergrafiken verarbeitet!

 

[mkdr]

Achtung: Hier werden keine Rastergrafiken verarbeitet!

Dann hast du dir wohl das falsche Bild angesehn. Es geht um "Endzustand". Und da sind Details dann weg (weichgezeichnet). Sieht richtig schlecht aus. Als wäre da 1-2px motion-blur drinn zu einer Seite.

 

[Snudl]

wirkt es fasst so, als würde man von einem farbindizierten, geditherten 4bit zu einem 24 bit wechseln.

Das wirkt nur so, eben weil jeder Strahl für sich (pseudo)zufällig verteilt ist. Intern wird aber meist mit 32 oder 16 bit floating-point pro Farbkanal gerechnet, in HDR mit linearem Gamma. Man kann das Rauschen schon im Rendering-Prozess eindämmen, indem man die hellsten Ausreißer (Fireflies) abdunkelt, oder mit benachbarten Pixeln vermischt.

Wäre es theoretisch möglich das eine SSE 4.2 CPU das Raytracing einer Turing GPU beschleunigt?

Das Raytracing selbst oder der Rauschfilter? Beim Raytracing ist der Nutzen eher begrenzt. Zum einen ist da der Effizienzunterschied von Software-Rendering vs. Hardware-Rendering - wohlgemerkt der ist für Raytracing kleiner als für Rastering. Zum anderen müsste die komplette Szene sowohl im Arbeitsspeicher und im Grafikspeicher liegen und koordiniert werden welche Teile von CPU und GPU zu rendern sind. Alternativ müsste mit derzeitiger Hardware ständig von A nach B kopiert werden, das bedeutet immensen Mehraufwand. An der Stelle kommt HSA zur Hilfe, welches AMD und ARM seit einigen Jahren vorantreiben.

 

[KarlKarolinger]

Erm... sieht ziemlich unscharf aus nach dem "Entrauschen".

Ja, einige Büsche im Hintergrund verlieren fast komplett ihre Struktur. Beim verrauschten Bild sieht man da geradezu noch einzelne Blätter, nach dem Entrauschen ist es eher ein grüner Blob. Klar ist das eine Abwägung, aber wenn man schon RayTracing für ein besseres Bild verwendet, dann würde ich zumindest bei ruhigen Szenen dann eher mehr ins RayTracing investieren.
Hat man in einem Film aber z.B. schnelle Verfolgungsjagden oder so, dann fällt die Unschärfe wahrscheinlich weniger auf, als wenn alles verrauscht ist. Da kann man dann in solchen Szenen bestimmt einige Zeit sparen.

Mein erster Gedanke beim Lesen der Überschrift war aber: "Oh, weil NVidia das mit seinen Tensor-Cores nicht richtig hin bekommt, bietet Intel jetzt seine Hilfe an/sieht eine Chance seine teuren CPUs notwendig zu machen!"
Denke aber nach dem Lesen, dass es wohl eher nicht für die Echtzeit-Anwendung gedacht ist.

 

[estros]

Dann hast du dir wohl das falsche Bild angesehn. Es geht um "Endzustand". Und da sind Details dann weg (weichgezeichnet). Sieht richtig schlecht aus. Als wäre da 1-2px motion-blur drinn zu einer Seite.

Endzustand? Die Verarbeitung läuft nicht mit Rastergrafiken, das wollte ich nur sagen, da er die Methode genannt hat.

 

[iPain]

Ich muss sagen, dass mir das erste Bild, trotz Rauschen, besser gefällt. Es wirkt insgesamt stimmiger und detailreicher als das "entrauschte" Bild. Durch das Entrauschen wird das Bild irgendwie matschig und verliert seine Tiefe :/

 

[Fermion]

Endzustand? Die Verarbeitung läuft nicht mit Rastergrafiken, das wollte ich nur sagen, da er die Methode genannt hat.

Huh? Ich hab mir Open Image Denoise noch nicht angeschaut, aber im Endeffekt arbeitet es mit Rastergrafiken - das fertig gerenderte Bild wird von der Library nachträglich bearbeitet, wobei das Rauschen reduziert wird. Das ist kein Prozess der während des Rendervorgangs stattfindet oder ihn gar ersetzt, sondern anschließend durchgeführt wird. Intel liefert, vereinfacht gesagt, einen Algorithmus der bereits gerenderte Bilder aufarbeitet um ganz spezifische Phänomene zu entfernen.

Das Problem ist, dass ein "gutes" Bild, das alle relevanten Details einigermaßen sauber darstellt, relativ schnell gerendert ist. Es rauscht allerdings je nach Szene sehr stark und um das zu beseitigen benötigt man in der Regel ein Vielfaches der Zeit, die das "gute" Bild benötigt. Im Grunde folgt das der gleichen Regel wie in anderen Bereichen und Disziplinen auch: Die letzten 10% benötigen 90% der Zeit - die möchte Intel hier kürzen.

In der Funktionsweise mit dem ganzen Deep-Learning-Neural-Network-Hokus-Pokus mag OID vielleicht einzigartig sein, ansonsten ist das Konzept des Denoisings im Post-Processing nichts wirklich neues. V-Ray hat beispielsweise sein Denoiser Render Element (funktioniert ebenfalls in real-time, zumindest in Kombination mit dem GPU-Renderer), Arnold hat einen separaten Denoiser für Post-Processing mit EXR-Dateien, Corona bringt auch Post-Processing Denoising-Features mit und neuerdings auch real-time Denoising via GPU (nutzt u.a. Nvidias Tensor-Cores), usw.

Vielleicht bin ich ja gerade total Banane, aber für mich klingt das eher danach, dass Intel hier lediglich nachzieht bzw dem eigenen Render Framework ein weiteres Feature spendiert. Weniger danach, dass das nun was bahnbrechend neues ist.

 

[fdsonne]

Danke. Dh, das Rauschen ist die Konsequenz von fehlender Mittlung von möglichst vielen Samples pro Pixel? Dh, bei nur einem, ist der (Monte Carlo-)Algorithmus so, dass jedes Pixel zwar korrekt errechnet aber insgesamt das Bild sehr rauschig aussehen kann?

Wäre das Pixel correct berechnet - gäbe es kein Rauschen
Das Thema ist eher, dass eben durch zu geringen Sample Count bei bspw. einer Schattenlage das Resultat schlicht ein schwarzes Pixel wäre - das Nachbarpixel ist aber ggf. nicht im Resultat im Schatten -> unterscheidet sich damit dann insofern stark, dass der Farbwechsel hart ist. Viele dieser harten Wechsel geben ein Rauschen über das Bild. Vor allem dort wo Übergänge stattfinden (was in der Szene recht viele sind)
Das Aussenden von mehreren Strahlen bedeutet beim Resultat, dass die Ergebnisse der Berechnungen kumuliert werden - es wird also viel weniger harte Wechsel geben. Die Verläufe werden weicher, die Schatten werden stimmig usw.

Mit nur einem Strahl pro Pixel wäre ein Pixel im Schatten schlicht schwarz - real wäre es das aber eigentlich gar nicht. Der Schattenwurf ist eher gräulich, weil du ja trotzdem etwas siehst. Schwarz würde bedeuten, du siehst exakt nichts. (es wird gar kein Licht zurückgeworfen) Das kommt so aber in den aller seltensten Fällen vor... Man sendet also mehr Strahlen aus - davon werden dann auch mehr kein Schwarz bringen. Im Schnitt am Ende kommt also wie gesagt eher ein Grau bei raus. Um so mehr Schatten, um so dunkler. Um so weniger, um so heller. (extrem vereinfacht gesagt)

Insofern passt das Wort "korrekt" in der Aussage mMn nicht ganz. Denn das Pixel wird mit um so mehr Strahlen annäherungsweise korrekt. Um so weniger, desto weniger nah ist man am korrekten Ergebnis. Da kann es dann mal passen - aber auch mal deutlich daneben sein. Was auch nicht nur Schatten (also die Helligkeit) betrifft, sondern eben auch die Farbe, welche durch sowas beeinflusst wird -> bspw. wenn durch indirektes Licht/Reflextion die falsche Farbe ins Spiel kommt.

Toll finde ich es, dass Intel diese (für mich Raketen)Technik unter Apache 2.0 Lizenz gestellt hat. So oft ich gegen den Laden schimpfe, sowas ist zu loben und bringt die Welt weiter.

Naja, ist jetzt nicht unbedingt so, dass es im Bereich Rendering keine OpenSource Software geben würde. Im Endeffekt hält sich der Spaß dort doch schon gut die Waage. Es gibt die bezahlmich Software mit recht großen Entwickler Teams, die auch gut pushen in dem Bereich - und es gibt die OpenSource Seite (bspw. zu nennen wäre hier die Blender Foundation oder auch die Leute hinter POV Ray), die das in "frei" machen.
Problem an "frei" ist halt wie sehr oft in der Industrie - auf dem Papier cool, in den Praxis aber fehlt dir nicht selten einfach der direkte Ansprechpartner. Selten gibt es Verträge zwischen dem Endnutzer und jemanden, den man da auf den Vertrag festnageln kann usw.

Hmm, oben wird von Bildern gesprochen, das wohl aber kaum das Anwendungsgebiet sein wird, sollte die Zeit kein erheblicher Vorteil zum Rendering sein. Sprich im Alltag wird der Entrauscher eher Videosequenzen aufbereiten.

Die Videosequenz besteht auch "nur" aus einer Abfolge von einzelnen Bildern.
Im Endeffekt wird in der Rendersoftware die Animation "beschrieben" - und diese Beschreibung läuft dann durch den Renderer, welcher anhand der Settings entsprechend x Bilder berechnet. Nach erfolgtem Rendervorgang werden die Bilder zu einem Video zusammen gelegt. Anders als bei einer Echtzeit-Methode ist die Geschwindigkeit des Outputs hier fix. Der Renderer wird nicht bei weniger komplexen Szenen mehr Bilder die Sekunde im Video haben - sondern immer exakt die gleiche Anzahl, er schafft dafür halt mehr Filmzeit.

Wenn ich die beiden Bilder vergleicht, ist beim ersten alles "verrauscht", nicht nur das Wasser (wie ich gedacht hätte). Die Bäume, die Berge, ...? Wieso sind die auch verrauscht?

Das Bild wird, wie schon angesprochen wurde, ganzheitlich über diese Methode "gerendert". Deswegen gibt es auch mal mehr mal weniger, aber auf dem ganzen Bild sichtbares rauschen. Dunklere Bereiche (Schatten) ist dabei idR anfälliger als hellere Bereiche. Was (siehe oben) in der Natur der Sache liegt, wenn zu wenig Strahlen ausgesendet werden um ein möglichst genaues Ergebnis des Pixels zu errechnen. Da wo aber wenig bis kein Schatten existiert und eh "alles" Licht quasi zurück geworfen wird - rauscht es auch nicht (so stark)...


MMn ist der Vergleich in Form der Winzig Bilder aber auch nur bedingt sinnig.
Man müsste das mal auf einem großen Output Sample machen. Also keine Ahnung 8k oder 16k oder so - und DANN mal vergleichen. Weil wenn der Ast im Hintergrund eh nur 1-2 Pixel breit ist - was soll da ein Denoiser groß machen können? Das kann nur Matsche werden...

 

[Recharging]

Wäre das Pixel correct berechnet - gäbe es kein Rauschen
Das Thema ist eher, dass ...

Herzlichen Dank, dass du dir für diese Antwort Zeit genommen hast.
Das scheint mir, beim Durchdenken, jetzt, Achtung, it just works-raytracinggerecht, einzuleuchten.
Je mehr Strahlen, desto größer das Sample desto besser die Näherung an menschliche Realität.

 

[fdsonne]

Ja, ich würde sagen, so könnte man das ausdrücken. Zumindest in stark vereinfachter Form.

 

[Yuuri]

Die Bilder entstehen doch rein digital, wo kommt dieses Dunkelrauschen/Ausleserauschen denn her?

Das kommt vom Path Tracing. Golem hat letztens über Q2VKPT geschrieben.

http://www.brechpunkt.de/q2vkpt/#media

Gerendertes Bild nach dem Path Tracing

+ Denoising Filter

 

[Shrimpy]

Wenn der zeitliche Unterschied so krass ist, lässt sich ja einiges an Produktionskosten senken

Kann mir nicht vorstellen das es was taugt.
DLSS schaut zu Nativen4k auch schlechter aus, natürlich läufts schneller.
Aber bei einem FIlm die paar Euros aus dem billigsten prozess der kette sparen?
Ka, ist für mich als wenn ein Youtuber ein gutes video macht mit Aufwand und zeit und es dann nur in 480p hoch lädt.
Für bereits gerenderte Produktionen ist das ja ok, wobei man auch hier wohl nochmal rendern könnte.

 

[schwenn]

Oo
Das ist sicherlich nicht der billigste Prozess der Kette..

 

[vander]

Mich wundert das im Artikel auch AMD genannt wird, funktioniert die Intel Software dort ohne CPU Dispatcher Fix überhaupt fehlerfrei und performant?
Es sollte doch schon länger bekannt sein das Intel gerade bei den hier verwendeten MKL Libraries trickst wo es nur geht, um alles was nicht GenuineIntel heißt, schlecht darzustellen.

 

[Qarrr³]

Kann mir nicht vorstellen das es was taugt.
DLSS schaut zu Nativen4k auch schlechter aus, natürlich läufts schneller.

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Das ist quasi das, was Nvidia für ihr Raytracing nutzt. Anders als hier, nutzen die nicht 16 sondern 1 Sample pro Pixel beim Ausgangsbild. Trotzdem hat sich niemand wirklich über die Qualität, nur über die Leistung beschwert. Dennoch: Statt Stunden für ein Bild zu brauchen, schafft eine Touring dutzende Bilder pro Sekunde. Das ist aber nur die erste Generation von neural networks und die erste Generation Hardware. Das sieht bei Intel nicht anders aus. Warte mal bis sich eine Industrie um Maschine learning ausgebildet hat, die den Markt sättigt.

 

[Colindo]

mich würde ja der zeitliche Faktor interessieren. Wie lange es in Sekunden dauert das Bild mit Path Tracing zu rendern und wie schnell das Denoising mit Intels Lib dann in Sekunden geht.

Kann man doch sicher zuhause testen, oder?

 

[andi_sco]

Oo
Das ist sicherlich nicht der billigste Prozess der Kette..

Wollte ich auch gerade schreiben.
Wenn man von x Stunden pro Bild ausgeht.

 

[givemeajackson]

Moana hat mich damals mit der wasserdarstellung komplett aus den socken gehauen. Wer sich irgendwie für 3d rendering interessiert sollte unbedingt einen neueren disney film auf bluray schauen. How to tame your dragon 2 ist ein weiteres beispiel welches einfach nur unfassbar gut aussieht im bezug auf beleuchtung.

 

[Tatwaffe]

Auf der Intel Seite steht aber das nur sse4.1 benötigt wird.
Ich dachte ich erwähns mal weils so dick in der Überschrift steht das 4.2 benötigt wird
"Your CPU must support at least SSE4.1 to run Open Image Denoise, and you need a 64-bit operating system as well "