On ne devient pas riche avec WordPress : 30% ont une rémunération brute annuelle de moins de 21000€ par an, 43% entre 21000€ et 35000€ et 25% au délà de 36000€.
Pour un studio d'animation ou d'effets spéciaux le coût des licences est un véritable problème qui amène à choisir du libre, mais il y a d'excellentes raisons pour choisir du propriétaire acheté ou développé en interne.
Tous les gros studios (ILM, MPC, Mikros je crois, The Mill où j'ai bossé, BUF) tournent sous Linux, stations de travail et fermes de rendu, pour au moins trois raisons:
- pas de licence à payer pour les OS (et il y a facilement des centaines de racks sur les renderfarms)
- la pile réseau a toujours bien marché pour cet usage, pourquoi changer ?
- l'héritage et les habitudes des stations Unix / Irix des pionniers des années 90
Seule exception: les artistes pour les textures ont souvent un Mac avec Photoshop pas loin et les quelques monteurs aussi.
En revanche les applications sont presque exclusivement propriétaires. Et d'ailleurs, ce n'est pas 3 ou 4 softs comme dit l'un des commentaires, mais une myriade d'outils qui sont utilisés pour des raisons différentes. Pour une production un peu complexe, il y aura facilement:
- Shotgun pour la gestion de projet (mais il y a aussi FTrack)
- RV pour visualiser les rendus (il y en a d'autres)
- Maya pour le modelling, texturing et animation des personnages (mais suivant les régions du monde et l'industrie, il y a aussi 3DSMax ou Cinema4D)
- Realflow pour l'animation des fluides (mais aussi Houdini)
- Massive pour la simulation des foules
- Nuke pour le compositing
- des logiciels dont les noms m'échappent pour l'étalonnage
- Houdini pour plein de trucs plus spécialisés (particules, fumées, mais c'est très réducteur)
- Arnold pour le rendu (mais aussi PRMan, VRay et une quantité d'autres)
- Mari pour le texturing 3D
- Katana pour la gestion procédurale d'énormes scènes
- des softs de reconstructions 3D pour les LiDar, la photogrammétrie
- des logiciels pour le Motion Capture
- d'autres dont je n'ai même pas idée parce qu'ils internes à des studios
La multitude de logiciels utilisés force les studios à avoir des équipes entières pour automatiser le flux de production au maximum: c'est le fameux "pipeline", aux contours aussi obscures que le nom est générique. Ce pipeline est composé de plein de bouts de code plus ou moins liés aux logiciels: ca va du script pour forcer des conventions de nommage de fichiers (rigolez pas, quand il y a 1000 artistes dans des studios autour du monde, c'est un problème crucial) à des formats de données très spécifiques pour pouvoir réutiliser le résultat d'un logiciel dans un autre (et qui donc force à développer des plugins pour chaque hôte ciblée) à des logiciels entiers parce qu'on ne les trouve pas le commerce.
Du coup quand on remplace un soft par un autre, ce n'est pas juste un exécutable différent à lancer en début de journée: il faut prendre en compte toute son intégration dans une chaine de production, avec tout ce que ca implique pour le pipeline d'une part, mais aussi pour trouver des artistes qui puissent l'utiliser d'autre part. Si c'est déjà compliqué de trouver de bons utilisateurs de Maya avec de l'expérience qui ne pensent plus à leur outil mais au boulot à faire, alors trouver un équivalent pour Blender c'est presque mission impossible. Et pourtant Blender a bien plus d'utilisateurs que Maya: Maya a cependant énormément plus d'utilisateurs professionnels que l'on peut embaucher sur portfolio et réputation. Je le regrette, mais c'est un fait qui compte beaucoup dans l'inertie à évoluer sur d'autres logiciels, sans même avoir commencé à parler de la qualité des alternatives.
C'est d'ailleurs ces deux facteurs (pipelines et disponibilité des artistes) qui a poussé deux points importants de l'industrie: l'abandon et la revente progressifs des logiciels internes et l'ouverture des sources de plein de briques de base.
Des logiciels comme Nuke, Arnold ou Massive (ou… Blender, mais l'ouverture s'est faite dans un tout autre contexte) étaient d'abord des logiciels développés aux seins de studios pour leur propre usage. Ils ont été revendus à des éditeurs ou sont devenus des boites à parts entières parce que d'une part payer des licences revient moins cher que de payer des développeurs dans certains cas, mais surtout cela rend le recrutement moins cher vu que les artistes sont déjà formés et expérimentés en arrivant dans le studio. L'éditeur a tout intérêt à mettre le paquet sur la formation et la qualité de ses softs s'il veut vendre des licences: c'est autant d'argent qui est économisé par les studios.
En somme, un artiste formé à l'outil est un artiste plus facile à intégrer dans le "pipeline humain": c'est toujours plus marrant de discuter des effets à produire plutôt que des boutons à cliquer.
Les départements R&D ouvrent de plus en plus des bibliothèques de code ou contribuent à des projets libres pour suivre la même logique d'intégration dans le pipeline. Par exemple le format d'image OpenEXR était utilisé en interne chez Industrial Light & Magic avant d'être libéré sous BSD-3. L'intérêt était moins de recevoir des patches que de laisser aux éditeurs la tâche d'intégrer EXR à leurs softs. Ca a été un succès, et c'est loin d'être le seul: les technos libérées par Mikros, Disney, ILM ou Pixar valent le coup d'oeil. Il y a un blog qui parle de l'open source (c'est très clairement la philosophie Open Source plutôt que Free Software qui domine cette industrie), mais il ne semble plus très actif: http://opensourcevfx.org/
À titre personnel je rêve de voir les studios tourner le dos aux grands éditeurs de logiciels et de dépenser les montagnes de fric de leurs budgets licences pour mutualiser leurs efforts dans Blender, Gimp, Krita, Cycle, DjvView et les autres. Mais on y viendra. La gronde contre les éditeurs monopolistiques monte et les alternatives sont de plus en plus abouties: Eevee, le nouveau moteur temps réel de Blender commence à faire saliver pas mal de monde et ouvre de belles portes.
Est-ce que tu aurais des exemples d'installations artistiques montées avec Faust ? Je suis curieux des raisons qui pousseraient à utiliser Faust plutôt qu'un environnement de plus haut niveau comme Pure Data. Merci !
Ce problème s'appèle bien du tearing. Il est en général plus souvent vu sur des jeux videos (rendu 3d en OpenGL) où le rafraîchissement de l'image n'est pas synchronisée avec celui de l'écran.
Je n'ai pas de VLC sous la main, donc je ne peux pas pointer vers une option en particulier, mais tu peux chercher de deux côtés:
- changer le driver de sortie pour Xv ou OpenGL (il se peut que tu sois en X11, qui est plus lent)
- cocher une option qui s'appèlerait un truc du genre "Vertical synchronisation"
Ca vaut aussi le coup de tester avec un autre player, comme mplayer en ligne de commande : avec l'option -vo, tu peux facilement changer le driver de sortie de mplayer et ainsi en tester plusieurs rapidement.
Ça vous fait 70km par jour, 6 jours par semaine. En tant que tel, c'est déjà sport… Les 70km / jour, c'est largement faisable, mais un seul jour de repos par semaine, c'est très contraignant. Si vous passez 4 jours dans un endroit cool, ça veut dire que vous pédalez tout le reste du mois sans repos. Galère…
Si en plus vous comptez vous arrêter un peu après deux semaines et prendre 125 photos / jour, vous êtes parti pour pédaler comme des dingues, être toujours en retard sur votre planning, sacrifier d'autres parties importantes du projet comme les photos, vous fatiguer, vous engueuler tous les deux et risquer une grosse tendinite (ou pire) qui vous scotchera à un endroit (qui sera nécessairement tout pourri au milieu de nulle part) pour des jours.
Comptez 1500km / mois. Pas plus. Si vous êtes plus rapide, cool, ça vous fait plus de temps pour faire et trier les photos ou rester vous reposer quelque part.
Et ce n'est pas la peine de prévoir un itinéraire précis au sentier près dès maintenant. Vous ne le respecterez pas de toutes façons, pour plein de raisons : parfois vous allez manquer de temps et prendrez des voies rapides, d'autres fois vous allez pédaler avec d'autres cyclistes, encore après vous fairez un détour. Soyez au courant des pays à traverser et des postes frontières à passer, soyez flexibles et prévoyez votre itinéraire de semaines en semaines. Pas plus, ça ne sert à rien si vous n'êtes pas très contraints par le temps.
Et si vous êtes contraints par le temps, et bien prenez des trains ou balancez les vélos à l'arrière d'un camion pour quelques centaines de kilomètres.
Vous avez déjà réglé les problèmes les plus importants :
- le vélo (vous avez fait un bon choix, vous ne regretterez pas le Rolhoff)
- le matos informatique / photo pour le projet (vous vous y connaissez assez pour faire un choix qui conviendra de toutes façons, quel qu'il soit)
- les frontières (soyez blindés sur les VISAs et les procédures, c'est de loin la partie la plus chiante du voyage)
Donc c'est bon, vous savez déjà que tout va très bien se passer.
L'itinéraire précis est très, très secondaire et facilement improvisable.
32 bits la clé, pas 64 : il faut qu'elle puisse passer partout. J'avais quelques ISOs sur un disque externe pour refaire des clés en cas de besoin (Ubuntu 32bits pour le netbook, Ubuntu 64bits pour le gros laptop, Backtrack pour cracker les réseaux WIFI WEP).
Les sacoches Carradice ont l'air solides, mais sont bien plus chères que les Ortlieb Backroller et semblent nécessiter un entretien plus important (cire spéciale). Si votre projet s'inscrit dans une démarche écologique / équitable / privilégier les petites boites, les Carradice ont du sens. Sinon vous n'aurez aucune surprise avec les Ortlieb.
Les Ortlieb ne sont pas parfaites non plus ni indestructibles, loin s'en faut :
- pensez à resserer les vis des crochets sur les sacoches tous les 500 / 1000 km. J'ai perdu un crochet comme ça…
- il me semble que j'avais cassé un fermoir, pas celui qui ferme la sacoche mais celui qui se rabat sur l'avant. Ce n'était même pas le fermoir lui même mais le tissu sur lequel il était attaché qui était arraché. Ça s'achète et se change facilement, mais ça vaut le coup d'en avoir un de rechange
- après avoir mal évalué la hauteur d'une bordure le dessous d'une sacoche avant a frotté et a été endommagé. Il y a un kit Ortlieb pour réparer ce genre de dégat (genre patch + colle pour réparer les voiles de bateaux il me semble).
- le plus gros problème c'est les adaptateurs placés dans les crochés de fixation pour en diminuer le diamère et s'adapter au racks fins. Ces adaptateurs se cassent et se perdent très facilement. Soit vous prenez un bon paquet de rechange, soit vous achetez des racks avec des tubes adaptés de gros diamètre (probablement la meilleure solution), soit vous modifiez les racks. Il y a quelque part sur un blog le bricolage d'un gars qui a utilisé deux couches de gaine électrique souple fendue pour augmenter le diamètre des tubes de son rack. Intelligent…
Point de vue hardware j'en suis plutôt content : bonne autonomie (plusieurs jours si on prend des points toutes les deux ou trois minutes), bonne précision, solide. Si balancé dans le sac sans faire attention il a tendance à s'éteindre facilement si quelque chose appuie trop longtemps sur son très gros bouton.
Point de vue software sous Linux c'est un peu moins cool. Il existe un projet de driver i-gotu basé sur la libusb et Qt : https://code.launchpad.net/~charlesf/igotu2gpx/gt600
Ça se présente sous la forme d'une commande (igotu2gpx) pour exporter les points du GT-600 en .gpx ou .kml. Je me servais ensuite des traces dans qlandkartegt et josm. Par contre il faut compiler et je n'ai jamais réussi à faire tourner igotu2gpx que sous root.
Le pach n'est pas intégré dans la branche principale pour une raison que j'ignore, mais appliqué sur la branche principale ça fonctionne.
Worst case scenario, les drivers fonctionnent très bien dans une machine virtuelle Windows.
Ça fait très longtemps que je dis que ça serait un excellent projet pour moi apprendre la programmation de drivers sous Linux, mais je ne m'y suis jamais mis. Si jamais vous utilisiez ce petit logger sous Linux, ça serait une bonne motivation pour me mettre au boulot. Vous partez quand ?
TL;DR : achetez du matériel informatique standard, de très bonnes sacoches de vélo imperméables et soyez sans pitié en triant vos photos tous les jours.
En 2011 / 2012 ma partenaire et moi avons pédalé de Cambrai, France à Cambrai, Australie. On a beaucoup écrit sur notre blog http://cambrai-cambrai.net et pris pas mal de photos. Ubuntu a été notre unique système d'exploitation pendant ces 18 mois autour du monde.
J'avais un petit netbook Acer Aspire One d'une lenteur incroyable (Compact Flash super lente en guise de DD interne…). Il me servait à écrire les textes de notre site et à coder les scripts de mise à jour du site (les connexions étaient souvent tellement pourries que passer par l'interface web de Wordpress était très pénible, alors qu'avec un petit script python attaquant l'API wordpress ça passait mieux).
L'autre PC était un Acer Aspire Timeline X. Je n'ai plus bien les specs en mémoire mais c'était du genre 4GO RAM / 768GO DD (aucune idée du processeur). Il suffisait largement à faire du traitement RAW basique, trier les photos, Skype et emails.
On se faisait aussi tout un monde de la survie des laptops en pédalant (d'où l'achat du netbook sans pièce mobile outre le ventilateur), mais en fait ça c'est très bien passé. Et tous les cyclistes qu'on a croisé sur le chemin avait des laptops standards et quasiment aucun n'ont eu de soucis. C'est vrai que les disques peuvent mourir (on a bousillé un DD externe en route), mais pas plus que dans "la vie de tous les jours".
Donc plutôt que de prendre un ToughtBook lourd et peu performant, achetez deux laptops standards. Ayez chacun votre PC ou vous allez vous taper dessus les jours de repos pour savoir qui peut aller checker ses emails.
Tous les documents importants (photos, cartes, scan des passeports et VISA…) étaient sur le gros laptop et chacun de nous avait un disque-dur de backup. On aurait sans doute pu faire avec un unique disque de backup sur le vélo qui ne portait pas le laptop, mais j'avoue une vraie paranoïa quand aux sauvegardes… Mea culpa… Un script rsync lancé manuellement dès qu'on pouvait faisait une simple réplication sur les disques de backup.
Pour le transport, les laptops était simplement dans leur housse standard dans nos sacoches étanches. Ne pas avoir de sacoches dédiées aux laptops nous a permis de tenter pas mal de configurations de rangement différentes au gré des saisons et de nos expérimentations. Bref, investissez dans de très bonnes sacoches de vélo étanches (on avait des Ortlieb) qui vous serviront pour tout le matos et pas juste pour le PC.
Les disques durs externes de backups étaient toujours dans les sacoches de guidon pour deux raisons :
1. on gardait toujours les trucs importants à porté de main, facilement détachables du vélo (passeport, argent, cartes, contacts, appareils photos, petits outils…)
2. la conception de la fixation de la sacoche de guidon apporte un peu de souplesse à l'ensemble, amortissant un peu les chocs : ça me rassurait sur la durée de vie des disques durs.
On a longtemps utilisé Shotwell pour gérer les photos, mais il nous a saoûlé par ses plantages et bugs (des photos dégageaient de la bibliothèque sans raison). Bref, on est passé à Digikam qui est beaucoup plus stable, et même si l'interface d'édition des photos n'est pas terrible, pour le tri et le classement il est très bien. Cela dit si c'était à refaire je tenterai volontier Darktable, il n'a pas l'air mal du tout.
Mais je vous en conjure : triez vos photos quotidiennement et soyez sans pitié. Vos disques-dur s'en porteront mieux, vos sauvegardes se feront plus rapidement et vous ne serez pas découragés en rentrant quand il faudra s'attaquer à 600GO de photos.
On s'était donné des règles :
1. on faisait d'abord une première passe directement sur les appareils photos pour virer les clichés flous / mal exposés / peu intéressants / franchement moches.
2. on importait les photos dans Shotwell / Digikam et on formatait immédiatement la carte mémoire. C'est pratique parceque comme ça on savait qu'une photo était soit sur disque, soit sur carte, mais jamais à deux endroits en même temps. Pas d'hésitation, si la photo est sur carte, c'est qu'elle n'est pas sur disque, donc pas backupée sur les disques externes, donc à importer au plus vite.
3. on faisait une second passe sur PC pour dégager les photos floues / mal cadrées / râtées techniquement parlant. On ne s'intéressait pas à la qualité artistique de la photo à cette étape, mais juste de la technique. On avait pas de temps à perdre sur des retouches poussées, donc soit la photo est bonne techniquement, soit elle dégage.
4. la dernière passe est pour les garder les vraies bonnes photos.
Objectif : 12 photos grand maximum par jour. Ce n'est pas facile, mais on ne s'est pas encombré avec des clichés qu'on estimait sans intérêt.
Embarquez une clé bootable (genre Live USB Ubuntu ou quelque chose du genre) qui vous servira si vous devez emprunter / racheter / réparer / installer un ordinateur en cours de route.
Un dernièr point : si vous n'avez pas le temps de vous mettre à Linux quelques mois avant de partir en voyage pour vous faire au système, restez sur Windows et Mac. Geeker un Linux et écumer les forums de barbus est la dernière chose que vous allez vouloir faire sur la route.
TPB est bloqué où j'habite. On peut passer par un proxy bien entendu, mais ça serait bien mieux si tu pouvais mettre un magnet dans l'article lui-même. Peut-être dans les liens ?
Merci pour tout !
L'article date de 2005. A l'époque il ne devait pas y avoir beaucoup de capteurs de plus de 3 mdp. Je ne pense pas qu'il y ait confusion entre définition et résolution ici.
Un Raw n'est pas une image : c'est juste des données brutes de capteur. Une image d'appareils photos, c'est une suite de triplets de valeurs (Rouge Vert Bleu) pour chaque pixel. Les données issues du capteur sont différentes d'un fabricant à l'autre, mais typiquement pour chaque pixel de l'image final on échantillonne sur 4 photosites agencés en carré deux valeurs de vert, une de rouge et une bleu (deux de vert parceque c'est à cette couleur que nous sommes le plus sensible). Il faut noter l'aspect "adjacent" : dans une image les trois valeurs RGB sont spacialement au même endroit. Construire des pixels à partir de données RAW en tenant compte du décalage spatial et l'échantillon de vert supplémentaire s'appèle "le dématriçage". C'est une opération que les ordinateurs font mieux que les appareils photo. Je ne retrouve plus l'article qui montre que les résultats obtenus par dcraw sont supérieurs à ceux obtenus par les algos internes des appareils photos…
Dans un appareil photo numérique, avant d'arriver à une image il y a trois étapes :
1. Récupération des données du capteur
2. Traitements d'image
3. Encodage en Jpeg
Un fichier RAW, c'est juste les données du capteur. En RAW ont récupère les données juste après l'étape 1. Ça permet trois choses principalement :
- traiter une image sur un ordinateur beaucoup plus puissant que les circuits internes d'un appareil photo. On peut accéder à des algos beaucoup plus puissant
- retravailler après prise de vue une image sans avoir déjà des traitements déjà appliqués
- ne pas avoir d'artefacts de compression inhérent au jpeg
Liseuse, pas tablette. L'autonomie de plusieurs jours est décisive dans mon cas.
Effectivement, un dictionnaire serait une très bonne chose. D'autres propositions ?
Excusez ma naïveté, mais comment peut-on introduire une porte dérobée dans un logiciel à source ouverte ? Si c'était dans un coin obscur du code, je veux bien, mais j'imagine que pour OpenBSD tout ce qui touche à la crytographie doit être étroitement surveillé, non ?
[^] # Re: Salaires ?
Posté par Charles Flèche (site web personnel) . En réponse au journal Wordpress en France : enquête 2019 sur l’emploi et les salaires. Évalué à 2.
Dans l'article:
# Gratuit et coopération
Posté par Charles Flèche (site web personnel) . En réponse au journal Le libre intéresse un studio d'animation français. Évalué à 10.
Pour un studio d'animation ou d'effets spéciaux le coût des licences est un véritable problème qui amène à choisir du libre, mais il y a d'excellentes raisons pour choisir du propriétaire acheté ou développé en interne.
Tous les gros studios (ILM, MPC, Mikros je crois, The Mill où j'ai bossé, BUF) tournent sous Linux, stations de travail et fermes de rendu, pour au moins trois raisons:
- pas de licence à payer pour les OS (et il y a facilement des centaines de racks sur les renderfarms)
- la pile réseau a toujours bien marché pour cet usage, pourquoi changer ?
- l'héritage et les habitudes des stations Unix / Irix des pionniers des années 90
Seule exception: les artistes pour les textures ont souvent un Mac avec Photoshop pas loin et les quelques monteurs aussi.
En revanche les applications sont presque exclusivement propriétaires. Et d'ailleurs, ce n'est pas 3 ou 4 softs comme dit l'un des commentaires, mais une myriade d'outils qui sont utilisés pour des raisons différentes. Pour une production un peu complexe, il y aura facilement:
- Shotgun pour la gestion de projet (mais il y a aussi FTrack)
- RV pour visualiser les rendus (il y en a d'autres)
- Maya pour le modelling, texturing et animation des personnages (mais suivant les régions du monde et l'industrie, il y a aussi 3DSMax ou Cinema4D)
- Realflow pour l'animation des fluides (mais aussi Houdini)
- Massive pour la simulation des foules
- Nuke pour le compositing
- des logiciels dont les noms m'échappent pour l'étalonnage
- Houdini pour plein de trucs plus spécialisés (particules, fumées, mais c'est très réducteur)
- Arnold pour le rendu (mais aussi PRMan, VRay et une quantité d'autres)
- Mari pour le texturing 3D
- Katana pour la gestion procédurale d'énormes scènes
- des softs de reconstructions 3D pour les LiDar, la photogrammétrie
- des logiciels pour le Motion Capture
- d'autres dont je n'ai même pas idée parce qu'ils internes à des studios
La multitude de logiciels utilisés force les studios à avoir des équipes entières pour automatiser le flux de production au maximum: c'est le fameux "pipeline", aux contours aussi obscures que le nom est générique. Ce pipeline est composé de plein de bouts de code plus ou moins liés aux logiciels: ca va du script pour forcer des conventions de nommage de fichiers (rigolez pas, quand il y a 1000 artistes dans des studios autour du monde, c'est un problème crucial) à des formats de données très spécifiques pour pouvoir réutiliser le résultat d'un logiciel dans un autre (et qui donc force à développer des plugins pour chaque hôte ciblée) à des logiciels entiers parce qu'on ne les trouve pas le commerce.
Du coup quand on remplace un soft par un autre, ce n'est pas juste un exécutable différent à lancer en début de journée: il faut prendre en compte toute son intégration dans une chaine de production, avec tout ce que ca implique pour le pipeline d'une part, mais aussi pour trouver des artistes qui puissent l'utiliser d'autre part. Si c'est déjà compliqué de trouver de bons utilisateurs de Maya avec de l'expérience qui ne pensent plus à leur outil mais au boulot à faire, alors trouver un équivalent pour Blender c'est presque mission impossible. Et pourtant Blender a bien plus d'utilisateurs que Maya: Maya a cependant énormément plus d'utilisateurs professionnels que l'on peut embaucher sur portfolio et réputation. Je le regrette, mais c'est un fait qui compte beaucoup dans l'inertie à évoluer sur d'autres logiciels, sans même avoir commencé à parler de la qualité des alternatives.
C'est d'ailleurs ces deux facteurs (pipelines et disponibilité des artistes) qui a poussé deux points importants de l'industrie: l'abandon et la revente progressifs des logiciels internes et l'ouverture des sources de plein de briques de base.
Des logiciels comme Nuke, Arnold ou Massive (ou… Blender, mais l'ouverture s'est faite dans un tout autre contexte) étaient d'abord des logiciels développés aux seins de studios pour leur propre usage. Ils ont été revendus à des éditeurs ou sont devenus des boites à parts entières parce que d'une part payer des licences revient moins cher que de payer des développeurs dans certains cas, mais surtout cela rend le recrutement moins cher vu que les artistes sont déjà formés et expérimentés en arrivant dans le studio. L'éditeur a tout intérêt à mettre le paquet sur la formation et la qualité de ses softs s'il veut vendre des licences: c'est autant d'argent qui est économisé par les studios.
En somme, un artiste formé à l'outil est un artiste plus facile à intégrer dans le "pipeline humain": c'est toujours plus marrant de discuter des effets à produire plutôt que des boutons à cliquer.
Les départements R&D ouvrent de plus en plus des bibliothèques de code ou contribuent à des projets libres pour suivre la même logique d'intégration dans le pipeline. Par exemple le format d'image OpenEXR était utilisé en interne chez Industrial Light & Magic avant d'être libéré sous BSD-3. L'intérêt était moins de recevoir des patches que de laisser aux éditeurs la tâche d'intégrer EXR à leurs softs. Ca a été un succès, et c'est loin d'être le seul: les technos libérées par Mikros, Disney, ILM ou Pixar valent le coup d'oeil. Il y a un blog qui parle de l'open source (c'est très clairement la philosophie Open Source plutôt que Free Software qui domine cette industrie), mais il ne semble plus très actif: http://opensourcevfx.org/
À titre personnel je rêve de voir les studios tourner le dos aux grands éditeurs de logiciels et de dépenser les montagnes de fric de leurs budgets licences pour mutualiser leurs efforts dans Blender, Gimp, Krita, Cycle, DjvView et les autres. Mais on y viendra. La gronde contre les éditeurs monopolistiques monte et les alternatives sont de plus en plus abouties: Eevee, le nouveau moteur temps réel de Blender commence à faire saliver pas mal de monde et ouvre de belles portes.
# Stream vidéo en direct
Posté par Charles Flèche (site web personnel) . En réponse à la dépêche Linux Audio Conference 2018 à Berlin. Évalué à 3.
La conférence sera diffusée en direct par le service video du Chaos Computer Club.
[^] # Re: Gold guns girls
Posté par Charles Flèche (site web personnel) . En réponse au message VPN: interpréter la sortie de `route -n`. Évalué à 3.
Merci, c'est très clair !
[^] # Re: Axoloti quelqu'un connaît ?
Posté par Charles Flèche (site web personnel) . En réponse à la dépêche LinuxMAO — Éditorial de décembre 2017. Évalué à 3.
Page officielle: http://www.axoloti.com
Code repo: https://github.com/axoloti/axoloti/
[^] # Re: La documentation automatique
Posté par Charles Flèche (site web personnel) . En réponse à la dépêche [Faust] Coder de l’audio en sifflotant. Évalué à 6.
Est-ce que tu aurais des exemples d'installations artistiques montées avec Faust ? Je suis curieux des raisons qui pousseraient à utiliser Faust plutôt qu'un environnement de plus haut niveau comme Pure Data. Merci !
[^] # Re: C'est le fonctionnement d'IPv6
Posté par Charles Flèche (site web personnel) . En réponse au message 2 adresses IPv6 free.fr ?. Évalué à 2.
Merci de la réponse, et je n'ai aucune inquiétude. Je me demandais juste pourquoi j'avais 2 IPv6 attribuées.
# Driver de sortie
Posté par Charles Flèche (site web personnel) . En réponse au message Problème Graphique. Évalué à 2.
Ce problème s'appèle bien du tearing. Il est en général plus souvent vu sur des jeux videos (rendu 3d en OpenGL) où le rafraîchissement de l'image n'est pas synchronisée avec celui de l'écran.
Je n'ai pas de VLC sous la main, donc je ne peux pas pointer vers une option en particulier, mais tu peux chercher de deux côtés:
- changer le driver de sortie pour Xv ou OpenGL (il se peut que tu sois en X11, qui est plus lent)
- cocher une option qui s'appèlerait un truc du genre "Vertical synchronisation"
Ca vaut aussi le coup de tester avec un autre player, comme mplayer en ligne de commande : avec l'option -vo, tu peux facilement changer le driver de sortie de mplayer et ainsi en tester plusieurs rapidement.
[^] # Re: 3615 Mavie
Posté par Charles Flèche (site web personnel) . En réponse au message Passer developer freelance : formalités, facturation. Des conseils ?. Évalué à 1.
Merci pour votre réponse !
AGA: Sur quelles critètes avez-vous choisi votre AGA ?
TVA étranger: qu'est-ce qu'il vous fait penser qu'il faille refacturer la TVA ?
[^] # Re: re
Posté par Charles Flèche (site web personnel) . En réponse au message Avis PC LDLC Bellone. Évalué à 2.
14" 1920x1080 c'est pour moi la taille limite. En dessous, ça commence à faire vraiment petit. Voyageant beaucoup, c'est un bon compromis.
[^] # Re: Humidité ?
Posté par Charles Flèche (site web personnel) . En réponse au journal RuggedPOD: le serveur dans le jardin ?. Évalué à 3.
Je suis à Rangoun en Birmanie jusque fin mai, si vous voulez faire des tests se sera avec plaisir.
[^] # Re: Xournal
Posté par Charles Flèche (site web personnel) . En réponse au message Notes à la tablette graphique. Évalué à 1.
Pas mal. Pas de canvas infini et la reconnaissance de la pression du stylet est erratique, mais c'est pas mal du tout.
Merci beaucoup !
[^] # Re: Retour d'expérience
Posté par Charles Flèche (site web personnel) . En réponse au message Un portable sous Linux en voyage. Évalué à 4.
Ça vous fait 70km par jour, 6 jours par semaine. En tant que tel, c'est déjà sport… Les 70km / jour, c'est largement faisable, mais un seul jour de repos par semaine, c'est très contraignant. Si vous passez 4 jours dans un endroit cool, ça veut dire que vous pédalez tout le reste du mois sans repos. Galère…
Si en plus vous comptez vous arrêter un peu après deux semaines et prendre 125 photos / jour, vous êtes parti pour pédaler comme des dingues, être toujours en retard sur votre planning, sacrifier d'autres parties importantes du projet comme les photos, vous fatiguer, vous engueuler tous les deux et risquer une grosse tendinite (ou pire) qui vous scotchera à un endroit (qui sera nécessairement tout pourri au milieu de nulle part) pour des jours.
Comptez 1500km / mois. Pas plus. Si vous êtes plus rapide, cool, ça vous fait plus de temps pour faire et trier les photos ou rester vous reposer quelque part.
Et ce n'est pas la peine de prévoir un itinéraire précis au sentier près dès maintenant. Vous ne le respecterez pas de toutes façons, pour plein de raisons : parfois vous allez manquer de temps et prendrez des voies rapides, d'autres fois vous allez pédaler avec d'autres cyclistes, encore après vous fairez un détour. Soyez au courant des pays à traverser et des postes frontières à passer, soyez flexibles et prévoyez votre itinéraire de semaines en semaines. Pas plus, ça ne sert à rien si vous n'êtes pas très contraints par le temps.
Et si vous êtes contraints par le temps, et bien prenez des trains ou balancez les vélos à l'arrière d'un camion pour quelques centaines de kilomètres.
Vous avez déjà réglé les problèmes les plus importants :
- le vélo (vous avez fait un bon choix, vous ne regretterez pas le Rolhoff)
- le matos informatique / photo pour le projet (vous vous y connaissez assez pour faire un choix qui conviendra de toutes façons, quel qu'il soit)
- les frontières (soyez blindés sur les VISAs et les procédures, c'est de loin la partie la plus chiante du voyage)
Donc c'est bon, vous savez déjà que tout va très bien se passer.
L'itinéraire précis est très, très secondaire et facilement improvisable.
[^] # Re: Tux à vélo
Posté par Charles Flèche (site web personnel) . En réponse au message Un portable sous Linux en voyage. Évalué à 1.
32 bits la clé, pas 64 : il faut qu'elle puisse passer partout. J'avais quelques ISOs sur un disque externe pour refaire des clés en cas de besoin (Ubuntu 32bits pour le netbook, Ubuntu 64bits pour le gros laptop, Backtrack pour cracker les réseaux WIFI WEP).
Les sacoches Carradice ont l'air solides, mais sont bien plus chères que les Ortlieb Backroller et semblent nécessiter un entretien plus important (cire spéciale). Si votre projet s'inscrit dans une démarche écologique / équitable / privilégier les petites boites, les Carradice ont du sens. Sinon vous n'aurez aucune surprise avec les Ortlieb.
Les Ortlieb ne sont pas parfaites non plus ni indestructibles, loin s'en faut :
- pensez à resserer les vis des crochets sur les sacoches tous les 500 / 1000 km. J'ai perdu un crochet comme ça…
- il me semble que j'avais cassé un fermoir, pas celui qui ferme la sacoche mais celui qui se rabat sur l'avant. Ce n'était même pas le fermoir lui même mais le tissu sur lequel il était attaché qui était arraché. Ça s'achète et se change facilement, mais ça vaut le coup d'en avoir un de rechange
- après avoir mal évalué la hauteur d'une bordure le dessous d'une sacoche avant a frotté et a été endommagé. Il y a un kit Ortlieb pour réparer ce genre de dégat (genre patch + colle pour réparer les voiles de bateaux il me semble).
- le plus gros problème c'est les adaptateurs placés dans les crochés de fixation pour en diminuer le diamère et s'adapter au racks fins. Ces adaptateurs se cassent et se perdent très facilement. Soit vous prenez un bon paquet de rechange, soit vous achetez des racks avec des tubes adaptés de gros diamètre (probablement la meilleure solution), soit vous modifiez les racks. Il y a quelque part sur un blog le bricolage d'un gars qui a utilisé deux couches de gaine électrique souple fendue pour augmenter le diamètre des tubes de son rack. Intelligent…
[^] # Re: Quelques commentaires
Posté par Charles Flèche (site web personnel) . En réponse au message Un portable sous Linux en voyage. Évalué à 1. Dernière modification le 04 juin 2014 à 06:37.
Pour le voyage à vélo autour du monde on avait un Mobile Action i-gotu GT-600 : http://global.mobileaction.com/product/product_i-gotU_GT-600.jsp
Point de vue hardware j'en suis plutôt content : bonne autonomie (plusieurs jours si on prend des points toutes les deux ou trois minutes), bonne précision, solide. Si balancé dans le sac sans faire attention il a tendance à s'éteindre facilement si quelque chose appuie trop longtemps sur son très gros bouton.
Point de vue software sous Linux c'est un peu moins cool. Il existe un projet de driver i-gotu basé sur la libusb et Qt : https://code.launchpad.net/~charlesf/igotu2gpx/gt600
Ça se présente sous la forme d'une commande (igotu2gpx) pour exporter les points du GT-600 en .gpx ou .kml. Je me servais ensuite des traces dans qlandkartegt et josm. Par contre il faut compiler et je n'ai jamais réussi à faire tourner igotu2gpx que sous root.
J'ai patché le code pour le rendre compatible avec le GT-600, il est dans ma branche https://code.launchpad.net/~charlesf/igotu2gpx/gt600
Le pach n'est pas intégré dans la branche principale pour une raison que j'ignore, mais appliqué sur la branche principale ça fonctionne.
Worst case scenario, les drivers fonctionnent très bien dans une machine virtuelle Windows.
Ça fait très longtemps que je dis que ça serait un excellent projet pour moi apprendre la programmation de drivers sous Linux, mais je ne m'y suis jamais mis. Si jamais vous utilisiez ce petit logger sous Linux, ça serait une bonne motivation pour me mettre au boulot. Vous partez quand ?
[^] # Re: Quelques commentaires
Posté par Charles Flèche (site web personnel) . En réponse au message Un portable sous Linux en voyage. Évalué à 1.
Vous utilisez quoi comme GPS ? Et les traces GPS, vous allez vous en servir dans quels logiciels ?
Merci !
# Tux à vélo
Posté par Charles Flèche (site web personnel) . En réponse au message Un portable sous Linux en voyage. Évalué à 9. Dernière modification le 03 juin 2014 à 09:58.
TL;DR : achetez du matériel informatique standard, de très bonnes sacoches de vélo imperméables et soyez sans pitié en triant vos photos tous les jours.
En 2011 / 2012 ma partenaire et moi avons pédalé de Cambrai, France à Cambrai, Australie. On a beaucoup écrit sur notre blog http://cambrai-cambrai.net et pris pas mal de photos. Ubuntu a été notre unique système d'exploitation pendant ces 18 mois autour du monde.
J'avais un petit netbook Acer Aspire One d'une lenteur incroyable (Compact Flash super lente en guise de DD interne…). Il me servait à écrire les textes de notre site et à coder les scripts de mise à jour du site (les connexions étaient souvent tellement pourries que passer par l'interface web de Wordpress était très pénible, alors qu'avec un petit script python attaquant l'API wordpress ça passait mieux).
L'autre PC était un Acer Aspire Timeline X. Je n'ai plus bien les specs en mémoire mais c'était du genre 4GO RAM / 768GO DD (aucune idée du processeur). Il suffisait largement à faire du traitement RAW basique, trier les photos, Skype et emails.
On se faisait aussi tout un monde de la survie des laptops en pédalant (d'où l'achat du netbook sans pièce mobile outre le ventilateur), mais en fait ça c'est très bien passé. Et tous les cyclistes qu'on a croisé sur le chemin avait des laptops standards et quasiment aucun n'ont eu de soucis. C'est vrai que les disques peuvent mourir (on a bousillé un DD externe en route), mais pas plus que dans "la vie de tous les jours".
Donc plutôt que de prendre un ToughtBook lourd et peu performant, achetez deux laptops standards. Ayez chacun votre PC ou vous allez vous taper dessus les jours de repos pour savoir qui peut aller checker ses emails.
Tous les documents importants (photos, cartes, scan des passeports et VISA…) étaient sur le gros laptop et chacun de nous avait un disque-dur de backup. On aurait sans doute pu faire avec un unique disque de backup sur le vélo qui ne portait pas le laptop, mais j'avoue une vraie paranoïa quand aux sauvegardes… Mea culpa… Un script rsync lancé manuellement dès qu'on pouvait faisait une simple réplication sur les disques de backup.
Pour le transport, les laptops était simplement dans leur housse standard dans nos sacoches étanches. Ne pas avoir de sacoches dédiées aux laptops nous a permis de tenter pas mal de configurations de rangement différentes au gré des saisons et de nos expérimentations. Bref, investissez dans de très bonnes sacoches de vélo étanches (on avait des Ortlieb) qui vous serviront pour tout le matos et pas juste pour le PC.
Les disques durs externes de backups étaient toujours dans les sacoches de guidon pour deux raisons :
1. on gardait toujours les trucs importants à porté de main, facilement détachables du vélo (passeport, argent, cartes, contacts, appareils photos, petits outils…)
2. la conception de la fixation de la sacoche de guidon apporte un peu de souplesse à l'ensemble, amortissant un peu les chocs : ça me rassurait sur la durée de vie des disques durs.
On a longtemps utilisé Shotwell pour gérer les photos, mais il nous a saoûlé par ses plantages et bugs (des photos dégageaient de la bibliothèque sans raison). Bref, on est passé à Digikam qui est beaucoup plus stable, et même si l'interface d'édition des photos n'est pas terrible, pour le tri et le classement il est très bien. Cela dit si c'était à refaire je tenterai volontier Darktable, il n'a pas l'air mal du tout.
Mais je vous en conjure : triez vos photos quotidiennement et soyez sans pitié. Vos disques-dur s'en porteront mieux, vos sauvegardes se feront plus rapidement et vous ne serez pas découragés en rentrant quand il faudra s'attaquer à 600GO de photos.
On s'était donné des règles :
1. on faisait d'abord une première passe directement sur les appareils photos pour virer les clichés flous / mal exposés / peu intéressants / franchement moches.
2. on importait les photos dans Shotwell / Digikam et on formatait immédiatement la carte mémoire. C'est pratique parceque comme ça on savait qu'une photo était soit sur disque, soit sur carte, mais jamais à deux endroits en même temps. Pas d'hésitation, si la photo est sur carte, c'est qu'elle n'est pas sur disque, donc pas backupée sur les disques externes, donc à importer au plus vite.
3. on faisait une second passe sur PC pour dégager les photos floues / mal cadrées / râtées techniquement parlant. On ne s'intéressait pas à la qualité artistique de la photo à cette étape, mais juste de la technique. On avait pas de temps à perdre sur des retouches poussées, donc soit la photo est bonne techniquement, soit elle dégage.
4. la dernière passe est pour les garder les vraies bonnes photos.
Objectif : 12 photos grand maximum par jour. Ce n'est pas facile, mais on ne s'est pas encombré avec des clichés qu'on estimait sans intérêt.
Embarquez une clé bootable (genre Live USB Ubuntu ou quelque chose du genre) qui vous servira si vous devez emprunter / racheter / réparer / installer un ordinateur en cours de route.
Un dernièr point : si vous n'avez pas le temps de vous mettre à Linux quelques mois avant de partir en voyage pour vous faire au système, restez sur Windows et Mac. Geeker un Linux et écumer les forums de barbus est la dernière chose que vous allez vouloir faire sur la route.
Bonne préparation et bon courage !
# Magnet
Posté par Charles Flèche (site web personnel) . En réponse à la dépêche Éblouissants Reflets, une exposition impressionniste à Rouen. Évalué à 2.
TPB est bloqué où j'habite. On peut passer par un proxy bien entendu, mais ça serait bien mieux si tu pouvais mettre un magnet dans l'article lui-même. Peut-être dans les liens ?
Merci pour tout !
[^] # Re: Attention, danger !
Posté par Charles Flèche (site web personnel) . En réponse au journal Darktable 1.0. Évalué à 1.
L'article date de 2005. A l'époque il ne devait pas y avoir beaucoup de capteurs de plus de 3 mdp. Je ne pense pas qu'il y ait confusion entre définition et résolution ici.
[^] # Re: Attention, danger !
Posté par Charles Flèche (site web personnel) . En réponse au journal Darktable 1.0. Évalué à 3. Dernière modification le 21 mars 2012 à 16:21.
Un Raw n'est pas une image : c'est juste des données brutes de capteur. Une image d'appareils photos, c'est une suite de triplets de valeurs (Rouge Vert Bleu) pour chaque pixel. Les données issues du capteur sont différentes d'un fabricant à l'autre, mais typiquement pour chaque pixel de l'image final on échantillonne sur 4 photosites agencés en carré deux valeurs de vert, une de rouge et une bleu (deux de vert parceque c'est à cette couleur que nous sommes le plus sensible). Il faut noter l'aspect "adjacent" : dans une image les trois valeurs RGB sont spacialement au même endroit. Construire des pixels à partir de données RAW en tenant compte du décalage spatial et l'échantillon de vert supplémentaire s'appèle "le dématriçage". C'est une opération que les ordinateurs font mieux que les appareils photo. Je ne retrouve plus l'article qui montre que les résultats obtenus par dcraw sont supérieurs à ceux obtenus par les algos internes des appareils photos…
Un bon article sur le sujet.
[^] # Re: Attention, danger !
Posté par Charles Flèche (site web personnel) . En réponse au journal Darktable 1.0. Évalué à 7.
Dans un appareil photo numérique, avant d'arriver à une image il y a trois étapes :
1. Récupération des données du capteur
2. Traitements d'image
3. Encodage en Jpeg
Un fichier RAW, c'est juste les données du capteur. En RAW ont récupère les données juste après l'étape 1. Ça permet trois choses principalement :
- traiter une image sur un ordinateur beaucoup plus puissant que les circuits internes d'un appareil photo. On peut accéder à des algos beaucoup plus puissant
- retravailler après prise de vue une image sans avoir déjà des traitements déjà appliqués
- ne pas avoir d'artefacts de compression inhérent au jpeg
[^] # Re: liseuse ?
Posté par Charles Flèche (site web personnel) . En réponse au message Liseuse ebook. Évalué à 1.
Liseuse, pas tablette. L'autonomie de plusieurs jours est décisive dans mon cas.
Effectivement, un dictionnaire serait une très bonne chose. D'autres propositions ?
[^] # Re: Une porte dérobée dans un logiciel libre ?
Posté par Charles Flèche (site web personnel) . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à -1.
(Sympa le petit strip quand on se répond à soit même !).
# Une porte dérobéde dans un logiciel libre ?
Posté par Charles Flèche (site web personnel) . En réponse à la dépêche Le FBI a-t-il introduit des portes dérobées dans OpenBSD ?. Évalué à 3.
# i-gotu
Posté par Charles Flèche (site web personnel) . En réponse au message Cherche un logger GPS avec une forte autonomie. Évalué à 1.
Quelqu'un a déjà essayé ?