Posts written by Liquid Dr4k3

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

Suppongo tu sappia che SnK è di 2 season, e sia reperire tutti i BD che encodarli richiede parecchio tempo. Per farti capire, tra il risistemare i timing, rifare il type (è 1080p da bd), applicare qualche correzione qua e la e rifare encode/mux ogni puntata ci perdo circa 3 ore (senza contare le ore di encode ovviamente). Ora, se uno ha intenzione di fare una release da BD, sapendo che possono licenziarlo da un momento all'altro, le opzioni son 2: O non lo fai o lo fai man mano. La prima opzione è non lo fai perché, ovviamente, potresti preparare 24 puntate man mano, e prima della 25° viene licenziato. Ma visto che in primis interessava a me averne una versione da BD dignitosa, in questo caso specifico lo avrei fatto anche correndo il rischio di non rellarlo mai. Le stavo rellando man mano che le facevo giusto per condividere quel lavoro... se poi lo licenziavano amen, e in tutto questo non ci vedevo niente di male sinceramente.

Ora arrivi te, butthurted per le ost, e mi vieni a dire che rellando una versione da BD con la consapevolezza che probabilmente quella serie verrà licenziata sto recando un danno a chi probabilmente lo comprerà in futuro. Te puoi anche pensarlo, ma qualunque serie potenzialmente può venir licenziata, e il danno maggiore (se la si pensa come te) è nel rellarla on going, non da BD dopo che l'hai già tutta bella che rellata.
Ma come? Non veniva fatto per promuovere l'animazione giapponese in Italia? Non stavi facendo un favore a tutti con il tuo lavoro?
Fattene una ragione, non funziona così, il 99% di chi scarica un fansub non comprerà i BD una volta che quella serie verrà licenziata. Quindi, o ammetti che anche te con il tuo hobby rechi un danno alle case produttrici, oppure lascia perdere la morale da 4 soldi su serie fatte da BD dopo la loro fine (con probabilità più o meno alte di essere licenziate), perché ti stai prendendo per il culo da solo.

Io penso che alla fine il fansub veramente è utile alle case produttrici, perché a conti fatti spero che si ritroveranno qualche copia in più venduta grazie alla pubblicità che gli viene fatta. Infatti l'appassionato avrebbe comperato il BD indipendentemente dal fansub, e tra tutti quelli che conoscono una determinata opera grazie al fansub una piccolissima parte andrà anche a comperare il BD. Ma allo stesso tempo penso che non ci sia un solo liciaz che, avendo scaricando una versione fatta da BD, non comprerà i BD a serie licenziata, perché sicuramente quel range di persone non l'avrebbe comperata comunque. Quindi spiegami in che modo starei recando danno, e soprattutto spiegami perché se io faccio una release da BD di una serie che probabilmente verrà licenziata sono un delinquente, mentre te che subbi serie on going sei il paladino dell'animazione giapponese in Italia.

Chiaro, una volta tolto non devi segnalarlo sul forum, e se ti chiedono il perché gli devi rispondere che lo hai fatto perché sei psicopatico. Credo che te sia leggermente egocentrico, non ho mai fatto il tuo nome e ho solamente detto che l'ho fatto per evitare la gogna che si sarebbe andata a creare da li a breve (qualcuno che reggeva la tua teoria strampalata ci sarebbe sicuramente stato), e non volevo cazzi. Mi sembra ragionevole no? Soprattutto considerando il fatto che in primis lo faccio per me, se non lo rello di certo non muoio.

Infatti chissà a chi è riferito il VITTIMISMO che, di minuto in minuto, editi con un fs sempre più grande. Comunque nessun vittimismo, ti ripeto... non ho voglia di starti a sentire tutto qua.

Hai detto bene, da tramandare ai posteri. Perché ho come l'impressione che quella valanga di stronzate si ritorcerà contro qualcuno prima o poi.

Sicuramente sarà scoppiato in lacrime.

Ma non penso sia tanto questo il problema, quanto il fatto che stai inserendo nell'equazione che determina il "giusto o sbagliato" il prezzo. Non penso che quelli siano affari che riguardano il fansub, alla fine chi ne ha acquistato i diritti farà (giustamente) come gli pare, e la cosa non ci giustifica in nessun modo a diffonderlo comunque.

E chi si lamentava? Tanto una volta fatta la guida si leggerà: "Ma che? quel WOT di sp su rs? Non ci ho capito una fava, con megui (nel migliore dei casi) faccio prima!!!1!!1!"
Almeno, una volta che hai terminato la guida, se veramente c'è qualcuno che ci si vuole mettere seriamente una linea guida cell'ha, ed il restante 99,9% che continuerà a piagnucolare non avrà la scusante del subber cattivo che non lo caga.
Senza contare che: GuidaEncode>>pokémon>>>>>>>>lovelab, quindi mi sembra il modo migliore di investire il tempo

Sono d'accordo con te, considerarlo un errore certamente è sbagliato, ma è sbagliato anche consigliarlo. Soprattutto se la persona che lo sta consigliando, diversamente da te, non sa neanche di cosa si sta parlando e non ha capito un'h di quello che c'è scritto su quel link (come ha ampiamente dimostrato col suo intervento successivo)

Si parla di un \fscx che cambia di un 30% e di un \fscy che cambia di un 2%, quindi quasi sicuro che non ti ritrovi font con glifi diversi da un frame all'altro. Il mio era un discorso generale, imho consigliare di usare \t con \fs invece che \fscx-y è sbagliato, se poi facciamo un discorso di close enough ne possiamo anche parlare, ma col close enough non ci sono mai andato troppo d'accordo. Detto questo neanche mi reputo un typesetter (infatti non l'ho fatto io il type di tokyo ravens) quindi ne sai sicuramente di più te, penso sia semplicemente una divergenza di opinioni ^^

Edited by Liquid Dr4k3 - 24/10/2013, 23:42

Poi sarei io il ritardato, sai leggere? Provo a ripostartelo:

http://blog.aegisub.org/2008/11/font-hinting-and-you.html

con questo non sto dicendo che è la morte, puoi anche usarlo, ma visto che c'è una alternativa che di fatto ti riduce a zero la possibilità che da un frame all'altro ti cambia character è stupido usare \fs. Deal with it.


Ma se c'è una alternativa che è equivalente ed evita a priori il problema perché non usarla? Mi dirai che in questo caso cambiava di talmente poco che sicuramente non ci sarebbero stati problemi, ma comunque non me la sentirei di consigliare \t con \fs no?

Il come è il problema
http://blog.aegisub.org/2008/11/font-hinting-and-you.html

Usare \t con \fs mi sembra una pessima idea

Sui cap di kimigonzo (TX) c'erano le CC, ma non so se sia possibile rimediare la .ts di No Continue Kid

Chiaro, 2deep4me. Scusami, non avevo capito che eri un boss... non ti disturbo più. Ma te continua pure a metterti in ridicolo, non vorrei interrompere tutto questo ^^