| Canon 5D Mark II, con una limitata gamma dinamica?
Segnalazione News slashCAM:
Canon 5D Mark II, con una limitata gamma dinamica? Di Rudi - 20 gennaio 2009 10:51:00
Da qualche giorno di calore le loro menti in rete circa il fatto che la clip della Canon 5D Mark II molto rapidamente tendono a ritaglio di luci e ombre. Avevamo già sospettato, ma è legata nel blog ormai dimostrato che questa è ancora una volta per affrontare il problema della conversione di conversione da YUV a RGB. Qui, i valori indicati YUV 16 .. 235 alla scala RGB 0 .. 255 Valori YUV inferiore ai 16 e oltre 235 si perdono per strada. HolgerScheel aveva dies seinerzeit schon bei DV-Codecs untersucht und beschrieben und wie es aussieht, gibt es die selben Probleme jetzt auch bei den Clips der Canon 5D MarkII. Für alle die sich jetzt fragen, was das heißt, in Kurzform: Die Canon Clips haben mehr Informationen in den Lichtern und Schatten, als bei den meisten Codecs beim Dekodieren dargestellt werden.
Also geht jetzt mal wieder die Suche nach einem Codec los, der YUV nativ an das Schnittprogramm weiterreicht, bzw. beim Umrechnen nach RGB den Wertebereich nicht künstlich aufbläst. PC-Anwender dürften aufgrund der breiten Auswahl hier schnell fündig werden, Apple User, die ja gerne von solchen technischen Feinheiten nichts wissen wollen, sollten dagegen mal näher hinschauen, ob z.B bei der Umwandlung nach ProRes so was irgendwo einstellbar ist. Profi-Colorist Stu Mashwitz in ogni caso, sembra essere non più Non hai trovato nulla.
Questa è una lista generata automaticamente
Risposta da joey23:
Perché gli utenti di Apple dovrebbe essere del tipo "sottigliezze" voglio sapere niente? Ridicola dichiarazione.
Risposta da Axel:
Che cosa è probabilmente fatto sì che il flusso di lavoro ProRes rilassato con molti FCPler noncuranza fare. Per il salvataggio dei valori di oltre 235 non sarà mai menzionati qui in ogni caso, non vi era "Wolfang Video Forum davanti a noi. Ma Maschwitz ha infatti trovato, con il colore, che infatti appartiene alla FCStudio.
Risposta da MarcBallhaus:
I dati del ricorso a venire in YUV 4:2:0, quindi, non in RGB. In qualche modo io non capisco è dove sono i problemi? Il mio modo di vedere per ottenere più nelle impostazioni del ricorso, perché avete il contrasto impostato a -4, non a 0 per un risultato neutrale.
MB
Risposta da Axel:
In qualche modo io non capisco è dove sono i problemi?
Non è in percepita come un problema, e riguarda tutti i video, non solo che la Mark II Maschwitz, creatore di Magic Bullet Suite, e il capo della società di titoli Orfanotrofio (Sin City) è un fanatico, ma come voi in prima il link al -- poi, vedi foto, vale la pena di affrontare la questione.
YUV a RGB: la scala dei valori (YUV) 16 - 235, ma le dinamiche originali di informazioni rientra sotto il tavolo. Evitare, in FCP, come Maschwitz scrive, solo la Apple 10-bit non compresso codec, e faranno da cornice ad utilizzare quando rendering per i filmati di qualità sempre superiore - nella rappresentazione originale in alta precisione YUV, che ovviamente funziona solo se si tratta di un codec YUV .
Risposta da Marco:
Il problema sta nella codifica de. Come vero, nella mia esperienza esattamente ciò che Rudy dice. Windows sistemi di editing sono i codec, che inevitabilmente ritaglio dopo la decodifica del segnale, piuttosto raro. Quasi tutta la cartografia correttamente, o può, opzionalmente, passare. Sul mio Mac è stato molto meno evidente. Forse ero) fortuna davvero troppo male (il codec non ho bisogno di citare o 'un po'.
Marco
Risposta da deti:
Nelle istruzioni per la fotocamera è lì, ma in modo molto chiaro:
La registrazione e la qualità delle immagini
...
Il film sarà registrata in equivalente di spazio colore sRGB ottimizzati per i filmati.
...
Così, si afferma implicitamente che l'intero spazio di 8 bit viene utilizzato, giusto?
Non capisco tutta l'eccitazione di persone che hanno bisogno di conoscere meglio.
Deti
Risposta da MacPro:
Nelle istruzioni per la fotocamera è lì, ma in modo molto chiaro:
La registrazione e la qualità delle immagini
...
Il film sarà registrata in equivalente di spazio colore sRGB ottimizzati per i filmati.
...
Così, si afferma implicitamente che l'intero spazio di 8 bit viene utilizzato, giusto?
Non capisco tutta l'eccitazione di persone che hanno bisogno di conoscere meglio.
Deti
Cosa c'è in esso "abbastanza chiaro"? I soli Stati che la funzione di trasferimento è utilizzato (primarie, gamma, punto bianco), ma nulla sul tipo di codifica (vs YCbCr. RGB vs scala. Scala Video)
Risposta da deti:
Cosa c'è in esso "abbastanza chiaro"? I soli Stati che la funzione di trasferimento è utilizzato (primarie, gamma, punto bianco), ma nulla sul tipo di codifica (vs YCbCr. RGB vs scala. Scala Video)
Quindi, se ho capito bene, stabilisce solo la raccomandazione ITU-R BT.709 che sono i cosiddetti "Studio-utilizzati livelli swing. sRGB permette sul suo proprio 8-bit e non conosce questa regola. Canon avrebbe scritto che la fotocamera è conforme ITU-R BT.709, allora sarei stato sorpreso a valori oltre l'intervallo 16-235 forte, troppo.
Deti
Risposta da Marco:
Il vero problema è a quanto pare "solo" Quicktime, o il modo in cui oggi è come la decodifica H.264 in Quicktime. Esattamente il problema descritto nel messaggio news con il file Quicktime H.264 che si è già alcuni anni fa.
Marco
Risposta da WoWu:
QU allora è stato tagliato a destra, perché i valori dei campi, tranne lo spazio colore xvYCC Y'CbCr non ha perso nulla.
Differisce anche da RGB Y'CbCr anche il fatto che essa non è costruita 16-135, così simile a RGB, ma dal centro ai lati. Questa valori sotto i 16, invece di verde scuro e il nero sono tutti al di sopra 235 "maiale rosa". A tale misura, Apple ha avuto ragione allora.
Chiunque desideri utilizzare i valori al di fuori del 16-235, è quello di rendere xvYCC.
Ecco un link per la Mark II e QT
http://www.film-tv-video.de/newsdetail.html?&uid=37689&no_cache=1
Risposta da Marco:
Oh no, not again ...
Marco
Risposta da WoWu:
Ebbene, proprio i fatti restano fatti, anche se li ignoriamo.
L'articolo di cui sopra la dice lunga ... solo che nel 2002 non esisteva ancora xvYCC. ... Ma oggi.
Risposta da Marco:
Sì. Il fatto è che, in linea di principio, in realtà "solo" bisogno di Quicktime per essere impedito di ottenere il video nelle loro mani. Più facile a dirsi che a farsi, ma va da, per esempio frameserving. Poi, non ci sono più problemi, o se avete ciò che deve rimanere, possono essere facilmente risolti. Non c'è verde scuro al posto del nero o rosa al posto del bianco.
Marco
Risposta da MacPro:
Differisce anche da RGB Y'CbCr anche il fatto che essa non è costruita 16-135, così simile a RGB, ma dal centro ai lati
Ma questo vale solo per Cb e Cr!
Ecco, questo è circa il super super bianco e nero, e Y 'è costruito normalmente da 0 a 1 (o 0-255).
Questa valori sotto i 16, invece di verde scuro e il nero sono tutti al di sopra 235 "maiale rosa". A tale misura, Apple ha avuto ragione allora.
Chiunque desideri utilizzare i valori al di fuori del 16-235, è quello di rendere xvYCC.
Non si tratta di espanso colori, ha ancora contestato, ma per l'ovvia impossibilità di essere in grado di leggere l'intero Lumasignal (che in tutti i codec QuickTime altri, ma consente Y'CbCr (!), A condizione che l'applicazione nativa (Y'CbCr) i dati da QT e QT non è richiesta la conversione a foglie RGB).
Ovviamente, però, si verifica h264 in architettura QuickTime, ma l'esterno come un codec RGB in apparenza, e che è proprio il problema in questione.
Ecco un link per la Mark II e QT
http://www.film-tv-video.de/newsdetail.html?&uid=37689&no_cache=1
Essi hanno la ragione, ma anche non comprendere appieno.
Risposta da WoWu:
Essi hanno la ragione, ma anche non comprendere appieno.
... Poi il hab'ich, ma non anche capito.
Vi è semplicemente in modo che una macchina fotografica produce segnali, che, pur non soddisfa le opere Y'CbCr nello spazio, questa!
Ogni telecamera potrebbe in teoria essere nella conversione di R'G'B Y'CbCr per l'intera gamma.
Fa una buona macchina ma non a causa del range di valori nello spazio di colore è stato risolto.
Così vale anche per la barra dei colori corrispondono ai seguenti valori di nuovo.
Non votare le barre di colore e la linea di segnale della fotocamera, è negativo, o difettosi.
I valori di colore in settori quali siano sufficientemente come "colore illegale", e dove NLE trasferimento, essi devono essere marcati o si dovrebbe essere in grado di tagliare, per l'ultima di monitor, che vengono trasferiti xvYCC, questi segnali non sono già visibili, se non xvYCC è presente. Anche il percorso di trasmissione TV sarà tagliato tali segnali.
Quindi, è giusto e ha voluto che questo accada in NLE.
Come già detto, lo spazio in cui questi valori sono trasferiti in un altro spazio riservato, che ha poi più di colore, perché fa la differenza se io) un colore spreader solo (come in questo caso, o se ero in realtà più colore che veicola.
Allora, dove è il problema, se i valori o dalla fotocamera ... o, se non possono essere rispettate dal NLE, lo spazio prescritto colore?
Che cosa ha senso per il trasferimento dei valori, (né la barra dei colori e l'ordine con lo spazio colore corretto ancora) con un percorso continuo di trasformazione sono trasmessi senza errori, e questo si trovano ancora nei campi che sono già occupati da uno spazio colore diverso?
Solo perchè sul monitor, se non opportunamente limitata, einwenig aspetto più luminoso e più saturi?
Allora hab'ich come i loro colleghi in questo articolo e qualcosa non è compreso.
Risposta da PowerMac:
Per i formati di cinema digitale, che avrebbe potuto mettere qualcosa, non certo quando TV relazioni.
Risposta da Marco:
Ho lavorato solo alcuni 5D filmati H.264 e rispetto.
Se mi consentono di decodifica per il percorso di Quicktime per essere ritagliato in molti luoghi nero (con RGB 0) e bianco (con RGB 255).
Ma io vado in un modo e con AviSynth VDubMode e quindi esportare il segnale di un formato che può gestire facilmente qualunque sistema in cui il valore di fondo scala (in questo caso è stato Newtek HQ 422), poi ritaglio le clip non è più display, o su i luoghi dove l'informazione è stata prima di clipping facilmente tagliare via, è oggi anche le informazioni video immagini di nuovo evidente.
Anche se la 5D alcuni file che non ho veramente adatto per tale scopo dimostrativo. Le informazioni di "recupero" non vi è più facilmente riconoscibile nel Waveformdarstellung rispetto all'immagine reale. Tuttavia, dimostra che per essere tagliato via con un Quicktime decodifica semplicemente le informazioni presenti, tra cui la decodifica rimarrà il percorso, però.
Ciò che viene dopo di che standard in materia di applicazioni specifiche possono essere giusto o sbagliato è una cosa. Ma il fatto è che non è la fotocamera, che sopprime le informazioni che tali informazioni rimangono abbastanza riproducibili se il segnale non viene Quicktime a cogliere e che anche i valori nelle zone di frontiera per molte applicazioni di essere utilizzati e sono anche molto importanti. Come ho già scritto, le distorsioni dei colori nella gamma 0-15 e 236-255 non esistono lì.
È il mio parere, anche in termini di un uso pura trasmissione, per non dire troppo bello per pratica per Quicktime giusto che sia così, dato che la zona di confine in uno (io la chiamo ora, i tempi) "trasmissione del segnale standard" eh non hanno perso nulla.
Quest'ultimo può anche essere corretta. Ma è per questo che mi concedo qualcosa di più che semplicemente tagliati fuori da un decoder in modo che il segnale lungo con le informazioni in esso contenute!
Il più elegante e penso che un modo più professionale di "segnale di trasmissione", ma quello che ho prima sostituito il segnale originale con tutti i suoi aspetti così come è stato registrato. Ho anche decidere per esempio, utilizzando una correzione mirata colore, come i limiti sono trasferiti al range di normalità, poi per quello - e solo allora - anche radicalmente, senza clipping.
Anche se lascio drüberfegen alla fine di un progetto completo e distante solo un filtro di trasmissione che mi aspetta, ma i valori in bianco e nero per mezzo di una curva nella gamma dei colori RGB 15 e sotto 236, sono al servizio di migliore qualità rispetto a una decodificazione clippenden.
Finché ho scelta, mi lascio in ogni caso di un decoder nel passo prima, la dinamica del segnale in tale coltura. Dynamics è un bene prezioso, e qui è come il 13 per cento.
Si dovrebbe sempre tenere a mente che il mondo è grande al di là delle trasmissioni tradizionali. Pertanto, una macchina fotografica non deve essere considerato buono o cattivo, solo perché sono il modo o le maniglie. La questione è stata più probabilità di sviluppare applicazioni per le quali una telecamera specifica per tutti.
È bene che la mia macchina fotografica economici così slancio rimasto molto e posso decidere da soli se il prodotto finale è uno standard di trasmissione, o sarà ottimizzata per altre applicazioni.
Marco
Risposta da MacPro:
Così ancora una volta, lentamente:
Di colore non è mai menzionato. è puramente e unicamente al Lumasignal.
È vero che nel valore di mappatura 16 Y '= 0 il valore RGB e il valore 235 Y' è = valore RGB di 255 non può essere modificata. Everything about it schonmal è illegale di per sé, perché al di fuori essere rappresentata.
Ora è un dato di fatto che (molti) anche le telecamere record Lumasignale superiore a 235 e poi a quelli in servizio di accedere, è un vantaggio considerevole, se si vuole prendere in giro un piccolo disegno di una zona di übersstrahltem.
Fatto è che i record Canon Superweiß. Si può discutere se questo è stato saggio o saggio per Canon, anche se non era meglio utilizzare solo il segnale mappato immagine nella fotocamera dovrebbe avere a 16-235, invece di estendere al settore della Super White. Tuttavia, questo si tradurrebbe in una perdita di valori tonali. REC ITU 709 vieta lo sfruttamento di ampi spazi di crescita per i dati video non è, al contrario: i livelli di solo 0 e 255 sono stati riservati per i riferimenti di temporizzazione. Il resto è per i "dati video" chiaramente prevedibile.
Che l'altezza libera non è visualizzata, di per sé, è già chiara e corretta, quindi questa è solo una questione di hineinretten questo Tonwertreserve al post.
Edit: Marco è stato più veloce ;-)
Risposta da WoWu:
Vedo la tesi, e non certo ad una difficoltà Ausbelichtung ggf, e quindi ogni conversione standard porta a risultati errati, perché non valutare il segnale, ma procedere dal dato spazio. Quindi questo porterà ad un rapporto corretto con il trasferimento a R'GB.
Sì, lo so adesso non se la Canon per aggiungere una barra di colore, ma (e credo che abbiamo concordato), sarà sempre il riferimento.
Ha un FB e ciò che dice in relazione al segnale?
Che non è il mio unico vero problema, se qualcuno vuole usare la zona, allora perché non lo stesso in xvYCC, in quanto ciò sarebbe un segnale, e quindi anche definito, e correttamente convertito.
Allora, perché per un tale (pseudo) Y'CbCr?
Risposta da MacPro:
Che non è il mio unico vero problema, se qualcuno vuole usare la zona, allora perché non lo stesso in xvYCC, in quanto ciò sarebbe un segnale, e quindi anche definito, e correttamente convertito.
Allora, perché per un tale (pseudo) Y'CbCr?
Ne Quantità:
1. xvYCC non è semplicemente attuato nel Canon!
2. Quale programma per Mac in grado di affrontare con xvYCC?
3. xvYCC non risolve il problema, o è la risposta a una domanda che non è stato fatto: xvYCC espande lo spazio di colore, vale a dire la Tonwertabstände restano in confronto ai tradizionali Y'CbCr stesso. non xvYCC espande la luminanza. Molto più spesso di quanto extremst colori saturi (che quindi si trovano al di fuori di sRGB) ha a che fare proprio con la scena di contrasto di grandi dimensioni, che è in qualche modo il valore stipati in pochi tono disponibili devono essere. Ci sono un sacco di siti che dimostrano impressionante quanto sia raro che i colori non sono coperti da sRGB, si verificano nelle scene naturali.
Risposta da Marco:
Suggerisce che si può gestire facilmente. La Canon 5D rende in linea di principio, non potremmo ma quasi tutti i DV, HDV e AVCHD telecamere là (ma probabilmente si estende solo verso l'alto, cioè fino a 254/255 RGB).
Quale sistema di editing in grado di gestire lo xvYCC? Ogni possibile, in linea di principio, con RGB 0-255 (trattare fino a quando il decoder non fornisce testarda e troppo presto attribuisce il bisturi).
Ma penso che con xvYCC non ha il diritto di fare comunque.
La particolarità di questo caso attuale è in realtà solo che la registrazione del segnale, mentre in container Quicktime si verifica, e quindi la flessibilità di decodifica erstmal è limitato. Non sarebbe utilizzato nel contenitore Quicktime, sarebbe nessuno a disturbare i segnali, perché sarebbe quindi più facile da gestire. Con tutte questo, mi riferisco principalmente a H.264. Come problematico o problema è con gli altri codec che sono radicati in Quicktime e vengono decodificati tramite QuickTime, io non lo so. Così il caso di clip H.264 sulla Canon 5D non deve necessariamente essere trasferiti ad altri formati.
Certo, non tutti possono qui ignorare le norme. Il più flessibile è una trasformazione, la maggior precisione gli obiettivi e, quindi, sono il modo migliore di tenere a mente.
Non sono ancora un problema accaduto qui, gestire il sistema di montaggio con un segnale RGB 0-255, anche se finirà per dover sendegerechtem compresso 16-235 doveva poi essere scavato come segnale YUV dal Betacart troppo.
Marco
Oops, questa volta è stato più veloce MacPro ...
Risposta da MacPro:
hehe ;-)
Risposta da Axel:
L'obiezione che non molti dispositivi di uscita e codec rappresentano l'intera gamma di luminanza, è una questione completamente diversa. Il range dinamico di elaborazione del segnale elettronico è limitata e dovrebbe essere deciso nella zona di accoglienza che ha bisogno di lavoro sono di disegno molto buono (di solito sì pelle) e l'altra deve essere evitata clipping. Come dire al mio avamposto, è particolarmente ecco, anche il post è ancora spazio per avere, e non vedo perché non per l'emittente dovrebbe essere rilevante.
Maschwitz, dall'altro, portando un massiccio sforzo di ricostruire via o segnali limitati in compressione digitale e mantenere durante l'intero processo di lavorazione. L'obiettivo qui è naturalmente la Fazen. Film con una videocamera DV (28 giorni più tardi con la Canon XL-1 per esempio) possono dare alcun po 'di più, ma è presentabile.
Persone film Professional come Maschwitz esegue un po 'sprezzante, andare al modo in altri, la registrazione con una pellicola analogica essere parzialmente 8k risoluzione, compresso rapidamente saltò in un digitale intermedi a titolo di 2K. La correzione del colore viene fatto con l'hardware che costerà sei somme figura, ma funziona anche con algoritmi di real-time che interferisce con il colore e la luminosità di informazioni, con risultati simili e fare ciò che distorce le telecamere dei consumatori. Meeting Point Cinema.
Risposta da WoWu:
Breve domanda:
La fotocamera dispone di un generatore di FB e che cosa fa il segnale rispetto al segnale generato immagine?
xvYCC non risolve il problema, o è la risposta a una domanda che non è stato fatto: xvYCC espande lo spazio di colore, vale a dire la Tonwertabstände restano in confronto ai tradizionali Y'CbCr stesso. non xvYCC espande la luminanza.
Questo è sbagliato, scjliesslich abbiamo a che fare con uno spazio colore.
Lo spazio digitale di espansione dei valori 1-16 e 241-254 in chroma-asse, e 1-15 e 236-254 utilizzati sull'asse luminanza.
(Ogni) meno i valori di sincronizzazione. Le definizioni possono essere definite in 8 o 10 bit di quantizzazione.
XvYCC così il problema sarebbe del tutto giusto, e soprattutto i dati indietro Torna alla RGB sarebbe riproducibile e non come un sacchetto di afferrare in grado di rilevare alcuna formula, perché rende il loro progetto non è così definitivamente per il NLE. Al più tardi, quando si tratta di un nastro, sarà su e giù di nuovo geclipped, così che cosa ha portato?
Oltre alla grande impressione sul lavoro.
In caso contrario sarà quando vado in raid con la mia data di chiusura. Perché vedo anche un vantaggio, a volte gli errori di calcolo nella transizione verso R'G'B 'a parte.
Risposta da Marco:
Non so se l'offerta Canon. Ma sarei un generatore di un FB-Konsumerkameras non vogliono andarsene. Chi garantisce che il calcolo è conforme? Non ci ho visto un sacco di bar fantasia ...
Di questi, tuttavia, ha portato al largo della Interessensfrage puro: Che intuizione potrebbe essere in questo caso specifico, uno Normfarbbalken? Che la fotocamera, diaframma / guadagno / esposizione / gamma / nero / bianco livello non è stato operato correttamente?
Il funzionamento del codec è così fuori di esso.
O si tratta semplicemente di essere in grado di fare una dichiarazione di cristallo chiaro che Normweiß, nero e tutti i colori di una barra di colore standard in questo caso, XYZ RGB in NLE essere mappato?
"Questo xvYCC il problema sarebbe del tutto giusto"
Ciò che è inutile a meno che non vi sia un NLE in grado di gestirlo.
"Almeno quando si tratta di un nastro, sarà su e giù di nuovo geclipped, così che cosa ha portato?"
Poi tagliate la parte superiore è ben lungi dall'essere incondizionato. "Tape" non è il fattore qui. Anche sotto solo se il nel post - come descritto in precedenza - non sono state prese in considerazione e anche weiterschreitet sui canali analogici.
Anche già detto in precedenza: lo scopo è quello di vedere che la gamma di valori, non solo, ma anche l'uso e reinrechnen anche in uno standard di trasmissione del segnale compatibile possibile. Proprio come il Black Stretch funziona una macchina fotografica. Così porta, anche per questo potenziale selbststranguliernden settore, che saranno utilizzati solo.
Il beneficio almeno ha sicuramente una decodifica clippendes. Questo è solo un metodo estremo mazza. In realtà, quasi un collasso nel trattare con i codec.
Marco
Risposta da WoWu:
Sul sito, è anche una questione di matrice colore della fotocamera, come farebbe il negativo della restituire valori ai valori positivi, perché nessun monitor può visualizzare i valori negativi. Ed è di questi processi, che in ultima analisi, ottenere un segnale è davvero dalla sua arbitrarietà, smettere di disciplinare le procedure standardizzate come per l'IEC 61966-2-4 xvYCC.
Riesco a vedere l'approccio e gli utili può davvero capire tutto, ma io non so se si tratta di un prodotto "del caso" è la soluzione.
Il colore sarebbe almeno l'indicazione se il segnale video a valle a tutti dalla spaziatura all'interno della matrice è costruita qui come valori negativi con il colore di matrice conversione dello spazio di nuovo essere convertiti in valori positivi. .... O anche se in realtà solo un segnale di "coincidenza", che esce dalla macchina fotografica. Ciò non essere peggiorativo, ma a volte è appena costruito per il mercato consumer e che cosa, ciò che realmente non soddisfa gli standard professionali.
Solo che io non avrei scommesso su di esso, perché allora la fotocamera prossima volta può essere molto diverso.
E, come ho detto .... è sì, allora nessun segnale di fine e la prossima conversione è, o flauto o sembra piuttosto "random" da essa.
Il beneficio almeno ha sicuramente una decodifica clippendes. Questo è solo un metodo estremo mazza. In realtà, quasi un collasso nel trattare con i codec.
Dato che io sono pienamente con te ... Ma queste cose possono effettivamente su altre curve molto più elegante di risolvere di andare facilmente in locali di valore al quale la prossima Verabeitungsschritt sa già di più.
. Anche già detto in precedenza: lo scopo è quello di vedere che la gamma di valori, non solo, ma anche l'uso e reinrechnen anche in uno standard di trasmissione del segnale compatibile possibile.
E, naturalmente, vi è un pericolo, perché si comprime un segnale, la cui espansione non è realmente conosciuta. Qui si perde del tutto casualmente valori che si sono faticosamente riuniti a voi.
Fondamentalmente, ci sono infatti d'accordo circa la meta, ho appena preferisco solo riproducibili (standardizzato) metodi
Risposta da Marco:
Beh, il problema dei ritagli della 5D-clip possono essere su un sistema Windows, in ogni caso da frameserving - e risolvere i bypass Quicktime -.
Come appare sul lato Mac, non so, ma vorrei anche essere interessato. Ho ripetutamente incontrato le informazioni che fattibile, sia direttamente, tramite le impostazioni di Quicktime, o in Final Cut sarebbe. Ma a quanto pare va su qualsiasi, non precedentemente descritti in dettaglio nel modo di colore.
"Eppure si perde del tutto casualmente valori che si sono faticosamente riuniti a voi."
Sì, non ho diretto (o solo) un impatto molto limitato di informazioni su quello che è poi davvero rübergerettet e cosa no. Ma almeno posso durante il processo (per il filtraggio) può essere osservato e, di conseguenza, se questo è ok.
Se la fotocamera registra hanno lo stesso limite, ho anche avuto alcuna influenza diretta su di esso e di solito anche meno controlli e contrappesi (se è tecnicamente non è un girevole con un controllo in parallelo).
Importante e decisivo è ancora di trovare per ogni ambiente la soluzione migliore per il trattamento del segnale, in quanto fornisce la stessa fotocamera. Mentre in bianco e nero ritagliato effettivamente terre nel mio NLE, sono le mie mani legate a questo proposito. Ma se so che la fotocamera non ha ritagliato per sé e non ha registrato modo che io possa lasciare la questione al motivo per cercare una soluzione a una decodifica senza clipping, e regolare ogni passo successivo, le condizioni necessarie.
Marco
Risposta da MarcBallhaus:
Così, se i clip che sono state filmate con la 5D in Quicktime apre e MPEGStreamClip parallelo, si vede molto chiaramente che il giocatore Quciktime i contrasti sono superiori a quelli MPEGStreamClip davvero molto chiara, soprattutto nelle zone di luce sono un sacco di informazioni via .
E sì QT di solito guarda come FCP o un compressore, ma avrei dovuto controllare separatamente.
MB
Risposta da Marco:
Almeno in FCE la rappresentazione è identica a quella di QuickTime Player, che è, per la decodifica con ritagliata in bianco e nero. Credo di Final Cut, in qualsiasi versione è in background per utilizzare automaticamente la decodifica di file QuickTime MOV sempre e fino a quando questo accade, ha i file H.264 per il Canon alcuna possibilità di un ungespreiztes Signaldecoding.
Esso, presumibilmente, a colori anche essere un modo per decodificare senza clipping. Non posso prendere in considerazione, però.
MPEGStreamClip gira su piattaforma Mac? Allora che sarebbe un modo semplice per sfuggire al problema.
Le opzioni di cui sopra per Windows in alcuni luoghi, da QuicktimePro di Avid DNxHD a camminare (il che rende le cose ancora di più), oppure utilizzare all'interno delle applicazioni di Windows CoreAVC poter effettivamente portare nulla, purtroppo, perché non è impedito dal fatto che la decodifica viene ancora eseguito Quicktime . L'unica eccezione sembra usare Cineform Neo, in combinato disposto con CoreAVC di essere. Anche io ho solo testato il metodo con il server di frame. Il lavoro in modo affidabile.
Marco
Risposta da MarcBallhaus:
Esso, presumibilmente, a colori anche essere un modo per decodificare senza clipping. Non posso prendere in considerazione, però.
MPEGStreamClip gira su piattaforma Mac? Allora che sarebbe un modo semplice per sfuggire al problema.
Gibts MPEGStreamClip per PC? Non sapevo nulla, chiaramente in esecuzione sul Mac. E il colore per la decodifica piuttosto non come lo strumento giusto per lui ...
MPEGStreamclip in grado di gestire lo stack? Non sono mai stato davvero così interessati ...
MB
Risposta da deti:
FFmpeg è tuo amico.
Deti
Risposta da Matzel:
Ciao,
Apple ha gentilmente risposto e l'aggiornamento di ieri a QuickTime 7.6 risolve il problema. QT trasformati ora offerta l'intera gamma di 0-255 e non è più limitato allo standard video di 16-235. Posso parlare solo per Mac, ma come ho letto da qualche forum, questo vale anche per QT su Windows.
Saluto
Risposta da Axel:
Una buona notizia.
Risposta da MarcBallhaus:
FFMPEG ho guardato verso di me ... opensource, che sta diventando più che la sua gestione della divisione PC, è necessario installare 4 programmi e per realizzare uno scopo ... non è affatto.
Grazie comunque per la punta.
Poi ho aggiornato volte QT.
MB
Risposta da filmpraxis:
Ho seguito con interesse l'articolo. Noi doktorn stato a lungo intorno a questo problema. Posso confermare che funziona con Apple QT 7,6 sul PC. Basta installarlo e riavviare piacere - dopo che tutti i tentativi elaborati per risolvere in qualche modo diverso.
Ho provato con EDIUS 5.01. La clip originale guarda bene e vince ancora la qualità, se tradotto in de Canopus HQ codec.
Suggerimento per un rapido test: MOV QT per giocare, poi nel menu di copia di "andare" e vanno in un visualizzatore di immagini / editing di immagini su "Insert". Con tutte le altre versioni di QT, l'immagine è buio qui.
Thomas Wagner
Risposta da MarcBallhaus:
Ho provato con EDIUS 5.01. La clip originale guarda bene e vince ancora la qualità, se tradotto in de Canopus HQ codec.
Un codec la qualità migliore? Ah, sì. Molto interessante.
Suggerimento per un rapido test: MOV QT per giocare, poi nel menu di copia di "andare" e vanno in un visualizzatore di immagini / editing di immagini su "Insert". Con tutte le altre versioni di QT, l'immagine è buio qui.
Thomas Wagner
Sbagliato. Oh gente ... in QT, vi è una modalità di compatibilità per FCP, il che rende l'immagine più scura è ciò che il passaggio gamma. Questo non ha nulla a che fare con essa a tutti.
---------
Ora ho installato la nuova versione di QT e il problema rimane lo stesso. Un PNG, rausgerechnet con MPEGStreamclip ha gamma più dinamico di quello stesso telaio con QT di PNG. In quest'ultimo, si vede chiaramente nella istogramma, che è semplicemente su e giù un po 'è stato tagliato, e precisamente a 16 e 235
MB
Risposta da Marco:
Ho appena installato l'aggiornamento nella versione per Windows. Quindi il problema è definitivamente risolto. Penso che sia difficile che Apple ha utilizzato per questa enorme tre anni.
Marc Ballhaus, non posso provarlo attualmente sul Mac con un Waveformdarstellung. Ma il confronto mostra l'immagine dopo l'aggiornamento alla versione precedente Quicktime visto più in dettaglio nel luci e le ombre. Così posso migliorare, ma non so se il clipping che - così come è nella versione Windows del caso - è completamente risolto.
Marco
Risposta da MarcBallhaus:
Ho appena installato l'aggiornamento nella versione per Windows. Quindi il problema è definitivamente risolto. Penso che sia difficile che Apple ha utilizzato per questa enorme tre anni.
Marc Ballhaus, non posso provarlo attualmente sul Mac con un Waveformdarstellung. Ma il confronto mostra l'immagine dopo l'aggiornamento alla versione precedente Quicktime visto più in dettaglio nel luci e le ombre. Così posso migliorare, ma non so se il clipping che - così come è nella versione Windows del caso - è completamente risolto.
Marco
Il miglioramento in grado di riconoscere a me, ma riguarda la gamma, non il ritaglio.
MB
Risposta da Marco:
Cambiamenti nella gamma, non ho preso veramente in considerazione. Ci sono miglioramenti evidenti nella gamma più oscura in bianco e nero. Ma per me essere sul Mac, purtroppo, non misurabile.
Marco
Risposta da domain:
Un cambiamento in esclusiva gamma, non riesco a immaginare in realtà non proprio, che sarebbe stato uno scherzo. Il quadro sarebbe sicuramente look morbido (span di 226 a 256 livelli, con gradazioni più fine), ma che risolverebbe il Clippingproblem infatti in alcun modo.
Risposta da Marco:
Sono andato sul Mac, una volta di dover utilizzare un software di grafica per renderlo almeno essere in grado di confrontare tramite istogramma. Purtroppo, ho dalla vecchia versione QT solo una tomba singola schermata in cui le luci non sono stati particolarmente critici. Ma nella zona di nero era lì con QT 7,5 ancora chiaramente riconoscibile, e anche il taglio l'istogramma misurata. Con Qt 7.6, la stessa clip mostra anche l'istogramma in nero non è più il clipping. Ciò che aveva precedentemente tagliato il taglio in nero, è oggi conservata come le informazioni di immagine nel range 0-15.
Marco
Risposta da Axel:
Il problema è, almeno per Quicktime, ha deliberato, il thread è obsoleto. Clipping Tutto ancora deplorevole deriva dalla esposizione durante le riprese.
Risposta da MarcBallhaus:
Il problema è, almeno per Quicktime, ha deliberato, il thread è obsoleto. Clipping Tutto ancora deplorevole deriva dalla esposizione durante le riprese.
Aha. E perché non vedo una differenza dalla stessa registrazione tra MPEGStreamclip e QT? Se visualizzate o esportati, QT taglia a 16 e 235 e stretshing a 0 e 255
MB
Risposta da domain:
Ora in poi diventa veramente interessante, a volte curioso di sapere se Ballhaus è giusto, che sarebbe un po 'troppo
Risposta da Marco:
...
Risposta da Marco:
Ora che ho installato una volta MPEG Streamclip su Mac e hanno avuto qualche confronto tra Streamclip e Quicktime Player su piattaforma Mac e frame-esportazioni dei due strumenti con il Windows contro i risultati, non vedo niente.
Marco
Risposta da Marco:
Possedimenti Herverglichen avanti e indietro di nuovo, anche tra Mac e PC. Tra la precedente versione di QuickTime 7.5 e l'attuale versione 7.6 è sicuramente una differenza enorme. Significativa di ritaglio in linea di principio in bianco e nero in versione 7.5, in, nessun taglio in bianco e nero in versione 7.6 - né su Mac né su PC.
Quicktime il segnale decodificato tra Mac e PC le versioni sono sostanzialmente identiche. Ho verificato il segnale sul PC con la forma d'onda, e istogramma RGB Parade. Dal Mac, ho l'H.264 Canon file da importare in FCE e poi esportato come file Quicktime con PNG.
Ho anche esportato dal Mac tramite MPEG Streamclip PNG. Questo segnali Streamclip sono ancora sostanzialmente identici alle versioni che ho vorbeigeschleust sul PC tramite il server per lo streaming QuickTime. Così l'output di Streamclip per Mac e PC server per lo streaming, posso effettivamente sedersi in una sola volta. E ovviamente, qui non clipping in luci e le ombre.
Tuttavia, vi è un chiaramente identificabile e facilmente misurabili differenza tra il torrente "" versioni e la versione di Quicktime. Le versioni di QuickTime sono quasi mai in RGB 16, hanno un totale di un accendino "" Gamma e compresso (non: clipping), i bianchi in ultima analisi, poco più. Il taglio nel bianco c'è, ma ancora non può davvero essere una qualsiasi questione, o se, sarebbe in una serie di solo 1 o massimo 2 per cento. Potrei, quello che vedo non è quello di descrivere con precisione rispetto alla precedente versione di Quicktime, ma quando clipping. Il Black eh no.
Nel complesso, le versioni Quicktime sembrano ancora dare qualcosa di più dinamico di quello degli "stream" musica. Solo che non sappiamo senza una immagine di prova come base, che è il segnale fede.
In contrasto con l'uscita di Quicktime 7.5, ora potevo vivere con entrambe le versioni.
Marco
Risposta da MarcBallhaus:
@ Marco ... machs ma non così complicato per esportare un PNG da sempre uno MPEGStreamClip e QT - su Mac - e Lad sia in Photoshop. Poi si può vedere nella Histo che clippt la versione QT. Se un Livelli limitata utilizzando, la dinamica nella versione MPSC a 16 e 235, il PNG appare esattamente esattamente come da QT. Così clippt QT.
MB
Risposta da Marco:
Avevo anche fatto (anche se non in Photoshop). Dato che, inoltre, non clippt, o almeno così minima che non è davvero rilevante. E le differenze con la versione precedente di QT sono enormi.
Marco
Risposta da MarcBallhaus:
Avevo anche fatto (anche se non in Photoshop). Dato che, inoltre, non clippt, o almeno così minima che non è davvero rilevante. (...)
Marco
You're funny. Così è ancora clippt!
Poi i film di notte e vedrete che ciò che in precedenza era minimo, improvvisamente c'è un problema perché i contrasti sono più alti durante la notte e si sono poi dipende in primo luogo mette in evidenza e di disegno in profondità, mentre i medi sono schnurzegal, a Tagaufnahmen è il contrario.
MB
Risposta da Marco:
Hab mal una curva lineare contrasto (da RGB 0 resi a 255), come la decodifica H.264 Quicktime e analizzare diverse. Se il segnale viene decodificato H.264 su un Mac, cambierà la curva di contrasto. Con un non compresso AVI non è succedendo. Sul PC non succede con H.264. Inoltre, le varianti che (da Mac) da MPEG Streamclip esportazioni da cornice ad uscire con Gamma 2.2 sono pressoché identiche alle spese testato Quicktime () sul PC. Ma con 1,8 gamma di uscita da Streamclip è molto più vicina all'originale.
Quindi, con tutto ciò che è lontano dal Mac uscite H.264 files've visto un cambiamento nella curva di contrasto chiaramente visibile, meno drammatica in Quicktime oltre a Streamclip, a seconda delle impostazioni di esportazione. In nessuno dei casi, la curva di contrasto della decodifica H.264 originale su Mac è stata riprodotta correttamente. Funzione di ritaglio è visibile solo leggermente (il 3 per cento).
Penso che il problema di ritaglio con Quicktime è in gran parte risolti, ma la rappresentazione della curva di contrasto nella trasformazione Mac può essere ottimizzato un pezzo.
"Sei buffa. Clippt Così ancora!"
Per i segnali critici sono stati tagliati con QuickTime 7.5 o 13 per cento del segnale. Con QuickTime 7.6, che è solo circa il 3 per cento. So soltanto che il valore esatto, dal momento che ho potuto testare con il gradiente di grigio (in video real ho preso ieri sera sotto il microscopio, non è stato preciso come analizzato). Che è già un enorme miglioramento.
La variazione effettiva del segnale è davvero molto a che fare con il cambiamento della curva, ma meno con il ritaglio. E 'stato molto diverso, con QT 7,5 ancora. Se la gamma, né di ottimizzare il controllo visivo probabilmente sarebbe alcuna differenza. In effetti, può essere curvato con la correzione gamma a Mac-esportazione verso la curva originale di nuovo a raddrizzare. Così la maggior parte è una questione di gamma. La perdita da parte di ritaglio, di corso, rimane dopo la correzione gamma.
L'istogramma risulta essere il modo non, come strumento valido. La visualizzazione delle forme d'onda rende chiaro ciò che sta accadendo.
Marco
Risposta da MarcBallhaus:
Il problema qui non è in genere di H.264 su Mac, ma ci sono le registrazioni della 5D in H.264/MOVs. Ciò che si sta descrivendo è solo una teoria, ciò che scrivo è una pratica. Ci dispiace, non fraintendetemi, ma i risultati possono essere teoricamente corretto, ma praticamente non è semplicemente il caso.
L'istogramma è lo strumento migliore per dimostrare a me circa la gamma tonale, come per qualsiasi altra cosa che è lì.
Risposta da MarcBallhaus:
La differenza con i PNG Quicktime non è minimo, ma significativo. Da Histo a parte, è giusto nell'immagine sopra indicato può buchi neri, di sinistra come il Reno, mentre l'immagine da qui ha MPEGStreamclip disegno significativo.
Risposta da Axel:
Hai ragione, Qt è disponibile in nero praticamente tagliata. Solo l'immagine Mpeg SC possibile utilizzare un Livelli (ma solo se) l'inverno, rami spogli della sinistra nel cielo sarà di nuovo visibile.
Che cosa rimane allora, se si vuole tagliare con FCP? Originale del file dalla fotocamera a colori e di importazione in uscita 10bit non compressi ...
Risposta da Marco:
Del corso, la gestione dei modelli di test generato è lontano dalla pratica. Ma finora queste recensioni del clip Canon anzi priva di ogni riferimento oggettivo! Finché non si sa come l'immagine potrebbe mai essere come nella condizione originaria, è difficile fare affermazioni attendibili su quale strumento è migliore e dove l'immagine finalmente succedendo esattamente quello che errore. Dal momento che ho a dare Wolfgang piuttosto che generati dalla Canon, barre di colore standard sarebbe molto utile (e meglio di un auto-generata e) di H.264 immagine di test codificati.
La differenza sul tuo screenshot è davvero evidente. Ma anche il segnale proveniente dal clippt Streamclip pur sempre un po '. Corrispondono alle ritaglio in nero che appare sulla tua versione di Quicktime può essere visto, anche in circa il 3 per cento di cui sopra. Questo motivo anche visivamente evidente in quelli che ho finora, purtroppo non è.
Se il file originale da qualche parte, forse come generalmente accessibile e disponibile per il download legale?
Quello che mi preoccupa in questo in particolare la differenza tra il Mac e il PC di decodifica. Quando ho esportare un file da Canon 5D FCE come un non compresso AVI, e confrontare questo output con il segnale originale Canon sul PC, poi mi sono costretti ad alzare la gamma è il segnale FCP circa il valore da 0.4 a una visione sostanzialmente simili. Così quando si confronta il Mac e l'edizione PC uccide la differenza tra la gamma erstmal altri errori.
Marco
Risposta da MarcBallhaus:
Se il file originale da qualche parte, forse come generalmente accessibile e disponibile per il download legale?
Questi sono tutti i colpi Mood in lunghezza, con 1-2 minuti. Ma io aspetto, quello che è su questa commissione in cui io possa avere rotto dopo 5 secondi ... si dispone di un indirizzo e-mail per me?
MB
Risposta da Marco:
Non ho ancora trovato sul web alcune fonti. Guardo erstmal se forse alcuni temi critici sotto.
Marco
Risposta da MarcBallhaus:
Non ho ancora trovato sul web alcune fonti. Guardo erstmal se forse alcuni temi critici sotto.
Marco
Dato che non darebbe così tanto su di essa, perché ho visto appena ottenuto ciò che, dove le persone a trovare le giuste regolazioni.
MB
Risposta da Bruno Peter:
Clip si può scendere laggiù, sulla necessità destra VIMEO?
http://www.vimeo.com/1764260?pg=embed&sec=1764260
Risposta da Marco:
Sì, grazie per il link.
Marco
Risposta da Marco:
In questa registrazione, la telecamera è stata fehleingestellt anche grossolana, ma ho potuto capire che in una certa misura anche il ritaglio in nero. Oggi ho avuto nuovamente setacciato un carico di circa 10 completamente diverso 5D clip. Il problema con la gamma errata-esportare il FCE e il valore di correzione di 0,4 per il PC è la stessa per tutti.
Sembrerebbe che sul PC con Quicktime decodifica il problema di ritaglio in ombra, nemmeno con il basso 3 per cento. Ma che è con le clip disponibili per me, non sono chiari. Questa clip ultimo è qualitativamente facile grottig male. Tuttavia, ci sono lì in ombra qua e là, un dettaglio ", che dopo la decodifica Quicktime su Mac non possono essere riprodotte, proprio come in una correzione del colore è avvitato.
Marc Ballhaus, se fai un piccolo esempio di un movente, simile a quello trovato sul screenshot mostrato, avrebbe, che sarebbe interessante. Per un segnale di qualità superiore, ho potuto un test affidabile per determinare se e in che modo si differenzia di ritaglio tra PC e Mac, Quicktime decodifica. La tua mail:
Senza dubbio, però, è con la decodifica Quicktime, come un po 'di qualcosa non andava, nonostante un significativo miglioramento rispetto alla versione precedente.
Marco
Risposta da MarcBallhaus:
@ Marco
Ho inviato nen Rohschnipsel. Mentre il calesse, perché mi sono dimenticato di disattivare la modalità automatica, ma che solo 20 MB. Ma per la prova e forse non a cattiva.
Darle il tempo di feedback sarebbe bello.
MB
Risposta da Marco:
Super, grazie per il clip! Era esattamente il motivo giusto.
Quindi: prima al PC, che è trattata rapidamente. Se io decodificare la clip sul PC con la versione Windows di MPEG Streamclip, Quicktime Player o il software di editing (che si basa su Quicktime per la decodifica), non fa alcuna differenza. La gamma è d'accordo a quanto pare, e anche le ombre più profonde non sono ritagliato.
Poiché il riferimento è chiaramente a oggetti, ad esempio sotto forma di un Farbalkens standardizzato dalla fotocamera, è l'assunto che la gamma della versione di Windows è corretto, è ancora in parte speculativa. Mi riferisco alla serie di test con la rampa generata internamente, che era quello di Quicktime H.264 la codifica e la decodifica seguite correttamente. Ma che porta ancora una certa quantità di fallimento.
Su Mac:
Dal momento che i segnali sul mio MacBook, non posso prendere in considerazione che ho fatto sia l'esportazione in PNG sequenze di immagini. Una volta con MPEG Streamclip e una volta con FCE. Il PNG-sequenza che ha poi controllato sul PC.
Entrambe le versioni - Esportazione dalla FCE e l'esportazione da MPEG Streamclip sembrava la stessa. Per aggiungere valore al 0,4 gamma, e ho cambiato anche il ritaglio leggera nell'ombra.
Quando ho Streamclip da un luogo diverso da quello di esportazione single frame scegliere, non ho scelta nella gamma. Penso che sarà utilizzato oltre 2,2. Questo è ciò che appare su Mac con Streamclip e QuickTime per il risultato più grande deviazione.
Poi ho esportato di nuovo, il primo fotogramma del clip con Streamclip gamma 1.8. Il risultato è migliore, a metà strada tra la versione 2.2 e le versioni di Windows, e il ritaglio sembra sostanzialmente eliminata.
Ma ciò che mi sorprende è che l'esportazione Mac Streamclip sul lato uno, la gamma del 1.8-opzione di esportazione non ai valori finale, una deviazione di 0,4 rispetto al 2,2-opzione di esportazione, e quindi non è ancora uguale alla versione di Windows.
D'altra parte sono anche lì (nel caso della gamma 1,8 opzione di esportazione), le ombre più scure sono altamente compressi in modo che vorbeischießt a un tema così cruciale solo un ritaglio.
Così, una volta, indipendentemente dallo strumento che conduce alla piattaforma ottimale per la decodifica, non riesco a raggiungere la decodifica dei 5D clip su Mac e PC un unico risultato.
Marco
Risposta da PowerMac:
Il passaggio di gamma, non sarà così, dato che il Quicktime Mac cerca di compensare il suo valore propria gamma di 1.8. Per esempio, anche se ho un Gamam monitor di 2.2 ... Sbagliato ancora una volta:) per stabilire uno standard per l'impossibile "corretta" la ricezione. Anche mostra molti, vedendo le condizioni, i parametri ...
Risposta da Marco:
Sowas ho paura. Io non sono la sella su Mac. Ho sempre pensato che la gamma di 1.8 sarebbe rilevante solo per la visualizzazione di Mac interno e il lettore, l'esportazione video finale, ma in linea di principio per un 2,2-Play deve essere interpretato. Penso che sia in altri formati video in Quicktime (Mac) Bill indossati. Proprio come H.264 sembra ballare fuori linea.
Quindi ancora una volta la questione dello spazio disponibile, che utilizza gamma-mapping per il D5 Canon con la codifica H.264.
La mia incertezza sia con QuickTime 7.6 su piattaforma Windows, è veramente così perfetto come sembra a prima vista, forse non del tutto ingiustificata. Ci sono alcune ipotesi (), in altri forum che questo è solo un "Quick'n'Dirty" soluzione, in cui l'piuttosto infelice da 3 hergewandelt diversi spazi di colore è tornato e cosa portare ad un segnale senza clipping del bianco e nero, l'8-bit del segnale è allungato, mentre, in modo che l'informazione è persa altrove. Il divario di istruzione è evidente nel istogramma. Avevo notato con una certa sorpresa.
Ci sono anche commenti qua e là per garantire che la gamma nella decodifica H.264 via Quicktime su piattaforma Windows è leggermente sopravvalutata e quindi l'immagine appare più brillante di quanto dovrebbe essere. Poi alla fine sarebbe quasi nessuna decodifica a questa pagina (tanto più che il risultato di una votazione nella versione Windows di MPEG Streamclip con il risultato Quicktime è identico).
È possibile che in realtà il risultato di MPEG Streamclip per Mac (e la versione server per lo streaming su PC ancora) il migliore, nel senso di essere più vicina all'originale.
Marco
Addendum:
La soluzione che rende l'impressione più autentica e spettacoli anche in ogni metro del minor numero di artefatti, sta scontando con il flusso tramite AviSynth.
Sul lato altro, è ancora diffidente del modo attraverso Quicktime. Come è stata la soluzione ad un problema creato nuovi problemi appaiono.
MPEG Streamclip con Gamma 2.2 uscita, sebbene nessuno dei due manufatti, come la soluzione AviSynth, ma gamma probabilmente errata, e ha clippt. MPEG Streamclip 1,8 con clippt gamma, anche se probabilmente non è, ma dimostra ancora di più gli artefatti (ma sempre meno di Quicktime per Windows) e resta da chiedersi se la gamma è corretta (la questione si pone, tuttavia finora in ciascuna delle soluzioni descritte qui ).
Risposta da MarcBallhaus:
Si prega di gerngeschehen:)
Io ora concludere che non hai il ritaglio nella misura in cui l'ho fatta?
MB
Risposta da Marco:
Noch abit è stato aggiunto in precedenza. Sarei lieto di inviare alcuni risultati, tra cui i display dei dispositivi di misurazione (forma d'onda, e la parata istogramma RGB). Il fatto che ogni strumento produce un risultato diverso rallenta, tuttavia.
La mia conclusione momentanea sarebbe che deve essere evitato, nonostante l'aggiornamento Quicktime per un risultato con una perdita 'di qualità Quicktime sul PC è sempre meglio lasciare il modo più frameserving dovrebbe, al Mac, MPEG Streamclip con la mappatura di gamma ottimale (se possibile).
Che solo è convinto che l'aggiornamento Quicktime ha migliorato il ritaglio di fattori più o meno orientata, e altri più nella nicchia teorica, provare aggiornamento Quicktime, di corso, una soluzione semplice.
A voi è personalmente probabilmente più dal lato Mac è importante, giusto?
Marco
Risposta da MarcBallhaus:
A voi è personalmente probabilmente più dal lato Mac è importante, giusto?
Marco
Sì, anche di più. Anche se ho ancora diversi PC, ma è anche un MacBook e un paio di decente Mac Pro. Ma andate facile se solo sul PC, allora è per PC.
MB
Risposta da Marco:
Su Windows, ho davvero alcun clipping, anche con Quicktime 7.6. Ma i risultati sono molto dubbia, con l'eccezione del metodo server frame.
Oggi, io non sono esempi di compilazione. I'm gonna catch up domani o il giorno dopo.
Marco
Risposta da Marco:
Gli esempi sono riassunte ->
| |
