[News] Premières images de la Blackmagic Pocket 6K

Que l'on travaille sur 8, 10 ou 12 bits ne change rien à l'affaire, c'est des nombres entiers, même si on les mets dans un registre 32 ou 64 bits.
Si on fait des opérations sur des nombres entiers, il y a obligatoirement des arrondis, donc perte d'information.
C'est pour cela que les logiciels évolués travaillent en flottant pour faire les opérations et reconvertissent le résultat final en entier.
Exemple :
divise 17 par 3 en nombres entiers : le résultat c'est 5 ou c'est 6 ?

olivier

 

Je pige pas bien ton lien. C'est le plugin que tu as développé ?

 

Pour completer ce que dit giroudf est qu'aussi a mon avis il y a une confusion depuis de début de la conversation parce qu'une partie des 12 bits servent pour stocker la luminosité des pixels et non le nombre de couleurs.
Sur les 4096 valeurs possibles, la première moitié est utilisé pour la couleur, l’autre pour la luminosité.
L’intérêt de monter dans les bits, si le capteur suit, c’est de pouvoir augmenter la plage de dynamique de l’image, ce que tout le monde veut.

 

Je viens de relire le fil plusieurs fois.

Le BRAW est bien, plus ou moins, compressé (3:1 -> 12:1), il ne s'agissait pas d'affirmer (à mon avis) que c'était plus ou moins du "RAW compressé"... (encore que... on pourrait se parle du "semi-dématricage en interne", si quelqu'un avait des informations, solides, à ce sujet...).

Dématricer le RAW en temps réel demande bien quelques ressources, une config un peu ancienne sera à la peine (il suffit d'essayer de faire du montage multicam avec du REDCode/BRAW/CRL/etc, juste pour voir la tête du GPU, sur une simple lecture...).

Le RAW 12 bit c'est bien 4096x4096x4096 valeurs théoriques possibles (Notons que Resolve peut être amené à gérer des RAW 16 bit). Est-ce que ramener plus de 68 milliards de nuances d'un "RAW gamut" (mettre ici le nom du constructeur concerné) vers un affichage utile (par exemple BT. 709) nécessite de travailler en 32 bit float, je n'en sais rien. Mais comme cela, au doigt mouillé, ça ne semble pas idiot, ACES 1.0 = 16 bit float.

Cela dit, je suis sûr qu'il est possible de prendre contact avec les équipes de développement de DaVinci Resolve (ou de SGO Mistika, eux aussi travaille en 32 bit float), si vous avez le temps de faire partager vos connaissances, dans l'idée de réécrire un moteur un peu mieux optimisé.

 

Le postulat de départ est : attention il faut une grosse configuration

La confusion commence quand Atobit explique ou rappelle post 17 ce que dit BM sur son BRAW, et je cite directement BM:
"... un nouveau codec RAW, dont une partie de la débayerisation est traitée à l’intérieur de la caméra au lieu du CPU de l’ordinateur..... Avec le Blackmagic RAW, vous obtenez la qualité, le débit, la plage dynamique et le contrôle en RAW, tout en profitant d’une performance optimisée et de fichiers plus légers qu’avec des codecs vidéo."

Or la réponse de Jean Claude post 18 qui rappelle les différents niveaux de compression de ce BRAW veut prouver quoi...? Je n'ai pas tout a fait compris non plus...je dirais même qu'elle est en faveur d'une certaine fluidité puisqu'il existe plusieurs qualités possibles

La réponse donc serait plutôt : pas tant que cela finalement ?....Bon mais je n'en sais rien c'est ce que j'en déduis de ce que je lis ici et ce qu'avance le marketing de BM

 

Oui, il le faut.

Après, la notion de "grosse conf", c'est relatif. Selon ses habitudes de travail (proxy, pas proxy), son budget, etc. Il faudra un "gros" GPU, des SSD pour éditer les rushes en temps réel. Il faudra aussi stocker son RAW, qui même s'il est compressé, occupe nettement plus de place que du H264...

On peut télécharger Blackmagic RAW speed test pour se faire une première idée (ou mieux, un rush natif, il y a du 8:1 par ici : BMPCC 6K First Footage & Downloadable Clips - Newsshooter

On peut regarder ce qu'il se passe dans Premiere avec du REDcode ou du CRL, là : https://www.pugetsystems.com/pic_disp.php?id=56819

 

Bon, merci pour toutes ses explications, je n’insisterai pas plus sur ce sujet technique/théorique que je ne maîtrise pas.

Du côté pratique, j’ai pu constater que pour mon petit environnement informatique, la limite c’est la monter en résolution plutôt que le codec lui-même. Et bien sûr, quelque soit la résolution, plus tu appliques des effets sur tes clips, plus cela demande des ressources matérielles pour une lecture fluide en temps réel.

 

Il est effectivement probable que le ratio de compression ne change rien (ou pas grand chose) en ce qui concerne les performances (c'est une supposition de ma part, il faut le tester). Cela aura une influence uniquement sur le résultat (et le stockage concerné, bien sûr). La notion de grosse conf peut s'entendre aussi dans la quantité de disques à prévoir, pour sécuriser sa matière première (RAID 1 = x2). Si on monte des 52 minutes ou des captations LIVE, l'impact sur le budget n'est pas le même que si on fait dans le clip de 3 minutes, la pub, les sujets courts... Je pense qu'on peut tous convenir qu'il faudra une machine plus puissante que si on travaille en H264 ou en ProRes 422.

C'est la contrepartie du truc (ça, et la qualité de l'intégration, selon les RAW compressés, selon les logiciels que l'on souhaite utiliser). D'un autre côté, c'est pas la mer à boire, et ça vaut carrément le coup.

 

Ok GRG tu confirmes des généralités avec lesquels tout le monde est d'accord...

On partait de Jean Claude : "... en RAW par contre : config amorphe => s'abtenir."

Or je partage l'avis Atobit, je ne comprend pas trop ce que cela vient faire ici on est en BRAW du compréssé justement, c'est l'originalité de la BM (ou d'autres outils maintenant).... je pensais en sollicitant Jean Claude à développer, qu'il avait des éléments concrets à apporter ( une expérience avec une BMPCC 4 ou 6K ?)

C'est cette config nécessaire qui intéresse les lecteurs de ce sujet, ici même.. pas des avis sur d'autres CODEC.

 

Alors, il me semble qu'une partie de la discussion sur la compression du BRAW a pour origine la phrase d'Atobit : "Le BRAW c’est du compressé, pas du plus ou moins".

Il me semble, hein. Et bon, après, c'est parti un peu dans toutes les directions (en passant par la couche alpha de la moitié des pixels qui sont juste de la lumière en plugin à arrondir en 16 bit float compressé dans le SDK de Premiere...).

Plus le RAW est compressé, plus il faut (à priori, avec le BRAW, comme on a plein de solides informations, je reste prudent) de ressources pour le dématricer en temps réel (mais il n'y a pas forcément une différence qui sera si notable que cela entre du 3:1 et du 8:1, ça peut très bien ne pas se remarquer, selon la puissance de traitement dont on dispose : je ne parle bien sûr pas de la qualité du résultat final, juste de la puissance de traitement). Cependant, lire de l'OpenEXR ou du DPX 16 bit, si on a les disques qui suivent, c'est moins de traitement à effectuer en temps réel (le RAW n'est pas compressé).

Tu es libre de penser qu'il y a une grande différence entre le REDCode, le ProRes RAW, le Cinema RAW Light et le BRAW. Dans les tests que j'ai mené pour le moment, si on colle de côté l'aspect intégration (prise en charge plus ou moins bonne, et dans plus ou moins de logiciels), ban, au niveau de l'espace occupé, à des ratios comparables, on est sur des résultats très très proches... Sur l'aspect "qualité", ça nécessite de mener quelques tests pour l'évaluer au mieux (autrement dit, ça ne saute pas aux yeux).

Concernant la config, si tu peux me définir ce qu'est une configuration puissante, on pourra probablement affiner...

Ce que je peux te dire, c'est qu'avec une RTX 2060 Super 8 Go, je suis bien au courant lorsque je traite du RedCode, du BRAW ou du CRL... Alors que bon, en 10 bit 422 XF-AVC 410 MBps, c'est relativement transparent.

C'est donc vraiment compliqué de répondre de façon tranchée (est-ce que tu veux une machine supra réactive, réactive, juste que ça se lise en 1/2 def, est-ce que tu vas monter dans Resolve - mieux optimisé pour ce genre de choses, ou dans Premiere, etc.).

Les tests de la société Puget propose aussi un élément de réponse : investir dans une RTX Titan n'est pas forcément une bonne idée (en tous cas, si tu utilises Premiere).

Tu peux aussi consulter le retour d'Atobit : BMPCC 4K : mon retour d'expérience après quelques mois d'utilisation | Tests | Le Repaire

"L’autre inconvénient, surtout si vous travaillez avec un ordinateur portable, c'est qu'avec le BRAW, il faut une bonne carte graphique pour une lecture fluide. Sur un portable sans GPU, même avec un CPU mobile a 4 cœurs de dernière génération (i7-8565U), ça saccade...beaucoup."

"Une petite note pour signaler que, même avec l'eGPU connecté sur le portable, et contrairement au fichier H264, la lecture des fichier BRAW avec Premiere Pro saccade."

On peut penser qu'avec le fameux (fumeux ?) semi-dématricage, tout est plus simple qu'ailleurs. Et se demander pourquoi Blackmagic RAW Speed Test existe, si c'est tellement "simple" (que tu peux télécharger, pour évaluer ta config, il est , je trouve, un peu optimiste, mais ça donne une idée).

On peut aussi se demander comment le BRAW va fonctionner avec les caméras des autres constructeurs (Eva1 et C300 Mk II par exemple). Il ne sera donc pas "semi-dématricé"...

Est-ce que quelqu'un peut assurer que la profondeur de codage reste la même selon le taux de compression employé ? Par exemple, le ProRes RAW, c'est 10 bit. Le ProRes RAW HQ, c'est 12 bit ( équivalent au 3:1). C'est d'ailleurs un peu la même chose en CRL.

Et au fait, c'est quoi le traitement en interne sur une BMPCC6K ? 16 bit, 14 bit, 12 bit ? Est-ce que le BRAW c'est 12 bit linéaire ? Si ce n'est pas le cas, comment ça se passe, exactement ?

On peut aussi se demander pourquoi la dynamique en ProRes 422 HQ est légèrement meilleure qu'en BRAW : Quite interestingly, using the ProRes HQ full sensor readout at Ultra HD, the dynamic range increases slightly from 11.8 stops to 11.9 stops at a signal to noise ratio of 2 (13 stops for SNR = 1).
Blackmagic Pocket Cinema Camera 6K Lab Test - Dynamic Range, Latitude, Rolling Shutter & More | cinema5D

C'est assez étrange, ça, hein. En attendant d'en savoir plus sur tous ces sujets, je vais me contenter de généralités.

 

Merci GRD de rappeler le retour d'Atobit que j'avais zapper...

Pour le reste ton questionnement me parait tomber à pique....l’expérience aide à avoir un bon raisonnement

Merci

 

Ben quoi ? C’est ma faute ?

Je peux très bien dire que j'ai profité des us et coutumes de la langue française : par "pas plus ou moins", j’entendais que le BRAW est compressé et non non-compressé.

A ma connaissance, on utilise l’expression "plus ou moins" pour exprimer une variation, comme la compris Jean-Claude, mais aussi pour exprimer une hésitation, un oui et non sans donner de détails, comme je l’ai compris.

 

....et d'ailleurs tu as surement plus ou moins raison ...

Bon mais cela m'a permis de relire ton excellent retour sur le sujet ..merci et que d'ailleurs GRD a rappelé en citant des extraits... donc merci j'avais du lire un peu vite à l’époque ..

 

Ce n'est pas une question de "faute", il m'a juste semblé qu'une partie (et une partie seulement) de, on dira, cette incompréhension, pouvait avoir cette origine (ce que j'ai d'ailleurs tenté de souligner dans un post précédent). Et je peux très bien (plus ou moins) me tromper. Il me semble que ce n'est pas bien important, et qu'on peut retourner au sujet de fond.

 

J’en suis à un point ou j’ai perdu le fils de la discussion. Serait-ce trop de demander ce qu’est le sujet de fond ?