Gatsu a écritc-cube a écritLe lien vers Wikipedia que tu donnes indique notamment ceci :
Overall, the algorithm used by JBIG2 to compress text is very similar to the JB2 compression scheme used in the DjVu file format for coding binary images.
PDF files versions 1.4 and above may contain JBIG2 compressed data.
Comme « very similar » ne veut pas dire identique, doit on en conclure que DjVu est affecté par le problème qui concerne JBIG2 alors que c'est JB2 (autrement connu sous le nom de DjVuBitonal) qui est utilisé ?
Je n'ai rien trouvé qui indique que DjVu pose les mêmes soucis que les programmes utilisant JBIG2, mais je suis bien sûr preneur de tout lien à ce sujet.
Je vais quand même essayer de reproduire cet artefact du 6 changé en 8 avec DjVu pour voir.
Désolé, je n'ai que celui déjà posté plus haut. Je vois qu'il y a d'autres liens sur la page wikipedia, mais ils semblent tous se reporter à celui que j'ai donné.
Pour « very similar », je suppose qu'il se base sur le même principe pour comprimer le texte (sans toutefois utiliser des algorithmes de reconnaissance rigoureusement identiques) : vérifier toutes les zones de texte, scanner toutes les lettres une par une et remplacer toutes celles qui se ressemblent le plus par une image unique. Et c'est sur ce principe là que je trouve la compression JBIG2 plutôt mal fichue. Autant un scan au format image TIF ou BMP, s'il y a un doute sur un chiffre ou autre à cause d'un floutage trop prononcé, on situe tout de suite le problème sur la page, au pire on redemande une copie en meilleure qualité. Avec JBIG2, c'est la machine qui choisit l'une ou l'autre version du chiffre en cause, et on est incapable de détecter la corruption du document après coup.
Oui, la méthode est effectivement problématique car une mauvaise substitution de caractères ressemblants est plus difficilement détectable qu'avec d'autres procédés. Quoi que quand je vois ce que ça donne avec JPEG, j'ai de sérieux doutes (cf. mon lien plus bas).
Après j'ignore si le problème est rigoureusement le même avec la méthode JB2 propre à DjVu qui est peut-être légèrement plus efficace.
Gatsu a écrit
c-cube a écritPar contre, on pourra remarquer qu'il est précisé que JBIG2 est utilisé par certains programmes générant du PDF. Pour moi c'est plutôt une raison supplémentaire de fuir le PDF lorsque je peux utiliser DjVu à la place. D'autant plus que DjVu est nettement plus performant sur certains contenus.
Attention, je dis pas que PDF c'est la panacée, je soulevais juste un problème que je trouve important concernant le format DjVu et sa méthode de compression après avoir lu la page wikipedia.
Oui mais comme tu parlais de fuir le format DjVu pour cette raison, je dois dire qu'à la lecture attentive de la page wiki dont tu parles j'ai un peu tiqué, car en fait le problème se pose aussi avec PDF.
Gatsu a écrit
c-cube a écritSinon, rien à voir non plus mais je viens de faire des tests avec le format DjVu et l'utilitaire cjb2 (encodeur en ligne de commande utilisant DjVuBitonal, donc JB2).
J'ai transformé une image TIFF comportant des 6 et des 8 de plus en plus petits (de police taille 14 jusqu'à police de taille 6) en un fichier DjVu.
Non seulement le problème soulevé pour la méthode JBIG2 ne se reproduit pas avec JB2 (mon fichier DjVu était correct et sans artefacts, même sur les très petits chiffres, alors même qu'il était 3 fois plus léger que le TIFF équivalent), mais j'ai par contre pu m'apercevoir que ce même problème survient avec du JPEG ! En scannant en JPEG, avec une résolution de 200 dpi, j'ai bien un 6 qui s'est transformé en 8.
Autrement dit, un matériel qui scanne en JPEG aura exactement le même problème qu'avec JBIG2 et rien ne prouve par contre que DjVu soit pire que PDF par rapport à ce problème, bien au contraire même.
Alors là tu m'en bouche un coin ! t'aurais un échantillon à poster ?
Sur cette page, ils disent explicitement que tout dépend de la police utilisée, certaines étant pire que d'autres. Ils citent notamment arial et helvetica.
>
http://fontfeed.com/archives/xerox-scanners%E2%80%8A%E2%80%8Aphotocopiers-randomly-alter-numbers/
Oui j'ai un échantillon :
Lien fichier JPEG.
La transformation du 6 en 8 se manifeste à la fin de la dernière ligne.
Je ne connais pas d'endroit où héberger gratuitement et rapidement mon fichier TIFF et mon fichier DjVu issu du TIFF, mais ça n'a pas d'importance. Tu peux les reproduire toi-même.
Il suffit pour cela de taper les chiffres en police FreeSans dans LibreOffice Writer (première ligne en taille 14, ligne suivante en 12, etc. jusqu'à la taille 6).
Ensuite tu l'imprimes puis tu le scannes en TIFF.
Sous Ubuntu, tu n'as plus alors qu'à installer le paquet djvulibre-bin puis utiliser la commande suivante :
cjb2 scan.tif scan.djv
Tu constateras alors que tu obtiens bien un fichier moins volumineux mais très peu différent du TIFF d'origine et que l'artefact du 6 changé en 8 n'apparaît pas.
Sinon, pour revenir au sujet du topic, je me suis amusé à utiliser l'utilitaire en ligne de commande
pdf2djvu sur le fichier d'origine (plan du métro en PDF). La commande de base, sans autres options que le fichier de sortie, est toute simple :
pdf2djvu -o metro_geo.djv metro_geo.pdf
Cela prend environ une petite minute à encoder. On obtient alors un fichier DjVu de 2,4 Mo, lequel est donc plus volumineux que le PDF original, ce qui est normal puisque la conversion produit du bitmap.
Mais l'avantage c'est que le fichier DjVu s'ouvre en à peine 5 à 10 secondes avec Evince et en tout juste 3 ou 4 secondes avec l'utilitaire DjView4 qui permet notamment un niveau de zoom plus élevé et une navigation dans l'image à la souris. Le tout restant parfaitement lisible et fluide.
Conclusion : si vous avez un plan PDF imbuvable, car farci de vectoriel, énorme et qui flanque la fièvre à votre processeur, la conversion en DjVu me semble un remède intéressant.
Merci GNU/Linux. Merci la ligne de commande. 🙂
PS :
Spécial dédicace pour ares. Et
ici aussi. 😉
