Benvenuto su VideoMakers.net
Iscriviti per condividere la tua passione sul principale sito web italiano dedicato al VideoMaking!

Gli eventuali inserti pubblicitari all'interno delle discussioni sono visibili solo se non hai eseguito l'accesso al forum; ricordati di eseguire l'accesso o, se non sei ancora registrato, fallo QUI

Clicca qui per leggere le regole del forum
Discussioni sui Cinecorder e sulle macchine fotografiche Dslr, SLT & Mirroless in ambito video.

Moderatore: Moderatori

#1328647

arcanico ha scritto:... prima di dire che era presente il difetto, ho analizzato la clip originale in edius prima della conversione in cdng con raw converter...
Non ho ben capito.
In edius hai analizzato la clip in prores raw? E il difetto era già presente? Se si, tutta la parte successiva ovviamente non mi interessa.



Nine Dots Film

#1328648
Ulteriore domanda che non mi è chiaro e potrebbe avere il suo peso.
Posto che il raw su hdmi sia ON sulla gh6, la risoluzione 5,7 k piuttosto che 4k la si decide sulla gh6 o sul ninja?
Intendo dire, la macchina trasmette al ninja comunque i 5,7k, e il ninja croppa a 4k, oppure va impostato sulla gh6 il 4k croppato al fine di registrare in 4k il raw sul ninja?
La risposta a questa domanda può ovviamente spostare le responsabilità del difetto alla gh6 o al ninja a seconda di come si opera.

Nine Dots Film


#1328649
Prima risposta:
Il difetto si presenta già analizzando la clip in edius, tutto il resto serve per trattare il cdng in dvrs.

Seconda risposta:
L'ho scritto più sopra, se hai abilitata l'uscita HDMI RAW sulla GH6, comanda la GH6 e controlla tutto la GH6.
Scegli sulla GH6 il 5.8K, il registratore si adegua e via così con tutte le altre possibilità.
Quando invece disabiliti l'HDMI RAW sulla GH6, il discorso cambia ed avvengono le conversioni automatiche quando si scelgono risoluzioni superiori al C4K, perchè puoi registrare contemporaneamente il 5.7K sulla CF Express ed in C4K sul registratore, convertito in automatico, con pari fps e la tabella di cui i link nel post precedente vi indica come avviene la conversione automatica.
In ogni caso, se gli fps coincidono, il registratore lascia invariati quelli impostati in cam, altrimenti interviene quello indicato nelle tabelle di cui sopra.
Quello che invece non puoi fare dalla GH6 è impostare il codec del registratore in automatico (a parte il raw), per cui dal registratore puoi scegliere apr, avid e h265 e la massima risoluzione è il C4K e gli fps massimi arrivano a 60.
Se dal registratore imposti apr raw e sulla GH6 non è impostato questo parametro, ricevi un avviso che ti invita o a cambiare sulla GH6 in apr raw oppure sul registratore ad impostare un altro codec.
Spero di essermi spiegato bene.
#1328653
Vi propongo queste due immagini di una stessa clip.
Tenete presente che la luce era al tramonto, intorno alle 18 e 30 ed all'interno della stanza non si vedeva quasi niente.
La ripresa è stata fatta col 10-25 1.7 con 1/50 a tutta apertura, quindi 1.7, 6400 iso, 5500k, 5.7K apr raw (cdng) 25 fps:

------------- prima ----------------
Statuette_6400_iso_1_50_f1_7_5_7K_color_preset_no_denoise copia.jpg
Statuette_6400_iso_1_50_f1_7_5_7K_color_preset_no_denoise copia.jpg (984.88 KiB) Visto 893 volte
------------ dopo ------------------
Statuette_6400_iso_1_50_f1_7_5_7K_color_preset_gradient_denoise copia.jpg
Statuette_6400_iso_1_50_f1_7_5_7K_color_preset_gradient_denoise copia.jpg (460.45 KiB) Visto 893 volte
---------------------------------------

Ho cercato di capire se c'è una logica nella manifestazione del problema segnalato, ma ahimè, no...le aree colpite possono essere in qualsiasi parte del fotogramma!
Il fenomeno si presenta usando tutte e due le camere.
#1328654
Questa invece è la ripresa fatta in apr 422 hq, vlog, prima (e cioè interpretata con le lut di riferimento) e dopo, con la color e denoise...


----------- prima -------------
apr_422_hq_color_preset_no_gradient_no_denoise.jpg
apr_422_hq_color_preset_no_gradient_no_denoise.jpg (748.56 KiB) Visto 881 volte

------------ dopo --------------
apr_422_hq_color_preset_gradient_denoise copia.jpg
apr_422_hq_color_preset_gradient_denoise copia.jpg (953.03 KiB) Visto 881 volte
----------------------------------

...
#1328655
Ok, da quello che mi dici devo concludere che con estrema probabilità il problema sia proprio nella gh6, quando "costretta" a trasmettere il flusso raw a 5.7k.
Oppure potrebbe essere un problema di implementazione non perfetta del protocollo per trasmettere il raw, ma sempre da parte di gh6.
Un test con una qualunque altra macchina potrebbe togliere ogni dubbio.

Nine Dots Film

#1328658
:wink: Buona domenica
Arcanico, ma tu hai due GH6?
Dici che le aree difettate possono essere ovunque nel fotogramma, ma nonostante ciò non si manifesta se durante la registrazione HDMI RAW ON il NInja crea un DCI/4K.
Se il difetto fosse creato dalla GH6 o dal suo protocollo di trasmissione Raw on HDMI, come spieghi, William, che in DCI/4K il difetto non si presenta nonostante le condizioni di impiego della GH6 siano le stesse?
D'altra parte non potrei nemmeno attribuire il problema al Ninja, per gli stessi motivi.
:( Non ho elementi risolutivi, perciò anche per me varrebbe la prova di usare il Ninja con un altra camera adatta o la GH6 con un altro registratore per il Raw on HDMI

bye
#1328660
Ne ho sempre avute due sin dai tempi della canon A1 ed FTb! (mia prima 13ma e mio primo premio di risultato quando avevo 16 anni! Lavoravo già ed andavo a scuola la sera per concludere gli studi superiori...)
Successivamente Eos 100 ed FTb...per poi vendere tutto a favore delle telecamere per ritornare sulle attuali DLSR perchè fanno i miracoli che fanno!
Gran vantaggio, con due ottiche già montate per non perdere il famoso "attimo sfuggente", che perdi puntualmente lo stesso...
Amo fare i time lapse e spesso, avendone una, poi non sai come passare il tempo nell'attesa, che può essere sfruttato con la seconda o a fare un secondo time lapse del particolare del primo o a riprendere altro, così il tempo scorre piacevolmente, piuttosto che passivamente.
Tornando al discorso del problema, ti confermo che il DCI/4K ne è esente, mentre è presente sia che la ripresa si faccia a 5.7K che a 5.8K (sensore pieno).
Il DCI/4K alla fine occupa solo la parte centrale del sensore, essendo una ripresa pixel/pixel, quindi si prende i suoi otto mega pixel e l'immagine è croppata. Per avere la stessa inquadratura, devi allontanarti dal soggetto.
Cosa che ho fatto per vedere se in entrambe le situazioni avevo o meno il problema evidenziato e ti confermo che in tutti e due i casi il problema non si presenta.
Quindi non rimane che fare la prova che suggerisce Willy e spero che appena si avrà un po' di tempo libero entrambi, di poterla fare.
#1328661

CCD ha scritto:Se il difetto fosse creato dalla GH6 o dal suo protocollo di trasmissione Raw on HDMI, come spieghi, William, che in DCI/4K il difetto non si presenta nonostante le condizioni di impiego della GH6 siano le stesse?
infatti nel mio post precedente ho chiesto un chiarimento su questo aspetto, ovvero chi decide, in raw, di registrare a 5,7k o a 4k?
Mi è stato risposto che comanda la gh6.
Ne devo dedurre che, se la gh6 è impostata a 5,7 k non è possibile registrare una parte croppata in apr raw a 4k da atomos. Ma devo impostare il crop a monte, sulla gh6.
Di conseguenza, se il problema si verifica a 5,7k ma non a 4k direi che molto probabilmente la causa è proprio la gh6. Non ho una certezza assoluta, ma sono molto orientato in quella direzione.



Nine Dots Film

#1328662
La spiegazione di William ha una sua logica, plausibile e razionale: comanda la GH6 e sapendo che il registratore avrà bisogno di un segnale solo a 4K è inutile inviare su HDMI un segnale a 5.7K, quindi il crop avverrebbe nella GH6.
Rimane la mia perplessità pensando al fatto che il crop significa "semplicemente" non trasmettere certi dati relativi ai pixel fuori dall'area centrale, tutti gli altri dovrebbero essere inviati tali e quali a come GH6 fa quando il crop non è operato. Trattandosi di Raw infatti i dati dei pixel non dovrebbero essere manipolati, ma solo impacchettati nel protocollo e trasmessi.
Non avendo conoscenze specialistiche in materia non riesco ad immaginare come si produca un artefatto solo in una delle due modalità di invio dei dati. E' vero, come abbiamo appurato, che nel caso del 5.7K la larghezza di banda occupata è maggiore però siamo sempre molto sotto i limiti della tecnologia impiegata (e che GH6 ha già praticamente dimostrato di gestire bene con altri formati, ma senza l'uso del protocollo Raw on HDMI). Che fosse proprio quest'ultimo? A ben vedere, di esso non conosco i limiti perchè non ho mai visto le sue specifiche.

Il medesimo comportamento di ben due GH6 escluderebbe la possibilità di un guasto, e fa propendere verso un problema di progettazione. La prova si ha da fare!

bye
#1328663
A questo indirizzo web ( https://www.arcanico.it/test_gh6/test_a ... tomos.html) potete scaricare i fotogrammi esportati da edius su un progetto UHD, ma se ingrandite l'immagine, anche semplicemente col programma che propone windows di default, potete osservare i pixel interessati al fenomeno.
La cosa curiosa è che nel 5.8K, l'anomalia è centrale, mentre sul 5.7K si concentra in alto e a sinistra.
Ho aggiunto anche il 4.4K, dove qui il fenomeno, in alcuni fotogrammi come quello linkato, si presenta ma in una forma molto blanda.
#1328664

CCD ha scritto:Rimane la mia perplessità pensando al fatto che il crop significa "semplicemente" non trasmettere certi dati relativi ai pixel fuori dall'area centrale, tutti gli altri dovrebbero essere inviati tali e quali a come GH6 fa quando il crop non è operato.
In realtà questo è normale.
I sensori, più o meno tutti, sono in grado di andare più o meno veloci a seconda di quanta parte dell'area del sensore scansionano.
Ad esempio, sulla zcam f6 che conosco bene, i 6k sono disponibili
Solo al massimo a 48 fps, mentre aree più piccole, ad esempio il crop a 4k, o il crop in 2,35:1 permettono di arrivare a 60 fps e anche oltre.
Questo è normalissimo perché il sensore scansiona i pixel uno per uno, per cui più sono e più tempo ci vuole.
I sensori hanno la possibilità, da firmware, di impostare la scansione e di fatto fare i vari crop.
In questo caso specifico potrebbe esserci un problema di velocità del processore della gh6, che in 4k sta dietro a scansionare il sensore e trasmettere i dati raw sulla hdmi, mentre a 5,7k, avendo praticamente il doppio dei dati da elaborare (anzi di più), non ce la fa.


Nine Dots Film

#1328666
La progressività del difetto all'aumentare della risoluzione sembra confermata dai tuoi snapshot, Arcanico, grazie.

William, sì conosco quella meccanica che descrivi su crop. Non era quello a rendermi perplesso, ma il fatto che lettura del sensore e la trasmissione del segnale avvengono senza manipolazioni. Quindi perchè con risultati diversi? Come appunto abbiamo ipotizzato cambia solo la quantità dei dati.
Solo che la tua valutazione è che il processore non ce la faccia a gestire il lavoro con risoluzioni più alte, mentre io tendo a scagionare il processore perchè è lo stesso che in altre situazioni (niente Raw on HDMI) gestisce con successo e contemporaneamente la lettura totale del sensore, la codifica e registrazione interna e la trasmissione di un segnale almeno il doppio più veloce sulla HDMI (non è così che succede?), cioè un compito ai miei occhi più gravoso.
Se quanto dico è vero, allora vedo più probabile che l'anello debole ad alte risoluzioni sia quel protocollo custom per il il raw su HDMI, forse anche perchè non ne conosciamo le specifiche.

bye
#1328667

CCD ha scritto: Se quanto dico è vero, allora vedo più probabile che l'anello debole ad alte risoluzioni sia quel protocollo custom per il il raw su HDMI, forse anche perchè non ne conosciamo le specifiche.

bye
tu non hai torto, ma resta il fatto che con altre macchine il protocollo custom pare funzionare perfettamente. Può essere però una implementazione non perfetta su gh6.
Un altra ipotesi che pure è già stata fatta è anche che il minimo di debayering e denoise fatti in macchina eliminano il difetto, per questo con altri codec non si vede.



Nine Dots Film

#1328671
Vi propongo un passaggio del blog suggerito da Willy, al quale chiedo di interpretarlo per noi...

"
ratocx
·
11 mesi fa
·
modificato il 11 mesi fa
Final Cut Pro X, Premiere Pro, DaVinci Resolve

Hai ragione sul fatto che RAW richieda meno larghezza di banda, ma ciò è dovuto al formato dell'immagine bayer, non che sia ProRes RAW. AFAIU la fotocamera in realtà non invia ProRes RAW, invia un flusso di dati bayer non compressi. (Potrebbe essere compresso in dati logaritmici a 12 bit dai dati di profondità di bit del sensore nativo lineare). Il formato bayer non ha dati RGB completi per ogni pixel, ma in realtà solo dati per un colore per pixel, tipicamente in un modello RGBG. Essenzialmente facendo sì che il flusso sia 1/3 delle dimensioni alla stessa profondità di bit. Aggiungi 12 bit rispetto a un normale segnale a 10 bit e la larghezza di banda totale del segnale è circa il 35-40% di un flusso RGB a 10 bit non compresso.

La conversione in ProRes RAW avviene nel Ninja V/V+, dove i dati Bayer vengono compressi utilizzando la compressione ProRes standard per ogni canale di colore, ma mantenendo i pixel in un formato Bayer. Inoltre Ninja V incorpora i metadati sulla fotocamera in modo che il software di editing sappia quale gamma e gamut applicare per farla sembrare normale. (Spesso puoi ignorarlo se lo desideri nel software di decodifica.)

Quando i file ProRes RAW vengono decodificati, viene applicato un debayer standard per tornare a quelli che sono essenzialmente dati RGB compressi ProRes a 12 bit.
"

Per quello che capisco io, la GH6 dovrebbe passare un flusso di dati al Ninja V+ che poi converte quell'informazione in prores raw...Ho inteso bene?
  • 1
  • 19
  • 20
  • 21
  • 22
  • 23
  • 29

Ciao William Fanelli. innanzitutto grazie per ave[…]

Grazie della risposta.....immaginavo.. Solo che s[…]

Grazie arcanico e totati per le risposte. @arcani[…]

First of all, consider your goals. If you want to […]