strange Normwandlung (sample inside)

der link geht nicht
(ja ich weiss wie man mit Geocities umgeht...)

https://localhost/www.arcor.de

Für eine so kleine Datei wäre doch Bittorrent die Lösung.

Ich habe dieser Tage sehr gute Ergebnisse erzielt, wenn man VOR der Restore24() Funktion entrauscht und zudem "adaptiv" schärft. D.h. weiche Kanten (wie bei blendings) bleiben weich und harte werden geschärft, das differenziert reguläre und blended Frames noch mehr. Somit hatte ich WESENTLICH weniger rest-artefakte.

Was die geschw. angeht. Tja, da musst du wohl in den sauren Apfel beissen, denn für mich kommen ebenso nur die optimalen Settings bei Restore24() in Frage.
WAS du aber machen kannst, ist z.B. direkt in 352x576 aufzunehmen oder am Anfang des Scriptes zu resizen, dadurch verringert dich der Rechenaufwand von R24() erheblich. Zudem sind NTSC/PAL Normgewandelte Sourcen meist eh nicht so Scharf, ud es ist ein guter Kompromiss. Dies mache ich z.B. um Folgen von Serien auf DVD zu bekommen und da bekommt man schon einiges auf eine DVD und zudem dann progressiv

incredible: schliesze DIch doch deswegen mal mit Didée in Verbindung.
(btw. hast Du schon mein update von restore24 gesehen?)

also, wenn mir der input zu verrauscht ist, nehm ich ganz brutal

separatefields().pixiedust(limit=?).weave()
(auch wenn bewegungskompensiertes entrauschen bei blends nicht so sinnvoll ist, ists besser als mit anderen denoisern)

vor dem intellibob(), aber nicht vor dem r24kernelbob()....

denn seit dem update gibts ne bessere edgemask in r24, die eigentlich sehr rauschresistent sein sollte...

Also ich habe den von dir HIER zur Verfügung gestellten R24() Ordner genutzt. Download vor ca. 2 1/2 Wochen.
Ich war 2 Wo in Urlaub demnach: Gibt es wieder ein neues Update von dir?

Bei mir und dem capturen ists ja so ...
.. wie im hiesigen Capture Forum beschrieben erledige ich das Denosien (smart) und shapen bereits beim Aufnehmen (bin da dieser Tage wie wild am testen) ... alles über den ffvfw Codec. Als Aufnahmecodec nehme ich mjpeg oder HuffYUV (interne ffvfw's).
Daher diese Bemerkung mit dem Filtern VOR dem "Restoren"

Die internen Denoise filter von ffvfw/ffdshow sind meines erachtens etwas besser und kommen schon näher an Pixiedust ran als die geläufigen avs 2.5er Denoiser.
Und wenn man NICHT während des capturens filtern möchte, kann man ja das avi mit ffdshow dekodieren/filtern lassen wenns in den Frameserver geht.

BTW: Habe gestern hier für die Agentur (NTSC zu PAL) Werbespots (L'Oreal etc.) via R24() zu progressiv gebracht, und zwar für eine Powerpoint Präsentation (PC/Beamer).
Genial dieses Ding von Didée inkl. der optimierung von Dir.

klar, hast Du da noch ne menge ghosts drinnen, weil der NTSC - 'Master' schon recht stark 'entrauscht' wurde.
dann noch ne normwanldung hintereher und fertig ist der blend matsch.

dieses script, verhilft wenigstens zu einer fluessigen bewegung:

setmemorymax(512)
loadplugin("C:\x\dgdecode.dll")
loadplugin("C:\x\kerneldeint140.dll")
loadplugin("C:\x\tcombmask.dll")
loadplugin("C:\x\masktools.dll")
loadplugin("C:\x\removeblend.dll")
loadplugin("C:\x\avisynth_c.dll")
loadCplugin("C:\x\smartdecimate.dll")


import("C:\x\avs-scripts\intellibob.avs")
import("C:\x\avs-scripts\restore.avs")
mpeg2source("yakuza1.d2v",cpu=6,iPP=true)
crop(16,80,-16,-80)


a=r24kernelbob()
b=intellibob()
restore24(a,b)


tweak(hue=+20)
lanczos4resize(624,336,2,6,686,404)

dann mach die r24 behandlung doch mit huffyuv oder VBLE als encoder.
wird zwar riesig viel auf er HDD, aber die wandlung dauert dann nicht solange, bis du ergebnisse hast.

btw. den hue solltest Du unbedingt aendern! (also den wert nehmen, den ich im script verwende!)

Das wird Ihm fast nichts bis gar nichts nutzen, weil AviSynth hier die extreme Bremse ist, nicht dier Zielcodec

Letztendlich zählt das, was die CPU alles leisten muss, und wenn neben Avisynth AUCH noch ein CPU intensiver encoder zum Einsatz kommt, dann verlängert sichs nochmal.

Aber eine Enkodierung vorab in ein Zwischenformat um dann letztendlich ins gewünschte Format zu wandeln wäre ein Umweg.

Um festzustellen, wie die funktion "greift", bestimme ich oft spezielle Abschnitte mit Trim().

Viperzahn: natuerlich nutzt das zwischenrendern nach HuffYUV sehr viel:

fiktive werte:

renderzeit von restore24 ohne encodiing: 16h
encodingzeit fuer huffyuv ohne vbideoprocessing: 1h
encodingzeit von XVId (einen Pass) : 4h

so, wenn wir two-pass mit xvid ohne zwischenschritt machen, landen wir bei
16+4 h fuer den 1. pass
und
16+4 h fuer den 2. pass

macht also 40h

wenn man jetzt aber einen zwischenschritt mit huffyuv macht, sieht das ganz anders aus:

20h + 1h fuer huffy rendering
4h + 4h (1st & 2nd pass)

macht also 29h. na wenn das mal nicht schon schneller ist.

ausserdem kann man sich das huffy noch in aller ruhe VOR dem encoding anschauen und eventuelle schnitzer beseitigen.

weiterhin kann man mit den xvid-settings probieren, ohne jedesmal r24 neu ueber das video laufen lassen zu muessen

Wenn etwas Verlustfrei ist, dann HuffYUV

Schaue mal bis wohin (wenn es noch zu lesen ist) encodiert worden ist und checke ab dort das Original, ... also ob es da einen Fehler auf der HD gibt etc.

den hue hab ich per "augenmasz" ermittelt.
(aendere ihn wenn Du noechtest. er ist aber auf jeden Fall falsch, so wie es auf der DVD ist)

und das mit den gelberen gesichtern ist auch nur ein geruecht!

die leute haben genauso rosa oder braune hautfarbe wie wir.
(je nach sonnenexposition der haut)

HuffYUV braucht etwa 10 MByte/sec (also 80 Mbps) fuer Full PAL (7xx*576)

bei kleineren aufloesungen entsprechend weniger