Votes taken by mirkosp

Strange è una funzione che ho scritto ormai parecchi anni fa per aiutarmi nel filtraggio tramite CL di YATTA.
Nel tempo si è rivelata una delle funzioncine sceme più utili e che mi è capitato più spesso di andare a usare per un motivo o per l'altro, forse più per abitudine.
Recentemente mi sono reso conto di un bug di strange in cui finora non ero incorso per come usavo strange in YATTA, ma che può accadere in condizioni normali in base all'uso.

Per la precisione, non era gestita la situazione in cui il clip di edit fosse di durata diversa rispetto al clip base.
Questo mi torna sovente comodo quando devo apportare modifiche shiftando frame o pezzi di video, quindi non volevo gestire l'eccezione dando un errore, per cui ho corretto facendo sì che, se il video di edit è più lungo, questo viene trimmato alla durata del clip base, se invece è più corto, viene allungato ripetendo il frame finale del clip di edit.
Vi lascio quindi qui la versione aggiornata:


Già che stavo mettendo mano al codice, ho deciso di revisionare inoltre del tutto il funzionamento. Al posto di gestire le eccezioni, aggiungo dei frame in testa e in coda.
In questo modo, idealmente, si dovrebbe riuscire a rendere leggermente più rapido il codice di strange, perché ha molti meno if da gestire.
Tuttavia, non avendo usando estensivamente questa versione di strange (anzi, al momento è puramente codice teorico che non ho provato con mano), non ho modo di caldeggiarla senza test su strada.
La lascio qui sotto come funzione a parte, stranger:


Se qualcuno di voi riuscisse a confermare che il risultato di stranger è bit exact a quello di strange, gliene sarei molto grato.
Anche eventuali test della velocità di esecuzione di codice tra strange e stranger potrebbero essere interessanti, anche se credo che la differenza di velocità, se realmente inesistente, sarebbe marginale, salvo un grande impiego di strange(r) nello script, che comunque è una situazione che può verificarsi.

Edited by mirkosp - 27/5/2018, 08:34

Ehilà!
Come state?
Oggi avevo altra roba da procrastinare, per cui eccoci qua.

In realtà questo passaggio potrebbe essere sintetizzato in:

RTFM: https://avisynth.org.ru/docs/english/exter...lters/tivtc.htm

Visto che ormai la teoria dietro l'IVTC la sapete tutta e quindi siete in grado di comprendere i passaggi, ma vedrò di riportare qui i punti chiave di TIVTC, visto che alcuni concetti si ripresenteranno poi per YATTA (e dovrete stabilire voi quanto essere autistici).


Capitolo 1: L'approccio per persone sane di mente all'IVTC - Il field match con TFM

TFM(d2v="percorso\al\file.d2v")


Capitolo 2: L'approccio per persone sane di mente all'IVTC - La decimazione con TDecimate

TDecimate(mode=1)


Fine!


Capitolo 3: ESSEPI NON PRENDERCI PER IL CULO, NON HAI POSTATO UN CAZZO PER TUTTO IL 2017

Ok, è giunto il momento di dire la verità: non penso che si arrivi ad una ventina di persone in tutto il mondo a cui importa (ancora) veramente così tanto della qualità video per stare a fare queste cose a mano nel 2018.
Ma alla fine questa verità è ciò che ho volutamente ignorato quando ho scritto tutte le parti precedenti della guida, per cui non ha senso smettere di ignorare questo fatto ora, no?
Se siete già arrivati a leggere tutta la guida fino a qui, quindi, o siete malati di mente quanto me, oppure avete davvero del gran tempo da perdere.

Se siete della seconda categoria allora mettersi a encodare i cartoni cinesi non è uno dei modi più utili all'umanità per occupare il tempo. Suggerirei il volontariato, ma non giudico.

Se siete della prima e davvero c'è bisogno di usare gli ovr, probabilmente avete a che fare con un qualcosa che è meglio fare con YATTA.

Pertanto, prendete quando segue come essenzialmente a scopo illustrativo: sono cose di cui ho fatto utilizzo prima di imparare a usare YATTA, che comunque fu creato proprio perché fare queste cose a mano manda in pappa il cervello.

Sostanzialmente, se non dovete sistemare cambi scena scazzati dall'MPEG-2, ma avete un video pulito con un pattern essenzialmente costante (a parte eventuali cambi pattern nei punti delle sigle e dell'eyecatch), vi conviene usare TIVTC ed evitare YATTA.

Ne consegue che in realtà per il fansub, visto che quando si sta gestendo materiale interlacciato si ha tipicamente a che fare con .ts televisivi con i soliti difetti da gestire (più comodi da sistemare con YATTA) o con DVD vecchiotti pieni di casini (in cui TIVTC farebbe errori se lasciato andare in modalità automatica), il più delle volte potrebbe convenire usare YATTA, e TIVTC è sostanzalmente "inutile", ma non è necessariamente vero.

La decisione dipende essenzialmente da quante sistemazioni ci sarebbero da fare rispetto all'IVTC automatico, quanto filtraggio per scena/per frame dovrete fare, e sostanzialmente quanta sbatta avete.
Anche nei casi in cui TIVTC commette errori, il risultato finale è tendenzialmente accettabile e per l'utente medio non esisterà differenza percettibile in playback.
Ma noi siamo qui per essere malati, per cui OVVIAMENTE non ci accontentiamo mica di una cosa logica e sensata come "raggiungere un risultato sufficientemente buono", ma vogliamo necessariamente "raggiungere un risultato inutilmente ottimo".

Nevvero?


Capitolo 4: Approfondiamo TFM

TFM si occupa del field match, ovviamente.
Per farlo, ha bisogno di calcolare tutte le metriche del caso, su cui stabilire come intervenire.
Con i computer d'oggi è un processo che si fa molto più rapidamente che il realtime di riproduzione, ma un tempo tagliare su questa roba serviva, per cui, per evitare di calcolare due volte certa roba, potete pure sputare fuori queste metriche tramite il parametro output, così da capire come sta intervenendo TFM, e poi ridargliele di nuovo in pasto a sé stesso con input, in modo tale che ai successivi usi dello script non ci sia bisogno di ricalcolarle.

Sputar fuori le metriche è utile perché essenzialmente avrete già segnalati i punti in cui TFM non è sicuro di aver fatto bene l'IVTC, dicendovi dove potrebbero esserci comb residui da dover sistemare a mano.
Un'altra cosa che possiamo valutare sono i cambi scena. TFM matcha c/p di default, utilizzando gli n in caso di cambi scena problematici in cui non trova un match. Questo significa che, se trovate dei match n nello script, probabilmente quello è un cambio scena problematico. In alternativa potreste avere una scena molto movimentata con tanta merda, e il match n usciva pulito, ma usandolo sminchiate tutto il movimento e vi beccate pure un dup in mezzo alla scena. Belle cose!

Chiarito come funziona il sistema di metriche, passiamo a qualche parametro di TFM.

Oltre ai classici parametri di order/field (sinceramente trovo un po' inutile averli separati, ma vabbè), il grosso lo fanno mode e PP.
Gli unici mode con un reale senso di esistere sono 0 e 1. Lasciare altre opzioni come automatici sono follia, eventuali altri match sono da stabilire a mano, fine del discorso.

Per PP le cose si fanno "interessanti".
PP 0 lo usate se siete assolutamente certi che non ci siano comb nel video, e volete evitare che per qualche motivo venga fatto del PP, 1 è utile per lasciare degli hint dei frame da postprocessare ma volete lasciare che il postprocess venga fatto poi da TDecimate.

Se vi state chiedendo cosa siano gli hint... in sostanza, nei primi 64 pixel in alto a sinistra del video, il bit meno importante viene sfruttato per veicolare tutte le informazioni utili.
È un sistema mutuato da decomb e che anche fieldhint/telecidehints sfruttano.
In pratica ci si mettono informazioni come le metriche, e si può flaggare il frame come progressivo o interlacciato per sapere se post-processarlo o meno.
La differenza è totalmente trascurabile, ma se volete essere completamente autistici, allora sì, prima di fare IVTC aggiungete un paio di righe nere in alto, da croppare a IVTC ultimato. Questo non lo faccio neanche io, per cui complimenti, mi avete superato.

I valori 2-7 sono "relativamente inutili". Se state leggendo questa guida vorrete sicuramente usare opzioni migliori di quelle interne di TFM per post-processare i field, per cui al più vi ritrovereste a usare il parametro clip2, e quindi usereste o un valore tra 2 e 4 per usare il clip2 così com'è, o un valore tra 5 e 7 per sfruttare la maschera di movimento di tfm. Per quel che ho potuto testare io, la maggior parte delle volte questa maschera di movimento non si è rivelata particolarmente affidabile, e se fate qualche esperimento si noterà benissimo quali pezzi sono presi dal clip2 e quali sono il match.

Per gli altri parametri di TFM...

d2v l'ho già messo sopra. Se avete un d2v, specificarlo fa solo bene, tutto qui.

slow: true (che è ovviamente default), perché nel 2018 non ha senso usare false.

mChroma: come dice bene il manuale, salvo abbiate particolari artefatti sul chroma da impedire un matching affidabile, è meglio lasciarlo su true.

y0/y1: servono per impostare una fetta (in verticale) di video da ignorare per le decisioni. Se avete un .ts con gli avvisi a 60i che passano in basso, impostare i valori di y0 e y1 consente a TFM di azzeccare i match in automatico, e in teoria dovrebbero arrivare metriche accurate a TDecimate che a quel punto non dovrebbe scazzare la decimazione, ma non ci metterei la mano sul fuoco (tanto poi ne riparliamo con gli ovr).

chtresh/chroma/blockx/blocky/MI/mthresh: tutti parametri legati al post-process automatico per decidere se un frame va post-processato o no. In generale, se c'è da fare post-process e non volete essere pesoculo, è bene assicurarsi a mano di quali frame vengono post-processati e quali no, per cui segnalereste a mano negli ovr i frame da post-processare senza che ci pensino questi parametri a doverlo decidere per voi.

E ora, finalmente, veniamo alla roba interessante...

ovr: per passare i file ovr che vi scriverete a manina; della struttura degli ovr ne parlo più sotto.

ovrDefault: per stabilire come comportarsi per il post-process nei frame non indicati a mano. Idealmente, come dicevo sopra, non dovreste lasciare decisione automatiche a tfm, ma fare a mano. Di norma vi ritrovereste a specificare nell'ovr i frame da post-processare e poi impostare ovrDefault a 1 per impedire che vengano post-processati altri frame.

Di input/output ne ho già parlato a inizio capitolo.

OutputC vi crea un file in cui vi indica quali sequenze sono state rilevate come potenziali sequenze progressive e cNum stabilisce quanti frame match c di fila devono esserci per considerare una sequenza da indicare nel file di cui sopra. Sono opzioni potenzialmente utili per sapere già dove andare a controllare per vedere se ci sono sequenze da fare in VFR.

E ora, finalmente...

Con gli OVR potete dire a TFM di TUTTO. Proprio TUTTO.
Ma ovviamente le cose utili sono essenzialmente solo 2:
1) dire a TFM che pattern/match usare
2) dire a TFM che frame post-processare
Il resto si può quasi definire superfluo, per come la penso io, per cui qui starò a spiegare solo le due cose di cui sopra, e se volete guardarvi anche il resto l'RTFM di inizio guida è sempre valido.

Anzitutto, il file di ovr è un semplice txt, in cui dentro indicate un frame (o un range di frame indicato tramite virgola) e poi cosa ci si deve fare.

Per i match, invece, avete a disposizione p, c, n, u, b. I valori u e b sono essenzialmente trascurabili, quel che conta sono ovviamente i classici match p, c, n.
TFM di default matcha p (che è l'opposto di quello che fanno decomb e yatta), per cui avete due opzioni:
- forzare tutti i pattern del video a mano così è tutto in match n
- usare il match automatico di tfm dove è affidabile e specificare il pattern con match p dove in automatico ha problemi
Se volete andare con la prima opzione, tanto vale usare YATTA, per la seconda invece potete aiutarvi con il file di output che è stato sputato fuori per capire dove serve agire.

Per il postprocess invece, + indica che il frame è combed (e quindi da post-processare) e - che il frame è pulito così com'è. Se avete indicato ovrDefault 1, dovrete solo indicare + nei frame/pezzi/pattern che vi interessano.

Dunque, quello che potete fare quindi è:

Indicare un singolo frame e dire cosa va fatto.
Ad esempio, per dire che il frame 10 va post-processato basta scrivere:

10 +

O se il cambio scena al frame 9001 va matchato n al contrario del resto, potete fare:

9001 n

Indicare cosa fare in un gruppo di frame.
Ad esempio, per dire che tutti i frame dal 20 al 30 vanno post-processati basta scrivere:

20,30 +

Indicare cosa fare in un determinato pattern.
E quindi, se avete un pezzo che tfm scaga in automatico, potete forzarlo. Ad esempio, dal frame 50 al 100 potete forzare ccppc facendo:

50,100 ccppc

Potete usare i pattern anche per il post-process. Quindi, per dire che ogni quinto frame dal 200 al 300 va post-processato, potete fare:

200,300 ----+

E... direi che per TFM è tutto.


La parte che riguarda TDecimate la rimando a data da destinarsi, che per oggi ho già scritto abbastanza.

Capitolo 5: Approfondiamo TDecimate

Su TDecimate, per la verità, c'è molto meno da dire che su TFM.

I parametri che analizzerò qui sono mode, cycleR, cycle e ovr.
Ci sono tanti altri parametri, anche utili, per migliorare la decimazione automatica di TDecimate, ma siccome lo scopo ultimo è usare tivtc automatico solo quando la sorgente non ha cose complicate e andare manualmente quando invece lo fossero, analizzare tutto è superfluo, e per il resto quindi vi rimando al RTFM di inizio guida, se foste così interessati.

Di mode, sostanzialmente, ce ne interessa una: 1.
Con mode 1, tdecimate cercherà la stringa più lunga di dup che mantengano lo stesso pattern di decimazione.

CycleR e cycle servono a stabilire il pattern.
CycleR determina quanti frame vadano decimati in un gruppo, mentre cycle quanto è grande il gruppo.
Per il materiale che gestiamo solitamente questo significa CycleR è 1, e cycle è 5, e questo corrisponde al default.

In ultimo ovr.
Creando un file ovr, come per tfm, possiamo dire di preciso a tfm quali frame vadano decimati indicandoli con il meno.
Per cui, per decimare il frame 9001, all'interno dell'ovr scriveremo:



Possiamo anche specificare un pattern di decimazione, utilizzando il + per dire quali frame tenere.
Se dobbiamo decimare il terzo frame in ogni gruppo di 5 dal frame 20 al frame 209, faremo:



Molto semplice.


Con questo ci siamo levati TDecimate dai coglioni.
In realtà se ne potrebbe parlare anche di più, ma volevo semplicemente chiudere questa parte relativamente superflua della guida (e fare un nuovo post dopo anni per memare duro), per cui tant'è.

Se mai vorrò togliermi *davvero* la paglia dal culo, dalla prossima parte dovrei coprire YMC e YATTA...

Edited by mirkosp - 18/4/2020, 13:35

Diciamo che in genere gli altri gruppi non licensubbano anche gli editori italiani, cosa che invece tu hai fatto sia con Days sia con All Out (basta guardare nyaa per sgamare le release, eh).
Non che per me faccia differenza, visto che io reputo licensub anche per crunchyroll, ma c'è chi la distinzione la fa, e tu resti licensubber anche in quel caso.

Ridicolas licensubba regolarmente la roba in simulcast, lo scopri adesso?

Veramente lo è, ti autorizzo all'OT (e al flame) libero!

Abbiamo toccato le quattro pagine e viaggiamo in bilico tra il meme e l'intervento umanitario, ma siamo ancora lontani dalle calde notti del quarto reich.
Avanti così.

Non mi sento di darti torto, infatti ho premuto affinché il fatto che il mio giudizio è stato limitato a quegli screen fosse specificato proprio per questo motivo. Il typeset va comunque visto con l'episodio in toto, ma per questioni pratiche (ho limiti di banda) e di tempo, non avevo davvero modo di stare a scaricare e guardare tre episodi interi per metterli a confronto.
Ovviamente questo significa che il mio parere è estremamente castrato, ma avere dei voti era richiesto, e quindi ho dovuto darli sulla base di quello che avevo. I commenti rispecchiano comunque la situazione di quello che mostrano gli screenshot, e mi sono assicurato di non risparmiare tempo almeno su quello, perché il primo scopo di ogni recensub è far sì che chi la riceve possa trarne informazioni per migliorare (i liciaz alla fine continueranno a guardare i sub da dove vogliono indipendentemente dai voti assegnati e dai commenti scritti).


Sul primo cartello, il problema è che avete cannato pesantemente i blur e il font, e questo rovina di molto il risultato. Se aveste fatto giusti quelli, sarebbe stato un cartello tranquillamente migliore di quello TNS, siccome è più leggibile data la dimensione generosa, e come dicevo l'impegno per lo sfondo è ottimo, visto che c'è pure tutta la colorazione sfumata della targa. Ma per quanto possa apprezzare sforzi e intenzioni, valuto e commento quello che ho modo di vedere, il risultato è quello, i difetti sono quelli e sono grossi, per cui portano in detrazione più di quanto detragga la inferiore leggibilità di quello TNS, che rimane comunque sufficientemente leggibile.
E il rovescio della medaglia, e un'altra cosa che bisogna sempre tenere in conto quando si typesetta, è anche quanto sarà intrusivo. In questo caso abbiamo dei video hardsubbati, senza possibilità di togliere i cartelli per avere un video pulito, nel caso in cui l'utente volesse poi vedere il video originale. Ne segue che un type incastrato come quello TNS è meno intrusivo del vostro, che copre una grossa percentuale dello schermo.
Chiaro, parliamo di un punto privo di informazioni rilevanti, trattandosi di un muro, ma il typeset perfetto è quello che riesce a trovare il miglior connubio tra leggibilità, intrusione minima e mimesi dell'originale.

Ed entrambi i cartelli, qui, per quanto non perfetti, sono ampiamente sopra la sufficienza, cosa che sinceramente, da commenti e voti, mi sembrava di aver reso chiara.


Purtroppo non posso fare un commento più esaustivo a riguardo, perché per valutare completamente questo cartello dovrei vederlo in movimento (infatti nel preambolo che ho richiesto ho specificato anche questo limite).
Sostanzialmente, andando a intuito, essendo un pezzo ispirato a nico nico douga, immagino che i commenti scorrano entrando da destra e uscendo da sinistra. Un buon type sarebbe stato fatto posizionando immediatamente sotto o sopra (o a destra, in caso di gravi mancanze di spazio: compatibilmente con la leggibilità, la traduzione deve seguire/fare riferimento al giapponese, per cui deve essere ben ricollegabile, viceversa avere una scritta italiana che precede quella giapponese ancor prima che questa compaia è una cattiva pratica, perché o spettatore non ha collegamenti) alla scritta inerente la traduzione e facendola seguire tramite tracking. Purtroppo, con il singolo frame, non ho modo di stabilire se il tracking ci sia o meno, e nel caso fosse presente se sia ben eseguito o no. Posso però dirti che, per quel poco di giapponese che so (a sufficienza per un N5, ma non è dire molto), il posizionamento attuale è quantomeno confusionario: prendo a esempio due scritte molto facili che riesco a comprendere anche io dal giapponese, e che mi aiutano a illustrare chiaramente il problema che ho riportato:
- "La maschera!!": la scritta traduce お面が, che però è molto più sopra, col posizionamento attuale sembra tradurre メルル, che invece è Meruru. Il numero di punti esclamativi poi non aiuta assolutamente a ricollegare alla scritta giusta, visto che metterne due anziché uno fa pensare appunto a meruru anziché all'"omen ga" a cui dovrebbe far riferimento.
- "Meruru lololol": a giudicare dal meruru dovrebbe essere la traduzione del メルル di cui sopra, però c'è quel lololol che a naso è la resa del www lì vicino. Ma la scritta è ウソでしょ, per cui dovrebbe essere semmai qualcosa come "È uno scherzo?!"/"Mi state prendendo in giro?!".
- "Non voglio vedere un vecchietto...": messo lì in basso così, da solo, è straniante. Non c'è modo di capire cosa stia traducendo, è solo una scritta volante a schermo, e pertanto non posso considerarla una scelta oculata di type.
Ancora una volta, posso apprezzare lo sforzo del voler rendere le scritte, ma va fatto a dovere. Gli esempi che ti ho riportato dovrebbe chiarirti il motivo per cui non reputo soddisfacente la soluzione attuale così come appare da questo screenshot.
A tutto questo va aggiunto poi il problema persistente dell'errato uso dei blur, che si ripresenta peraltro anche nell'altro screen che hai incollato in questo pezzo che sto quotando: posizonamento, inclinazione, font e colori vanno benissimo, ma il blur è ancora una volta sballato pure lì.


Mah, ne parlerei anche volentieri e potenzialmente il voto andrebbe rivisto in funzione di questo, ma come ci ho tenuto a esplicitare, mi hanno chiesto un mio parere sul typeset, non avevo cuore di rifiutare, perché una buona recensub è sempre utile, ma non avevo modo di fare una valutazione completa. Ho semplicemente cercato di essere quanto più accurato possibile con quanto poco avevo a disposizione. Se è il voto a urtare, per me si può anche rimuovere dalla recensione, ma penso che i miei commenti limitatamente agli screen statici a cui sono riferiti restino validi.


In calce, spero che con questo approfondimento tu abbia capito che non c'è stata da parte mia alcuna malafede né pregiudizio nei confronti dei gruppi in esame, e mi sono limitato a essere quanto più oggettivo potessi essere con quel poco che avevo a disposizione per pronunciare un qualche tipo di giudizio.

Sono leggermente commosso.

Autohardsubber usa libass per fare il rendering dei sottotitoli, che è l'unico renderer presente su ogni sistema operativo.
L'aegisub di windows e kcp/cccp usano invece vsfilter, che rispetto a libass fa un rendering diverso di alcuni tag. In situazioni normali non si nota la differenza, ma col type avanzato ovviamente le differenze portano a bug evidenti di rendering.
Per ovviare al problema puoi impostare aegisub per usare libass al posto di vsfilter e assicurarti che il typeset esca bene lì prima di hardsubbare, ma a quel punto avresti il problema inverso (se rilasci softsub, chi riproduce con vsfilter avrà il type scagato), oppure puoi fare una release con doppia traccia sub in base al renderer di chi riproduce, o ancora scendere a compromessi di complessità di type per un rendering uguale tra i due.
Se invece ti interessa SOLO l'hardsub con autohardsubber, allora ti basta fare il typeset corretto con libass e tanti saluti.

Parere personale? Se devi rilasciare hardsub, fai typeset con vsfilter e hardsubba tramite avisynth correttamente. Autohardsubber è pensato né più né meno come un quickfix per i leecher che vogliono riprodurre i fansub su hardware non compatibile.

Ultimamente ho dovuto lavorare su un botto di roba nativa yuy2, ma ci sono molti filtri che lavorano solo a yv12.
Se mi serve solo il luma non è un problema, perché mi basta fare un mergeluma con dentro convert+filtro+convert senza troppi problemi, ma se ho bisogno di processare anche il chroma, le cose si complicano leggermente.
Nulla di esoso, ma scrivere tutto a mano ogni volta è una noia, per cui ecco qui la mia ennesima funzioncina di utility per semplificarmi la vita.

Il filtro va passato come stringa, per cui se all'interno del filtro stesso dovete passare delle stringhe come parametri, ricordatevi di usare le triple virgolette.
Il parametro lumaonly l'ho messo per pesaculaggine estrema, ma non si sa mai, in genere questo filtro dovrebbe tornare utile proprio se si deve processare anche il chroma.
Il parametro dhmode cambia come il filtro si comporta per far filtrare il luma. Il risultato dovrebbe essere identico nei filtri che trattano luma e chroma allo stesso modo, per cui vedete cosa va più veloce, mentre per filtri di derainbow e cose del genere, dhmode true vi consente di trattare il chroma realmente come chroma, al costo di far girare il filtro pure su un luma del doppio dell'altezza originale (quindi con materiali HD potrebbe risultare parecchio più lento del dovuto).

Tutto sommato potrebbe essere ottimizzabile più di così (come sempre quando ci sono io a scrivere filtri, del resto), ma a meno di sgamare errori mentre lo uso più estensivamente direi che il codice resterà così.



PS: Se avete YV16 ve lo convertite da soli in YUY2 prima di usare il filtro. Kthxbai.

Edited by mirkosp - 20/2/2017, 20:30

Mi ritrovo a encodare dopo mesi e TAAAC mi ritrovo a fare una funzione.

Solita situazione, mi serviva fare una cosa, ho riflettuto che è una cosa che faccio abbastanza spesso, per cui ho deciso di pulire il codice e renderlo generico per eventuali necessità future (e per condividerlo con altri sciagurati, sai mai che possa tornare utile).

A questo giro mi serviva un mask basato sulla differenza col frame precedente, nulla di particolare. È una cosa che ho fatto spesso, e a 'sto giro mi ero stancato di riscrivere da capo qualche lut e roba varia, per cui eccovi serviti:



Diffmask è un semplice filtro che genera una maschera basandosi sulla differenza. La comodità è prevalentemente per i valori intermedi di thr che vengono scalati automaticamente.



Shift invece shifta il clip dei frame richiesti. Con valori negativi si va ai frame precedenti, con quelli positivi ai frame successivi. Ovviamente con 0 dà errore, perché sarebbe identico a last, per cui inutile.

Due funzioncine che, assieme, tornano utili quando devo fare i mask confrontando col frame precedente o successivo. È roba che facevo anche spesso, eppure non m'era mai venuto in mente di scrivermi qualche funzioncina per semplificarmi la vita. Ovviamente, sfruttando queste due assieme, il massimo del pesaculismo è riunito nelle seguenti funzioni:



Che danno il mask con la differenza dal frame precedente o dal frame successivo.


Bene, ho fatto il mio post inutile periodico, ciao.

www.facebook.com/cumpaforce/videos/1429518193730354/

CUMPA SEMPRE SUL PEZZO

Visto che il tizio in tag non ce la fa...

Ma chi se ne frega di Mirai Nikki, dico io...

Ma pietà un cazzo. Se non ho fatto errori, ora è bannato. Il post lo tengo per sport, però.