Images, compression et pdf

[geo cherchetout]

Bonsoir,

Je reviens vous embêter avec mes histoires de pdf d'amateur parce que ce
groupe me semble être le plus adapté, si je me trompe merci de m'aiguiller
ailleurs.

Nous avons vu récemment comment obtenir qu'Adobe Acrobat 9 pro extended,
utilisé pour « océriser » un document, délivre en sortie un document pdf
dont la taille ne dépasse pas environ 104 % de celle du pdf pris en entrée,
sans que les images contenues dans ce dernier subissent la moindre
dégradation. Je rappelle que ces images sont initialement en niveaux de gris
indexés, enregistrées en png puis archivées en pdf à l'aide de pdfLaTeX.

C'est très satisfaisant du point de vue volume mais le couteau suisse
Acrobat n'est pas le champion de l'OCR.
ABBYY FineReader 9 fait mieux, je peux éventuellement dire en quoi, mais le
pdf qu'il produit dans les mêmes conditions est énorme. Sa taille atteint en
effet quelque 130 % de celle de l'original. L'option conduisant à ce
résultat comporte pourtant l'utilisation de l'algorithme LZW, proche parent
du LZ77 employé pour la compression en png. (Sauf erreur car c'est une
science nouvelle pour moi.) FlateEncode n'est pas proposé et aucune des
autres options ne convient mieux. (ZIP, JPEG, CCITT, etc.)

On peut dégraisser les pdf de FineReader en les faisant digérer par Acrobat,
ce dernier offrant une option de conversion LZW -> Flate, mais je ne suis
pas encore satisfait car la taille est encore de 112 % de l'original.

À force de fouiller les pdf à l'éditeur hexadécimal, je crois avoir compris
que cet embonpoint irréductible serait du au fait que les images contenues
ne seraient plus en niveaux de gris *indexés*.

Cette explication est-elle sensée ? Si oui, comment arranger ça sans perdre
le bénéfice de l'OCR ?

J'ai essayé avec ghostscript et son device pdfwrite mais n'ai pas encore
trouvé la bonne commande. Est-ce une voie sans issue ? Je préférerais le
savoir...

[Tardigradus]

Post by geo cherchetout
À force de fouiller les pdf à l'éditeur hexadécimal, je crois avoir compris
que cet embonpoint irréductible serait du au fait que les images contenues
ne seraient plus en niveaux de gris *indexés*.

Qu'appelles-tu des niveaux de gris indexés ? Chez Adobe, et d'autres
(tout le monde ?), un niveau de gris est codé sur 8 bits, ce qui
autorise jusqu'à 256 nuances différentes, limite opérationnelle du
Postscript.
À part ça, j'vois pas.

[geo cherchetout]

Post by Tardigradus
Qu'appelles-tu des niveaux de gris indexés ? Chez Adobe, et d'autres
(tout le monde ?), un niveau de gris est codé sur 8 bits, ce qui
autorise jusqu'à 256 nuances différentes, limite opérationnelle du
Postscript.
À part ça, j'vois pas.

Je ne sais pas exactement ce que cela signifie mais je veux bien qu'on
m'explique.
Dans Gimp je peux enregistrer une image simplement en niveaux de gris ce qui
donne un fichier png d'une certaine taille. Quand il s'agit d'une page de
texte scannée, je ramène généralement le nombre de niveaux à 16, ce qui
donne un fichier nettement moins gros sans perte de qualité sensible. Enfin
si je choisis l'option « Mode indexé », le fichier est encore moins gros
sans dégradation supplémentaire. (C'est réversible.)
Peut-être le fait que cela ne change rien à l'impression expliquerait-il que
postscript ignore cette notion ?

[geo cherchetout]

Post by Tardigradus
Qu'appelles-tu des niveaux de gris indexés ? Chez Adobe, et d'autres
(tout le monde ?), un niveau de gris est codé sur 8 bits, ce qui
autorise jusqu'à 256 nuances différentes, limite opérationnelle du
Postscript.
À part ça, j'vois pas.

Une ébauche d'explication ici :
http://docs.gimp.org/fr/gimp-images-in.html

[geo cherchetout]

Post by Tardigradus
Qu'appelles-tu des niveaux de gris indexés ? Chez Adobe, et d'autres
(tout le monde ?), un niveau de gris est codé sur 8 bits, ce qui
autorise jusqu'à 256 nuances différentes, limite opérationnelle du
Postscript.
À part ça, j'vois pas.

Dans le corps des pdf sans matière grasse (PDF-1.3.1) que produit pdfLaTeX à
partir de mes images png, celles ci sont encadrées d'informations comme les
suivantes, que je recopie à la main :

obj << /Filter /FlateDecode /Length 537544 /ColorSpace [ /Indexed / Device
RGB 84 8 0 R ] DecodeParms << BitsPerComponent 8 /Predictor 10 /Colors 1
/Columns 1624 >> /Type /XObject /BitsPerComponent 8 /Height 2312 /Width 1624
/Subtype /Image >> stream ... ... ... endstream endobj

Où l'on voit bien que le pdf connaît cette notion de couleurs indexées. Si
postscript l'ignore, cela implique-t-il que je n'ai aucune chance d'arriver
à mes fins avec ghostscript ? Je n'ai pas trouvé de réponse dans la
documentation de ghostscript, ni personne d'autre pour m'expliquer.

[Tardigradus]

Post by geo cherchetout
Où l'on voit bien que le pdf connaît cette notion de couleurs indexées.

Ah mais attention, nuance. Une couleur indexée, je sais ce que c'est.
C'est le gris indexé que j'ignore. Chez Adobe, une couleur indexée,
c'est une couleur 8 bits, appartenant à une palette qui peut être
constituée de différentes manières. Par exemple : standard PC, standard
Mac, ou encore limitée aux seules couleurs existant dans la photo RVB
d'origine, par exemple.
Si ça se trouve, un gris indexé, c'est ça : une gamme de gris limitée
aux gris existant réellement dans la photo en niveaux de gris 8 bits
d'origine...

[geo cherchetout]

Post by Tardigradus
Ah mais attention, nuance. Une couleur indexée, je sais ce que c'est.

Je m'en doutais bien.

Post by Tardigradus
C'est le gris indexé que j'ignore. Chez Adobe, une couleur indexée,
c'est une couleur 8 bits, appartenant à une palette qui peut être
constituée de différentes manières. Par exemple : standard PC, standard
Mac, ou encore limitée aux seules couleurs existant dans la photo RVB
d'origine, par exemple.
Si ça se trouve, un gris indexé, c'est ça : une gamme de gris limitée
aux gris existant réellement dans la photo en niveaux de gris 8 bits
d'origine...

L'expression « gris indexé » est de moi. Je ne savais comment dire autrement
qu'il s'agissait d'images en niveaux de gris enregistrées en mode indexé.
Comment Gimp constitue-t-il son index ? Il me donne le choix entre :

1)- Générer une palette optimale.
2)- Limiter le nombre maximal de couleurs à une valeur comprise entre 2 et
256 (au total ou par composante, ce n'est pas précisé).
3)- Utiliser une palette optimisée pour le web.
4)- Utiliser la palette noir & blanc.
5)- Utiliser une palette personnalisée.

Comme j'ai déjà fixé (à 16 le plus souvent, mais parfois plus) le nombre de
niveaux de gris de mon image, le choix 1 ne change strictement rien au
contenu de l'image. La taille du fichier est seulement plus petite. Il
apparaît donc que Gimp procède alors comme tu le supposes : Il met dans son
index les seuls niveaux de gris présents dans l'image.

[Tardigradus]

Post by geo cherchetout
1)- Générer une palette optimale.

C'est-à-dire utiliser les gris déjà présents dans l'image d'origine

Post by geo cherchetout
2)- Limiter le nombre maximal de couleurs à une valeur comprise entre 2 et
256 (au total ou par composante, ce n'est pas précisé).

Quelles composantes ? Si l'image est en couleurs, elle est convertie en
niveaux de gris, c'est-à-dique qu'elle passe de trois canaux (ou couches
ou Dieu sait comment Gimp appelle ça), un pour chaque couleur, à un
seul, pour gérer les niveaux de luminosité, donc de gris.

En fait, on peut donc réduire le nombre de gris à un niveau inférieur à
256, c'set ça qu'il faut comprendre, au cas ou l'utilisation de toute la
gamme ne serait pas pertinente; ça permet de ne les coder sur moins de
bits que 8, mais le gain ne m'apparaît pas formidable, sauf 4 bits, qui
divise le poids par 2 mais qui ne permet que 16 niveaux de gris. On y
perd plus qu'on n'y gagne, je pense...

Post by geo cherchetout
3)- Utiliser une palette optimisée pour le web.

POur les couleurs, je vois, pour le gris, pas du tout, mais je ne suis
pas spécialiste du web.

Post by geo cherchetout
4)- Utiliser la palette noir & blanc.

Donc un seul bit, soit deux possiblités, noir ou blanc. Dans ce cas, les
gris sont simulés en mélangeant les pixels noirs et blancs, tout comme
on le fait sur papier, en mettant des points d'encre noire sur du papier
blanc. C'est la solution la plus légère mais la moins bonne en qualité,
évidemment. Tout se paie.

Post by geo cherchetout
5)- Utiliser une palette personnalisée.

À créer soi-même, en n'y mettant que les gris que l'on veut. Cas très
particulier, compliqué et chiant.

[geo cherchetout]

Post by Tardigradus

Post by geo cherchetout
1)- Générer une palette optimale.

C'est-à-dire utiliser les gris déjà présents dans l'image d'origine

Post by geo cherchetout
2)- Limiter le nombre maximal de couleurs à une valeur comprise entre 2 et
256 (au total ou par composante, ce n'est pas précisé).

Quelles composantes ? Si l'image est en couleurs, elle est convertie en
niveaux de gris, c'est-à-dique qu'elle passe de trois canaux (ou couches
ou Dieu sait comment Gimp appelle ça), un pour chaque couleur, à un
seul, pour gérer les niveaux de luminosité, donc de gris.

Dans Gimp, on choisit d'abord entre les modes RVB, Niveaux de gris et
Couleurs indexées. On peut par exemple ouvrir une image précédemment
enregistrée en niveaux de gris et la transformer en Couleurs indexées, avec
les quelques options déjà citées. C'est équivalent à ce que je fais. Si je
fais la même chose avec une image en couleurs, elle reste en couleurs mais
ce n'est pas beau à voir.

Mais je regrette d'avoir présenté mon exposé sous forme de question.
Satisfait du travail de Gimp, je n'ai pas besoin de savoir au juste comment
il opère. Mon souci est de redonner aux images incluses dans un document pdf
ce caractère « Indexé » qu'elles ont perdu et je ne compte pas sur Gimp pour
le faire. Gimp n'est pdfologue-obstétricien.

Post by Tardigradus
En fait, on peut donc réduire le nombre de gris à un niveau inférieur à
256, c'set ça qu'il faut comprendre, au cas ou l'utilisation de toute la
gamme ne serait pas pertinente; ça permet de ne les coder sur moins de
bits que 8, mais le gain ne m'apparaît pas formidable, sauf 4 bits, qui
divise le poids par 2 mais qui ne permet que 16 niveaux de gris. On y
perd plus qu'on n'y gagne, je pense...

J'exploite plus finement ces possibilités. Par exemple, dans une même page,
je réduis à 16 le nombre de niveaux de gris du texte, à 31 ou 61 certaines
illustrations, à 121 certaines autres. Crois-moi, tout cela conduit à des
fichiers de taille minimale pour le niveau de qualité voulu.

Pour ceux que cela intéresserait, les 16 niveaux de gris sont équidistants
sur une échelle linéaire allant de 0 à 256. Même règle quelque soit le
nombre. Ainsi, quand je ramène une zone d'une image à 31 niveaux, je
n'ajoute que 15 niveaux aux 16 qui suffiront aux zones de texte, et non 31
nouveaux niveaux. Un octet est un octet. ;-)

[Tardigradus]

Post by geo cherchetout
Par exemple, dans une même page,
je réduis à 16 le nombre de niveaux de gris du texte,

Heu, le texte ? Voilà autre chose. Normalement, le texte en en noir,
donc il n'y a aucunement besoin de réduire son information couleur.

[geo cherchetout]

Post by Tardigradus

Post by geo cherchetout
Par exemple, dans une même page,
je réduis à 16 le nombre de niveaux de gris du texte,

Heu, le texte ? Voilà autre chose. Normalement, le texte en en noir,
donc il n'y a aucunement besoin de réduire son information couleur.

Décidément, c'est dur de se comprendre. Dans mes pages de revue scannées, il
y a beaucoup de texte. C'est de ces images de texte que je voulais parler.

Pour le reste, je crois que je tiens une piste : Passer en option à
Ghostscript le chemin d'un fichier joboptions adéquat. L'épilogue est
proche, j'espère.

[Anne G]

Post by geo cherchetout

Post by Tardigradus

Post by geo cherchetout
Par exemple, dans une même page,
je réduis à 16 le nombre de niveaux de gris du texte,

Heu, le texte ? Voilà autre chose. Normalement, le texte en en noir,
donc il n'y a aucunement besoin de réduire son information couleur.

Décidément, c'est dur de se comprendre. Dans mes pages de revue
scannées, il y a beaucoup de texte. C'est de ces images de texte que je
voulais parler.

Mais ne parliez-vous pas d'OCR ?

Post by geo cherchetout
Pour le reste, je crois que je tiens une piste : Passer en option à
Ghostscript le chemin d'un fichier joboptions adéquat. L'épilogue est
proche, j'espère.

[geo cherchetout]

Post by Anne G

Post by geo cherchetout
Décidément, c'est dur de se comprendre. Dans mes pages de revue
scannées, il y a beaucoup de texte. C'est de ces images de texte que je
voulais parler.

Mais ne parliez-vous pas d'OCR ?

Oui, mais je tiens à ce que soit affichée l'image elle-même de la page
scannée, le texte reconnu n'étant pas visible. Dans le pdf océrisé, ce texte
est sous-jacent. On peut le sélectionner avec la souris où y rechercher des
mots mais on ne le voit pas. J'ignore s'il a une couleur, mais une fonte lui
est attribuée. (Plusieurs si besoin.) Ce n'est peut-être pas ce qui se
pratique le plus souvent...

[geo cherchetout]

Post by geo cherchetout
Pour le reste, je crois que je tiens une piste : Passer en option à
Ghostscript le chemin d'un fichier joboptions adéquat. L'épilogue est
proche, j'espère.

Mais je n'ai pas réussi avec Ghostscript et son « device » pdfwrite. Je
parviens à lui dicter différents modes de compression mais mes images en
sortie ne retrouvent jamais leur caractère indexé si avantageux.

Faute de médecine douce adéquate, j'ai donc du recourir à la chirurgie.
L'opération consistait à remplacer purement et simplement dans le pdf
océrisé les objets images par ceux extraits du pdf original. Dans le cas
d'images en mode indexé, l'objet image doit naturellement être accompagné de
son objet index associé. Le plus difficile est ensuite de rétablir les
connexions mais quelques outils bien employés facilitent grandement la
tâche. Comme souvent, c'est plus facile à faire qu'à expliquer. Outre
l'éditeur hexadécimal, voici les quelques commandes que j'ai utilisées :

- Pour tronçonner un document pdf en pages :

$ pdftk document.pdf burst

- Pour décomposer une page en ses objets constitutifs :

$ csplit -z -n 3 page.pdf "/ obj/" {*}

Les fichiers produits sont par défaut nommés xx000, xx111, etc.

- Pour obtenir la liste de ces fichiers avec leur taille et, surtout, leur
numéro d'objet contenu dans les premiers octets :

$ for i in xx*; do head -c 3 $i; ls -g -G $i; done

- Pour réparer sans efforts la table de références d'un document pdf :

$ pdftk document-corrompu.pdf output document-répéré.pdf

Je signale que pdftk n'est pas réservé aux utilisateurs de GNU/Linux, il
existe notamment des versions pour Windows et FreeBSD et certains
l'utilisent même sous MAC OS X.

http://www.pdfhacks.com/pdftk/

Si quelqu'un est intéressé, je fournirai avec plaisir plus de détails sur
cette aventure qui finit bien.

[Tardigradus]

Post by geo cherchetout
Si quelqu'un est intéressé, je fournirai avec plaisir plus de détails sur
cette aventure qui finit bien.

Tu fournis l'aspirine avec ?

[geo cherchetout]

Post by Tardigradus

Post by geo cherchetout
Si quelqu'un est intéressé, je fournirai avec plaisir plus de détails sur
cette aventure qui finit bien.

Tu fournis l'aspirine avec ?

Bonne question ! Non, désolé, je n'en possède pas parce que je n'en ai pas
besoin. :-)

[Laurent S.]

Au sujet de son exploitation du logiciel libre "pdftk"

Si quelqu'un est int'eress'e, je fournirai avec plaisir plus de d'etails sur
cette aventure qui finit bien.

L'amélioration de fichiers PDF est une activit'e importante; je suis tr`es
enthousiaste pour suivre les détails de cette aventure réussie !

Laurent S., CNRS

[Anne G]

Post by Laurent S.
Au sujet de son exploitation du logiciel libre "pdftk"

Si quelqu'un est int'eress'e, je fournirai avec plaisir plus de d'etails sur
cette aventure qui finit bien.

L'amélioration de fichiers PDF est une activit'e importante; je suis tr`es
enthousiaste pour suivre les détails de cette aventure réussie !
Laurent S., CNRS

Je n'arrive toujours pas à comprendre comment un document PDF peut
contenir des images indexées...
Ni surtout quel en est l'intérêt.

Mais bon.

[geo cherchetout]

Post by Anne G
Je n'arrive toujours pas à comprendre comment un document PDF peut
contenir des images indexées...

J'ai découvert cette possibilité quand j'ai confié à pdfLaTeX la mission de
réunir sous forme de documents pdf mes images indexées. Auparavant, je ne
produisais pas ce genre d'images et ne m'étais donc pas posé la question,
mais c'est déjà prévu dans les spécifications du pdf 1.3, et peut-être avant.
Dans le pdf produit, l'image et son index sont séparés en deux objets
distincts. L'objet image contient l'ID de son objet index associé qui permet
au lecteur d'interpréter l'image correctement. En l'absence de cet index, le
lecteur affiche une page blanche. (Dans laquelle je peux néanmoins, dans mon
cas de pages scannées océrisées, sélectionner le texte sous-jacent, c'est
assez comique.)
Je ne sais pas si cela répond à ta question.

Post by Anne G
Ni surtout quel en est l'intérêt.

Comme je l'ai déjà indiqué, le fichier pdf bénéficie ainsi d'une taille plus
réduite. Je n'ignore pas que le MiB ne coûte plus très cher aujourd'hui mais
j'espère faire tenir toute ma collection de revues scannées sur un seul DVD
ordinaire sans renoncer à un niveau de qualité correct...

[geo cherchetout]

Post by Laurent S.
L'amélioration de fichiers PDF est une activit'e importante; je suis tr`es
enthousiaste pour suivre les détails de cette aventure réussie !

Entrons donc dans le vif du sujet. Supposons une même page décomposée en ses
objets constitutifs : D'une part la page Xn.pdf issue du pdf océrisé et
d'autre part la page Yn.pdf issue du pdf original, dans laquelle l'image est
enregistrée en mode indexé.
La page X a produit par exemple 50 objets xx001 à xx050. Supposons que
l'image y soit représentée par l'objet xx0030 d'identifiant 25.
La page Y a produit 10 objets par exemple yy001 à yy0010. Supposons que
l'image y soit représentée par l'objet yy006 d'identifiant 4 et son index
associé par l'objet yy007 d'identifiant 3.
À l'aide d'un éditeur hexadécimal, ouvrons l'objet yy006 et remplaçons son
identifiant 4 par 25. Recherchons y également la référence de son index
associé et remplaçons sa valeur 3 par 2. (La place pour un objet 2 est
toujours libre dans les pdf que je traite.) Enfin, renommons cet objet yy006
en xx0030 en écrasant le xx0030 existant.
D'autre part, ouvrons l'objet yy007 et remplaçons son ID 3 par 2. Renommons
ce fichier en xx051. (50 + 1)
Reconstruisons notre page :

$ cat xx* > Zn.pdf

À ce stade, Acrobat Reader renâclerait mais accepterait quand-même d'ouvrir
la page. Normal, sa table Xref ne reflète plus la réalité des objets
contenus. Pas la peine de recalculer soi-même les offsets des objets comme
je l'ai fait la première fois, pdftk s'en charge :

$ pdftk Zn.pdf output Wn.pdf

Ceci étant réalisé pour toutes les pages qui le méritent, il n'y a plus qu'à
reconstituer le document complet :

$ pdftk W*pdf cat output Document.pdf

« Mon » procédé est donc extrêmement simple dans le principe mais très
fastidieux quand il faut l'appliquer manuellement, et on risque de commettre
beaucoup d'erreurs. (Récemment toute une après-midi pour mon premier
document de 48 pages.) Un programme réalisant automatiquement tout cet
enchaînement d'actions serait bienvenu, s'il n'existe pas déjà. Un programme
gratuit, de préférence.

Les images du pdf océrisé étant compressées avec l'algorithme LZW, donc non
dégradées, il est possible de les extraire avec pdfimages, puis de les
ré-enregistrer en mode indexé en utilisant la commande convert d'ImageMagick
et ses précieuses options que je n'ai pas recherchées. La commande optipng
peut aussi aider. Pour en faire un objet de pdf, on peut alors utiliser
pdfLaTeX ou convert. Ceci pour le cas où on ne disposerait pas du pdf original.

Pour info :
***********
L'identifiant de chaque objet, un nombre décimal, réside dans les premiers
octets de cet objet. Il est suivi d'un blanc, puis d'un zéro, puis d'un
blanc, puis de obj, comme ceci dans le cas d'un objet 68 :

68 0 obj

Quand une image est enregistrée en mode RGB indexé, elle contient en clair
l'identifiant de son objet index associé sous cette forme :

/ColorSpace [/Indexed /DeviceRGB 84 62 0 R]

(Dans cet exemple l'index est l'objet 62. 84 semble être le nombre de
couleurs diminué de 1, ou le nombre de couleurs différentes du noir, je ne
sais pas.)

Tout ceci résume des connaissances nouvellement acquises qui ne sont pas
totalement sûres et peut-être pas vraies pour d'autres générations de pdf.
Le procédé peut forcément être amélioré. Merci d'avance pour vos critiques
et suggestions.