Si stava meglio quando era tutto a 720p [cit.]

Ormai è parecchio tempo che si parla di risoluzione e "risoluzione effettiva" per discriminare i magici upscale che ci ritroviamo su BD, .ts, release di FranceBB ecc ecc... dalla risoluzione "di partenza" sulla quale è stato fatto l'upscale. Fino a qualche tempo fa questa risoluzione di partenza era sempre 720p, quindi la questione si approcciava con "debilinear a 720p e gg", mentre adesso si hanno sempre più spesso casi di anime con una risoluzione >720p.
Volevo aprire questa discussione per approfondire proprio questo aspetto in quanto, almeno per quanto mi riguarda, ultimamente mi ci sono ritrovato molto spesso a combattere, e suppongo che lo stesso sia capitato anche ad altri. In particolare volevo prendere in considerazione questo aspetto per quanto riguarda i BD, visto che per release TV/Crunchy, imho, è un aspetto marginale.
Di solito il primo passo che si segue consiste nell'andare su anibin per vedere qual è la risoluzione effettiva che viene riportata per l'anime che ci interessa. Sinceramente, ignoro quale black magic venga utilizzata, o se sono dati ufficiali/ufficiosi, fattostà che in un paio di circostanze ho constatato che ha toppato, quindi non mi fido. Considerando questo, ho cercato di ricavare un metodo più o meno "empirico" per trovare quale fosse la risoluzione di partenza, in quanto se si vuole utilizzare debilinear a 720p bisogna essere sicuri che la risoluzione di partenza sia 720p, mentre invece se si vuole rellare con risoluzioni improbabili, o si vuole effettuare un resize basato sul "MightyUpscale" proposto da chibi, è necessario conoscere questa risoluzione di partenza con precisione.
Per farla breve, riporto il procedimento che ho applicato agli ultimi 2 BD che mi sono ritrovato ad encodare (Henneko e Shingeki no Kyojin) i quali, entrambi, hanno una risoluzione effettiva >720p. Lo scopo sarebbe quello di approfondire il discorso con gente che ne sa più di me, in modo da ottenere una linea guida precisa da seguire in queste circostanze.
Iniziamo con un .avsi che mi sono preparato per questi casi:


Niente di nuovo, va a fare debilinear(risoluzione effettiva presunta)->bilinear(risoluzione di partenza) e il risultato di questo lo va a "confrontare" con la clip di partenza tramite un makediff. In questo modo vengono evidenziate le differenze tra le due clip. Ovviamente nel processo viene considerato solo il luma, in quanto il kernel inversion sul chroma non verrebbe comunque effettuato. In ingresso viene richiesta solo l'altezza, in quanto la larghezza se la va a ricavare da solo. Quello che viene visualizzato quando si richiede la preview della clip è la differenza vista in precedenza, con in alto a sinistra il valor medio del luma, in alto al centro un "plus" o "minus" e in alto a destra la "Width" considerata per la risoluzione effettiva. Quando si ha plus vuol dire che la width è stata ricavata approssimando all'intero pari più vicino verso l'alto, quando si ha minus invece è stata utilizzato quello più vicino verso il basso, se non si ha nulla vuol dire che è mod2 (senza considerare le frazioni di pixel). Nel caso in cui si sta considerando una risoluzione la cui corrispondente width non è mod2, viene visualizzato uno stack verticale con sopra la plus e sotto la minus. Ho messo anche un ulteriore intero che può essere passato alla funzione (mode) se si vuole visualizzare solo il plus o solo il minus per una determinata risoluzione (mode=1 stack, mode=2 plus, mode=3 minus, default = stack). Oltre a questo andrà a generare un file .txt chiamato output con le varie entry costituite da (+ -> Plus, - -> Minus, = -> Mod2);Risoluzione;ValorMedioDelLuma.

EDIT1: Aggiunta la possibilità di selezionare tra 3 diversi kernel, cioè Bilinear, Bicubic MitchellNetravali e Bicubic CatmullRom. Inoltre lavora anche con input che hanno AR diversi da 16/9
EDIT2: Grazie a Chibi per aver riscritto in maniera dignitosa lo script e aver inserito il lut. Per i dettagli sulle modifiche clicca qui
EDIT3: Aggiunti PARNum e PARDen, per i dettagli clicca qui e qui (thx sp)

A questo punto direi di passare proprio ad un approccio pratico, cioè a cosa ho fatto quando mi sono ritrovato, ad esempio, a dover encodare i BD di SnK. Per prima cosa sono andato a vedere se la risoluzione fosse o meno di 720p:




Un po' di grain è normale che resti, visto che viene aggiunto sempre a 1080p. Ma quando nella preview si riescono a distinguere i volti e le artline sicuramente la risoluzione è sbagliata, quindi in questo caso è evidente che la risoluzione non è 720p. Ok, stiamo nella merda, cosa si può fare? Andiamo a vedere su anibin quale risoluzione riporta:



vediamo allora a 824p cosa abbiamo:




Dal risultato direi che ancora non ci siamo, le artline sono troppo visibili. C'è da dire che anibin spessissimo ci prende, e se non ci prende con ogni probabilità la risoluzione effettiva starà vicino al valore che riporta. Supponiamo di non cagarlo e andiamo a fare la preview spostandosi di 2 in 2 per la risoluzione. Il txt generato dallo script è formattato in modo che importare i dati in excel è una fesseria, quindi riporto il valor medio del luma ottenuto per ogni risoluzione:




Il valore del luma è molto indicativo, infatti più sarà basso e più il frame sarà "spento". Il fatto che all'aumentare della risoluzione ci sia una diminuzione di questo valore è normale, in quanto ci si sta avvicinando sempre dippiù alla risoluzione di partenza. Quello che deve insospettire è quando questo andamento non viene rispettato, cioè se si hanno dei punti dove il valore decresce per poi ricrescere subito, come appunto accade in corrispondenza della risoluzione 858p con width approssimata per difetto, quindi 1524x858. Questo non vuole assolutamente dire che quella sia la risoluzione effettiva al 100%, ma quantomeno deve destare un sospetto. Per verificarlo andiamo a vedere cosa si ottiene con 1524x858 e con 860p:







Ok, a questo punto è più di un sospetto. Infatti a 1524x858 resta solo il grain e le artline grossomodo scompaiono, mentre a 860p ricompaiono. Quindi, per essere sicuri di averci preso, va fatto un riscontro sulla clip effettiva:


858p Vs. 860p

inb4: ma sono uguali!!11!1
Fissate il volto di Mikasa, compare merda random a palate. Avevo un altro screen dove Eren diventava praticamente un panda, ma non lo trovo. Con 1524x858 invece molto meglio, c'è giusto un po' di haloing.
A questo punto si è più o meno sicuri che la risoluzione sia quella, quindi basta decidere il resize. O si usa quello visto sopra (che sarebbe il MightyUpscale), oppure anche con RHQ per fare downscale dopo nnedi si ottengono buoni risultati:


invks Vs. RHQ

È un po' più blurrato di quello che si ottiene con invks (MightyUpscale), ma allo stesso tempo invks produce più haloing, tende a sminchiare il grain e bloata il filesize di brutto (soprattutto a 1080p). Inoltre si possono anche avere delle sequenze con risoluzione effettiva diversa, ma sono piuttosto rare di solito (nelle prime puntate di SnK purtroppo ce ne stavano parecchie). Nel caso in cui la risoluzione cambia di continuo conviene lasciare a 1080p e levare il poco blur dovuto all'upscale con uno sharpner tweakkato dignitosamente.
Ma di questo /cares al momento, l'unica cosa che mi interessava qua era discutere della ricerca della risoluzione effettiva. In particolare troverei molto utile se qualcuno avesse qualche suggerimento o qualcosa da aggiungere per esperienza personale o, ancora meglio, se qualcuno vede qualche minchiata scritta :E

Edited by Liquid Dr4k3 - 23/12/2013, 17:15

Hai ragione, andrebbe preso in considerazione anche quello. Casomai vedo di aggiungere la possibilità di fare il test anche con debicubic con kernel MitchellNetravali, CatmullRom e magari anche SoftCubic, Hermite e Robidoux (anche se sono piuttosto rari). Inoltre sarebbe da aggiungere un flag per le .ts, visto che hanno un AR diverso da 16/9.

Ok, aggiunti altri 2 kernel, ora si può usare Bilinear (Default), Bicubic MitchellNetravali e Bicubic CatmullRom (gli altri 3 non penso serva aggiungerli). Inoltre adesso con le .ts non dà problemi, visto che lavora con qualunque AR.
Se qualcuno trova eventuali errori, oppure se avete qualche consiglio fatemi sapere.

Grazie mille per averla risistemata come cristo comanda xD
Aggiornato il primo post ^^

Ho fatto qualche test e direi che il removegrain e, soprattutto, il lut fanno un lavorone. Infatti adesso la differenza che si ha per l'esatta risoluzione rispetto a quelle vicine è molto più marcata, e quindi è più facile da ricavare. L'unica anomalia che ho riscontrato consiste nel fatto che per la risoluzione esatta ottengo dei valori del valor medio del luma più bassi con bicubic rispetto a bilinear, mentre senza il lut la situazione era l'inversa (anche se comunque erano piuttosto vicini). Evidentemente, in questo caso specifico, risulta essere un po' più aggressivo sulla clip che si ottiene considerando bilinear. Comunque, imho, non è un gran problema, visto che se è stato utilizzato bicubic invece di bilinear per upscalare in teoria la differenza dovrebbe essere molto più marcata (come si notava dagli screen di Hell), e quindi non si andrebbe a creare questa situazione di "incertezza". Mentre invece se cambiando kernel si hanno valori più o meno simili direi che bilinear al 99% è la scelta giusta. Purtroppo non ho nulla di upscalato con bicubic per provare, Hell potresti provare a vedere con sasami a 720p che risultati ti dà? In teoria dovresti avere una differenza più marcata di prima tra dbl e debicubic grazie al lut.

Guarda che l'unica cosa che richiede un po' di skill in mezzo a tutta quella roba è il lut di chibi, il resto è fuffa. Volevo semplicemente discutere del problema della ricerca della risoluzione effettiva, mica fare il figo con script da 4 soldi.

Sorry, my bad, l'avevo intesa diversamente. Guarda, tempo fa avevo provato ad aggiungere una flag per fare in modo che iterasse automaticamente da una risoluzione di partenza a una di destinazione per ritrovarsi il file scritto bello e pronto. A quel modo, se uno si ritrova senza avere la minima idea di quale possa essere la risoluzione, non se le deve passare tutte a mano prima di avere il file scritto. Il problema è che, da quanto ho capito, su avisynth l'unico modo per iterare è la ricorsione, non esattamente gentile con la memoria. Infatti dopo tipo 15-20 iterazioni mi collassava la memoria e cagava errori random. Quindi se avessi idee sul come implementare una cosa simile penso potrebbe tornare molto utile per la scrittura del file (non so se si è capito, ma sono tutto tranne che un programmatore).

Anche un dato come la varianza sarebbe significativo, ma ti assicuro che con il lut anche il valor medio può andare. Infatti senza di quello per la risoluzione esatta hai una diminuzione del valor medio di circa un 15-20% rispetto ai valori vicini, mentre con il lut aggiunto da chibi si riduce a circa 1/5 del valore per poi risalire. Quindi è come se si andasse proprio ad incrementare la varianza degli errori medi rendendoli più significativi. BTW, se ci fosse il modo di implementare la varianza standard al livello di detenzione sarebbe sicuramente un'informazione utile.


Ok, appena torno vedo come si possono inserire, thx ^^

EDIT. Se metto ResWidth = Int(((Res*clp.Width()/clp.Height())/2)+0.5)*2 al posto di ResWidth = Res*clp.Width()/clp.Height() andrei a considerare solo le width Mod2, invece in alcuni casi mi interessa proprio che non sia Mod2 in modo da andare a vedere le 2 possibili approssimazioni della width che valore mi danno (infatti, ad esempio, per SnK proprio una di queste due approssimazioni era la risoluzione che stavo cercando).

Edited by Liquid Dr4k3 - 9/12/2013, 14:16

Altra modifica per le .ts
Per come lavorava prima si andava a considerare una risoluzione effettiva con lo stesso AR dell'input, cosa non vera per le .ts visto che per queste l'input è 4:3 mentre comunque la risoluzione effettiva ha un AR pari a 16:9.
Ho inserito una flag "TS" che se messa a "true" va ad upscalare la clip di ingresso a 1920x1080 con lo stesso kernel utilizzato per fare il confronto. Inizialmente volevo evitare di upscalare andando a cambiare solamente il calcolo di ResWidth, infatti mettendo ResWidth=Res*16/9 invece di ResWidth = Res*clp.Width()/clp.Height() per le .ts si sarebbe comunque risolto il problema. Solamente che facendo in questo modo oltre i 810p debilinear e debicibic si sarebbero ritrovati a dover upscalare, e quindi avrebbero restituito errore.

Si ringrazia per la collaborazione un misterioso encoder messicano, il cui nome inizia per cabra e finisce per man :E