MARQUE-BLANCHE - Ocerisation

[lvinsonneau]

L'"ocerisation" des délibérations et annexes est-elle fonctionnelle pour la partie "recherche" de la marque-blanche ? Si non, a-t-on une visibilité sur sa date de mise en production ?

[yguenneugues]

@lvinsonneau L'ocerisation des délibérations est mis en place en preproduction, vous pouvez réaliser des tests. L'ajout de l'ocerisation à un fort impact sur la CPU du serveur. ( prévoir un ajout de CPU)

Techniquement nous avons ajouté les libs tesseract-ocr tesseract-ocr-fra imagemagick numpy scikit-image dans l'image docker de apache solr - dockerfile apche solr

[lvinsonneau]

OK @yguenneugues , pour l'ajout de CPU, @spelhate : tu peux peut-être voir avec Fred ?

[spelhate]

Vu avec Frederic. Il nous faut le nom de la VM (Pas sur ce canal) pour créer un ticket côté SIB + maj du DAT avec les caractéristiques de la VM.

[lvinsonneau]

@yguenneugues : je viens de tester l'ocerisation en pré-prod, ça a l'air de super bien marché !!!! @ElodieTessier et @spelhate : vous avez testé ?

[spelhate]

Pas encore testé de mon côté, mais c'est prévu d'ici la fin de semaine.

[spelhate]

• Testé avec CHEVALIER -> ok (1 résultat)
• Testé avec Chevalier -> ok (1 résultat)
• Testé avec DE GAULLE -> ko (672 résultats)
• Testé avec "DE GAULLE" -> ok (6 résultats)

[ElodieTessier]

Je regarde ça de suite !

[ElodieTessier]

@yguenneugues @lvinsonneau @spelhate Essais avec : Liberté : 10 Liberte : 0 LIBERTE : 0 LIB : 0 Lib : 0

[lvinsonneau]

Testé avec "gourhant" (du nom d'une signataire d'une délibération full image). Et ça marche !

[yguenneugues]

Le nombre de CPU à ajouter n'est pas évident à définir. On définit "la qualité de l'océrisation" avec un nombre de dpi comme pour un scanner. Plus le nombre de DPI est élevé meilleur sera le résultat de l'océrisation mais on consommera plus de CPU. (exponentielle)

En fonction de nos tests, on devra définir un nombre de DPI qui nous semble acceptable ( actuellement fixé à 300 DPi en preprod) ça consomme pas trop pour un résultat qui me semble correcte.

[ElodieTessier]

Merci @yguenneugues , peux-tu expliciter les notions de CPU et DPI svp ?

[lvinsonneau]

@ElodieTessier : CPU = processeur DPI = dot per inche (point par pouce en français), cela équivaut à la résolution

[spelhate]

Sans entrer dans le détail, :

• CPU = Microprocesseur(s). Plus il y en a et plus la vitesse et la capacité de calcul de la machine sont élévées.
• DPI = Il s'agit d'une résolution. Plus cette résolution est élévée, plus la précision est grande.

[ElodieTessier]

@lvinsonneau @spelhate Merci à vous deux, je comprends mieux.

[clemoigno]

Attention ne confondez pas la recherche case sensitive/insensitive comme les cas de test de @spelhate et @ElodieTessier avec le cas de test de l'OCR (comme le test 'gourhant' de @lvinsonneau). Les deux premiers cas, ça n'a rien à voir avec l'OCR. C'est 'juste' des options de la recherche (qu'il faut peut-être régler d'ailleurs mais c'est une autre tâche).

Côté technique dev, la mise en place de l'OCRisation semble fonctionnel mais il faut réfléchir à la mise en oeuvre (puissance nécessaire, reprise de l'existant)

[lvinsonneau]

OK @clemoigno , on attend vos préconisations techniques. Merci.

[lvinsonneau]

@yguenneugues : OK pour test et paramétrage. En attente d'un étude sur les charges CPU nécessaires (action SIB) Puis trancher (Mégalis) en fonction des questions de green-it. Dans un monde idéal, les documents devraient être numérisés en amont.

[lvinsonneau]

Stats sur les documents scannés/non scannés = 2/3 scannés et 1/3 non scannés, sachant que le 1/3 non scannés est censé augmenter, mais le constat fait (cf. TB superset Supervision opendata). Si on mettait en place l'ocerisation, cela impacterait beaucoup le fonctionnement de la plateforme notamment sur l'aspect indexation.

On laisse comme ça pour le moment (sans ocerisation)