Discussion :

[dranakan]

Hello,

Je désire compresser une courte chaîne d'information (pour générer un code-barres de petite taille). En m'aidant de java.util.zip, je m'aperçois que la chaine compressée est plus grande que la taille originale (ce qui est normale avec les données que je donne et l'algorithme utilisé).

Voici un exemple de chaîne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<S>fi=3452355&re=aadjek&ty=df&nb=1000343</S>

Y-t-il un autre algorithme/API à utiliser pour réduire la taille de cette chaîne ?

Je me suis aider de ce code pour effectuer la compression : http://softwaredevscott.spaces.live....F3B7!299.entry

Merci bien.

[tchize_]

ce n'est pas possible car
-> pour un code barre, tu est limité dans le nombre d'octets utilisable (obligé de prendre de l'ascii en général
-> Une courte chaine ne présente aucune redondance pouvant servir à la compression

[dranakan]

Merci bien

[thelvin]

Bah, au fond... Si le <S> de début et le </S> de fin sont toujours là, il est inutile de les mettre dans la forme compressée. Tu n'as qu'à les remettre à la décompression.

Si les paramètres sont toujours fi, re, ty et nb, dans cet ordre, tu peux virer cette information.

Ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

3452355&aadjek&df&1000343

Les nombres peuvent être écrits en hexadécimal ou en base64 pour gagner de la place.

[adiGuba]

Salut,


Si tes différents champs ont une limite de taille bien précise, on pourrait même aller plus loin dans la proposition de thelvin en supprimant les & et en mettant chaque champs sur un nombre fixe de caractère.

a++

[Jimmy_]

Oui c'est possible il faut utiliser une compression statistique de Huffman avec une table fixe calculée une fois pour toute. Ce qui te permet de la stocker sans la faire transiter.
Les caractères revenant le plus souvent sont compressés sur quelques bits (3 ou 4), les autres sur plus.

Zip sauve un dictionnaire pour décompresser ce qui le rend inutile pour des fichiers petits.

[tchize_]

jimmy: tu va te retrouver avec du pur binaire, autrement dit une information qu'on ne peux sotkcer dans un code barre. A l'arrivée il devra convertir ses nombres 8 bits en un ensemble de données acceptable par le truchement, par exemple, de base64, ce qui au final refera grandir l'élément de 1/3 de la taille compressée. Vu le style de donnée, je suis dubitatif quand à
-> la présence de données récurrentes
-> l'utilité de tout ce bordel pour peut être gagner 5%

[dranakan]

Merci pour vos conseils.

Les valeurs du style "re" correspondent à un argument. Il pourrait être différent, c'est pourquoi on doit le garder. Les tailles ne sont pas fixes. Si possible, j'aimerais ne pas devoir changer la structure de ce string (mise à part une compression ou autre).

Je vous expose le processus complet... Peut-être trouvera-t-on une autre idée pour améliorer ceci...

Le but : Avoir un code-barre le plus petit possible car il devra être imprimé sur des documents destinés à des clients.

1) Exemple : Valeur du code barre (pire des cas) (dans la réalité, les chiffres ou les lettres ne se suivront pas)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<S>fi=1234567891234&re=abcdefghijklmnopqrstuvwxyzabcdef&ty=ddf&nb=fi=1234567891234</S>

2) Génération d'un code-barres (avec zxing, type QRCode )
3) Insertion du code-barres sur un document
4) Impression (en papier)... le document part chez le client et revient
5) Scannage du document (matériel standard (200 DPI))
6) Découpage du PDF pour isolé le code-barre (avec API itext) cela permettra de demander moins de ressource à la prochaine étape
7) Conversion du morceau de PDF en image (avec convert de ImageMagick) (cela permettra d'être plus efficace (améliorer la lisibilité) pour la prochaine étape)
8) Lecture du code-barre (avec Zbar)

[tchize_]

solution alternative: tu prend un code QR, qui non seulement permet de stocker beaucoup plus d'information mais présente aussi les avantages suivants
-> support unicode
-> Standard existe pour y stocker des url
-> identifiable automatiquement sur un document par zxing, sans nécessité de découpage (j'ai fait des tests ici, par curiosité, pour d'autres besoins)
-> supporte la dégradation (papier griffé, déchirure, etc) théoriquement jusqu'à 30%

exemple: lien vers cette page:


la version "code barre" d'un lien beaucoup plus court:

[dranakan]

J'utilise un QRCode (j'ai ajouté cette info qui manquait à mon post).

Le découpage n'est pas nécessaire mais il permet de diminuer le temps CPU lors de la conversion en GIF (qui permet d'améliorer la reconnaissance du code-barre) (en tout cas avec Zbar).

[adiGuba]

Ben avec un QRCode tu n'a pas besoin de compresser le texte !!!
Pour ton dernier exemple ca donne ceci :

(via le générateur online de zxing)


a++

[tchize_]

Je décode l'image attachée en moins d'une seconde avec le décodeur en ligne de zxing. Par rapport au temps nécessaire à l'opérateur pour aller sélectionner le code, je suis pas sur qu'il y aie quelque chose à gagner....
J'ai l'impression que tu te gratte la tête pour essayer de gagner du temps là où il n'y a pas grand chose à gagner....

[dranakan]

Merci de votre intérêt.

La compression n'est pas pour que cela fonctionne mais pour obtenir un code-barre le moins détaillé possible pour qu'il soit facilement lu.

Plus il y a d'informations dans le code-barres, plus il devient "précis" (les dessins sont plus petits).

Je recherche à obtenir un code-barre le moins détaillé possible pour pouvoir réduire sa taille au maximum sur le document à imprimer.

[dranakan]

J'ai l'impression que tu te gratte la tête pour essayer de gagner du temps là où il n'y a pas grand chose à gagner....

Le décodage se passe très bien si on prend un image depuis l'ordinateur, je suis d'accord.

Cependant, si le code-barre est imprimé (disons avec une taillle 1 cm sur 1cm) et puis scanné en une résolution standard (200 DPI) il devient plus difficile au décodeur de faire son travail.

[tchize_]

pour une même taille de points, la différence entre les données "complètes" et les données hypothétiquement compressée d'un facteur 30% qu'on a utilisé plus haut, ca va être de l'ordre de 2 à 4mm sur le dessin final pour une même taille de points (en prenant un code utilisant un point de 0.5mm à 1 mm). Ca vaut vraiment le coup de se casser la tête pour réduire une image de 29mm à 25mm (si un point = 1mm)?

[dranakan]

Mon but est d'obtenir un code-barres de 1 cm sur 1 cm (ou moins).

J'essaie d'explorer le plus de voies possible pour y arriver.... d'après vos conseils, une simple compression ne va pas pouvoir m'aider pour ceci...

Merci

[tchize_]

Maintenant un bon "truc" si tu utilise un scanner PDF, c'est de ne pas passer par des outils comme imagemagick ou pdf2ppm, car ceux-ci vont faire le "rendu" de chaque page suivant les règle PDF. Tu aura, souvent, un meilleur résultat en utilisant un outils comme pdfimages qui va ouvrir le pdf et extraire les images qui sont dedans sans y toucher. Avantage: elle sont telle que le scanner les a vue, et non pas telle qu'un outils PDF les afficherais. ci joint le même code QR issu du même PDF issu d'un scan unique à 200DPI N&B, l'un convertit en image par pdfimages, l'autre par pdf2ppm

L'un est décodabe, l'autre non...

La seule compression valable que je verrais serait d'attribuer une numéro unique à ta chaine, de la stocker dans une DB et de n'encoder que ce numéro dans le code. Mais ca nécessite que le client aie accès à la db en question...

[dranakan]

Je vais regarder ceci. Merci bien :-)