Juil 02 2012

Comprendre le format Raw - Deuxième partie

FormatRAWetFluxdeProd_2.jpg[NdLR : je vous propose une introduction au format Raw extraite (et légèrement adaptée pour le web) du début du deuxième chapitre de mon livre Le format Raw : développement et flux de production, paru aux Éditions Dunod. Cette introduction est découpée en trois parties et dotée de liens de circulation des unes vers les autres. Voici la deuxième partie, intitulée dans le livre Comprendre le format Raw.]

Dans la première partie, nous avons évoqué les différents processus, de nature essentiellement électronique, qui aboutissent au fichier Raw tel que l’appareil l’enregistre sur la carte mémoire. Il ne s’agit pas de données brutes au strict sens du terme, car le signal a subi plusieurs traitements de réduction du bruit avant et après la conversion analogique/numérique. Disons que le Raw contient des données aussi brutes que possible, dont il tire son nom (raw = brut en anglais).
Examinons à présent le contenu de ce fichier et les méthodes qui permettent de le convertir en image de type bitmap. En direction des photographes encore hésitants sur l’adoption du format Raw et qui liraient cet article pour se convaincre définitivement de ses bienfaits, je propose ma vision du match «Raw contre Jpeg» dans la troisième partie.


Comprendre le format Raw

Si le Raw est d’un point de vue technique un format d’image, il n’est pas encore une image au sens bitmap du terme dans la mesure où il doit être interprété pour être visualisé. Il est donc en réalité une infinité d’images en puissance. C’est sur cela que se fondent l’analogie entre le Raw et le négatif numérique, et l’adoption du terme de développement pour désigner le processus d’interprétation et de transformation en format d’image classique.
Quelle que soit la nature d’un fichier informatique (texte, son, image, etc.), il est toujours codé en langage binaire. L’ordinateur doit le décoder afin que vous puissiez le lire, l’écouter ou le visionner. Le Jpeg est dans ce cas : il ne nécessite rien d’autre qu’un décodage binaire pour être transformé en image affichable. L’erreur serait de croire que le Raw est juste un fichier codé de manière un peu plus complexe, que seuls quelques logiciels seraient capables de décoder et d’afficher en tant qu’image.
Nous l’avons vu, le Raw est pour l’essentiel un enregistrement brut de la lumière reçue par le capteur. De nombreux paramètres majeurs caractérisant une image ne sont pas spécifiés et relèvent de l’interprétation : luminosité, contraste, balance des blancs, calage de la colorimétrie et de la dynamique, etc. Tous ces ingrédients doivent être injectés au Raw pour le transformer en image. Fabriquer une image affichable à partir d’un Raw est donc fondamentalement différent d’un simple décodage de bits.
Quand un logiciel ou une simple visionneuse est capable d’afficher un Raw, c’est qu’elle a procédé à sa conversion en lui fournissant tous les paramétrages nécessaires. Ce n’est donc pas le Raw qui est affiché, mais l’une des interprétations de ce Raw parmi une infinité. Pour cette raison, aucun logiciel ne vous proposera la même image par défaut, ce qui est la cause de bien des interrogations tant nous sommes habitués à ce qu’une image s’affiche partout de la même manière (pour peu qu’elle intègre un profil de couleur).
On peut légitimement se demander ce que sont devenus tous les paramétrages du boîtier soigneusement pensés puis programmés : balance des blancs, contraste, saturation, netteté, modes Scène, etc. La réponse n’est pas simple, car elle dépend du logiciel utilisé pour traiter le Raw. Seuls les logiciels propriétaires sont en mesure de comprendre ces réglages et de les prendre en compte, car leurs algorithmes sont apparentés à ceux du processeur du boîtier (ils sont le plus souvent capables de fabriquer le même Jpeg que celui que le boîtier aurait produit). Pour les logiciels indépendants, le réglage « +1 » en saturation – pour citer un exemple – n’a pas de sens a priori. Ils ne sauront pas à quoi cela correspond pour leurs propres algorithmes. Seul l’univers logiciel du constructeur est à même de comprendre les instructions en provenance du boîtier et de les appliquer.
Cela peut occasionner de mauvaises surprises lorsque l’affichage par défaut d’un Raw dans un logiciel indépendant est très différent de celui affiché sur l’écran de l’appareil sitôt après la prise de vue. Il ne peut pourtant en être autrement, mais c’est là l’une des causes de méfiance envers le format Raw.

Dublin_comparaison.jpg

Trois interprétations par défaut d’une même photo prise en Raw par le logiciel propriétaire (à gauche), Lightroom (au centre) et DxO Optics Pro (à droite). On constate des variations en termes de luminosité, de contraste ou de saturation des couleurs, même en très petit format comme ici. La version de gauche se distingue un peu plus des autres, car la photo a été prise avec un ajout d’optimisation dynamique que seul le logiciel propriétaire a été en mesure d’interpréter.

L’interprétation proposée par un logiciel propriétaire n’est pas nécessairement meilleure que celle d’un autre logiciel. Aucun algorithme ne peut prétendre reproduire la vérité, et il faut également abandonner l’idée que le Jpeg produit par le boîtier en est plus proche que les autres. Bien que très répandue, elle est également fausse. En argentique, une même prise de vue pouvait donner des résultats très différents selon le type de film utilisé et selon ses modalités de développement. Il en va de même en numérique. En revanche, l’utilisateur peut être attaché aux choix colorimétriques de son constructeur, ce qui le portera alors vers le logiciel livré avec son boîtier, même si les éditeurs indépendants s’efforcent d’en reproduire le rendu par défaut.


Conversion du Raw en image

Nous avons vu dans la partie précédente qu’avec la technologie de filtrage par une matrice de Bayer, chaque couche RVB est enregistrée de manière incomplète. La conversion du Raw en image passe par une phase dite de dématriçage destinée à reconstituer l’information manquante. Cette phase est d’une importance capitale, car la précision des couleurs et la finesse des détails de l’image finale en dépendent. Les algorithmes utilisés sont d’une grande complexité et constituent une bonne part des différences qualitatives entre les logiciels.

dematricage.jpg

Rendue nécessaire par l’utilisation d’un filtrage de Bayer, la phase de dématriçage reconstitue les couches RVB incomplètes. Ce processus complexe est la principale origine des différences de rendu entre les logiciels, car il n’existe pas de méthode universelle.

Pour prendre la mesure de la difficulté de l’opération de dématriçage, imaginez que la scène photographiée est un damier noir et blanc dont la forme et le nombre de cases s’ajustent très exactement à la répartition des pixels du capteur. La lumière des cases blanches arrive sur les pixels recouverts de filtres verts et la « non-lumière » des cases noires sur les pixels recouverts de filtres rouges et bleus. Le capteur va donc enregistrer des valeurs maximales aux emplacements des pixels verts qui auront reçu la lumière blanche et... pas le moindre photon sur les pixels rouges et bleus. Le dématriceur, qu’il s’agisse du processeur du boîtier ou d’un logiciel, va être tenté de conclure que les valeurs de la couche verte sont uniformément maximales, et que celles des couches rouges et bleues sont uniformément nulles car rien ne lui permet d’envisager une autre solution. Finalement, il va conclure que le damier noir et blanc est uniformément vert ! Ce cas est bien sûr caricatural, mais il permet de mesurer la difficulté de l’entreprise.


Gamma et capture linéaire

Une autre étape importante de la conversion d’un Raw est le redressement de la réponse tonale du capteur, car celui-ci fonctionne différemment de la vision humaine. Pour le capteur, l’intensité lumineuse est proportionnelle au nombre de photons reçus. La réponse tonale est donc linéaire, représentée par un gamma = 1. Celle de l’œil est différente, et possède un gamma valant approximativement 2,2.

gamma.jpg

Simulation de la vision d’un dégradé de gris, du noir au blanc, tel que le verrait le capteur du fait de sa capture linéaire (gamma = 1) et telle que le voit l’œil humain (gamma = 2,2).

Lorsque l’intensité de la lumière est doublée, notre œil procède à une compensation automatique qui réduit la perception d’accroissement de la luminosité (et inversement, notre œil s’adapte à une baisse de luminosité, que nous percevons moins forte qu’en réalité). C’est particulièrement vrai aux extrêmes, tandis que la réponse de l’œil est plus proportionnelle lorsque l’éclairement est modéré. La réponse de l’œil est donc proche de celle du film argentique, qui présente une courbe sensitométrique aplatie aux extrêmes et quasi linéaire au centre.

suricate.jpg

Illustration du redressement de la réponse tonale : à gauche l’image obtenue avec un gamma = 1, à droite avec un gamma = 2,2.


Profondeur de codage

Sur les reflex, les bridges et les compacts experts, le Raw est codé sur 12 ou 14 bits. Cela signifie qu’il possède 16 ou 64 fois plus de nuances qu’une image bitmap codée en 8 bits, comme le Jpeg. Si pour une visualisation sur écran ou un tirage sur papier les 8 bits du Jpeg suffisent, ce n’est plus le cas lorsque des retouches doivent être réalisées. La faiblesse de la profondeur de codage génère des artefacts qui se traduisent par des trous dans l’histogramme. La compression aggrave le problème, car si les informations détruites l’ont été de manière intelligente afin que cela ne soit pas perceptible en affichage ou en impression, elles font défaut quand une retouche un peu appuyée modifie l’image.

poisson_clown.jpg

Histo_2.jpgHisto_1.jpg

Poisson Clown après un renforcement du contraste et une augmentation de luminosité. À gauche l’histogramme du TIFF 16 bits, à droite celui du TIFF 8 bits.

Cela étant, seule la profondeur de codage nous intéresse ici. Pour éviter le problème lié à la compression dans l’illustration ci-dessus, j'ai exporté un Raw sans modification en TIFF 8 bits et en TIFF 16 bits. J'ai appliqué à ces deux images identiques un renforcement du contraste à l’aide de la Courbe des tonalités, puis une légère augmentation de la luminosité. On constate qu’à l’issue du traitement, l’histogramme issu du TIFF 8 bits présente une forme de peigne, découvrant les pertes d’informations dans l’image. L’histogramme du TIFF 16 bits est resté parfaitement régulier grâce à sa profondeur de codage plus importante.

À suivre...


Commentaires   

# Raw et outils gratuit...Aymeric 02-07-2012 18:59
Bonjour Patrick,

Ce nouvel article démontre bien la perte de qualité à laquelle il faut s'attendre en post-traitant du JPEG. Et surtout la puissance de manipulation que l'on obtient en passant au format RAW.

Je l'ai certainement déjà dit plusieurs fois, mais cela fait maintenant presque 2 ans que je suis passé au format RAW et j'apprécie de jour en jour toujours plus les possibilités d'interprétation que me laisse ce format.

Pourtant je ne travaille pas sur des outils très professionnels (RawTherapee). Je suis sur la politique du "logiciel libre". Mais ma vie a changé entre le "bricolage" sous Picasa ou Photofiltre et le passage à un dérawtiseur, même gratuit.

J'ai fait mes début avec UFraw, qui est un freeware sympa et simple d'utilisation pour le débutant. RawTherapee est plus lourd mais contient plus d'options de réglages (notamment une meilleure gestion du bruit et la récupération des hautes lumières, même si cela n'est pas encore parfait).

Il m'arrive, quand je dois fournir 200 photos très rapidement suite à un matche de foot par exemple, de retravailler en RAW pour satisfaire les gens pressés d'avoir les photos. Ca me fait du mal de fournir du JPEG sans être passé par la case RAW. Mais parfois on n'a pas le choix, il faut faire vite en bien.

Quels outils (si possible gratuit) de retouche utiliserais-tu pour traiter du JPEG directement (améliorer un peu le contraste, la lumière) ?

Aymeric
# Patrick Moll 02-07-2012 21:25
Si je devais retoucher des Jpeg avec un outil gratuit, ce serait assurément Gimp. Heureusement pour moi, la photo étant indissociablement liée à la notion de plaisir, je ne m'inflige aucun logiciel gratuit parce qu'il est gratuit... :wink:
# lawre51 02-07-2012 21:21
Bonjour Patrick,

Attention Patrick, comme Gilbert Volkert tes explications sur le gamma et la capture linéaire m'ont embrouillé.

Sur ton illustration, il faut expliquer que l'image obtenue avec un gamma de 1 est sombre parce qu'il n'y a pas de correction gamma en amont et que l'affichage sur un écran (gamma 2.2) donne cette image sombre.
Si le logiciel interne au boitier ou le logiciel de dématricage applique une courbe de réciprocité (inverse du gamma donc égale à 0.45), l'image sera perçue normale comme celle de droite.

C'est cela ou je me trompe?
# Patrick Moll 02-07-2012 21:31
Non, tu ne te trompes pas, mais je ne suis pas sûr que ton propos soit plus clair.
Le capteur fonctionne en gamma = 1 alors que l’œil est en gamma = 2,2. Cela a des conséquences sur la répartition des informations sur la plage des tonalités. Pour le capteur, 1 IL d'écart signifie deux fois plus ou deux fois moins de lumière. C'est cela qu'il est important de comprendre indépendamment du fait que, bien évidemment, le gamma est corrigé en post-traitement.
# RAW (2è partie)Thierry 04-07-2012 17:28
Question de profane:
L'image visible n'étant jamais en RAW mais dans un format bit map "developpé en 8 bits"; ne pert-on pas l'avantage des 14 ou 16 bits du format original ?
# Patrick Moll 05-07-2012 17:36
Ce qu'il faut comprendre, c'est qu'un écran d'ordi n'est pas capable d'afficher plus que 8 bits et qu'un papier n'est pas capable de restituer plus que cela non plus. Une visualisation, et même une impression, en 8 bits est donc parfaitement adaptée. Ce qui est important, c'est que le développement et les retouches soient faites avec le maximum d'informations pour minimiser les dégâts et offrir une plus grande latitude d'intervention. Quand l'image est définitivement figée et qu'on y touchera plus, ce n'est pas un problème qu'elle soit codée en 8 bits.
# RAW 2è partiethierry 04-07-2012 23:17
Bonjour Patrick,

question de profane:
que reste-t-il du traitement du RAW sur une image bitmap en 8 bits c,a,d, sur l'image finale après dématriçage et peut-on restituer les valeurs et nuances originales des 14 ou 16 bits du RAW ?
# Patrick Moll 05-07-2012 17:39
J'ai déjà répondu en partie à ta question. J'ajoute juste que le passage de 14 bits à 8 bits est sans retour : ce qui a été supprimé est perdu pour toujours. D'où l'importance de ne pas faire de retouche sur le Jpeg 8 bits quand on dispose du Raw. Ou alors en mode non destructif dans Photoshop quand on ne peut pas faire autrement.
# 2cran à tubes et reproduction des couleurs:Cocagne 06-07-2012 20:59
Citation en provenance du commentaire précédent de Patrick Moll :
Ce qu'il faut comprendre, c'est qu'un écran d'ordi n'est pas capable d'afficher plus que 8 bits et qu'un papier n'est pas capable de restituer plus que cela non plus. Une visualisation, et même une impression, en 8 bits est donc parfaitement adaptée. Ce qui est important, c'est que le développement et les retouches soient faites avec le maximum d'informations pour minimiser les dégâts et offrir une plus grande latitude d'intervention.
[...]
Quand l'image est définitivement figée et qu'on y touchera plus, ce n'est pas un problème qu'elle soit codée en 8 bits.


Toujours en attente de décision pour choisir un écran j'avais abordé le sujet avec un tireur qui fournit de nombreuses affiches de théâtre entre autre et produit pour pas mal de professionnels de ma bonne ville de Montpellier.
Il travaille avec deux écrans un à tube de bonne marque et un à dalle aussi de grande marque.les deux de grande taille.
Il m'a fait la démo avec une même image issue d'un moyen format numérique, image qu'il préparait pour un tirage d'expo, des différences de potentiel entre un très bon écran plat que je ne nommerais pas, car d'après lui c'est à peu prés pareil avec d'autres marques, et un écran à tube genre Trinitron.
L'écran à tube produi une gamme de tons linéaire, les corrections sous Photoshop sont bien plus progressives alors que sur l'écran plat elles apparaissent par palier assez brutaux .
Il est possible que les deux disposent de la même amplitude mais le résultat est visiblement plus fin sur l'écran à tube.
C'est encore plus flagrant avec des fichiers de films numérisés (quand ils ont été bien exposés)

Inconvénient des écrans à tubes:
Nécessite des étalonnages hyper-fréquents.
Fatigue les yeux
Difficile à trouver sur le marché.
Inconvénient des écran plats restitutiuon non linéaire liées à ce fameux nombre de bits

Cet homme suggère donc de travailler pour le tout venant sur un écran plat quand même bien plus confortable d'usage, professionnel si nécessaire et si possible par contre pour les cas difficiles ou les demandes exigeantes il préconise de conforter ses choix avec un écran à tube.

J'ai de la chance c'est mon tireur et du coup un brave écran expert amateur devrait me suffire pour lui suggérer ce qui me conviendrait .

Attention je clique !
# Patrick Moll 06-07-2012 22:20
La qualité des dégradé est l'un des points importants qui différencient les écrans plats. Mais la qualité du calibrage est très importante pour cela également. Pour avoir testé de nombreuses sondes et de nombreux logiciels pour mon dossier de Compétence Photo, je peux assurer que les différences peuvent être énormes sur ce point.
Pour le reste, il y a bien moins d'écarts entre deux écrans qu'entre un écran et un papier. En tant que scientifique, ça me fait toujours un peu marrer de voir les gens faire des efforts démesurés pour produire des données d'entrée hyper précises alors même que le résultat final ne peut espérer être qu'une approximation grossière. Mais bon... :wink:
# Cocagne 07-07-2012 20:34
Pas vraiment d'accord avec ta dernière phrase, si je l'ai bien comprise bien sur.

C'est la fameuse histoire du maillon de chaine :
On ne va tout de même pas bâcler la fabrication d'une chaine de mouillage sous le prétexte que ensuite ce sera une ancre marine aux performances médiocres qui va retenir le navire !

Cela me rappelle le raisonnement que me tenait un entrepreneur en bâtiment alors que j'insistais sur le fait que les bétons qu'il mettait en place lui arrivaient fabriqués et contrôlés avec rigueur et que ses rajouts d'eau dénaturaient le produit en réduisant sa résistance de beaucoup. Et bien sais tu ce qu'il m'a opposé ? Que les architectes prenaient de telles marges de sécurité qu'il pouvait fort bien en ôter une part en sa faveur et qu'il en resterait assez pour le bâtiment.
Si encore il m'avait répondu (pour faire pendant avec ton exemple de l'impression) qu'il lui était impossible de mettre un tel produit en œuvre sans en modifier les performances

Tu nous as fait tous adhérer à ta défense du Raw pour diverses raisons toutes bien démontrées dans tes écrits alors pourquoi baiser sa garde devant effectivement une faiblesse dans la transition des donnes d'un support à l'autre.

Mais sur fond je sais que tu as raison mais alors je serais heureux d'avoir ton impression (sans jeu de mots)sur les écrans à tube.

Précédant tes préconisations j'avais, même avec mes premiers compacts ou bridge quasiment toujours enregistré en format natif, en Raw, bien m'en a pris car aujourd'hui je peux revenir sur des images avec les nouveaux logiciels. Sera ce identique avec les technologies d'impression ? Préservons l'avenir
# Patrick Moll 11-07-2012 04:12
Il ne s'agit pas de bâcler quoi que ce soit. On a ici une problématique qui n'a rien à voir avec les problèmes de croissance d'erreur dans des processus complexes. Sujet que je connais très bien en tant que spécialiste des processus chaotiques, de la sensibilité aux conditions initiales et de la divergence des trajectoires sur l'attracteur (c'est mon pain quotidien au boulot).
Ici, on se demande juste si c'est utile de voir parfaitement sur écran des détails, des nuances ou des couleurs qui n'ont aucune chance d'être imprimés. Ma réponse est qu'il faut faire du mieux qu'on peut, sans toutefois aller jusqu'à élargir le fondement des diptères. Les écrans cathodiques, je ne connais plus personne qui en utilise, même chez les professionnels de la couleur. Tu sembles avoir sous la main l'un des derniers représentants de cette espèce en voie de disparition. Il faudrait sauver un couple pour créer un Cathodic Park... :wink:
Plus sérieusement, j'en ai discuté avec des spécialistes. Pour eux, un CRT dérive tellement vite que pour des besoins pros, il faudrait le calibrer chaque matin pour qu'il puisse prétendre faire mieux qu'un LCD. Et toujours pour eux, les LCD haut de gamme avec dalles IPS ou PVA et gamut à plus de 100% de l'Adobe RVB enterrent le meilleur écran cathodique. Évidemment, c'est beaucoup plus cher...
De mon côté, mes yeux et moi-même nous félicitons chaque jour de ne plus avoir à regarder de CRT. Et c'est peu de le dire...
# cocagne 12-07-2012 09:07
Bon voila une réponse sur les écrans à tube, c'est tout ce que je voulais.
# Olv 15-07-2012 10:39
Bonjour,

Quelques questions de pur néophyte à propos du RAW :

- je comprends que le principe consiste à obtenir de meilleures images à partir du fichier RAW que celles que propose l'appareil lui-même après sa propre interprétation.
- par quelle(s) opération(s) commence-t-on le traitement ?
- combien de temps prend le retraitement d'une image ?
- est-on censé refaire tout le travail de l'appareil, image par image, après être revenu avec des dizaines, voire des centaines de photos sur sa carte, ou est-ce un exercice ponctuel sur des images sélectionnées ?
# Patrick Moll 19-07-2012 12:35
Il faut distinguer deux choses : le réglages des paramètres globaux et la retouche de détails qu'il faudrait faire aussi bien en Raw qu'en Jpeg.
Les réglages globaux consistent à fixer la balance des blancs, ajuster les tonalités et réduire le bruit. Selon le logiciel dont vous disposez, ces opérations peuvent se faire par lot d'images homogènes (prises dans les mêmes conditions de lumière). C'est donc très rapide, bien plus que s'il faut retoucher un à un des Jpeg imparfaits. J'explique cela dans le livre sur le Raw, mais aussi dans celui sur Lightroom sorti il y a un mois.
Les différences entre Jpeg et Raw font précisément l'objet de la troisième partie de ce sujet, que je vais mettre en ligne sous peu. On pourra continuer cette discussion en commentaire de cette troisième partie... :-)
# Olv 20-07-2012 09:35
Ok, merci.

Hâte de lire cette troisième partie. Au passage je trouve ce site très bien fait et la qualité des articles et de l'expression écrite de tout premier ordre. Ce doit être un travail de romain, mais le résultat est un régal.
# Patrick Moll 21-07-2012 04:19
Merci à vous. En effet, ce site est assez chronophage, mais c'est aussi un plaisir pour moi de partager et d'échanger avec les photographes lecteurs. Donc je fais de mon mieux en fonction de mes disponibilités (qui sont à peu près nulles au moment où j'écris ces lignes).

Les commentaires ont été désactivés

Connectez-vous pour bénéficier de la mise en ligne automatique de vos commentaires !

Flux de production

17 mars 2014
x-rite-colortrue-la-gestion-des-couleurs-pour-les-appareils-mobilesNi Apple avec iOS, ni Google avec Android n'ont intégré dans leur système d'exploitation mobile la gestion des couleurs. Pour la plupart des usages, les [...]
28 décembre 2012
colorimetrie-comparee-des-logiciels-de-developpement-des-rawCet article, rangé dans la catégorie Gestion des couleurs, aurait pu figurer dans la rubrique Idées fausses tant le sujet abordé fait l'objet [...]
06 août 2012
comprendre-le-format-raw-troisieme-partie [NdLR : je vous propose une introduction au format Raw extraite (et légèrement adaptée pour le web) du début du deuxième chapitre de mon livre Le [...]
24 juin 2012
comprendre-le-format-raw-premiere-partie [NdLR : je vous propose une introduction au format Raw extraite (et légèrement adaptée pour le web) du début du deuxième chapitre de mon livre Le format [...]
06 avril 2012
protocole-de-test-pour-evaluer-la-colorimetrie-dun-boitierCet article présente le protocole de test qui servira à tester la colorimétrie des boîtiers Sony Alpha et NEX. Il ne présente donc pas d'intérêt majeur en [...]
25 février 2012
notions-despace-de-representation-et-de-profil-de-couleurAprès l'introduction aux problématiques de la gestion des couleurs, je vous propose d'aborder les notions d'espace, de représentation et de profil de [...]
19 février 2012
introduction-aux-problematiques-de-la-gestion-des-couleursHier, je relisais la review du NEX-7 par dpreview, qui est ce qui se fait de mieux et de plus complet actuellement (malgré certaines faiblesses de leur [...]

Communications

16 février 2015
migration-d-alpha-numeriqueLors des voeux de bonne année, j'ai évoqué la refonte de la maquette d'Alpha-numérique rendue impérative par l'arrêt de la maintenance du CMS (moteur de [...]
01 janvier 2015
alpha-numerique-vous-souhaite-une-excellente-annee-2015Alpha-numérique devait redémarrer avec la nouvelle année. Hélas, la refonte impérative de la maquette (qui doit être adaptée à la version la plus récente [...]
29 avril 2014
fermeture-d-alpha-numerique-pour-une-duree-indetermineeTrop de travail, trop peu de disponibilités, lassitude après tant d'années et plus de 1000 articles, départ en voyage, tout ceci me conduit à fermer le [...]
12 avril 2014
test-d-une-protection-anti-spam-sans-captcha-sur-alpha-numeriqueLe SPAM, c'est la vérole du Web. C'est lui qui m'oblige à imposer le remplissage d'un Captcha pour les commentaires des lecteurs non enregistrés, et je [...]
05 avril 2014
reprise-de-l-activite-sur-alpha-numeriqueAprès quasiment trois semaines sans article faute de disponibilité (en particulier du fait de l'écriture d'un très gros dossier à paraître dans le [...]
01 janvier 2014
alpha-numerique-vous-souhaite-une-excellente-annee-2014L'année 2013 aura été riche pour les sonystes. La marque orange a encore fait feu de tout bois avec beaucoup d'innovations, au premier rang desquelles [...]
21 décembre 2013
nouveau-module-expresso-news-sur-alpha-numeriqueLes articles publiés sur Alpha-numérique apparaissent dans la zone principale en format blog, ou dans un module latéral s'ils sont moins importants. Faute [...]