Quel est l'état actuel du support logiciel pour JPEG-2000?


20

La recommandation générale pour enregistrer les images numérisées originales était «utiliser TIFF». Mais les programmeurs ont besoin d'une évolution du format pour "l'évolution du logiciel", et j'ai besoin de faire évoluer mon système pour passer du TIFF au JP2.

J'ai un grand stockage d'images (téraoctets) pour les documents scannés légaux et scientifiques, ils ont besoin d'un enregistrement original. J'utilise certaines règles de mise en cache, mais le système doit afficher (via le téléchargement Web) ou manipuler (ImageMagick et autres) les données originales.

J'ai lu un article sur la migration des stockages d'images de TIFF sans perte vers JPEG-2000 sans perte et la conclusion est de rester avec TIFF. Cependant, l'article date de 2009 et, à l'époque, ils ont constaté que la prise en charge du format JPEG-2000 par les logiciels disponibles était très médiocre. Les conversions au format JPEG-2000 ont subi des pertes dans le logiciel qu'ils ont testé, et le logiciel disponible pour consommer des images ne supportait pas bien le format.

Est-il temps de passer du TIFF au JP2 ou non? Le support logiciel est-il toujours aussi imparfait qu'en 2009?


Le choix du format aura beaucoup à voir avec la nature des données (couleur / niveaux de gris / bw, profondeur de bits, résolution, et surtout s'il s'agit principalement de texte, de photos, de graphiques, flous, granuleux, etc.), donc cela aiderait un peu si vous pouviez nous en dire plus. Plus important encore - l'original TIFF numérisé était-il avec ou sans perte? S'il s'agissait d'une perte, cela signifie que cette perte d'informations a été tolérée (contrairement à d'autres modifications), et il est très peu probable que vous trouviez un format sans perte qui correspondra à sa taille de fichier.
Daniel B

4
Ce serait sur le sujet ici Peter si vous A) ne faisiez pas une demande de ressources mais demandiez plutôt une réponse à votre question et B) clarifiiez la question. L'actualité de votre Q est en fait un excellent ajustement ici, vous avez juste besoin de clarifier une question répondable spécifique.
Jimmy Hoffa

Merci @JimmyHoffa et al! J'ai édité, mais peut-être plus tard, d'autres personnes ont fermé la question ...
Peter Krauss

Merci @ thorstenMüller, vérifiez si maintenant (édité) est plus explicite.
Peter Krauss

6
@PeterKrauss Je sais que ce n'est pas clair par le libellé de "fermer" mais fermer signifie en fait verrouillé jusqu'à sa révision, le réparer et il sera rouvert, ils le supprimeraient s'ils ne pensaient pas que cela pourrait être corrigé.
Jimmy Hoffa du

Réponses:


8

Sur la base de la liste des applications de Wikipedia , le support de nos jours semble assez bon. Il gagne également du terrain dans les organisations axées sur les archives du monde entier:

  • Voici une page discutant de son adoption par l'OTAN, entre autres.

  • Ce document mentionne que la bibliothèque de l'Université Harvard passe également au format JPEG-2000.

  • Cet article détaille les efforts du British Museum et de Harvard et ajoute la Wellcome Digital Library.

Sur mon MacBook Pro fonctionnant sous 10.7.5, voici quelques résultats de navigation ( source 1 , source 2 ):

  • Safari: pas de problème

  • Chrome: parfois nécessaire pour charger QuickTime

  • Firefox: pas de problème

Je n'ai pas testé IE, mais à partir de ces trois et de la liste Wikipedia, je pense que le support JPEG-2000 est maintenant très répandu.

En ce qui concerne la question de savoir si vous devez changer, étant donné que JPEG-2000 semble avoir un support de plate-forme suffisant maintenant, je ne changerais que s'il y a de fortes raisons techniques de le faire:

  • tailles d'image plus petites

  • des performances plus rapides

  • plus sûr

  • TIFF commence à ne pas être pris en charge.

Si vous choisissez de changer, veuillez poster votre expérience en le faisant!


Merci. Oui, je suis d'accord avec vos arguments sur "un support de plateforme suffisant". Les navigateurs et les applications SIG ont été les premiers à prendre en charge, mais les normes NLM / PMC pour les documents numérisés et les illustrations originales , etc., recommandent encore le TIFF ... Je ne sais pas pourquoi.
Peter Krauss

@PeterKrauss Je peux me tromper sur ce point, mais la première chose qui me vient à l'esprit serait le manque de prise en charge (généralisée?) De plusieurs pages dans un seul fichier pour JPEG et JPEG-2000? La prise en charge de la compression sans perte en est un autre, et la famille JPEG a toujours été orientée photo et ne fonctionne pas aussi bien sur les documents numérisés. Historiquement, le TIFF a été et est toujours extrêmement répandu et dominant dans le monde de la numérisation. Demander pourquoi, c'est un peu comme demander pourquoi Windows est dominant sur le bureau - c'était assez bon au bon endroit et au bon moment.
Daniel B

Non pris en charge semble beaucoup trop. Une enquête auprès de plusieurs grandes institutions a montré une image différente: photo.stackexchange.com/a/69661/45210
Nemo

4

Je pense que la réponse dépend de si vous remettez en question l'utilisation réelle ou la couverture du support de la bibliothèque. Puisque vous posez la question sur programmers.stackexchange, vous voulez peut-être parler de bibliothèque, mais tout le monde semble supposer que vous posez des questions sur les applications. Je suivrai la foule.

En parlant d'applications, basé sur la liste des applications de Wikipédia, le support de nos jours semble assez mauvais. Les logiciels utilisateur compatibles avec lui sont numérotés et sont généralement des outils professionnels, et il ne fait que gagner du terrain dans certaines organisations mondiales axées sur les archives que vous pouvez terminer la liste sur une seule page. Bref, jp2 est hors de portée du peuple. À ce rythme, il n'atteindra jamais le seuil de rentabilité pour être accepté par le public, malgré la supériorité technique.

En parlant de navigateurs, Wikipedia a indiqué que seul Safari avait un support natif. Tous les autres, Firefox, Chrome, IE ... ne le font pas, sauf certains le font avec QuickTime, qui ne peut pas être garanti sur Android / Windows et n'est pas là sur Linux.

Sur mon OpenSUSE 13.1, voici quelques résultats de navigateur avec des exemples (notez que l'ouverture de la page d'exemple ne compte pas pour OK, vous devez ouvrir les images .jp2 à l'intérieur):

  • Chrome 33: impossible, proposez aux utilisateurs de télécharger.
  • Firefox 27: impossible, proposez aux utilisateurs de télécharger.

(Puisque Linux lui-même prend en charge jp2, les utilisateurs peuvent ouvrir les images après le téléchargement)

** Modifier après avoir lu le commentaire de Peter Krauss ** Dans le contexte de la préservation, vous pouvez peut-être choisir le format, car généralement vous fournissez des outils aux utilisateurs; l'environnement de bureau et de navigateur des utilisateurs est d'une importance secondaire.

Faire évoluer votre logiciel ne signifie pas accepter les dernières normes technologiques. La dernière norme technologique est l'espoir d'une future technologie du comité de normalisation, et les gens votent à pieds après leur décision. Exemples: Beaucoup ont migré vers XHTML puis HTML5 tandis que la plupart de HTML4 directement vers HTML5, et beaucoup ont migré vers FireWire (1394) puis eSATA et USB3 tandis que la plupart de USB2 directement vers USB3.


Oui (!) "Bibliothèque moyenne", je dois vérifier la "couverture du support de bibliothèque" sous Linux, Windows et Mac. Si la communauté des développeurs et des grands référentiels (comme PMC et SciELO ) peut adopter jp2. <br/> Oh, illustration parfaite de vos échantillons , merci.
Peter Krauss

2
A propos de " JP2 est hors de portée du peuple (...) il n'atteindra jamais le seuil de rentabilité pour être accepté par le public". Point important à retenir ici pour les lecteurs et pour les comparaisons: bien sûr, JPG est "pour les foules" ; aujourd'hui (et peut-être pendant des décennies) JP2 , JLS et TIFF sont destinés à des contextes de préservation , et ils sont au centre de l'attention ici.
Peter Krauss
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.