Beiträge von Didée

Schön wenn's funktioniert. Allerdings muss der Code schon in zwei Zeilen geschrieben werden, so wie ich's gepostet hatte. In einer Zeile, über "." verkettet, ist es falsch. So können die beiden Select()'s den NNEDI nämlich noch gar nicht "sehen", sondern nehmen die vorherige Zeile als Input. Avisynths Konzept von "inherent 'last' ".

Aaaahhh ... moment mal.

Zitat

Bob().SelectEven().PointResize(...) -> reencode Xvid

Ist das mit dem PointResize() wirklich sicher? Wenn ja, dann ist das schon ein Problem.

Ein "stärkeres" AA das auch über den (schwierig zu fixenden) Phase-Shift von einem Pointresize drüberbügelt (die bob()-interpolierten Zeilen liegen mal in den Even-Fields, mal in den Odd-Fields) wäre dann

NNEDI3(field=-2)
Merge(SelectEven(),SelectOdd())

Das ist vom AA her auf jeden Fall stärker, kann aber (so wie alles andere) nicht viel gegen eventuelle "Unstetigkeiten" in der Signalkurve ausrichten, die von PointResize ggf. verursacht wurden.

Zitat von may24

Hi, na ja ich hab ihn jezt mal eingebaut, aber sehr viel un-aliased des nicht:

Code

nnedi3(0, dh=true).turnright().nnedi3(1, dh=true).turnleft().spline64Resize(720,406)

So ist das ja auch falsch.:) - Du willst nicht die Höhe des bereits gebobbten Clips verdoppeln (wobei automatisch die "schlechte" Interpolation von Bob() im Bild drinnen bleibt) ... sondern Du willst die von Bob() interpolierten Zeilen komplett verwerfen, und durch eine neue/bessere Interpolation ersetzen. Also: ohne "dh=true", und in der Folge auch ohne TurnLeftRight() oder hin-und-her-Resizing.

Abhängig davon ob das Originalmaterial BFF oder TFF war, entweder

NNEDI3(field=0) oder NNEDI3(field=1)

Im Zweifelsfall einfach probieren, eines der beiden sollte augenfällig "schärfer" erscheinen.

Die Motion Compensation ist DAS zentrale Element von QTGMC. Abschalten macht keinen rechten Sinn, weil dann QTGMC als ganzes keinen rechten Sinn mehr macht. (In TGMC hatte ich noch die "draft"-Option drin, die tatsächlich eine "schnell+dreckig"-Operation ohne MC durchgeführt hat. Weiß nicht ob die in QTGMC noch drin ist oder nicht ... interessiert auch nicht wirklich. Gedacht war die hauptsächlich nur für "Vorschau"-Zwecke, weniger zur eigentlichen Benutzung....)

Komplett ohne die pöse pöse MotionCompensation:

NNEDI3(field=-2)

Fertig, Feierabend. Zeitfilter geht nicht, weil DER macht ja die Geisterbilder. Die MotionCompensation ist dazu da, diese Geisterbilder zu vermeiden ... und genau das macht sie ja auch. Wenn überhaupt, dann treten Doppelbildartefakte an irgendwelchen Stellen auf, wo die MC mal nicht richtig gearbeitet hat. Wenn man nun aber die MC komplett abschaltet, dann arbeitet sie niemals und nirgendwo richtig.
(Den letzten Absatz bitte so oft lesen bis es "klick" macht.);)

... und da es sich um "Serien" handelt: wenn tatsächlich "Interlacing" vorliegt, dann handelt es sich mit 99% Wahrscheinlichkeit nicht um normales Interlacing, sondern um eine Fieldblended Normconversion, wo es dann mit einfachem Deinterlacing nicht getan ist, sondern man zu Srestore greifen müsste ...

Zitat von Lapje

Mein Gedanke dahinter: Ich möchte jetzt z.B. nicht in 4.1 kodieren, wenn die Erhöhung bei einer Austrahlung in 3.2 oder 4.0 überhaupt nichts bringt, es aber zu Nachteilen bei der Wiederhabe kommen könnte.

Oder direkt gefragt: Hätte eine Erhöhung des Levels irgendwelche Vorteile?

Mir scheint, Du erstellst da gedanklich einen "falschen Zusammenhang". Die verwendeten Levels bei einem re-Encoding haben, rein bildtechnisch, absolut gar-nichts mit den verwendeten Levels des Eingangsmaterials zu tun. Vereinfach gesagt sind die Levels ein Maß dafür, wieviel Komplexität der Encoder verwenden darf, um viel möglichst viel Qualität bei möglichst kleiner Bitrate zu erzielen. Von daher macht es absolut Sinn, ein zB. Levels 3.0 - Eingangsmaterial mit zB. Levels 4.1 beim Re-Encoding zu Kodieren. Der Encoder bekommt irgendwelches Bildmaterial, und dieses Bildmaterial kann er um so effizienter kodieren, je höhere Levels er verwenden kann.

Die einzig entscheidende Frage ist, auf welcher Hardware das Ergebnis potentiell abgespielt werden soll. Dafür muss man gegebenenfalls entsprechend kleine Levels verwenden. Aber einen Bezug auf die Levels-Einstellungen des Eingangsmaterials gibt es nicht.

Zitat von may24

das Motion Compensation ist manchmal etwas fehl am Platz. Gibt es eine Möglichkeit dioeses zu deaktivieren ?

Bitte mal erklären, inwiefern das MC fehl am Platz sein sollte, bzw. warum Du es deaktivieren willst?

Einerlei ... für (fast) alle denkbaren Möglichkeiten gilt: würde man die MC abschalten, würde es bestimmt nur noch schlimmer. Bestenfalls würde es nicht besser.

Ja, diese feinen Strukturen von kleinem Text, und insbesondere asiatische Schriftzeichen, die können einen Bob/Deinterlacer sehr leicht durcheinanderbringen. Der Filter interpretiert sowas gerne als "Lacing/Combing", obwohl es gar keines ist, und deinterlaced (interpoliert) die betreffenden Bereiche, obwohl es gar nicht nötig wäre.

In so einem Fall böte es sich an, von dem initalen Bob-Deinterlacer einen spatialen High-Pass abzugreifen, diesen mit einer Kombination aus sich gegenseitig beschränkenden temporal-GaussFilter und temporal-Medianfilter zu filtern, und dann den auf dem High-Pass erzielten Effekt auf das Original zu übertragen.

Muss man wohl nicht weiter erklären - ist ja offensichtlich, es drängt sich einem geradezu auf.

# dgdecode.dll
# removegrain_sse2.dll
# mt_masktools-25.dll
# srestore.avsi


v1 = mpeg2source("D:\__DL\VTS_01_CHAPTER_16_1_tt.demuxed_cut.d2v") 
v2 = mpeg2source("D:\__DL\VTS_01_CHAPTER_16_1_tt.demuxed_cut_2.d2v")


v1+v2


yadif(mode=1)


o    = last
LOP  = o.removegrain(11).removegrain(4).removegrain(11)
HIP  = mt_makediff(o,LOP)
D1   = mt_makediff(HIP,HIP.clense(reduceflicker=false))
D2   = mt_makediff(HIP,HIP.temporalsoften(1,255,0,26,2))
DD   = mt_lutxy(D1,D2,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?")
calm = o.mt_makediff(DD,U=2,V=2)


# stackhorizontal(o,calm)  # nur zum Nachschauen/Vergleichen, ob das ganze eigentlich was bringt ;-)


calm.srestore(frate=23.976)


return(last)

Man könnte da natürlich auch anders herangehen, oder auch ganz anders. Aber, diese Methode erscheint mir aus dem Bauch heraus als am einfachsten, mit den meisten positiven und den wenigsten negativen Nebenwirkungen.

Srestore ist schon richtig. Nur tfm() davor, das ist falsch. Srestore muss im Regelfall immer ein Bob-Filter vorangehen.

Mpeg2Source("whatever.d2v")
Bob() # oder z.B.: Yadif(mode=1)
Srestore(frate=23.976)

a) Avisynth: Quadrilateral,
b) Avisynth: xyremap,
c) Avisynth: Reform

sollten allesamt in der Lage sein, die gewünschte 2D-Transformation zu erzielen.

Zitat von Rattenjäger

(Nebenbei bemerkt, bei Filmen von 24p auf 48p zu gehen wirkt Wunden und funktioniert in jeder Situation, was bei Fernseher die das in Echtzeit machen müssen nicht der Fall ist.)

Nebenbei vermutet: Du hast nicht zufällig einen Fernseher von LG, nein? Wenn Dir die Echtzeitberechnung von TVs nicht gefällt, dann hast Du wahrscheinlich keinen Samsung oder Sony?

Prozent zu Qualität verhält sich wie Wurstbrot zu Turnschuh.

Sehr generischer Lösungsansatz zur Halo-Entfernung: "Gauss-Blur mit Radius 1, beschränkt auf Halo-Edgemask". (Halo-Edgemask ist: die Kantendetektion auf das Ergebnis einer Kantendetektion)

Halomask_DeHalo.png

Hab' das allerdings nicht mit Avisynth gemacht, sondern Step-by-Step in der Bildbearbeitungssoftware, die war eh' gerade offen. Müsste man halt in Avisynth nachbauen. Im Prinzip ist das aber sowieso "BlindDeHalo3", mehr oder weniger.

Quasi-Code:

source.Resize(50%).Edge(roberts).Resize(100%).Edge(roberts)
Expand().Inflate().Darken(last,mask=last.Expand(2).Inpand(2))
Source.Merge(source.gauss(r=1),mask=last)

Könnte sein, dass bei einer MaskTools-Implementierung ein anderer Kernel als "Roberts" besser geeignet wäre.

Oh, ja. Wenn man für den TFT so herumbiegen muss, dann ist das für die Darstellung ganz schlecht - die Korrekturen erfolgen da ja i.d.R. nur in einem 8bit-Farbraum, da bringt jedwede "Korrektur" automatisch Tonwertverluste mit sich. (Im Büro hab ich auch so ne Gurke, ein alter Philips, der zeigt von RGB 0 bis 16~20 nix als Schwarz ... und Voll-Gelb ist Neon-Zitronen-Gelb)

Aber trotzdem: der Unterschied, den Du mit dem Differenz-Bild aufgezeigt hast, der dürfte sich wohl weitgehend mit der RGB 0-255 <> YUV 16-235 Geschichte erklären lassen.

Zitat von LigH

Differenz ... Sieht hübsch bunt aus.
Ist das wirklich nur die RGB-YUV-Konvertierung? Oder steckt da noch mehr dahinter?

Das dürfte, so weit, wirklich zu einem *sehr* großen Teil der RGB > YUV Konvertierung zu schulden sein. Überleg' mal: die RGB-Daten belegen das vollständige Spektrum 0-255. Und bei der Konvertierung zu Standard-YUV wird das Spektrum gleich mal auf 16-235 zusammengeschnurzelt. Also Reduzierung von 255 Helligkeitsstufen auf 220 Helligkeitsstufen. Ist keine Überraschung, dass da sowas wie Banding entsteht, und in diffizilen Bereichen auch sichtbar wird.

Soweit es die CRF6 - "Arbeitsdatei" angeht, dürfte es wohl gleich deutlich besser werden, wenn man mit ConvertToYV12(matrix="PC.709") ein Fullrange-YUV erstellt. Natürlich muss irgendwann später trotzdem die Reduzierung auf Standard-YUV 16-235 vorgenommen werden, und da wird man für maximale Qualität an Dithering nicht vorbei kommen. Aber für's Erstellen der komprimierten Arbeitsdatei sollte Fullrange-YUV - vermutlich - erst mal ausreichen.

Möglich, aber wenn schon QTGMC, warum dann überhaupt noch TFM? Dann könnte man doch auch gleich QTGMC().SelectEven() ...

Ooooder ... TFM(slow=2,pp=0).Vinverse()

Soweit es den geposteten Videoschnipsel betrifft - der ist nicht blend-konvertiert, und in gewissem Sinne auch nicht "richtig", sondern eher "falsch interlaced". Sprich: Phase-shifted progressive.

Wenn es durchgängig so ist wie im Sample, dann könnte man mit "separatefields().trim(1,0).weave()" die verteilten Halbbilder wieder zu Vollbildern kombinieren.
In vielen Fällen kann man der Sache aber nicht so recht trauen, oft hat man einen "dynamischen" Phase-Shift, d.h. es wechselt zwischen Sequenzen [mit] und [ohne] Phase-Shift. Und statt alles von Hand abzusuchen und abschnittsweise zu korrigieren, ist ein automatischer Field-Matcher wesentlich bequemer: TFM() aus der TIVTC.dll.

Vertikaler Fieldshift hat einen Phase Shift der Chroma-Ebene verursacht.

mpeg2source("chroma_beispiel.d2v")
a=last
b=a.mergechroma( a.swapfields() )
stackhorizontal(a,b)
bob() # zur Visualisierung was richtig / was falsch ist

Zitat von Selur

dass Du bei so hohen Datenraten und dem Material einfach keinen Unterschied mehr siehst.

Genau, das hatte ich ja auch schon geschrieben. Nun bin ich hier allerdings etwas "entsetzt" über die Bitrate, die Genesis bei diesem CRF18 - Test 'rausbekommen hat. Rund 40 Mbps bei CRF18 ist schon recht gewaltig! Ich mach' keine Game-Captures ... ist das normal bei solchem Material wie Skyrim? Oder, (mein Verdacht), war da noch immer das Avisynth-Script mit dem "Sharpen(1)" in Verwendung? Das würde die sehr hohe Bitrate nämlich gut erklären ... grundsätzlich treibt ja jeder Schärfe-Filter die Bitrate in die Höhe, aber Sharpen() ist besonders schlimm, und erst recht mit voller Stärke (1.0), weil das Ding wegen Rechen- bzw. Rundungs-Ungenauigkeiten auch noch 'ne ganze Menge Pixelrauschen hinzufügt. Und sowohl Luma als auch Chroma (!) schärft, wogegen viele andere Schärfer ja nur in Luma agieren.

40 Megabit bei CRF18. Hei-ei-eieiei ....

Zitat von sneaker2

Bei seinem zweiten Beitrag hat er es ja nun auch auf 1500 kbit/s runtergesetzt.

Die 1500 mit dem "Uaah"-Ergebnis waren aber gar nicht die Spezial-Settings von Genesis. Das war Preset Medium, wie der Dateiname nahelegt. Quantizer-Level 19.9 mit 29.5 vergleichen. - Also, so als Gute-Nacht-Witz war das schon ganz gut.