Crop + Resize oder Resize inklusive Crop?

  • Bisher waren doch wohl alle der Meinung: Warum erst croppen und dann resizen, wenn doch die Resizer-Funktionen auch schon einen Ausschnitt croppen können? Das wäre immerhin wesentlich effizienter. Man vergleiche auch DVD2SVCD mit GordianKnot.

    Dachte ich mir auch - bis ich durch einen hochscrollenden Vorspann entdeckte, dass es da in der Version vom 29.7.2004 sowie in der letzten RC2 vom 20.8.2004 doch Unterschiede gibt:

    LXG.avs mit Crop + Resize:

    Code
    MPEG2Source("LXG.d2v")STMedianFilter(8,15,4,7)Crop(0,72,720,440)Lanczos4Resize(512,208)Levels(0,1.4,255,8,248)Tweak(sat=1.2,cont=1.1)Trim(900, -100)


    LXG.avs mit Resize incl. Crop:

    Code
    MPEG2Source("LXG.d2v")
    STMedianFilter(8,15,4,7)
    Lanczos4Resize(512,208,0,72,720,440)
    Levels(0,1.4,255,8,248)
    Tweak(sat=1.2,cont=1.1)
    Trim(900, -100)


    Man achte auf den unteren Rand: Mit separatem Crop ist es sauber, mit Resize allein gibt's eine verdoppelte Zeile.

  • Vielleicht falsche Idee, aber Lanczos4Resize mit 2 Parametern ist int, ebenso crop mit 4 ints. Lanczos4Resize mit 6 Parametern ist crop Teil float (zumindest laut Doku). Float sollte eigentlich genau genug sein, aber vielleicht wird in die falsche Richtung gerundet.

  • Mit "vielleicht wird in die falsche Richtung gerundet" meinte ich Programmierfehler. Ich wollte es nur nicht so drastisch formulieren.

    Bei BilinearResize in VD gibt es das gleiche Phänomen, vielleicht verwandte Quelle:
    BilinearResize uses standard bilinear filtering and is almost identical to VirtualDub's "precise bilinear" resizing option. It's only "almost" because VirtualDub's filter seems to get the scaling factor slightly wrong, with the result that pixels at the top and right of the image get either clipped or duplicated.
    (Doku AviSynth)

  • Ich gehe mehr so von einem Fehler der Kathegorie "von hier bis kurz vor da" aus. Ich kenne das: Programmierer verwechseln öftes mal 0 und 1, bzw. "bis Maximum" mit "bis Maximum-1". Da es alle Resizer betrifft, wird's im Cropping-Teil des Algorithmus liegen, der für alle Resizer zutrifft.

  • Der Ärmste, der das jetzt im Source finden muß...

    Ich verwende für diese Aufgaben bisher VirtualDub, aber dort wird es dann vermutlich auch auftreten.

  • Du hast Recht. Ich habe nur gesehen, daß manche Filter für beide Programme verwendet werden und da VirtualDub GPL ist, könnte man auch Teile davon in anderen Programmen finden. Aber es stimmt, das ist reine Spekulation.
    AviSynth gefällt mir von der Beschreibung aber sehr gut, ich werde in Zukunft auch dieses häufiger benutzen. Zum capturen verwende ich aber auf jeden Fall VirtualDub.

  • Hi,

    also ich resize eigentlich schon ewig so in einer Zeile und mir ist nie was aufgefallen. Das was oben im Anhang ist, ist aber schon sehr drastisch, ich kann mir nicht vorstellen, das mir das nie aufgefallen wäre?!

    Wie schauts denn mit folgendem aus:
    BicubicResize(512,208,0,0.75,0,72,720,440)

    kommt da der gleiche Fehler? Ich hab bisher fast nie Lanczos verwendet.


    ....cu

  • Ich kann den Fehler mit einem anderen Clip bestätigen.
    Eigentlich ist mir das schon bei der Beta von AviSynth 2.55 vom 13.07 aufgefallen - da es in meinen Tests jedoch nur bei einem Clip auftrat und auch dort auch nur bei einer bestimmten Szene, dachte ich an irgendeine krankhafte Abnormität der Quelle. Es gab dort bei mir auch keine doppelte Zeile, sondern eine ca. 1 Pixelzeile (aua ;)) dicke braune Linie, etwa 3 Pixelzeilen vor dem Ende des unteren Randes.

    Gruss,
    Viperzahn

    Es ist zu einer gesellschaftsfaehigen Unsitte geworden, dass jeder etwas von sich geben muss, auch wenn er keinerlei Ahnung hat. Und wer vielleicht mal 30 Sekunden nachdenkt, bevor er etwas sagt, dem wird weniger geglaubt als jemanden, der sofort gutklingenden Muell von sich gibt.
    -> http://people.freenet.de/dynamischerpha…esse_halten.mp3

  • Lanczos und Bicubic b=0/c=0.5

    Um das Skript rekonstruieren zu können, muß ich den Film erneut rippen, da ich ihm seinerzeit nachträglich eine niedrigere Sicherungspriorität eingeräumt hatte.
    Mach ich morgen im Laufe des Tages.

    Gruss,
    Viperzahn

    Es ist zu einer gesellschaftsfaehigen Unsitte geworden, dass jeder etwas von sich geben muss, auch wenn er keinerlei Ahnung hat. Und wer vielleicht mal 30 Sekunden nachdenkt, bevor er etwas sagt, dem wird weniger geglaubt als jemanden, der sofort gutklingenden Muell von sich gibt.
    -> http://people.freenet.de/dynamischerpha…esse_halten.mp3

  • So, hab das noch mal reproduziert:

    Code
    LoadPlugin("DGDecode.dll")LoadPlugin("TomsMoComp.dll")##SOURCE=AssumeTFF(MPEG2source("DGIndex.d2v",iPP=true)).Trim(18131,0)##A1=SOURCE     \.SeparateFields()     \.LanczosResize(576,160,14,4,692,280)     \.Weave()#A2=SOURCE     \.SeparateFields()     \.Crop(14,4,692,280)     \.LanczosResize(576,160)     \.Weave()#B1=Interleave(SOURCE.TomsMoComp(-1,5,0),SOURCE.DoubleWeave().SelectOdd().TomsMoComp(-1,5,0))     \.AssumeFrameBased()     \.LanczosResize(576,320,14,8,692,560)     \.SeparateFields()     \.SelectEvery(4,1,2)     \.Weave()#B2=Interleave(SOURCE.TomsMoComp(-1,5,0),SOURCE.DoubleWeave().SelectOdd().TomsMoComp(-1,5,0))     \.AssumeFrameBased()     \.Crop(14,8,692,560)     \.LanczosResize(576,320)     \.SeparateFields()     \.SelectEvery(4,1,2)     \.Weave()#C1=SOURCE     \.TomsMoComp(-1,5,0)     \.LanczosResize(576,320,14,8,692,560)#C2=SOURCE     \.TomsMoComp(-1,5,0)     \.Crop(14,8,692,560)     \.LanczosResize(576,320)


    Der Fehler trat hier mit Lanczos3 und Bicubic b=0/c=0.5 nur bei A1 auf.


    Mit der Implementierung von SSRC stimmt auch irgendwas nicht ->

    Code
    V1=AVISource("8kHz_Mono_CBRMP3.avi",audio=true,pixel_type="YV12")
    	\.Crop(14,2,424,332)
    	\.BilinearResize(336,240)
    	\.Blockbuster(method="noise",detail_min=1,detail_max=100,mean=0,variance=10,cache=2048)
    	\.AddBorders(8,0,8,0)
    	\.AssumeFPS(29.970,sync_audio=true)
    	\.SSRC(48000,fast=false)
    		A=AudioDub(V1,MergeChannels(GetChannel(V1,1),GetChannel(V1,1)))

    Beide Kanäle des resultierenden Audiostreams müßten identisch sein, was jedoch nicht der Fall ist. Statt dessen sind beide Kanäle erst synchron, dann asynchron, dann wieder synchron usw. und an den synchronen Stellen stimmt die Wellenform oft nicht überein. ResampleAudio(48000) funktioniert.

    Gruss,
    Viperzahn

    Es ist zu einer gesellschaftsfaehigen Unsitte geworden, dass jeder etwas von sich geben muss, auch wenn er keinerlei Ahnung hat. Und wer vielleicht mal 30 Sekunden nachdenkt, bevor er etwas sagt, dem wird weniger geglaubt als jemanden, der sofort gutklingenden Muell von sich gibt.
    -> http://people.freenet.de/dynamischerpha…esse_halten.mp3

  • Zitat

    Könntest du vielleicht noch den Fehler weiter eingrenzen, indem du statt einer DGindex D2V Datei das klassische DVD2AVI nimmst?!


    Klar, selber Fehler mit DVD2AVI 1.77.3 von http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/ und MPEG2DEC3.dll von http://www.avisynth.org/warpenterprise…ll_20030728.zip
    Einstellungen:
    DGIndex iDCT = 64-bit Floating Point / DVD2AVI iDCT=32-bit SSE MMX - rest Standard

    Gruss,
    Viperzahn

    Es ist zu einer gesellschaftsfaehigen Unsitte geworden, dass jeder etwas von sich geben muss, auch wenn er keinerlei Ahnung hat. Und wer vielleicht mal 30 Sekunden nachdenkt, bevor er etwas sagt, dem wird weniger geglaubt als jemanden, der sofort gutklingenden Muell von sich gibt.
    -> http://people.freenet.de/dynamischerpha…esse_halten.mp3

  • Hmm,

    ich meinte eigentlich DVD2AVI 1.76.
    Am besten wäre es, wenn man den Fehler einfach nur nachvollziehbar machen könnte. Vielleicht mit Animate und Subtitle ne Animation generieren und die dann resizen bzw. croppen + resizen.
    Schliesslich ist das ein Bug und dieser sollte schnellsten entfernt werden, weil die resize Funktion lädt ja gerade dazu ein, das croppen wegzulassen.


    ....cu

  • Zitat

    ich meinte eigentlich DVD2AVI 1.76.


    Das macht keinen Sinn. Wenn mich meine Erinnerung nicht trügt, schreibt DVD2AVI 1.77.3 die gleiche Indizierungstabelle, lediglich im Kopf der Datei ist ein Informationswert dazu gekommen. Außerdem, wie weit zurück soll ich gehen? Soll ich anfangen AviSynth 1.0 beta irgendwas mit Dividee's MPEG2DEC.dll zu installieren? ;)


    Zitat

    Am besten wäre es, wenn man den Fehler einfach nur nachvollziehbar machen könnte.

    Code
    A=BlankClip(length=250,width=768,height=288,pixel_type="YV12",fps=25.00000,color=$FFFFFF)
    B=BlankClip(length=250,width=768,height=288,pixel_type="YV12",fps=25.00000,color=$000000)
    Interleave(A,B).AssumeFieldBased().Weave()
    Crop(16,8,736,560).LanczosResize(576,432) # LanczosResize(576,432,16,8,736,560)


    Zitat

    Vielleicht mit Animate und Subtitle ne Animation generieren und die dann resizen bzw. croppen + resizen.


    Bei mir tritt dieser Fehler nicht in einer kryptischen Animation oder ablaufenden Endcredits auf, sondern in einer normalen, aus natürlichen Bildern bestehenden Szene.

    Gruss,
    Viperzahn

    Es ist zu einer gesellschaftsfaehigen Unsitte geworden, dass jeder etwas von sich geben muss, auch wenn er keinerlei Ahnung hat. Und wer vielleicht mal 30 Sekunden nachdenkt, bevor er etwas sagt, dem wird weniger geglaubt als jemanden, der sofort gutklingenden Muell von sich gibt.
    -> http://people.freenet.de/dynamischerpha…esse_halten.mp3

  • Viperzahn

    den Code den du da geposted hast, kann man da den Fehler mit aufdecken?!
    Ich habs mal kurz in VdubMOD reinkopiert und sehe keinen Unterschied zwischen crop und crop + resizer.

    Vielleicht kann sich ja auch jemand anders dazu mal äussern, immerhin sieht der fehlerhafte anhängsel von LigH ziemlich übel aus.


    ....cya

  • Mein Beispiel lässt sich ja immerhin mit praktisch jeder DVD als Testquelle und möglichst einem Vertical-Scroll-Bereich (z.B. Abspann) nachvollziehen; STMedianFilter kann man sicher auch weglassen.

    Leider kommt im englischen Forum nicht viel zu diesem Thema: Kaum bringt einer ein anderes Problem, wird erst mal darüber diskutiert, und ich kann meins dann nur noch immer wieder in Erinnerung rufen. War beim "Orange-blue bug" nicht anders (milan hatte die Unterstützung für die Rundungsfehler in DivX 5.0 bis 5.0.2 mal zwischendurch versehentlich herausoptimiert).
    __

    Hab mal Viperzahn's Script erweitert, um Differenzen zu verdeutlichen:

    Code
    A=BlankClip(length=250, width=768, height=288, pixel_type="YV12", fps=25.00000, color=$FFFFFF)B=BlankClip(length=250, width=768, height=288, pixel_type="YV12", fps=25.00000, color=$000000)Interleave(A,B).AssumeFieldBased().Weave()C=Crop(16,8,736,560).LanczosResize(576,432)D=LanczosResize(576,432,16,8,736,560)Subtract(C,D).Levels(96,1,160,0,255)

    Ich hab keine gesehen. Bei meiner Variante sieht man komischerweise dafür erhebliche Unterschiede:

    Code
    MPEG2Source("LXG.d2v")
    Clip1=Lanczos4Resize(512,208,0,72,720,440)
    Clip2=Crop(0,72,720,440).Lanczos4Resize(512,208)
    Subtract(Clip1,Clip2).Levels(96,1,160,0,255)
  • Zitat von LigH

    ...Ich hab keine gesehen. Bei meiner Variante sieht man komischerweise dafür erhebliche Unterschiede:...

    Hi,

    das ist aber doch ein Hinweiss darauf, das nicht unbedingt der resizer fehlerhaft ist, sondern irgendwas davor?!
    Ich hasse mystische Bugs die mal auftreten und mal nicht.


    ....cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!