Idée de geek: un nouveau support de stockage ?

Nouvelle Update

L’idée que je vais vous exposer, me trotte dans la tête depuis la publication de l’article sur les Qr-code, j’en ai parlé à quelques amis qui ont trouvé l'idée intéressante. Je voudrais donc la partager avec vous, en espérant peut être q’un programmeur s’y intéresse. Allez je me lance Comme certains d’entre vous le savent surement, un octet (la plus petite unité de stockage) est un ensemble de 8 bits. Il s'écrit sous la forme : 01011010. Avec les deux valeurs possibles pour chaque bit, on a donc 256 possibilités [2^8].

Qr-code

Voir octet et binaire sur Wikipedia     

Le concept est donc de pourvoir utiliser le même système de stockage que le Qr-code, mais au lieu de prendre le binaire comme unité de référence, on va utiliser l’octet.
Comment faire ? Tout simplement on se servant d’un code couleur de 256 teintes.
L’utilité d’un tel procédé est tout à fais différente de celle des Qr-code, dont le principal avantage reste la possibilité d’être lu par un simple Camer-Phone.

Mon idée repose elle, sur un couplage Scanner / imprimante. En effet on peut assigner a chaque état de l’octet une couleur bien définie, par exemple pour le 00000001 c’est le noir, le 01001001 le vert, 00001110 le rouge on peut donc avoir tout les états de l’octet dans une palette de 256 couleurs, il suffit ensuite de programmer un petit logiciel qui retranscrit chaque octet en une couleur qui lui est prédéfini. On peut donc logiquement imprimer cette couleur sur une feuille, l’emporter avec nous, la placer dans un scanner puis récupérer très facilement avec le même programme sa valeur initiale.

Maintenant imaginons qu’on réduise la taille de cette couleur à un pixel, avec un taux de 96 pixels par pouce, ce qui reste bien évidement loin d’une qualité normale en impression, même une jet d’encre grand public se situe aux alentours des 300pixel par pouce. A 96px /P les pixels sont carrément visible a l’oeil nu (d’ailleurs pour les Qr-code on utilise déjà du 96px/P quand on veut stocker beaucoup de données). Après un petit calcul, j’ai conclu que si on imprimait toute la surface d’une page A4 (794 x 1123px a 96px/P) et en éliminant 1 cm de bord (ce qui nous laisse 719 x 1053px).

On atteint un total de 757.107 Pixels, soit un espace de stockage de 757 ko par page, multiplié par 2 ça nous donne 1,514 Mo par feuille, c’est a dire un peut plus q’une disquette 3.5 pouce.

Biensur a ce niveau on peut se poser quelques questions, la première c’est est ce qu’on imprimant a 96px/P les pixels peuvent être facilement reconnu lors du scan. La réponse est sans hésitation oui, puisque même les scanners d’entré de gamme se situent aux alentours de 2400ppp (c’est vrai que la on parle de Point par pouce et non pas de pixel par pouce, mais de toutes façon ça reste largement suffisant pour bien distinguer chaque pixel), et comme je vous l’ai déjà dis les pixels restent visible même a l’oeil nu, donc de ce coté la pas de problème.

Ensuite le deuxième obstacle qui se pose, c’est la diversité des imprimantes et des scanners, ce n’est pas toujours certain que les couleurs soient représentées de la même façon, même si sur les 65.000 teintes (prises en charge par les produits grand publics), on se limitant a 256 couleurs on est plus au moins sûr qu’elle soit assez éloigné pour éviter toute confusion.

On peut de ce fait imaginer que dans certains cas, les couleurs ne soient pas reconnues de la même façon. Pour cela la solution est simple, on va réserver quelques pixels dans un coin de la page, qui serviront de repère pour le logiciel (512px suffiront a raison de 2pixels par couleur + éventuellement une barre noire pour les séparer des autres pixels, soit un peut plus de 768px en tout). On lui dira par exemple qu’en cas de doute, de se référer à la palette imprimée dans le coin nord ouest de la page, il aura ainsi toutes les couleurs qui se suivent dans l’ordre prédéfini, chaque emplacement correspondant a un état de l’octet.

Après avoir résolu le problème de couleur, il nous reste un dernier petit détail inhérent à la qualité du papier et de l’encre utilisée. En effet il se peut, que quelques pixels s’altèrent, s’effacent ou se fondent une fois la feuille pliée ou manipulé à plusieurs reprises. Pour cela on peut réserver (tout comme pour le Qr-code) entre 7% et 30% de la surface de la feuille pour intégrer un système de récupération. Voir carrément 50% de la surface, ce qui équivaut a réimprimé 2 fois la même chose. Moins de risques de voir 2 fois le même pixel perdu.
Voila grosso modo l’idée, biensur on peut l’améliorer ont utilisant une plus grande palette de couleur et un plus gros taux de pixels par pouce (150px/pouce par exemple) on peut ainsi facilement atteindre plusieurs mégaoctets. Par contre niveau fiabilité ça devient un peu aléatoire, il faudrait sûrement faire quelques essaies pour voir ce qu’on peut vraiment en tiré. Mais de toute façon 700 ou 500ko par face, c’est déjà pas si mal.
Les utilisations potentielles d’un tel concept, sont nombreuses, on peut y stocker plusieurs images jpg, des petits logiciels des documents word, powepoint html… ça peut facilement remplacer une disquette.
Mais c’est surtout le coté ludique et au niveau Marketing que ça devient intéressant, imaginez par exemple des petites cartes distribuées ou trouvées dans des paquets de corn flakes, contenants des avatars, des sonneries, des fonds d’écrans, des minis jeux… (Pour ça 50 ou 70 ko sont largement suffisant) qu’on peut récupéré comme par magie, simplement en les scannant et en les passant sur un mini programme téléchargé sur le site de l'annonceur.

(Avec un peu d’imagination on peut trouver plein d’autres utilisations )

Souvenez vous aussi du super jeux 3D que j’avais présenté y’a quelques temps, qui tiens dans à peine 96 ko, (A ce sujet je vous prépare un article, avec un petit tour d’horizons des pros de la compression, certains arrivent par exemple a stocker l’équivalent d’un album électro, ou d’un clip de 6 minutes tout en 3D, dans pas plus de 64ko).

Pour finir, je pense qu’un tel logiciel serrait assez simple à programmer, (avis aux intéressés), on pourrait imaginer qu’à sa sortie on tombe sur des articles avec comme titre « Transportez un mega jeux 3D, en l’imprimant sur un quart de page » ou encore « Utilisez votre imprimante pour stocker des données » Un petit exemple de carte :)

Update 1:
 

Ca pourrait aussi relancer l’attrait pour les collections de cartes. Je me souviens quand j’était plus jeunes on s’échangeait, on gagnait, on troquait plusieurs cartes contre une. Selon les périodes c’était des joueurs de foot, des personnages de manga, des Pogs... Comme la nouvelle génération est « Hypertechno », je pense que ça les intéresserait d’avoir des cartes contenant des avatars, des mini-jeux – des skins – des petites animations

On peut aussi imaginer, l’apport que ça pourrait donner aux jeux de cartes tel que Magic, ça permettrait d’avoir une forte interactivité entre le jeu de table et sa version jeu video, on pourrait ainsi importer les caractéristiques de la carte réel, dans le jeu Pc.

Imaginons aussi qu’un opérateur l’adopte pour ses cartes de recharge, on aurait ainsi au dos de la carte une partie contenant, des sonneries, des fonds d’écran, des animations

Supposons encore qu’un jeu de voiture intègre un système permettant de créer automatiquement de nouveaux véhicules. En lui fournissant simplement les données relatives, au moteur, aux suspensions, aux formes de la carrosserie, accessoires...

Voici un exemple d'insertion presse, en double pages.
 

Comments

[CHRISTIAN]

Salut,
Je consultais avec intérêt l'ensemble de ton site lorsque je suis tombé sur ton article.
Voilà je pense que ce que tu as développé est très proches d'un système breveté par une société en suisse.
En effet, tu dois savoir que tous le monde de passeport avec biométrie (c'est mon métier). Aujourd'hui tout le monde parle de la puce sans contact afin de stocker les informations qui permettront la biométrie. Cette puce sera au minimum de 32KO afin de pouvoir y stockr au minimum la photo jpeg2000 du titulaire.
Cepandant, personne ne parle de BACKUP de la puce, en clair que se passe t il si la puce ne fonctionne pas? cette société suisse a donc pensé à faire ce qu'elle appelle un code barre 2D en couleurs qui permet de stocker des informations.

[papygourbi]

Bonjour, je suis l'actualité du site depuis un bon moment déja. Je suis programmeur en .net et je pense que tout cela est réalisable. Contactes moi sur mon msn.

[Seifko]

comment le penses-tu Benm?

[Benm]

Dans ce cas la, il faut que je reparle a mon oncle, il se peut qu'il m'est mal compris.
Encore une fois merci pitouthestar.

En effet Seifko, comme j'ai dis dans un post précédent, si jammais ca se complique j'ai d'autres idées. Dont la plus radicale serait de n'utiliser que 8 couleurs, mais pas tout a fais comme tu le pense. (c'est un peut long a expliquer, mais dés que j'abouti à quelque chose j'en reparlerai):0059:

[pitouthestar]

benm : de rien, j'adore ton site et c'est avec plaisir que je discute de tes idées ;)
j'ai demandé dans la boite ou je bosse : imprimer seulement en pantone est impossible...dans certains cas le max qu'on ai vu est une 10aine de pantones : en effet, il faut un rouleau d'impression pour chaque pantone, sachant que ces machines font deja plusieurs metres carrés avec CMJN seulement, imagine celles capables de produire une impression de 5 ou 6 pantones !!!
++ et a bientot