Benjamin Profile picture
Apr 13, 2020 95 tweets 40 min read Read on X
Défi confinement #SMPTE, lire les quelques 300 documentations techniques et normes du cinéma.
Déjà, ce qu'on peut constater que les premières normes éditées & publiées démarrent en 1996: On commence par la télévision, puis on passe par le Cinéma (70mm, 35mm, 16mm, 8mm), un petit retour sur la télévision puis un gros retour Cinéma numérique. En tout plus de 600 documents.
Dans le monde, on a du 24 images/seconde (cinéma), du 25 (télévision), du 30 (télévision new-gen) et puis on a un à 29.97 bâtard pour la télévision US (NTSC). Pourquoi ? 30/1.001=29.97. Mais pourquoi faire un drop-frame ? Pour la rétrocompatibilité noir et blanc de la TV NTSC !
Dans la norme SMPTE-96M, on te donne un tableau récapitulatif d'un film au format cinéma vers un format télévision 16/9. ImageImage
Vous voyez dans les films, le petit passage bizarre au démarrage d'un film 35mm: Le début de la première bobine d'un film comporte des éléments informatifs et sont ultra-codifiés et normalisés à l'image près. Et pas le droit de déborder ! (SMPTE-55)
Le truc le plus pété du monde du cinéma 35mm : Pourquoi les bobines font 610 mètres ? C'est vrai, pourquoi le chiffre 610 et pas 600 ou 500 ? Bah, 610 mètres correspondent à 2000 ft (pieds). #ViveLeSystemeMetrique (SMPTE-192)
Il existe plusieurs formats de pellicule: 8mm, 16mm, 35mm, 65mm et 70mm. Et certains permettent même de stocker les formats plus petits dans d'autres formats plus grands. (SMPTE-184) Image
Je ne pouvais pas éviter la norme SMPTE-268 sur le format DPX, le format d'image Cinéma ! Niveau bit-depth, on peut monter jusqu'à 64 bits ! Et pour la cryptographie, la clef ne peut être que de 32 bits maximum et donc être faible pour certains algorithmes :-/ ImageImageImage
Les identifiants (UUID ou URN) commencent par 06.0E.2B.34 sont des identifiants SMPTE réservés. smpte-ra.org/class-1314-reg… (SMPTE-298) Image
Pour compléter à propos du début et fin de bobines 35mm, voici les détails des photogrammes (SMPTE-301) ImageImage
J'ai mis un peu de temps, mais voila: Enfin terminé la lecture de la norme du format télévision et cinéma MXF. 183 pages.
Attention, désolé par avance: je vais être un peu technique pendant les 3-4 prochains tweets. Image
Petit préambule: le format MXF est devenu la norme pour la diffusion en télévision et au cinéma et prochainement pour le stockage long-durée d'oeuvres cinématographiques (IMF). C'est donc un format important dans le milieu audiovisuel.
Le format MXF est comme un jeu de LEGO, ce sont des briques qu'on pose l'une après l'autre. Ces briques sont des KLV (Key-Length-Value): La première partie est une clef d'identification, puis la taille de la partie V et enfin, les données. 2/.. Image
Les clefs (16b) débutent toujours par "060e2b34". Les valeurs (les données) sont soient des données structurés (pour avoir des metadatas, soit le contenu brut). Par exemple, pour une image d'un film, le JPEG2000 (non chiffré) est directement placé dans la partie Value.
Chaque image d'un film est ensuite empilé par une succession de LEGO (KLV). Après lecture de ce pavé, j'ai pu écrire un parser MXF qui fonctionne à merveille ! (et qui me servira pour mes futurs travaux).
Fin des tweets techs, je ferai peut-être un papier-résumé pour + d'infos :) ImageImage
On continue le défi "lecture": Le chiffrement du SDI est basé sur de l'AES-128 pour le chiffrement flux, sa clef AES est chiffrée elle-même en RSA-2048 (RSA_oaep_mgf1p_sha1_2048 pour être précis). Et que la clef change périodiquement afin de sécuriser le flux vidéo. (SMPTE-427)
Et en lisant cette norme, on constate que le protocole d'échange SDI prévoit des évolutions (meilleure crypto par exemple) car quand on lit entre les lignes, on voit qu'ils ont réservés des paramètres et valeurs pour de futurs algorithmes cryptographiques.
A l'heure actuelle, j'en suis à 319 documentations lues sur les 503 que j'ai en ma possession. Et au fur-et-à-mesure du temps, les papiers sont plus volumineux que les premiers. J'espère ne pas saturer avant la fin tellement il y a beaucoup à lire. #SMPTE #challenge
Je ne fais pas de compte-rendu sur chacun des papiers lus car cela serait trop long et chiant pour tout le monde, je tweete que ce que je trouve important, étonnant ou pertinent pour moi et/ou les gens.
Pour ceux voulant calculer rapidement le nombre de couleurs au total par rapport rapport au bit-depth, je vous ai fait un petit résumé en image rapidos Image
Suite de la lecture SMPTE, j'avais fait une pause. Auparavant, j'avais lu une grande partie du SMPTE-429 qui porte sur le cinéma numérique: Pictures/Sound Track, MXF JPEG200 Track, TimedText Track (les sous-titres). La partie "Essence Encryption" m'a particulièrement intéressé
Pour le SMPTE-429-6 (Essence Encryption), la norme diffère de ce que j'ai constaté sur un MXF. Dans les tableaux, les données diffèrent: il manque les tailles entre chaque bloc de données (ou alors j'ai loupé une phrase dans ce pavé). Je reviendrai dessus plus en détail + tard.
Et là, j'attaque le SMPTE-429-7 sur les fameuses Composition Playlist (CPL), élément important de tout film cinéma numérique. C'est une version des normes de base n'évoquant pas encore les pistes auxiliaires (AuxData) permettant de jouer du Dolby Atmos ou du DBox (cinéma 4DX) Image
Si je devais retenir un truc: Chaque AssetType (Picture, Sound, Subtitle, Marker) est dépendant d'un autre (GenericAssetList), j'ai fait un petit résumé en image avec les valeurs et options. Le sous-type récupère tous les attributs de son parent (cf. Id, EditRate, ...) Image
Niveau "Marker", ce sont des marqueurs permettant d'identifier certains moments clefs du film (tableau 1) et tributaire du type du film (tableau 2).
Et le petit détail marrant: une bobine ne peut pas être de moins d'une seconde.
Fin du SMPTE 429-7 (CPL) ImageImage
J'ai oublié quelques éléments:
- Le hash est calculé en SHA1 + Base64
- La différence entre IntrinsicDuration et Duration: IntrinsicDuration est la durée totale de l'asset de la bobine, Duration est la portion qu'on souhaite utiliser en projection (en utilisant l'EntryPoint) Image
Je passe sur SMPTE 429-8 et 429-9 : PackagingList (PKL) & AssetMap des films numériques. Pas grand chose à dire, hormis que j'ai enfin trouvée le passage dans la norme qui dit qu'on peut avoir plusieurs PKL dans un DCP (non référencé dans la 429-8 bizarrement) Image
On passe la stéréoscopie avec le SMPTE-429-10.
Pas grand chose de neuf, hormis que le MainStereoscopicPicture est une instance PictureTrackFileAssetType (voir tweets précédents)
Et on commence toujours le film, la première frame dans le MXF, est l'image pour l'oeil gauche. Image
On passe au SMPTE-430-1: KDM (les messages contenant les clefs de déchiffrement des films cinémas). C'est seulement une base de normalisation. Les éléments à retenir sont principalement la structure du CipherValue contenant les métadonnées et les clefs pour le film (AES) ImageImage
Cette partie est chiffrée avec l'algorithme RSA-2048+OAEP, le tout englobée dans du base64. Chaque clef est identifiée par un type (MDIK, MDAK, ..) que vous retrouverez dans les CPL et les KDM (en 15 ans, jamais compris l'utilité, hormis identifier le type ... qu'on connait déjà) Image
Petite info pour labos cinéma sur l'Atmos: certains matériels Dolby ne supportent pas d'avoir un KDM sans clef de déchiffrement pour les pistes Atmos. Même si, chiffrer les pistes Atmos, est optionnel (cf. règles de Dolby). Seule solution: faire de l'Atmos chiffré quand même… Image
Ces parties deviennent + techniques. Dans les 1ères normes SMPTE, on parlait surtout de 16, 35 et 70mm et cela parle (quasi) à tout le monde. Mais avec les dernières normes, je pense que beaucoup vont décrocher car trop technique. N'oubliez pas de mute le thread si pas intéressé.
Quand le cinéma numérique faisait déjà du blockchain avant la hype de 2008. Dès le début du DCI (2006), les journaux d'activité en salle cinéma devaient être parfaitement certifiés: chaque évènement était loggué et avec un peu de crypto, authentifiait l'évènement et son précédent Image
La norme cinéma SMPTE-431-1 défini les bonnes performances cinématographiques en projection numérique (Luminance, Chrominance et Uniformité). Autant vous dire que pas mal d'exploitants ont du mal à respecter 😋 (sauf s'ils font leurs maintenances correctement avec un calibrateur) ImageImage
Suite du SMPTE: Je pensais que la "zone sécurisée" dans l'image (vidéo) était une technique qu'on s'échangeait entre techniciens de l'image, mais je m'aperçois qu'elle est défini dans le SMPTE-2046: Elle définit une zone où ne doit placer des informations essentielles
dans l'image et le rendu, cela afin d'éviter que - si la régie finale, les intermédiaires techniques ou l'écran du spectateur ne coupe l'image - l'essentiel de l'information de cette dernière reste compréhensible pour le spectateur. Image
Dans le SMPTE-2048-1 "Digital Cinematography Production Image Formats FS/709", on y retrouve pas mal d'information sur les systèmes colorimétriques, les FS-Log/Gamut et notamment les règles de conversions BT709 RGB vers XYZ Image
SMPTE-2065-1.2012: Academy Color Encoding Specification (ACES), le nouveau système de gestion des couleurs pour le cinéma qui va devenir la référence ultime entre le plateau, la postprod, la projection et la préservation. ImageImage
Résumé: Un espace colorimétrique RGB additif. Les primaires rouges/vertes/bleues entre les valeurs 0.0000 et 1.0000 (16bit), le Color Component est entre -65504.0 et +65504.0. Un workflow de conversion stable. Le ACES intègre tous les ColorSpaces habituels (RGB, DCIP3, REC2020) ImageImageImageImage
Une référence dans l'industrie avalisée par l'Academy of Motion Picture Arts and Sciences (~Oscars), l'industrie cinématographique, les constructeurs de caméra et workflow postprod, etc.
Quelques références pour en savoir plus:
- chrisbrejon.com/cg-cinematogra…
- premiumbeat.com/blog/what-is-a… ImageImage
J'ai oublié ce lien vers le site de l'Academy of Motion Pictures Arts and Sciences (AMPAS) sur la documentation ACES: oscars.org/science-techno…
SMPTE-2065-4.2013 est intéressant, c'est la description du format de fichier ACES Image Container. Il reprend les bases du format OpenEXR développé par Industrial Light & Magic (ILM) et complété par Disney, Sony Pictures, Pixar, DreamWorks, etc. et intègre ces ajouts spécifiques Image
Ce format de stockage des images sera utilisé pour la production cinématographique pour permettre de conserver sur toute la chaine de production la qualité de l'image et des metadatas associés.
D'un point de vue technique, chaque couleur est sur 16f bit (j'imaginais plus, en sachant que l'OpenEXR peut aller jusqu'à 32f). Qu'il y a une gestion stéréoscopique (étonnant, il considère que l'image primaire est celui de l'oeil droit :) et au niveau metadatas (..)
il y en a tellement, cela va des classiques données sur l'image du film mais aussi la position de la caméra dans espace tridimensionnel, sa direction visuel, etc. ainsi que des données de la caméra, de la lentille (même ses attributs), du focus, de l'exposition de l'image, etc..
Pour le coup, je n'ai pas encore vu passer ce format, au détriment du DPX, mais je me demande si cela ne va pas être son remplaçant pour les générations à venir dans le monde du cinéma et la postproduction (vu comment cela est défini, c'est envisageable)
Note: vu que j'ai regardé rapidement les titres des autres documentations et que je vais arriver au format IMF (format master pour l'audiovisuel/cinéma, utilisé par pas mal d'acteur déjà comme Netflix & Canal+), je vois déjà la logique du biniou: ACES File Container -> MXF -> IMF
Révélation: dans l'IMF, il y a le support du Karaoke ! Je tombe de haut 😆
Pour compléter: DCP peuvent avoir plusieurs PKL & plusieurs CPL: "AssetMap can contain mappings for more than one package - AM is used to locate the PKL(s) which detail the contents of available package(s). Assets are chosen from the PKL(s) and the selected assets are ingested." ImageImageImage
Suite des docs sur l'IMF, j'ai lu SMPTE 2067-20 à 2067-50 qui évoque les "applications" possibles, ex formats d'image acceptés dans l'IMF. Sans être étonnant, nous avons donc du JPEG2000 et MPEG4. Chaque "Application" IMF correspond à une utilisation: Télévision, Cinéma, Archives ImageImageImageImage
On y retrouve une des applications possibles de l'IMF nommée "Cinema Mezzanine" permettant d'avoir des images 16bits (DCP=12) allant jusqu'à 8K ! (son application/utilisation est pour de la préservation cinématographique par exemple). Et bien entendu, une version pour l'ACES 😃
Je me demandais s'il y avait une spécification "App" IMF avec des images non compressées. Effectivement, c'est l'App #1 - probablement défini dans les docs SMPTE ST-2067-1 à 19 [Core]: MXF avec du DPX non compressés. (ils me manquent certains SMPTE-2067 dans ma collection) ImageImageImage
Un bon résumé rapide des différentes "Apps" IMF suivant le type d'utilisation (Cinéma/TV). Je découvre aussi que l'App#4 a une "traduction" normée effectuée par la @cstis sous le nom de code CST-RT-021: cst.fr/recommandation… ImageImageImageImage
Les principaux et premiers "utilisateurs" de l'IMF sont Sony Pictures, Disney et Netflix. Mais maintenant, beaucoup plus, comme Fox, Apple, Amazon, etc. En France, j'ai ouïe-dire que Canal+ était un gros pousseur (et déjà utilisateur ?) du format IMF pour leurs contenus.
Concernant App#4/RT021:
- Images jusqu'à 8K
- JPEG2000 Lossless
- Colorspace XYZ
- Codage linéaire 16bits (unsigned)
- CPL simplifié
Petit détail que j'ai oublié, l'IMF App#4 Cinema Mezzanine utilise du JPEG2000 ISO/IEC 15444-1, donc JPEG Reversible Profile, donc Lossless aka "sans aucune perte d'informations dans l'image"
J'ai probablement oublié le groupe France Televisions (@matt_parmentier pourra confirmer ou infirmer)
La suite des docs SMPTE ! on passe au 2067-101 sur l'IMF et ses "Output Profile List" avec des petites options pour définir une sortie d'image provenant d'un film "IMFisé". On y retrouve le scale, crop, pixel-enc, etc.. avec des petites touches d'algorithmes ImageImageImageImage
La SMPTE 2080-3 donne les références d'un environnement de visualisation idéal pour l'evaluation des images HDTV. Il préconise d'attendre 10 min pour que l'oeil s'adapte correctement, ne pas dépasser certains angles et la distance idéal soit de 3 à 3.2 fois la hauteur de l'image. ImageImageImage
Et voici le workflow d'un contenu HDR / SDR. En gros [très gros], on fait des validations HDR et SDR du film, puis on fait un master HDR, on lui colle les métadatas HDR & SDR et en distribution, on lit le contenu HDR et on applique les metadatas correspondant à la sortie visuelle Image
On poursuit avec le SMPTE 2113 : "Colorimetry of P3 Color Spaces" - en gros, l'espace colorimétrique utilisée en projection cinéma. Il y a plusieurs "profiles" de P3 : P3D60, P3D65 et le fameux P3DCI (Digital Cinema). Chaque sont assez proches, leurs différences sont sur le blanc ImageImage
Dans le SMPTE EG-0432-1-2010 "Digital Source Processing - Color Processing D-Cinema", on y retrouve le workflow complet du labo postprod à la salle de projection Image
Les specs cinéma définissent que la puissance lumineuse doit être à 14 Foot Lamber (fL), soit 48.0 cd/m2 (à titre de comparaison, EclairColor est à 30 fL). La tolérance est en salle de vérification est de ±3.5 cd/m2 (± 1.00 fL), et en salle de projection ±10.2 cd/m2 (± 3.00 fL)
Un gros morceau, SMPTE définissant Dolby Atmos. A retenir: Actuellement, le DolbyA est soit du 48 kHz, soit du 96 kHz et en 24-bit. Que le support des frames sont 24, 25, 30, 48, 50, 60, 96, 100 et 120 images par second. Si vous voyez une séance Dolby Atmos autre, il y a un souci ImageImageImage
SMPTE Dolby Atmos: Le système de positionnement de chaque canal Dolby Atmos est défini avec des coordonnées Euclidiennes dans une plage de 0 à 1. Le son [0, 0, 0] est en avant de la salle, à gauche en bas. [1, 1, 1]: Arrière de la salle de projection, côté droit et en haut. ImageImage
SMPTE ARRIRAW Image File : Où comment-que-c-est-guaulé-dans-les-rushes-de-camera-ARRI. Les caméras ARRI sont plutôt réputées dans le milieu. ARRI a une véritable expertise dans le domaine du numérique et sont assez ouverts sur les fichiers que leurs caméras produisent. Image
J'ai été étonné de voir en préambule qu'on peut écrire des logiciels pour interpréter/analyser des rushes ARRI, mais que pour pouvoir en créer, il faut être membre du programme Partner ARRI. A priori, c'est pour éviter de pourrir le format avec des logiciels mal codés. Image
La structure d'un rush ARRI est assez simple: une série de fichier .ari contenant des données, dont les images. L'entête (header) est de 4096 bits fixe, après, ce sont les données récoltées par le capteur de la caméra (bayer toussa) ImageImage
Dans l'entête, des données pour chaque secteur, cela va des infos sur l'image, mais aussi colorimétrique, bcp de données caméra (allant du nom de la lentille jusqu'aux coordonnées GPS). J'en ai profité pour écrire un logiciel analysant les rushes ARRI (pas toute les metadatas) : Image
*qu'on puisse écrire (... à quand l'edit sur twitter...)
Pour compléter ce SMPTE: les données dans les en-têtes sont à positions fixes. La position des données image est variable, mais assez fréquemment, elles se trouvent soit à des offsets classiques (2048, 4096, 8192). J'en ai profité pour écrire un prog (proto) pour gérer les DPX : Image
Bon à savoir, quand on lit chaque composant RGB en 10-bits, on lit le rouge sur 10-bits, le vert sur 10-bits et le bleu sur 10-bit, puis on lit 2 bits pour le padding pour faire un joli 32-bits tout "rond" Image
Petit point sur mon défi SMPTE : Au début du confinement, je me suis lancé un défi: Lire toutes ces documentations sur le cinéma. Cela fait un peu près entre 8.000 et 10.000 pages de docs réparties sur plus de 500 papiers. Il me reste qu'une petite 20ène de docs!... Bientôt fini!
Je dois vous avouer que tout lire donne parfois des maux de têtes. L'impression de me faire injecter dans la tête des données en rafale.
SMPTE RDD-44-2017: La définition (rapide) de l'Apple ProRes. Format pas mal utilisé dans les laboratoires de postprod depuis 10-15 ans. Les seuls éléments que je retiens de ce SMPTE est le tableau de correspondance des différents débits, ... ImageImage
(..) la description rapide des macroblocks et des composants YCbCr (Y pour la luminance, Cb: bleu et Cr: rouge, le vert étant calculé), et que tous les blocs de macroblocks ne sont pas égaux, les derniers blocs sont plus petits, à cause de la subdivision imparfaite de l'image ImageImage
SMPTE RDD-47: IMF ISXD: Une extension pour le format IMF (futur format pour toute l'industrie cinéma/TV/préservation), pas vraiment compris à quoi cela servait... ni même si cela sera utilisé réellement... ImageImage
Les sous-titres DCP:
- Le DCP Interop a des sous-titres XML non-chiffrés
- Le DCP SMPTE apporte le support des sous-titres MXF-XML et la possibilité de les chiffrer mais ne l'impose pas
- Le DCP SMPTE 2.1B impose un chiffrement des sous-titres si autres pistes chiffrées Image
Passage au SMPTE RDD-52-2020: Le DCP Bv2.1, c'est la dernière spécification pour les films numériques cinéma, quelques évolutions (non-exhaustives): Les sous-titres ne doivent pas dépasser 256kB. L'ensemble des contenus pour les subs (XML, PNG, Font) ne doivent pas dépasser 115MB ImageImageImage
L'AnnotationText dans la CPL qui sera présenté aux différentes intervenants de la chaîne de distribution du film était avant optionnel (DCP SMPTE v1), maintenant il est devenu obligatoire et en plus il doit être égal au ContentTitleText. On se demande alors pourquoi ce doublon Image
J'ai bien une idée: peut-être que le ContentTitle va devenir (v3?) plus structuré et non plus un texte lambda essayant de respecter une convention pas vraiment normalisée à la base (Digital Cinema Naming Convention). Ainsi, on se fera plus chier à l'analyser pour la postprod
Autre nouveauté, le Hash de chaque élément du film (Picture, Sound, ...) devient maintenant obligatoire ! Et si une piste est chiffrée (encrypted), toutes les autres pistes (peu importe le type: Picture, Audio, Subtitle, AuxData) doivent être aussi chiffrées ! Image
Dans les autres nouveautés, une piste pour le langage des signes. Les films pourront intégrer une piste spécifique. Il sera au format WebM VP9, d'une résolution de 480x640... ImageImage
Complément ce SMPTE DCP 2.1B avec la taille des frames selon que ce soit du 2K ou du 4K. Image
Suite avec SMPTE RP-428-4:2010 sur le D-Cinema Distribution Master - Audio File Format and Delivery Constraints, aka DCDM Audio (pour les connaisseurs). On voit que les pistes audio sont extrêmement normalisées pour leur version master que ce soit au niveau contenu comme nommage. ImageImageImage
SMPTE.RP.0428-6-2009 - DCDM - Digital Leader : Sous ce nom barbare se cache simplement le début et fin d'un film pour la partie numérique (déjà vu dans ce thread pour la partie 35mm). Cette norme détaille chaque frame de début et de fin. ImageImage
Le début doit être de 8 secondes, soit 192 frames en 24 img/s, le compteur doit commencer à partir de 8 et la petite aiguille doit faire 15° par image pour faire un beau 360°. Le background n'est pas figé, on peut faire un peu ce qu'on veut il faut juste respecter certaines infos ImageImageImage
Au niveau des bandes de couleurs ou de gris qu'on voit dans la charte, ce ne sont pas des couleurs/gris aléatoires, elles sont codifiées pour permettre d'identifier un problème colorimétrique à l'oeil ou via des capteurs spécifiques (avec un spectro, c'est mieux ;) ImageImageImageImage
Et enfin, la fin respecte aussi une certaine codification, elle doit durer 4 secondes (soit 96 frames pour du 24 img/s). J'ai passé vite car il y a aussi les "sync pop", le fameux bip (1000 Hz) Image
SMPTE 430 : Les certificats numériques utilisés par les lecteurs films numériques (DCP). Ces certs servent à authentifier le matériel & chiffrer les clefs pour les KDMs. Vous avez deux clefs: une publique (donné au laboratoire) et une privée, qui ne sort jamais (normalement ;) ImageImage
Sans grande originalité: c'est du x509v3, avec une structure certs : la racine (géré par le constructeur, exemple Dolby / Doremi), l'intermédiaire (idem) et la "leaf": le certificat du player en salle cinéma. Certains champs sont obligatoires et doivent respecter une nomenclature ImageImageImageImage
SMPTE-2073: Je découvre le format VC5, qui est le nom de code pour le CineForm, qui est un format pour la post-production de film. Selon la page Wikipedia, ce format a été utilisé sur des films comme Slumdog Millionaire & Need For Speed. ImageImage
Il se base sur un format d'image wavelet non-destructeur - comme le JPEG2000 utilisé dans le DCP (film numérique) et IMF (~format d'archivage et d'échange de film) - et le format a été placé en opensource par GoPro (détenteur du codec après un rachat).
Voila, c'est la fin des lectures des docs SMPTE. Entre 7000-9000 pages, parfois assez obscures, intéressantes (presque ;). Vous pouvez lire le thread pour avoir un résumé rapide des différentes docs. Je n'ai pas écrit sur certaines car pas forcément intéressantes pour le "public"

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Benjamin

Benjamin Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @_prae_

Apr 4, 2021
En passant à Kyoto, je suis tombé dans une boutiques de livres d'occaz, j'ai trouvé un magazine que je connaissais pas: CGWorld. Un magazine sur la production d'images de synthèse dans le cinéma et aussi dans le monde des jeux-vidéo. Et là, je tombe sur du making-of ! Thread ⬇️
Le magazine édité en 2004, on y découvre du ResidentEvil, du VirtualFighter, RidgeRacer, Shenmue, Metal Gear Solid, du Tekken, SilentHill, et plusieurs autres gros titres, 200 pages d'infos de productions de ces titres cultes. Ici du GrandTurismo3, Silpheed et Zone Of The Enders
Ici, on y voit la production de Virtual Fighter 4 et de Shenmue 2, avec des modèles filaires de certains protagonistes et de scènes
Read 8 tweets
Apr 16, 2019
Guillaume Lemans (scénariste "Dans la brume"): "Mes traitements font entre 30 et 40 pages, sans dialogues mais quasiment séquencés. Avec les 3 actes, il y a tout. Chaque ligne est une séquence."
G. Lemans: "Dans La Brume a été pensé pour une diffusion TF1 un dimanche soir en prime time. (...)". "La brume a été utilisée comme technique pour permettre de cacher beaucoup de choses et faire de croire à des choses disproportionnées."
G. Lemans: "Il y a 120-140 comédies produits par an et une grande partie sont des films pourris. C'est plus facile aujourd'hui de financer une mauvaise comédie qu'un bon film de genre. "
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(