Recensubs HQ

Posts written by Liquid Dr4k3

view post Posted: 14/12/2013, 14:52     +6Il topic degli screen random - Fun & Fail
Ma infatti non hanno mica detto di subbarlo in Italiano:

U9fqy6J
view post Posted: 12/12/2013, 10:44     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
Appena torno a casa lo provo. Per il lut suppongo convenga usare il makediff, tanto alla fine equivale al fare un lutxy con "x y - 128 +", ma in maniera più efficiente (almeno stando a quello che dice la documentazione). Inoltre suppongo convenga aggiungere histogram("luma").greyscale() in modo da evidenziare le differenze (altrimenti averageluma() restituisce valori piuttosto bassi).
view post Posted: 11/12/2013, 18:16     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
Diciamo che in questo modo va a fare un check su un +/- 20 della risoluzione che gli passi. Se possibile si può implementare in modo di dargli una res di partenza ed una di destinazione? Tanto non facendo ricorsioni di alcun tipo non penso ci siano problemi al livello di utilizzo di memoria, anche se le iterazioni diventano parecchie.
view post Posted: 10/12/2013, 17:56     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (Khanattila @ 10/12/2013, 17:37) 
CITAZIONE (mirkosp @ 10/12/2013, 16:48) 
@Khanattila: Appunto, però è più rapido da eseguire (crei direttamente il float anziché creare un int e farlo diventare float).
E considerando che stiamo puntando alla ricorsione, tagliare ogni angolino conviene.
@Drake: Comunque l'alternativa è far PARNum e PARDen come opzioni, entrambe a 1 di default. Per un .ts 1440x1080 si metto rispettivamente 4 e 3, così da avere direttamente il *4/3 corretto. Inoltre, creando le variabili come float, anche se l'utente scrive 4 e 3 il risultato finale è comunque float. E può tornare utile per eventuali 2.35:1 o 1.85:1 ─ anche se quelli normalmente sono comunque letterboxati in un 16:9 1.0.

Riguardo ai DVD upscalati, ricordo Re: Cutie Honey che è crossconvertito da 360p (mentre il BD ha tipo dettaglio forse anche 540p e non è crossconvertito). Inoltre svariati DVD PAL sono upscalati da res NTSC, con inerente dubbio se sia un upscale da 480 o da 486. Poi c'è anche il caso dei cortometraggi indipendenti, tipo Elemi.

Bah... per mia esperienza personale non è che c'è tutto sto risparmio. Poi non sappiamo come gli int e i float siano stati implementati in avs... Comuqnue quello che intendevo era che come avevi scritto avevi un float come risulato mentre pensavo servisse un int.

@Liquid Dr4k3
CODICE
int(Res*clp.Width()*PAR/clp.Height())

I casting sono implementati con lo shift dei valori nel registro. Quindi 3,999 diventa 3. Valuta se inserire un +0,5.

Oh... wow, non sapevo approssimasse in maniera tanto derp. Comunque adesso con PARNum e PARDen non dovrebbe andarsi a creare una situazione del genere. Il problema è che aggiungendo +0.5 mi ritroverei anche che, ad esempio, 3.6 mi diventa 4, altrimenti ce lo metterei anche subito. Comunque se noti che in alcune circostanze tira fuori width a muzzo fammi sapere che vediamo come si potrebbe mettere.
view post Posted: 10/12/2013, 17:13     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
Ok, direi che la soluzione con PARNum e PARDen è la migliore, aggiornato. thx!
view post Posted: 10/12/2013, 16:47     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
Non avevo pensato ai DVD upscalati (anche se c'è da dire che solo sp può essere così sfigato da beccarne uno xD) quindi direi di rimettere nuovamente:
CODICE
int(Res*clp.Width()*PAR/clp.Height())

(ovviamente senza l'int mi scazza sia il %2 che dbl perché si vedono arrivare float)
Solo che in questo caso bisogna stare attenti a quanti decimali mettere, altrimenti inizia ad approssimare a casaccio. Infatti con PAR 1.33 a 810p mi dava width pari a 1436, e mettendo alti decimali iniziava a darmi lo stack con plus 1440 e minus 1438, solo con parecchi decimali inizia a tirar fuori i valori corretti.

Per quanto riguardava il 4/3 avevo controllato, sembrava che i calcoli li eseguisse correttamente. Comunque adesso col PAR float sicuramente va a fare i calcoli come si deve.
view post Posted: 10/12/2013, 10:50     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (mirkosp @ 10/12/2013, 03:35) 
Oppure potevi semplicemente fare che una volta arrivati a 1440x810, le risoluzioni superiori venivano confrontate con un downscale sempre a 1440xN; soluzione migliore, in quanto upscalare più volte, seppur con lo stesso algoritmo, porta a risultati differenti, per cui rende più complesso trovare la risoluzione originale.
Contando che i .ts 1440x1080 sono già downscalati dall'upscale 1920x1080 iniziale, questo significa che introduci effettivamente un altro resize che ti allontana ulteriormente da una buona comprensione della res originale, più di quanto non faccia già l'avere un .ts con tutte le sminchiate del caso.

In pratica, quindi, secondo me conviene implementare questo metodo generico:
CODICE
[...]
function ResFinder(clip clp, int Res, int "Kernel", int "Mode", float "PAR")
[...]
PAR = Default(PAR,1)#per i 1440x1080 si usa 1.33, in quanto per portare a 16:9 un 4:3 ci vuole un PAR di 4:3
[...]
ResWidth = Res*clp.Width()*PAR/clp.Height()
ResWidth = (ResWidth > clp.Width()) && (Res < clp.Height()) ? clp.Width : ResWidth
[...]

Che ho scritto su due piedi senza controllare, per cui magari scaga.
Attualmente la parte && (Res < clp.Height()) è superflua ed è lì solo in attesa che qualcuno trovi un modo decente per implementare la ricorsione nello script.

Ok, grazie mille.
Ho messo:

CODICE
ResWidth = TS == true ? (Res*clp.Width()/clp.Height())*4/3 : Res*clp.Width()/clp.Height()
ResWidth = (ResWidth > clp.Width()) && (Res < clp.Height()) ? clp.Width() : ResWidth

perché già inserendo PAR a 1.33 approssimava a muzzo in alcuni casi, quindi senza stare a complicare la vita a chi deve inserire il PAR conviene mettere un flag (tanto sempre 4:3 sarà, non vedo circostanze in cui possa servire un par differente).

Edited by Liquid Dr4k3 - 10/12/2013, 11:32
view post Posted: 9/12/2013, 22:14     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
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
view post Posted: 9/12/2013, 12:59     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (Khanattila @ 9/12/2013, 12:24) 
CITAZIONE (Liquid Dr4k3 @ 9/12/2013, 11:53) 
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).

Avisynth non ha chiamate per liberare memoria, o almeno io non le ho trovate. Si possono fare dei cicli creando dei blocchi con ForNext e poi facendoli valutare. Per risparmiare memoria si potrebbero usare delle variabili globali e cercare di minimizzare tutto il resto.

Poi per quanto riguarda la vera e propria detenzione credo che si debba trovare qualcosa di meglio dell'errore medio. Sarebbe interessante implementare la varianza standard ma le Runtime functions oltre la mediana non vanno.

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.

CITAZIONE (Khanattila @ 9/12/2013, 12:56) 
ResWidth = Res*clp.Width()/clp.Height().

Senza che lo gestisci dopo possiamo fare qualcosa di più raffinato per avere un'approssimazione ottimale.
width = Int((clip.Height()*AR / 2) + 0.5))*2

Aggiungerei un Assert( 0 == height % 2) per verificare che la height sia corretta. Diffidare sempre dell'utente.

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
view post Posted: 9/12/2013, 11:53     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (Khanattila @ 9/12/2013, 11:39) 
CITAZIONE (Liquid Dr4k3 @ 9/12/2013, 00:12) 
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.

Io ho solo scritto che scrivere i dati su file potrebbe essere una cosa utile. Se poi vuoi fare polemica sul nulla è un altro discorso.
Invece se vogliamo parlare di come migliorare la detenzione sono ben disposto.

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).
view post Posted: 9/12/2013, 00:12     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (Khanattila @ 8/12/2013, 23:49) 

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.
view post Posted: 8/12/2013, 23:01     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
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.
view post Posted: 8/12/2013, 19:35     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (Tada no Snob @ 8/12/2013, 19:20) 
Ho moddato un po' la tua funzione perché era veramente troppo duplicata, e aggiungere nuove feature con copia e incolla è una rottura di cazzo.

Modifiche:
1) se la larghezza è mod2 allora usa sempre il modo 1 (tanto la differenza è solo quella di una stringa, e preferisco vedere nella clip se la risoluzione è mod 2 o no)
2) in caso di mod2 nel txt si identifica con = e non con + (mi pare un po' un imbroglio altrimenti)
3) aggiunto removegrain(1) per eliminare i singoli pixel ed avere un risultato meno influenzato da compressione/arrotondamenti/salcazzo
4) aggiunto un non parametro "turnback" (non so quanto valga la pena di parametrizzarlo, e bisognerebbe vedere se è utile o no), in pratica una volta ottenute le differenze le diminuisce di *valore di turnback*, anche questo aiuta a rendere i risultati meno influenzati da approssimazioni/salcazzo, visto che tanto se tra debilinear.bilinear e l'originale c'è 1/255 di differenza di luminosità dubito che la cosa possa creare problemi

Chiaramente lo script è di Liquid Dr4k3 quindi se non gli piacciono 1) e 2) può sempre rimuovere le modifiche (3 e 4 sono un esperimento interessate, controllerei se aiutano o meno).
Il refactoring lo terrei, perché almeno se si deve modificare qualcosa lo si fa in un punto solo e non in 3 punti diversi. (Ho anche reso tutti i parametri interni non opzionali, visto che non ha senso che lo siano, imho)

Grazie mille per averla risistemata come cristo comanda xD
Aggiornato il primo post ^^
view post Posted: 8/12/2013, 16:14     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
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.
view post Posted: 8/12/2013, 01:25     Si stava meglio quando era tutto a 720p [cit.] - Il ghetto dei fansubbers
CITAZIONE (H e l l. @ 7/12/2013, 20:59) 
CITAZIONE (Liquid Dr4k3 @ 7/12/2013, 18:35) 
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

Per esperienza personale ti dico che la roba upscalata con Bilinear non è così comune come si crede, quindi sostanzialmente se una persona si ritrova con una source upscalata con Bicubic si rischia di scagare anche alla risoluzione giusta.

Provato con il primo BD bicubic che mi sono ritrovato nell'HDD (Sasami, 720p):
Bilinear:
http://abload.de/img/debiliqseq8.png

Bicubic:
http://abload.de/img/debicu6bf4g.png

Chiaramente per la versione bicubic ho fatto solo un ctrl+h sostituendo debilinear con debicubic (mitchell netravali) e bilinearresize con bicubicresize.

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.
197 replies since 18/7/2011