Avisynth - Editing Non Lineare


Scritta da aytin il 17-01-2006

Piccolo e letale. Avisynth un potentissimo strumento di editing audio-video.


EDITING NON LINEARE CON AVISYNTH 2.5.5

- scritta da: ..::Aytin::..
- collaborazione, supporto, revisione: ..::Divxmania Staff::..


1. Premessa

Il seguente articolo non ha la pretesa di essere un manuale d'uso, quindi non aspettatevi noiosi rendiconti su liste di filtri, ma vuole raccogliere in linea di massima le esperienze di chi utilizza Avisynth in modo da evidenziarne gli aspetti più interessanti.

Può essere un utile riferimento per chi ci si accosta per la prima volta, facendone un uso minimale. Va bene anche per quello.

Altrimenti si può decidere di andare oltre il semplice utilizzo, utilizzando delle tecniche di editing che risolvano i vari problemi legati all'acquisizione.
Rimane inteso che, in questo caso, non si può prescindere dalla documentazione allegata, alla quale questo articolo non vuole sostituirsi ma vuole essere un supporto per una metodologia dell'acquisizione.

L'articolo è diviso in due parti principali, A e B.
La prima, introduttiva, è destinata a chi sta iniziando ad usare questo tool e magari non vuole entrare nel merito delle caratteristiche più sofisticate.
La seconda parte approfondisce meglio alcune tematiche legate alla codifica, mostrando come si possano risovere tramite Avisynth.
Nel farlo, necessariamente si suggerisce l'uso di alcuni filtri. Ovviamente per ognuno di essi ne esistono almeno altri 10 simili se non migliori.
La scelta è legata esclusivamente al gusto e all'abitudine personale. Il vostro, chiaramente, può essere benissimo diverso.

Quello che mi premeva particolarmente, era soprattutto evidenziare la gerarchia esistente nelle operazioni di editing.
Spero che essa risulti sufficientemente chiara. Poi, come si deciderà di affrontarla, dipenderà da voi. Io mi sono limitato a suggerire uno dei possibili approcci new_smileyb.gif

Tutto quello che leggerete non è assolutamente da considerare come un riferimento assoluto. Tutt'altro.
Spero, anzi, che possa stimolare la nascita di interventi, correzioni (tante), rettifiche e migliorie da sviluppare direttamente sul forum di www.divxmania.it.
Un feedback da parte vostra è più che gradito.

Bene. Occupiamoci ora dell'aspetto relativo alla codifica in MPEG-4.

Per il backup dei DVD esistono diversi ALL-IN-ONE più o meno buoni che consentono, in pochi passaggi, di effettuare la codifica in MPEG-4 con risultati apprezzabili.
Vi sono dei casi però in cui il raggiungimento di un buon risultato dipende da fattori che un ALL-IN-ONE non riesce a controllare.
Ad es. Tutto questo si può ottenere a patto di cambiare approccio alla codifica, ossia avere un controllo più fine dei processi di acquisizione, sia di quello video che di quello audio.



PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10. Post-Processing e altre peculiarità 2. Cos'è Avisynth

Avisynth è una dll usata anche per il frameserving, ma è anche, e soprattutto, un potentissimo strumento di editing non lineare.
L'editing è non lineare quando gli interventi sui frame non sono condizionati dalla loro sequenzialità. I frames possono essere ritoccati, ricostruiti, rimontati in un ordine che non necessariamente è quello iniziale.
Un esempio di editing lineare è invece il montaggio su una VHS.

Il frameserving è una tecnica secondo cui un applicazione (Avisynth) processa i frame di una sorgente (es. MPEG-2) per consegnarli ad un'altra applicazione (VirtualDub Mod) che li acquisisce e li codifica per mezzo del codec (DivX, XviD, X264, VP7,...).

user posted image

fig. 2.1

Dove sta il vantaggio nell'usare il frameserving di avisynth? user posted image
La velocità nella codifica si apprezza a patto di confrontare un all-in-one sugli stessi filtri e sullo stesso numero di essi.
A queste condizioni, non c'è paragone. Avisynth è nettamente superiore.
Ovviamente se arricchisco il mio script con un buon numero di filtri (a volte è necessario) che facciano denoise, smoothing, sharpening, deinterlace (nelle altre sezioni verrà spiegato il significato e l'uso di questi termini) la velocità si riduce drasticamente perchè ogni frame viene elaborato pesantemente.




PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10. Post-Processing e altre peculiarità 3. Installazione di Avisynth

Avisynth è scaricabile da http://www.avisynth.org oppure dalla sezione download di Divxmania.
Al termine, non avrete un programma da eseguire, ma una dll presente nella directory di sistema di Windows (generalmente c:\windows\system32) mentre in "Start\Programmi" avrete i riferimenti alla documentazione e alla cartella dei plugins che conterrà i filtri.

user posted image

fig. 3.1

Esistono anche altri tool come GordianKnot, AutoGK, ARCalculator che, facendo uso di avisynth, provvedono ad installarlo automaticamente.

Ok, una volta installato, siamo pronti per lavorare con il nostro tool.

Per farlo basta un editor semplicissimo, es. il Blocco Note di Windows oppure, se c'è disponibilità (e dev'essere così, perchè vi servirà in ogni caso), si può usare l'editor integrato in VirtualDub Mod che dispone, per le istruzioni che fanno parte del core di Avisynth, anche di un simpatico code-completion attivabile con CTRL+SPACE.

user posted image

fig. 3.2

Per l'installazione dei plugin non occorre nessun accorgimento particolare.
Basta scegliere una directory o crearla ad hoc e depositarvi tuttil i plugin, che non sono altro che dll.
Le dll saranno riferite all'interno dello script tramite loadPlugin (vedi esempi al par. 4.2).

user posted image
Consiglio questo approccio perchè usare la directory di default può crare qualche problema.
L'attivazione di Avisynth infatti, comporta il caricamento di tutte le dll che sono presenti nella directory di default e alcune di esse possono andare in conflitto causando il crash dell'applicazione che sta usando Avisynth.




PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10. Post-Processing e altre peculiarità 4. Primi Script

Avisynth è un tool per l'editing video ma non aspettatevi una Gui per il settaggio dei paramentri.
Avisynth viene settato attraverso degli script ed è sulla preparazione di questi script che si concentrerà tutto il resto.
.
Nell'economia della codifica MPEG-4 tutto quello che serve è: Lo script nella fig. 2.2 vale come esempio del "minimalismo" accennato sopra.

CODE

#Caricamento filtri.
#Il DGDecode serve per accedere all'indice dei frames
LoadPlugin("C:\PROGRAMMI\DGMPGDec\DGDecode.dll")

#SORGENTE
mpeg2source("c:\film.d2v", idct=0)

#CROP, per il taglio delle bande nere
crop(6,14,708,548)

#RESIZE
BilinearResize(512,272)


L'ordine nelle operazioni non è casuale.
crop -> filtri -> resize
Normalmente il resize avviene dopo l'applicazione dei filtri, i quali sono successivi al crop (e anche questa sequenza potrebbe essere ampiamente discussa su elaborazioni particolari che verranno discusse più avanti. Al momento, è sufficiente per i nostri scopi).
Per ragioni di pulizia innanzitutto, ma anche perchè un denoise (i filtri che attenuano il rumore video) è meglio che lavori sui frame originali, in modo che levi,il più possibile, solo il rumore senza toccare i dettagli rilevanti.
Il resize apporta delle approssimazioni e se il denoise lavorasse sul risultato del resize lo farebbe in modo scorretto.
Ovviamente rimane il fatto che lavorare dopo il resize, quindi su frame ridimensionati, è più vantaggioso dal punto di vista della velocità.

user posted image
Non si creda che le speculazioni enunciate finora corrispondano ad un rigido modello applicativo dal quale non ci si possa discostare.
Sono frutto di esperienze personali e di considerazioni "ragionevoli" nell'applicazione dei filtri.
Nessun limite viene posto alla creazione di un diverso processo applicativo che chiunque usi avisynth potrebbe proporre.



Ora analizzeremo con cura lo script, perchè le operazioni evidenziate sono quelle che ritroverete nel 99% delle codifiche elementari (da usare quindi come base per script futuri) user posted image
Un altro resize che può tornare molto utile è il simpleResize. Nella gerarchia tracciata in precedenza, lo si può collocare fra il bilinear e il bicubic (Bilinear -> Simple -> Bicubic -> Lanczos) e garantisce una buona definizione senza appesantire eccessivamente l'immagine.


Ogni funzione di Avisynth restituisce un clip ossia una sequenza di frame.
Il risultato viene acquisito implicitamente oppure può essere memorizzato in una variabile se si vogliono eseguire delle elaborazioni più fini.
L'applicazione delle funzioni sui clip può avvenire: Alla luce di quanto, detto lo script precedente equivale:

CODE

#Caricamento filtri.
#Il DGDecode serve per accedere all'indice dei frames
LoadPlugin("C:\PROGRAMMI\DGMPGDec\DGDecode.dll")

#SORGENTE
sorgente=mpeg2source("c:\film.d2v", idct=0)

#CROP, per il taglio delle bande nere
clip=sorgente.crop(6,14,708,548)

#RESIZE
clip=clip.BilinearResize(512,272)


ma anche a:

CODE

#Caricamento filtri.
#Il DGDecode serve per accedere all'indice dei frames
LoadPlugin("C:\PROGRAMMI\DGMPGDec\DGDecode.dll")

#SORGENTE
sorgente=mpeg2source("c:\film.d2v", idct=0)

#CROP, per il taglio delle bande nere
clip=crop(sorgente,6,14,708,548)

#RESIZE
 clip=BilinearResize(clip,512,272)


e a tutte le variazioni del caso.

4.1. Selezione di una porzione video

Volendo rendere lo script un filo più sofisticato si può ricorrere all'utlizzo di trim per selezionare porzioni di video su cui applicare filtri differenti.
Ad es.

CODE

#Caricamento filtri.
#Il DGDecode serve per accedere all'indice dei frames
LoadPlugin("C:\PROGRAMMI\DGMPGDec\DGDecode.dll")

#SORGENTE
mpeg2source("c:\film.d2v", idct=0)

#CROP, per il taglio delle bande nere
crop(8,74,704,428)  

#RESIZE
a=trim(0,1000).BilinearResize(576,240)
b=trim(1001,134678).BicubicResize(576,240,1/3,1/3)
c=trim(134678,0).BilinearResize(576,240)

return a+b+c


In questo caso abbiamo selezionato 3 porzioni video a cui applicare 3 resize differenti, il secondo un pò più aggressivo rispetto agli altri,
Ogni porzione viene assegnata ad una variabile e, alla fine dello script viene ricomposto il film intero ossia a+b+c.
E' quello che si fa nel caso in cui per i titoli di testa e di coda si vogliano minimizzare le risorse. Il bitrate risparmiato viene utilizzato per il film.

4.2. Come migliorare la comprimibilità

Se si vuole migliorare la comprimibilità si può ricorrere all'uso di un paio di semplici tecniche:
  1. Riduzione della luminosità
  2. Riduzione minimale del dettaglio

    E un paio di considerazioni ragionevoli:

  3. Uso di resize meno aggressivi
  4. Diminuzione della risoluzione
Il senso della prima nasce dal fatto che i codec MPEG-4 hanno una difficoltà congenita nel comprimere le scene chiare a differenza di quelle scure che sono ottimamente comprimibili. Riducendo un pochino la luminosità si aumenta la comprimibilità senza che le immagini siano troppo degradate.
Stesso discorso per il dettaglio. Riducendolo in minima parte, non sarà comunque visibile ad un'analisi superficiale del video, a tutto vantaggio della comprimibilità.
La scelta di ridurre la risoluzione e/o l'aggressività del resize prescinde ovviamente dal tool in oggetto, ma è di carattere generale e abbastanza nota.

user posted image
Si sa che più la risoluzione è alta e più si deve pompare il bitrate per non rischiare la produzione di artefatti indesiderati.
Idem dicasi per il resize. Senza dilungarmi ulteriormente, a una maggiore aggressività deve corrispondere un bitrate sufficiente ma anche una risoluzione adeguata (vedi Scelta Resize)
Ad es. secondo me è inutile utilizzare un filtro come il Lanczos su una risoluzione tipo (512,xxx). Oltre che a richiedere un certo numero di risorse in termini di bitrate, pena la produzione di blocchetti,renderebbe in ogni caso le immagini inutilmente spigolose e introdurrebbe un sacco di rumore video.
Si tenga anche conto infatti che la precisione del resize si paga anche in termini di rumore introdotto.


CODE

#Caricamento filtri.
#Il DGDecode serve per accedere all'indice dei frames
LoadPlugin("C:\PROGRAMMI\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRAMMI\Avisynth 2.5\filtri\Undot.dll")
LoadPlugin("C:\PROGRAMMI\Avisynth 2.5\filtri\Unfilter.dll")

#SORGENTE
mpeg2source("c:\film.d2v", idct=0)

#CROP, per il taglio delle bande nere
crop(6,14,708,548)  
LumaYV12(-2,1) #molto leggero
#LumaYV12(0,0.9) #un pò più efficace
Unfilter(-3,-3) #smooth leggero
Undot() #deringing

#RESIZE
a=trim(0,1000).BilinearResize(576,240)
b=trim(1001,134678).BicubucResize(576,240,1/3,1/3)
c=trim(134678,0).BilinearResize(576,240)

return a+b+c


LumaYV12(offset, gain)
agisce sulla componente luma del pixel.
Se y è la luma del pixel, y * gain + offset è ciò che restituisce la funzione
Il default risulta quindi LumaYV12(0,1) (y*1+0 è sempre y).

- offset è compreso fra -255 e +255. I valori assunti agli estremi corrispondono al video nero o bianco rispettivamente
- gain è compreso fra 0 e 2. Fra 0 e 1 la luminosità si riduce. Fra 1 e 2, aumenta. Amplifica in ogni caso l'effetto dell 'offset

Unfilter(HSharp, VSharp)
Intensifica (+n) o diminuisce(-n) il dettaglio agendo separatamente sulla componente orizzontale e su quella verticale. n va da -100 a 100

Undot()
Non ha bisogno di parametri. Riduce l'effetto "mosquito" sui bordi.

Una volta finito, si salva lo script come: "nomeScript.avs".
Lo si può testare su un qualunque player (fortemente consigliato Media Player Classic)

Una volta salvato lo script avs, si dà in pasto a VirtualDub Mod e dare il via all'operazione di encoding.

user posted image

fig. 4.1

Non è poi così difficile new_smileyb.gif



PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10. Post-Processing e altre peculiarità 5. Avisynth: dove il codec non arriva

In molti casi anche la miglior configurazione del codec ASP non basta a coprire gli artefatti inevitabili dovuti: Con Avisynth è possibile intervenire puntualmente per eliminare o ridurre in parte quegli artefatti che il solo codec, normalmente, non riuscirebbe a risolvere:
  1. Interlaced è riferita a un particolare tipo di sorgente. Quando i frames costituiti da coppie di fields vengono visualizzati su dispositivi progressivi, vengono mostrati contemporaneamente invece che in leggera differita (come succede per i normali televisori per es.) e questo determina il tipico effetto seghettato sui bordi degli oggetti.
  2. Il telecined è il processo da cui si ottiene un video PAL / NTSC partendo da un film.
  3. Il noise è il tipico effetto-neve, una vera dannazione perchè diminuisce drasticamente la comprimibilità del video.
  4. Il mosquito è un particolare tipo di noise ma si manifesta soprattutto attorno ai bordi degli oggetti particolarmente contrastanti. Ad es. delle lettere su sfondo biando, sui visi o su qualcosa che contrasti con lo sfondo.
  5. Il blocking è il tipico effetto "blocchettoso" dovuto a un migliaio di motivi differenti fra cui l'onnipresente basso bitrate oppure la presenza di vaste aree uniformi di colore.
Ognuno richiede un intervento specifico ed è possibile ottenere un risultato notevole che non sarebbe altrimenti raggiungibile se non con l'editing.

Usare Avisynth è più semplice di quello che sembra ma il tool dà il meglio di sè non tanto nell'applicazione dei singoli filtri, anche se molto potenti, quanto nella possibilità di definire degli script che li combinino a seconda delle esigenze.

Pur mettendo a disposizione un linguaggio di scripting, quindi relativamente semplice, Avisynth dispone di un set di istruzioni che permette di coprire quasi ogni esigenza. La possibilità di applicare anche dei filtri condizionali attraverso ConditionalFilter permette perfino di rendere l'applicazione dei filtri dinamica, ossia dipendente da condizioni variabili.

Nell'affrontare il problema del rumore video, molto noto a chi acquisisce da sorgenti analogiche, per es. nella conversione di vecchie VHS, si può fare ricorso a filtri che non sono proprio tali. Si tratta in realtà di script che calibrano l'applicazione di uno o più denoise. E' il caso di qualche script che usa RemoveGrain per es.

Anche per le anime il discorso è analogo. Caratterstica di questo tipo di video è la presenza di vaste aree di colore uniformi e di bordi molto netti che si possono danneggiare nella codifica. Uno dei filtri più potenti per la conservazione di tali bordi è proprio uno script che, seppure molto lento, mantiene la definizione degli orli in modo molto pulito.

In ogni caso avisynth non dispone, almeno per ora, di un ambiente visuale per cui è necessaria sempre tanta pazienza e voglia di provare perchè i filtri devono essere calibrati "ad occhio". L'esperienza insegnerà a minimizzare il numero delle prove al variare dei casi.



PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10 Post-Processing e altre peculiarità 6. Telecined, Progressive e Interlaced

Telecined, progressive e Interlaced sono concetti strettamente connessi fra loro.

I film su DVD, per fare un esempio, sono dei video ottenuti a partire da uno standard (film) che non è quello usato dai comuni televisori su cui ta e che dev'essere adattato affinchè lo si possa usare anche su questi sistemi.
Dal punto di vista del sistema che usiamo noi (PAL), si vedrà che l'acquisizione di un DVD NTSC nasconde delle problematiche che si possono risolvere solo conoscendo le tecniche (telecined) con cui tale dvd viene creato.

Ciò che rimane di questo processo, è la presenza di un artefatto piuttosto comune nel caso enunciato sopra (come anche nel caso di acquisizione da sorgente analogica) e che si cerca di rimuovere il più possibile. Si parlerà di interlacing e della conseguente rimozione (deinterlacing).

Le definizioni progressive, interlaced sono piuttosto ricorrenti e potranno indicare ambiguamente: 6.1. UN PO' DI TERMINOLOGIA

FRAME-STRUCT
La struttura di un frame si dice frame (appunto) quando contiene l'immagine intera
Quando l'immagine viene ripartita in 2 parti, la struttura del frame prende il nome di fields.

FRAME-TYPE
I frames si dicono progressive quando rappresentano sequenze di immagini intere.
I frames si dicono interlaced quando l'immagine intera si compone su due frames adiacenti. La sequenza si ottiene interlacciando i frames. Tipicamente i frames interlaced riconducono ad una struttura del frame per fields.
Attenzione a non equiparare erroneamente la struttura del frame con il suo tipo (es. se il frame è interlaced allora la sua struttura è per fields. non è vero!)
Più avanti si vedrà un caso molto comune (nei DVD) in cui i frames, pur non essendo strutturati per fields, possono essere ugualmente interlaced.

VIDEO-TYPE
Un video è una sequenza di frames.
Un formato video è frame-based quando è costituito da fotogrammi strutturati per frame.
Tipicamente, il formato film (pellicola da 35 mm, nel seguito la parola film si riferirà sempre a questo formato) è un formato frame-based a 24 frames per secondo.
Un formato video è fields-based quando è costituito da fotogrammi strutturati per fields.
PAL e NTSC sono due formati fields-based.
Nel caso PAL, abbiamo 50 fields al secondo (25 frame per secondo o fps).
Nel caso NTSC abbiamo 59,94 fields per secondo (29,97 fps) oppure 47,952 fields per secondo (23,976 fps)

Nei formati PAL/NTSC, la visualizzazione di ogni frame avviene mostrando prima il primo field (top) contenente le linee dispari, e successivamente il secondo (bottom) contenente le linee pari. Questa visualizzazione differita dei campi permette di ovviare alle insidie dei video interlaced.

Tipici sistemi di visualizzazione interlaced sono per es. le televisioni analogiche.
Analogamente, tipici sistemi di visualizzazione progressive sono per es. i monitor PC.

La visualizzazione di un video interlaced su un dispositivo progressive può provocare gli artefatti mostrati in figura, dovuti al fatto che il frame viene mostrato per intero:


user posted image

fig. 6.1

In ogni caso, per capire a fondo la differenza fra frame progressive e interlaced, si rimanda al paragrafo 6.6.

Dalle definizioni enunciate sopra risulta chiatro che per riprodurre un video frames-based (film) su sistemi field-based (PAL/NTSC) è necessaria una rielaborazione dei fotogrammi, della loro struttura.
Tale rielaborazione prende il nome di Telecine


user posted image

fig. 6.2



Siccome la nostra attenzione si concentrerà in particolare nella conversione di video NTSC => PAL (di sistemi field-based quindi), la conoscenza di questo processo sarà importante per capire cosa bisognerà fare.
In altre parole, le domande a cui sarà necessario trovare una risposta saranno: Conoscere la risposta è importante perchè un video che viene fuori da un processo di telecine è un mix di frame progressive e interlaced (arrivati a questo punto, sarete diventati bravi con le definizioni new_smileyb.gif) e lo sforzo sarà quello di rendere il video progressivo

6.2. CONVERSIONE frame-based => field-based

Per la visualizzazione su sistemi field-based (PAL / NTSC), occorre passare da un formato frame-based a un formato field-based in pratica: Col Telecine, un film viene trasformato in un video NTSC a 29,97-23,976 fps o PAL a 25 fps partendo dal presupposto che se un frame corrisponde a 2 fields (top, bottom), i 24 fps di un film corrispondono a 48 fields per secondo.
Allora basta aggiungere i fields che mancano per far tornare i conti.
Vediamo come.

Supponiamo di voler produrre un video NTSC a 29,97 fps partendo da una sorgente film a 24 fps
Secondo quanto detto prima, il telecine mi viene in aiuto in questa trasformazione che viene effettuata (per duplicazione) aggiungendo 6 frame ogni 24 per arrivare ai fatidici 30 fps (i 29,97 fps effettivi sono stati approssimati per comodità di calcolo, ritorneremo più avanti sull'argomento)
Quali sono i frames da duplicare?

La regola adottata impone di ripetere i fields secondo un pattern n:m ossia: Il pattern a cui faremo riferimento da questo momento in poi sarà il 3:2. Facciamo un esempio:
Supponiamo di avere 4 frame: A, B, C ,D, ognuno diviso nelle sue componenti: top (t)e bottom (b), avremo:

A, B, C, D = (AtAb), (BtBb), (CtCb), (DtDb) => [telecine] => (AtAbAt), (BbBt), (CbCtCb), (DtDb) = (AtAb), (AtBb), (BtCb), (CtCb), (DtDb)


user posted image

fig. 6.3

La scelta dei fields da duplicare trova giustificazione nel fatto che, in ogni frame ricostruito, dev'essere presente sempre un field top e uno bottom alternativamente, come si può notare nell'ultimo passaggio quando vengono mostrati i 5 frames finali.
E' questo il modo in cui viene aumentato il numero di frame nell'unità di tempo.
Notare che nel processo sono stati prodotti 2 frames interlaced (il 2° e il 3°). Sarà un particolare di cui tener conto.

Tutto quanto è stato detto finora vale in maniera speculare se il pattern adottato è il 2:3 pulldown.

A questo punto i primi 3 punti della casistica iniziale sono praticamente risolti. film => PAL a 25 fps e film => NTSC a 23,976 fps sono piuttosto semplici.
Il telecine in questi casi seguirà un pattern 2:2 che, ormai sappiamo corrispondere alla sequenza di 2 fields per ogni frame.
Di fatto, il numero (e quindi l'ordine) dei frame del film equivale al numero dei frame del video, come pure il framerate di partenza per cui l'unica cosa che si fa in questi casi è correggere il framerate audio e video.

6.3. CODIFICA IN MPEG-2

I player DVD si interfacciano con sistemi field-based (TV analogiche) e hanno bisogno quindi che i frames siano codificati con i classici fields affinchè la visualizzazione proceda nel modo classico, per mezzi frames.
Nella codifica in MPEG-2 però i frames non vengono duplicati (sarebbe uno spreco di spazio) ma si fa ricorso a due flag booleani attraverso i quali si riproduce in postprocessing l'effetto del telecine. In questo modo il numero di frames del film rimane invariato.
Associamo ad ogni frame del film originario 2 flag: TFF e RFF

- TOP_[b]FIELD_FIRST, con valori (0,1)
- REPEAT_FIRST_FIELD, con valori (0,1)

Se TFF = 1 => il primo field del frame telecinato è il 1° field del frame originale. Altrimenti sarà il secondo.
Se RFF = 1 => il primo field del frame telecinato viene ripetuto.

Con questi flag possiamo riprodurre ogni combinazione.
Vediamo come andrebbero settati i flag per ottenere la situazione nel nostro 3:2 pulldown.

user posted image

Riproducendo questa sequenza relativa ad un secondo di film

TFF = {1001 1001 1001 1001 1001 1001}....
RFF = {1010 1010 1010 1010 1010 1010}...

e siccome ad ogni frame sono associati i 2 flag TFF e RFF, la sequenza deve essere letta per colonne:
(11), (00), (01), (10), (11), (00), (01), (10).....
che può essere letta in decimale come:
3,0,1,2,3,0,1,2....
che è ciò che restituisce DGIndex prelevando questi flags dagli header. Esaminando la sequenza si riesce a risalire al pattern utilizzato.

In questo modo il formato film viene riprodotto come NTSC senza nessuna variazione del numero di frames.
Quella sequenza di bit non è altri che la firma del telecine.
Attraverso DGIndex è possibile risalire alla sequenza TFF-RFF ed è inutile aggiungere quanto sia importante disporre di un tale strumento per verificare con precisione la natura del video.

Nel caso del pattern 2:2 troveremmo i flag TFF-RFF pari a:

TFF = {1111 1111 1111 1111 1111 1111}...
RFF = {0000 0000 0000 0000 0000 0000}...

Oltre a questi 2 flag, ce ne sono altri 2 altrettanto importanti per i video NTSC a 29,97
  1. FPS
  2. DROP_FRAME
Entrambi fanno in modo che la visualizzazione avvenga col framerate corretto (29,97 oppure 25 per es.) visto che l'applicazione del "telecine indiretto" grazie ai flags TFF-RFF produrrà 30 (o 24) frame per secondo. E tutto questo lasciando inalterato il numero di frames.
FPS setta il framerate in modo che la visualizzazione avvenga ad una velocità ben definita e costante
DROP_FRAME invece conta il numero di frame e ne elimina 2 ogni minuto per arrivare ai 29,97 fps. Infatti (60 * 30-2)/60 ~ 29,97

6.4. INVERSE TELECINE (altrimenti detto iVTC)

Il telecine abbiamo visto permette di ristrutturare i frames in termini di fields in modo da garantire il pasaggio del video su sistemi field-based (PAL/NTSC)
Ma cosa succede se vogliamo che un video NTSC diventi un video PAL?
Semplicemente possiamo sfruttare il fatto che se sottoposto ad un processo di telecining, si può utlizzare l'operazione inversa.
Il telecine lascia degli strascichi che dobbiamo risolvere. Nelle sequenze mostrate in figura 3, si vede che 2 frames su 5 sono interlacciati.
Nel passaggio NTSC => PAL possiamo avere due scenari:
  1. NTSC telecined
  2. NTSC nativo a 29,97
Il 1° caso è risolubile con l'iVTC grazie al quale si rendono progressivi i frames interlacciati.

user posted image
Una considerazione sul framerate:
L'Inverse Telecine di un video NTSC a 29,97 fps produce un video a 23,976, per cui sarà necessario un ulteriore ritocco al framerate audio e video per ottenere una sincronizzazione perfetta.



Al 2° caso invece l'iVTC non è applicabile.
Se i frames venissero eliminati eliminati si potrebbero produrre delle scattosità nel video (jerky effect)
Se si sceglie l'altro approccio e si fondono i frames può capitare: Purtroppo in questi casi la conversione è veramente difficile e l'eliminazione completa di questi artefatti è quasi impossibile.

user posted image
Le asincronie audio-video in questi casi sono irrecuperabili. Eliminando dei frame nel video con iVTC infatti si altera il loro numero che non coincide più con quello audio. Anche lavorando in seguito sul framerate audio si può adeguare la lunghezza dello stream audio a quello video ma senza ottenere quella corrispondenza frame-to-frame necessaria per la sincronia. In pratica audio e video inizieranno insieme e finiranno insieme ma quello che ci sarà in mezzo potrebbe essere un disastro.

Un ultimo tentativo potrebbe essere quello di forzare il framerate audio-video a 25 fps. La sincronia in questo caso è garantito ma l'effetto audio potrebbe essere shockante. Le voci, i rumori, diventano lenti e cavernosi.
Conclusioni: O ci si accontenta sapendo già a cosa si andrà incontro, o si decide di lasciare tutto così com'è.

I casi sopra descritti si collocano alle estremità dell'insieme di tutti i possibili casi che possono capitare quando si ha a che fare con materiale NTSC.
In mezzo a tutto questo sta il cosidetto "materiale ibrido" vale a dire un insieme di FILM e VIDEO.
Per i due casi visti poco fa, si capisce subito che l'impresa sarà ardua perchè un eventuale iVTC danneggerebbe il VIDEO provocando scattosità.
Se si decide di non forzare il film e di lasciarlo così com'è per lavorare su una base uniforme, dovremmo essere consapevoli di: 6.5. INVERSE TELECINE IN MPEG-4

Dopo questa imponente parte teorica passiamo finalmente esaminare alcuni filtri che Avisynth mette a disposizione per la risoluzione di questi problemi.

Innanzitutto occorre capire la natura del materiale che stiamo trattando e DGIndex, per questo, fornisce veramente un sacco di informazioni quando il materiale è su uno stream MPEG-2.
Dalla sua anteprima è possibile raccogliere dati relativi a: Per ulteriori approfondimenti sulle analisi effettuabili con DGIndex vi rimando all'omonima guida.

Nel caso il video sia un FILM, occorre vedere in che percentuale lo è. Se la percentuale è superiore al 95%, vuol dire che la firma del telecine 3:2 pulldown è presente praticamente dappertutto (l'ideale sarebbe il 100%) e possiamo utilizzare l'iVTC nativo di DGIndex, Force Film, che attua un processo di conversione dei frame interlaced secondo il pattern 3:2 e corregge il framerate.
Il demux offerto da DGIndex inoltre provvede ad estrarre l'audio mantenendo la sincronia con il video.
La parte che rimane scoperta della percentuale di FILM del video può essere recuperata con un filtro deinterlace adattivo.

Se la percentuale dovesse essere più bassa, l'uso del Force Film è abbastanza sconsigliato. Occorre effettuare l'iVTC in un altro modo, usando dei filtri specifici (in questo caso non usare ovviamente Force Film su DGIndex)
Il package Decomb offre una serie completa di filtri che vengono incontro ad ogni esigenza. Con i primi due si attua l'iVTC, il 3° filtro è utile nel caso di sorgenti interlacciate. Il 4° filtro è funzionale nell'economia dei filtri condizionali grazie al quale si stabilisce se il frame sia interlaced o meno. E' usato da autoGK per es. quando deve stabilire se una sorgente sia interlaced.

DGIndex riconosce il Telecine solo se la firma è quella regolare del 3:2 pulldown. Ma ci sono dei casi in cui il telecine, pur essendo presente, è fatto male e DGIndex non riesce ad evidenziarlo (magari perchè c'è un pattern atipico).

user posted image
Dei semplicissimi script avs possono essere utilizzati per effettuare delle analisi empiriche del video quando DGIndex non riesce ad essere esaustivo o semplicemente quando non può essere usato.
Dopo l'acquisizione con mpeg2source:

AssumeTFF()
SeparateFields()

può essere utilizzato per scoprire l'ordine dei campi. Si fissa l'ordine come TFF e attraverso virtuaDub Mod, frame per frame nelle scene di movimento, si cerca di capire se nel movimento non ci siano cambi di direzione improvvisi che indicano un inversione dei fields.

telecide(post=false)
può essere utilizzato per scoprire il pattern. Sempre con virtualDub Mod si cerca di risalire alla sequenza dei frames progressive e intrlaced. Per questo motivo viene disabilitato il postprocessing che attuerebbe il deinterlace per quei frames. Se si riesce a risalire ad una sequenza regolare di frames progressivi e interlacciati possiamo procedere col telecide.



Condizione necessaria per l'applicazione di questi filtri è che essi non siano preceduti da nessun altro filtro o da un resize. In questo caso infatti i processi di riconoscimento che questi filtri attuano sui frames, sarebbero gravemente compromessi.

Telecide ricostruisce la giusta sequenza dei frames telecinati
Decimate elimina quei frames che possono essere rimasti dopo l'applicazione di Telecide completando di fatto l'iVTC puro.
Sulla base dell'esempio fatto a proposito del 3:2 pulldown, Telecide e decimate lavorano in questo modo:

user posted image

Ristabilisce la progressività dei frames ma lascia un frame duplicato che si può eliminare o col postprocessing di Telecide o col Decimate
Vediamo alcuni dei parametri rilevanti di Telecide: Per Decimate sono: Ovviamente la prudenza vorrebbe che attivando il postprocessing di telecide non venga attivato il decimate e viceversa.

6.6. NON SOLO iVTC - DEINTERLACE

Quand'è che si deve deinterlacciare?
Banalmente quando non si può procedere in alcun modo con l'inverse telecine: nè con force film, nè con qualunque altro iVTC.
Se l'analisi fatta da DGIndex non ci permette di risalire a nessuna sequenza regolare è meglio procedere col deinterlacciamento.

E' una situazione tipica dei video fields-based nativi, es. serie televisive. o delle acquisizioni da sorgente analogica.
Notare che l'anteprima di DGIndex per i flussi MPEG-2 a volte ci dice che un frame è interlaced anche quando poi si tratta di un frame progressive.
Questo è dovuto al fatto che nello stream MPEG-2 è solamente attivo il flag relativo al frame type (vedere guida dgindex) ma i due campi di cui è composto contengono l'immagine intera.
Quando un frame è veramente interlaced (ossia quando potenzialmente può riprodurre l'artefatto riportato in basso), i due campi possono contenere rispettivamente le linee pari del frame A e le linee dispari del frame (A+1).
Un dispositivo field-based (televisione analogica) copre il difetto visivo dovuto alla sovrapposizione dei due mezzi frames in virtù della visualizzazione differita, ma un dispositivo progressive mostra la combinazione dei due campi contemporaneamente con effetti come quelli mostrati in fig.6.1.
O anche peggio, come quella mostrato qui sotto:

user posted image

fig. 6.4

Un telecide applicato male può essere dannoso perchè potrebbe lasciare intatti dei frames interlacciati (lasciando quindi una parte degli artefatti che si prova ad eliminare).

E' sufficiente verificare con l'anteprima video, procedendo fotogramma per fotogramma. Se, soprattutto nelle scene di movimento, si notano gli artefatti da interlacciamento in maniera quasi uniforme allora è opportuno utilizzare il solo FieldDeinterlace che, a differenza di altri, è un buon filtro adattivo (nel senso che non necessariamente processa tutti i frames ma si possono fissare delle soglie di tolleranza)
Concludiamo con FieldDeinterlace; Qualche esempio:
CODE

########################################################
#Queste istruzioni devono essere le prime dello script #
########################################################

1)
# Sorgenti interlaced pure
FieldDeinterlace(full=false)

2a)
# Per una sorgente telecined con adeguamento del framerate
Telecide(order=1,guide=1,post=0).Decimate(cycle=5)
AssumeFPS(25) #forza a 25fps il framerate video. Analogamente dovrà essere fatto per l'audio.

analogo a:

2b)
#senza decimate e col deinterlacciamento del telecide settato su interpolazione dei fields (più pulito ma più lento)
Telecide(order=1,guide=1,post=2, blend=false)
AssumeFPS(25)

3)
# Per una sorgente ibrida di cui non si vuol far variare il framerate (29,97)
Telecide(order=1,post=0).Decimate(mode=1,threshold=50) # all'occorrenza, potrebbe essere necessario alzare il threshold. L'esempio è solo indicativo





PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10 Post-Processing e altre peculiarità 7. GESTIONE DEL COLORE

E' risaputo che i colori degli streams MPEG-4 sono un filo più sbiaditi rispetto all'originale.
Oltre che da una caratteristica intrinseca dell'MPEG-4, l'opacità del colore è legata anche al fatto che gli streams MPEG-2 possono usare dei codici colore differenti rispetto a quelli usati dall'MPEG-4.
La correzione è affidata ad un filtro specifico mentre se si vuole dare più vivacità al colore è necessario intervenire manulamente.

7.1. CORREZIONE DEI COEFFICIENTI COLORE

ColorMatrix serve per mantenere sullo stream di destinazione la gamma cromatica dello stream d'origine (es. MPEG-2 -> MPEG-4).
Una buona parte degli streams MPEG-2 usa dei coefficienti di colore differenti (Rec.709) rispetto a quelli usati dalle routine di conversione di colore di avisynth o dai decoder XviD/DivX (Rec.601) col risultato che gli XviD/DivX o gli MPEG-2 ottenuti con TMPGEnc/QuEnc presentano un leggero calo di luminosità, o meglio, un colore un pò più sbiadito rispetto al'originale.

Il filtro ricalcola i valori YUV in modo che gli stream in uscita (MPEG-2 o MPEG-4) si vedano correttamente.

ESEMPI: Il filtro inoltre definisce i range di valori per luma e chroma rispettivamente a (16-235) e (16-240) come previsto dallo standard CCIR-601 per quel che riguarda i valori considerati utilizzabili per le TV. E' la stessa cosa, in pratica, che fa anche limiter()

SINTASSI: colorMatrix (clip, string "mode", bool "interlaced", bool "mmx", bool "hints", string "d2v", bool "debug")[/b]

mode (default="Rec.709->Rec.601")
mode può assumere i seguenti valori: "Rec.601->Rec.709" o "Rec.709->Rec.601", il cui significato è stato spiegato ampiamente in precedenza.
mode non verrà considerato se hints vale true

interlaced (default=false)
Non c'è bisogno di particolari commenti.
Da utilizzare quando la sorgente è interallacciata.
L'utilizzo ideale sarebbe in combo con hints. Più avanti si capirà perchè:
Mpeg2source("c:\film.d2v", info=3)
colorMatrix(hints=true, interlaced=true)

mmx (default=true)
A causa dell'arrotondamento, le ottimizzazioni introdotte dall'mmx (presente solo per YV12) non producono risultati fedelissimi. Tali differenze (+-2 sul piano Y e +-1 per UV) possono rientrare disabilitando proprio tali ottimizzazioni, settando il parametro: mmx=false.
colorMatrix(clip, mode="Rec.601->Rec.709", mmx=false)

hints (deafult=false)
Le ultime versioni di DGDecode forniscono i dati sul "colorimetry" in modo che sia più semplice scegliere il "mode" corretto da usare.
Basta attivare l'anteprima di DgIndex:


user posted image

fig. 7.1


Queste informazioni possono essere visualizzate anche così:

Mpeg2source("c:\film.d2v", info=1) (solo dalla versione 1.20 in poi di DGDecode.dll).
Attivando lo script su un player:

user posted image

fig. 7.2


Normalmente i coefficienti rimangono costanti su tutto lo stream. Quando questo non succede (es. sorgente interallacciata), colorMatrix potrebbe peggiorare la qualità invece di migliorarla. Ponendo hints=true, si forza il plugin ad usare i coefficienti che vengono fuori dinamicamente dall'azione del DGDecode.dll (quindi da "Mpeg2source"):

Mpeg2source("c:\film.d2v", info=3)
colorMatrix(hints=true)

Notare che in Mpeg2source il parametro info dev'essere pari a 3 e non ad 1, nel qual caso l'azione di hints sarebbe nulla. Utilizzare hints inoltre potrebbe appesantire l'esecuzione di colorMatrix (e rallentare tutto il processo di encoding, alla fine).

d2v
Specificando il file .2dv, colorMatrix prenderà i coefficienti direttamente da questo file. Utile quando i coefficienti non variano mai nel video (praticamente quasi sempre) e, inutile dirlo, molto più veloce di hints.
Mpeg2source("c:\film.d2v")
colorMatrix(d2v="film.d2v")
Se lo script avs e il file .d2v sono in cartelle differenti, in colorMatrix bisogna specificare tutto il path.

debug (default=false)
debug=true per visualizzare le informazioni relative agli hints. E' necessaria la DebugView utility per la loro visualizzazione.


Il >>>seguente esempio<<< mostra gli effetti di ColorMatrix.


Come si può vedere, questo filtro non corregge i colori ma solo il modo in cui questi vengono codificati negli stream MPEG-4.
Una correzione sembrerebbe opportuna (il codec usato in questo caso è XviD 1.1 CVS 16102005) ma senza esagerare. C'è il rischio di creare dei contrasti eccessivi e poco naturali rispetto all'originale. Nelle anime viene decisamente meglio.
Anche senza ingrandire le immagini, si nota che nella fig.7.3 i colori sono un pò più sbiaditi. Un ingradimento è fortemente consigliato per apprezzare le differenze.

Ricordo ancora che ColorMatrix corregge solo la gamma cromatica, vale a dire che permette una codifica dei colori più corretta (per dirla breve, senza ColorMatrix si evidenzia un lieve calo di luminosità, una sorta di opacizzazione), ma non migliora assolutamente il colore, nel qual caso è necessario un intervento differente (Vedi paragrafo 7.2)

CONCLUSIONI: l'informazione sui coefficienti del colore sta nell'header dello stream MPEG-2 visualizzabile come è stato già detto, con le ultime versioni del DGDecode.dll, con Mpeg2source(info=1) oppure guardando la preview di DGIndex oppure ancora aprendo il file d2v con un banale editor di testo. Com'è mostrato nell'esempio su un estratto di un file d2v, il 2° numero (in grassetto) è il colorimetry.


user posted image


Colorimetry:
user posted image

Se non è presente, il default è dato dai coefficienti Rec.709
Per le conversioni MPEG-2 => MPEG-4, colorMatrix() oppure colorMatrix(d2v="c:\film.2dv") vanno bene quasi sempre e migliorano la qualità della codfica.

user posted image
Prestare attenzione alla versione di DGIndex utilizzata.
La 1.4.3 per es. era viziata da un errore nell'interpretazione del colorimetry, per cui il valore di colorimetry 1 (vedi tabella sopra) veniva interpretato come 5, nel file d2v il famoso 2° numero, in alcuni casi, era un bel 5.
La 1.4.5, attualmente l'ultima release stabile, presente nella nostra sezione
download, corregge questo errore.



7.2. CORREZIONE DEL COLORE

Per restituire brillantezza ai colori di un MPEG-4 ottenuto con DivX/XviD si può: Tweak(Hue, Sat, Bright, Cont)

Permette di regolare intensità, saturazione, luminosità, contrasto. In poche parole: BANALE.

Nella >>>figura successiva<<< troverete alcune immagini ottenute settando tweak nelle varie modalità (passare col mouse sulle figure per evidenziare le differenti impostazioni)


Il consiglio che posso dare è quello di usare questo filtro con prudenza perchè c'è il rischio di attribuire una cromaticità eccessiva al video che lo renderebbe poco simile all'originale. Ci sono dei casi in cui questo non è vero, nelle anime per es o quando la sorgente è particolarmente rovinata.
Al solito, occorre decidere caso per caso.



PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10. Post-Processing e altre peculiarità
8. Ripulire la sorgente video

Caratteristica di alcuni video è la presenza del noise, del rumore, che si può presentare sotto la forma del tipico effetto-neve o come una grana presente in maniera uniforme più o meno su tutto il video.
Perchè ci si ostina nella sua rimozione?
In primis, perchè la presenza del rumore rende meno comprimibile il video rispetto a quanto potrebbe esserlo.
E' anche vero che c'è chi ritiene la presenza del rumore essenziale per conferire ad alcuni video quell'affascinante aspetto "old-style", ma se si vuole dare priorità alla qualità dell'archiviazione, è meglio rimuoverlo.
Si ripulisce l'immagine e si rende più comprimibile, risparmiando spazio.
Tutto questo si può ottenere con un numero sterminato di filtri:
PeachSmoother (concepito proprio per l'acquisizione TV), Denoise, Fluxsmooth, MipSmooth, Deen, Convolution3d, TemporalSoften tanto per citarne qualcuno.
I Denoisers, come vengono chiamati, agisono su due piani: quello spaziale e quello temporale o tutti e due insieme.
Il denoiser spaziale prende un frame, ne esamina i pixel servendosi al più dei pixel circostanti nello stesso frame e, in base ad essi, determina se si tratti di rumore oppure no.
Il denoiser temporale prende un frame, ne esamina i pixel servendosi al più dei frame circostanti e, in base ad essi, determina se si tratti di rumore oppure no.
Chiaramente il secondo approccio è più attento nella rimozione dei dettagli ma anche più lento.
Sembrerebbe incauto a questo punto l'uso di un filtro spaziale però si deve tener conto che: Ci occuperemo ora di un filtro molto particolare che unisce all'aggressività dei filtri spaziali la moderazione propria dei filtri temporali in maniera molto originale.
Tanto per ricalcare ciò che era stato detto nell'introduzione della Parte B, non si tratta di un filtro ma di uno script.

8.1. Denoise con Remove Grain

Ciò che segue è una parziale traduzione delle istruzioni sul filtro in allegato.

RemoveGrain è un filtro molto potente per la rimozione del rumore video.
Si presenta in 4 versioni differenti ottimizzate a seconda della tipologia del processore in uso.
E' essenzialmente un filtro spaziale ma in combinazione con altri filtri appartenenti allo stesso package, Clense e Repair, è possibile definire delle funzioni Avisynth per operare nche in ambito spazio-temporale o su sorgenti interlaced.

Ogni denoiser spaziale adotta più o meno la stessa tecnica, vale a dire che il pixel di riferimento viene stimato se essere rumore o meno, ed eventualmente rimpiazzato con uno dei pixel adiacenti. La stima viene fatta confrontando il luma, o il chroma, o tutti e due.

RemoveGrain dispone di 18 modalità.
Le 1-10,17,18 sono state concepite per sorgenti progressive, mentre le 13-16 per quelle interlaced.
Non è efficace per la rimozione delle grosse macchie o dei graffi tipici delle vecchie VHS per es. (per le quali è consigliabile usare qualcosa di specifico come Despot o Descratch) ma per il rumore che non oltrepassa la grandezza di un pixel.

Che fa removeGrain? Se 1 <= mode <= 4, il pixel in esame viene evenualmente rimpiazzato con uno degli 8 pixel adiacenti ossia tutti quelli che gli stanno intorno.

Come?
Fra gli 8 pixel ordinati per luma, ne vengono scelti 2. Fra i 3, vince il pixel (che rimpiazza quello eventualmente in esame) che ha il luma che sta nel mezzo (il minmax clipping delle istruzioni in allegato fa esattamente questo).
La scelta dei due dipende dalla modalità (mode) in uso perchè si considerano i pixel pmode e p(9-mode).

Es.
Supponiamo il nostro pixel abbia luma=39 e che i pixel adiacenti abbiano luma=32,180,56,32,83,215,17,43
Ordinandoli avremmo: 17,32,47,53,83,110,180,215 Il pixel verrà rimpiazzato solo per mode >= 3. I primi 4 modi sfumano per diminuire il rumore e aumentare la compressione, i mode 5-9,17,18 coservano meglio i bordi.
in particolare il mode 17 è una variante del mode 4 ma più conservativo.
Questi modi non lavorano sui pixel adiacenti come i primi 4, ma pigliano come riferimento le linee adiacenti al pixel, che sono 4: destra, sinistra, sopra e sotto.

Alcuni accorgimenti nell'uso:
  1. RemoveGrain non può levare il rumore dai bordi perchè, per costruzione, non riesce a catturare i pixel adiacenti.
  2. O si usa il filtro prima del crop o si tiene il rumore sui bordi.
  3. Il mode 2, quello di default, è il miglior compromesso fra efficienza e velocità.
  4. Il resize dev'essere fatto dopo l'applicazione del filtro se si aumenta la dimensione originale. Prima, se si diminuisce. (Thanks Dijkstra ocio.gif)
Altri filtri compresi nel pacchetto sono Clense e Repair. Il primo è un efficace pulitore ma un pò brutale. Dev'essere usato insieme a Repair per la gestione degli artefatti che inevitabilmente produce. Per questo motivo l'utilizzo migliore di questi filtri è all'interno di uno script che li combini in modo ottimale.

Nell'area download è presente il tipico RemoveDust estratto dallla documentazione del filtro.
Richiede il clip, ovviamente, e il mode per RemoveGrain.
Lo script è semplicissimo. Non fa altro che: Clense, Repair e RemoveGrain.
La modalità di Repair usata è la 16, un buon compromesso fra conservazione dei dettagli e comprimibilità che, volendo, si può cambiare adeguandola a RemoveGrain ricordando che: RemoveGrain (1-6) -> Repair (11-16)

E siccome tante chiacchiere servono a poco, in basso troverete un estratto dell'EncByJonny 1.03 che mostra le due differenti situazioni nell'uso o meno di RemoveDust e che fa vedere benissimo come possa aumentare in maniera sensibile, a parità di condizioni, la comprimibilità a scapito di una minima perdita di dettaglio:

Codec=XviD 1.1 CVS del 16/10/2005
Settaggi: 1° script:
CODE
(...)
crop(6,14,708,548)
lumaYV12(-2,1)
undot()
BilinearResize(512,272)

2° script:
CODE

(...)

#E' già migliore rispetto all'uso di undot
RemoveGrain(mode=1)

crop(6,14,708,548)
lumaYV12(-2,1)
BilinearResize(512,272)


3° script:
CODE

(...)
crop(6,14,708,548)
lumaYV12(-2,1)

#E qui l'utilizzo combinato dei filtri prende decisamente il largo.
#Usando RemoveDust(4) la percentuale sarebbe stata anche più alta ma con gli artefatti decisamente più visibili.

RemoveDust(1)
BilinearResize(512,272)


EncByJonny 1.03:

user posted image

fig. 8.1

Di seguito, le >>> immagini proposte <<< sono ancora più esplicative.

Ingrandendo le immagini a tutto schermo si può notare meglio la perdita dei dettagli più fini.
Cos'altro si può dire?
Che la differenza visiva fra Undot e RemoveGrain è quasi nulla (è anche vero che la risoluzione 512 x 272 aiuta) a fronte di un notevole incremento di comprimibilità.
Invece RemoveDust(1) si fa già sentire parecchio. Il Clense al suo interno "mangia" molto più dettaglio.
La fig. 8.2 mostra comeRemoveDust renda l'immagine più sfumata.
Sarebbe bene infatti usarlo per il motivo per cui è stato concepito, ossia il rumore, ma anche così è interessante notare come la compartecipazione di un filtro aggressivo come Clense col TemporalRepair, rendano lo script, tutto sommato, molto accorto.



PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10 Post-Processing e altre peculiarità 9. Anime

Le anime sono una vera rogna, la dannazione di ogni codec MPEG-4 ASP.
Alcuni si comportano meglio di altri, ma ogni codec soffre, in misura variabile, di perniciosa antipatia.
In questo ambito, più che in altri, è necessario ricorrere ad una vera e propria azione di cesello.
L'anime richiede un approccio su vari livelli che deve tener conto (per non parlare di eventuali problemi legati a sorgenti telecined o interlaced) di: Il secondo e il terzo praticamente inevitabili per i motivi enunciati varie volte in precedenza e che ricordo ancora una volta:

- mosquito:: si presenta sugli orli degli oggetti a forte contrasto. Anche un bitrate alto non riesce ad evitarlo.
- blocking: si presenta, anche ad alto bitrate, quando il colore e troppo uniforme.

Entrambi vanno a nozze con le anime.
L'azione secca di un codec ASP, come DivX o XviD, anche ad alti bitrate, rischia di non risolvere gli artefatti di cui sopra.
Come si può fare?
Tralasciando il settaggio del codec (si spera che sia stato fatto correttamente new_smileyb.gif) diciamo che "l'intervento chirurgico", almeno in prima approssimazione, si deve articolare nei seguenti punti: Mosquito, noise e blocking si possono circoscrivere con dei filtri... denoise.

Il blocking in particolare, si può far rientrare con i denoise spaziali con settaggi molto aggressivi.
Questo perchè, a differenza di un film, non ci sono dettagli in rilievo che il filtro altrimenti piallerebbe (con conseguente appiattimento dell'immagine), per cui il filtro lavora bene, Oltretutto, si elimina anche l'eventuale rumore.

In più, filtri come Deen, PeachSmoother o Convolution3D, lavorano sulla componente luma e sulla componente chroma e un settaggio aggressivo su questi parametri può "mescolare" i colori che, in un'anime diminuisce l'effetto di "blocchettosità", in un film fa un mezzo schifo.

Un pò di attenzione è richiesta anche in questo caso altrimenti col "mescolamento", per quanto prudenti siano i filtri, i bordi andrebbero a farsi benedire.

A questo proposito, un filtro interessante è MSmooth, che ha un azione di spianamento notevole (visibile negli esempi che seguiranno) unita ad una notevole attenzione per i bordi.
Suggerirei di non usare Unfilter. E' vero che è uno smoother spaziale ma tende a sfumare tutto (non è, come si dice, edge-sensitive, anche gli orli, che diventano difficilmente recuperabili anche con gli sharpener più incazzati.
Se questi filtri vengono configurati come si deve, oltre al Blocking, anche il Mosquito Noise rientrerà del tutto.
Il default spesso va più che bene ma i casi particolari (es. codifica di anime acquisite da sorgente analogica) vanno trattati con maggior cura

Dopo mosquito e blocking è giunto il momento di occuparsi dello sharpening.

user posted image
Comincia ad essere evidente cosa significhi "lavorare di cesello".
Va ricordato che usare uno sharpener in materia scriteriata può causare la comparsa degli artefatti eliminati nella fase precedente, vale a dire mosquito e blocchi.
L'uso di Avisynth dev'essere concepito come una calibratura di varie fasi, ognuna delle quali non è mai circoscritta in un compartimento stagno ma lascia degli strascichi di cui si deve tener conto nelle varie fasi del processo.
Il sapere, anche approssimativamente, cosa comporta l'uso di un filtro particolare, quale "eredità" lasci, se vogliamo, mette al riparo da brutte sorprese.
E' una regola generale.



La precisione degli orli è importante in un'anime perchè i contorni, quasi sempre neri o molto scuri, si devono stagliare netti e ben definiti.
Esistono numerosi "sharpener".
Fra gli sharpener va ricordato il più semplice di tutti: Unfilter, già visto in precedenza (vedi paragrafo 4.2).
Ma anche come sharpener, dovendo necessariamente usare un settaggio aggressivo, non va benissimo perchè la sua azione è troppo globale e c'è la forte probabilità che i blocchetti, eliminati nella fase precedente con tanta fatica, si ripresentino di nuovo.

Meglio rivolgere l'attenzione a dei filtri che nascono per questo scopo come: aSharp, aWarpSharp, warpSharp, MSharpen
Sono tutti filtri adattivi, come lo è MSmooth per lo smoothing, il terzo viene considerato in quanto facente parte (insieme ad aWarpSharp) di uno dei migliori script esistenti per lo sharpening delle Anime: MFtoon.

Negli esempi che seguiranno, verranno mostrati degli script minimali in cui l'unica cosa che viene effettivamente testata, è il comportamento dell'accoppiata smoother-sharpener.
Gli accoppiamenti sono del tutto arbitrari e ognuno può scegliere quelli che meglio crede.
Non credo di poter stabilire quale procedimento sia migliore perchè ognuno ragiona in base a criteri personali di qualità o velocità.
Le conclusioni le rimando alla fine.

1° script: Lanczos + Unfilter
CODE

(...)
crop(0,2,350,284)
Unfilter(-20,-20)
Undot()
LanczosResize(496,368)

2° script: Bicubic + MSmooth + MSharpen
CODE

(...)
crop(2,2,348,284)
MSmooth(threshold=12,strength=3,highq=false,mask=false,show=false,debug=false)
MSharpen(15,100,false,false,false)
Tweak(sat=1.2)
ColorYUV(gain_u=15)
BicubicResize(496,368,0,0.6)

3° script: Bicubic + MFtoon + Deen
CODE

(...)
Crop(2,2,348,284)
deen("a3d",4,10,12)
mfToon()
Tweak(sat=1.2)
ColorYUV(gain_u=15)
BicubicResize(496,368,0,0.6)

Due parole sugli script prima di proseguire:
L'immagine originale (piuttosto rovinata) è stata ingrandita (l'originale era un (352 x 288)), quindi per tutti gli script è stato usato un resize "robusto"

Nel 1° script si lascia la definizione dei bordi al lanczos e la diminuzione della blocchettosità ad Unfilter.

Il 2° e 3° script sono molto simili fra loro. I filtri usati sono molto validi in entrambi. A differenza del primo, preferisco usare un resize meno aggressivo del Lanczos e lasciare il lavoro di rifinitura agli sharpener.

E' un esempio di ragionamento che varia molto a seconda delle condizioni dei video che si devono trattare.
Viene fatto giusto per fissare le idee e per mostrare uno dei possibili procedimenti. Ce ne saranno senza dubbio altri trecento alltrettanto validi. L'importante è che si capisca che per fare le cose per bene un procedimento universale non esiste.

MSmooth e MSharpen hanno la bella particolarità di essere definiti appositamente per le anime.
Sono dei filtri adattivi che permettono di impostare la "sensibilità" alla presenza del bordo nero, tipico delle anime.
MSmooth è deputato allo "spianamento" delle eventuali imperfezioni, utile anche per il ripristino dell'uniformità dei colori.
MSharpen ridefinisce i bordi (passare col mouse sulla figura per evidenziare la maschera usata dal filtro):


>>> Clicca qui per vedere il Mask Filter <<<


mfToon è uno script che combina vari sharpener e, almeno per me, si è dimostrato il migliore in assoluto.
L'invocazione è quanto di più semplice si possa immaginare: mfToon() che agisce per default con la massima potenza (strength=255) e lo fa benissimo.
Se si vuole limitarne il raggio d'azione basta settarne opportunamente l'efficacia: mfToon(strength=128) (per ridurre lo sharp del 50%)

Lo svantaggio è che si tratta di un filtro molto lento ma l'attesa è ampiamente ripagata.
Come denoiser spazio-temporale ho usato deen perchè il potente mescolamento dei colori attuato da questo filtro lo rende particolarmente indicato per le superfici ampie delle anime.

Ho aumentato lievemente la saturazione ed ho corretto la gamma cromatica attraverso ColorYUV
Questo filtro, come tweak, permette di regolare luminostà e colore ma in modo più avanzato. Infatti è possibile intervenire su ogni singolo canale della gamma cromatica: Y,U e V.
In effetti si potrebbe utilizzare il solo ColorYUV ma tweak è più semplice da usare e ColorYUV è comodo per bilanciare meglio i colori con i parametri gain_u, gain_v. Poichè tweak agisce dappertutto, con ColorYUV è possibile rendere solo alcuni colori più o meno evidenti di altri.

Nel mio esempio il valore positivo di gain_u serviva per ridure il colore giallognolo diffuso un pò in tutto il video in modo da esaltare il bianco e conferire agli incarnati un colore un pò più naturale.

Di seguito, viene mostrato il confronto fra i risultati prodotto dall'accoppiata mfToon() + deen con gli altri casi.


>>> Clicca qui per confrontare i vari filtri <<<


Nel confronto è anche evidente come, pur mantenendo un buon livello di definizione, l'accoppiata Msmooth + Msharpen rimane un gradino al di sotto dell'accoppiata mfToon + Deen. E' ovvio che molto dipende dalla configurazione dei filtri. Non nego che una configurazione più accorta avrebbe prodotto risultati migliori.
Rimane il fatto che il caso in oggetto, che prevedeva l'ingradimento dell'immagine e la ripulitura causa sorgente particolarmente rovinata, ha richiesto per mfToon e Deen praticamente il solo default (a differenza di Msmooth + Msharpen) vale a dire:
minimo sforzo, massimo risultato.



PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10 Post-Processing e altre peculiarità 10. Post-Processing e altre peculiarità

Oltre che per l'editing, avisynth può essere sfruttato benissimo per altri scopi.
Una delle grosse potenzialità di Avisynth è quella di permettere, attraverso script semplicissimi, la visualizzazione di video di varia natura: MPEG-2, AVI, WMV, ASF, Real ecc.
Questa caratteristica può essere benissimo sfruttata a nostro vantaggio per ottenere una serie di "prestazione aggiuntive".
Vediamone alcune.

10.1. Post-Processing

Una caratteristica insospettata che rende Avisynth particolarmente attraente è la sua estrema flessibilità nell'agire in post-processing.
Gli script che abbiamo preparato finora per la codifica possono benissimo essere utilizzati per correggere la visualizzazione dei nostri video in condizioni un pò avverse.

Basta specificare, con le opportune istruzioni: Esattamente quello che facevamo prima, con la differenza che lo script stavolta diverrà il tramite fra il video, che provvederà a filtrare opportunamente, e il player.

Ad es. supponiamo di avere un avi un pò rovinato e poco luminoso.
Se siete arrivati fino a questo punto, saprete esattamente cosa fare per rendere il video meno blocchettoso e più chiaro new_smileyb.gif

Questo script ha qualcosa di familiare, o mi sbaglio? new_smileyb.gif

user posted image

fig. 10.1 - Post Processing

Tenete presente che più i filtri saranno aggressivi e numerosi più sarà richiesta potenza alla CPU.
Ogni buon post-processing che si rispetti richiede un certo tributo in termini di risorse.

10.2. Confronto nell'applicazione di filtri

Supponiamo che si voglia confrontare l'effetto di due (o più) filtri differenti per avere un'idea dell'impatto. Che si fa?
Preparare due script differenti, salvare le slide e confrontarle sembra un pò macchinoso. vengono in nostro aiuto.
Entrambi non fanno altro che visualizzare contemporaneamente due clip source e destination come VirtualDub, disponendole verticalmente od orizzontalmente. L'ideale, quindi, per confrontare l'efficacia di un filtraggio rispetto ad un altro.
Es.

CODE

#  SOURCE
mpeg2source("c:\film.d2v", idct=0)

#  CROPPING
crop(2,64,764,448)

clip1=last

clip1=lumaYV12(clip1,-5,1)
clip1=unfilter(clip1,-50,-50)
clip1=bilinearResize(clip1,560,240)


#  RESIZING
clip2=clip1.undot()
clip2=LanczosResize(clip2,560,240)

StackVertical(clip1, clip2)


e questo è il risultato:

user posted image

fig. 10.2 - StackVertical


10.3. Cut e Append

Visto che Avisynth è uno strumento di editing non lineare, si può sfruttare questa sua peculiarità per effettuare delle giunzioni o dei tagli "volanti" che mantengano inalterato l'avi (o il real, o l'asf, o il wmv)originale.
Supponiamo per es. di avere un avi composto da 3 puntate di una serie televisiva (magari il risultato di un'acquisizione da sorgente analogica) e che si vogliano levare le parti di video relative alle sigle.
Basta uno script di questo tipo:

CODE

avisource("c:\film.avi")
trim (0,28895)+trim(35122,62819)+trim(66112,98549)


Analogamente, se invece si vuole effettuare una o più giunzioni:

CODE

avisource("c:\film1.avi","c:\film2.avi",... )

#oppure

avisource("c:\film1.avi")+avisource("c:\film2.avi")+...

#oppure

a1=avisource("c:\film1.avi")
a2=avisource("c:\film2.avi")
...
return a1+a2+...


E qui mi fermo. Sarebbe inutile continuare ad elencare tutti le possibili applicazioni in fase di post-processing.
E' chiaro ormai che avisynth può essere usato in maniera ambivalente: in fase di encoding e in fase di riproduzione.
Mi limito a tracciare una strada, ora sta a voi percorrerla new_smileyb.gif

CONLUSIONI

Avisynth è estremamente versatile. Definirlo "tool per l'editing video" sembra quasi riduttivo, a questo punto.
Questo articolo ha cercato di dare visibilità ad alcuni degli aspetti più interessanti e spero possa avervi incuriosito in qualche modo anche se forse solo il 2% di tutto quello che si poteva far vedere è stato mostrato.
Leggere e provare è l'unica regola che vale sempre. Per il resto, l'unico limite penso possa essere definito sola dalla vostra immaginazione.

Un ringraziamento particolare ai ragazzi dello staff di Divxmania, per la pazienza che hanno dimostrato nel leggere, primi fra tutti, questo pò pò di roba, per gli incoraggiamenti ricevuti e le pacche "virtuali" sulle spalle.
L'ultima revisione è stata sempre la mia per cui mi assumo la responsabilità di ogni possibile imprecisione.
Ogni comunicazione al riguardo, ribadendo quanto già detto nella premessa, è più che gradita e sarà eventualmente sviluppata nel forum di Divxmania.

..::Aytin::..




PARTE A

Cap. 1. Premessa
Cap. 2. Cos'è Avisynth
Cap. 3. Installazione di Avisynth
Cap. 4. Primi script


PARTE B

Cap. 5. Avisynth: dove il codec non arriva
Cap. 6. Telecined, Progressive e Interlaced
Cap. 7. Gestione del Colore
Cap. 8. Ripulire la sorgente video
Cap. 9. Anime
Cap. 10. Post-Processing e altre peculiarità

Pagina stampata da Divxmania.it
Vietata la copia e la distribuzione (anche parziale) senza la previa autorizzazione.