T'es au courrant que l'esclavage a été aboli ? [:anathema]
cybergg
Merci Moebius pour cette nouvelle info, je m'en vais de ce pas tester cette piste. Mon rapport à été remis aujourd'hui, mon "chef" à semblé apprécier le fait que nous ayons tous ensemble cherché malgré "l'évidence". Il se peut qu'un de ces quatre mon "chef" se pointe en ses contrées amicales, je lui ai parlé de forum, peut-être que j'aurais pas dû ;-) non blague à part, encore merci à tous
Le naim fort graphiste va pouvoir enfin dormir "normalement" et récupérer avant le prochain défi de mon "cher chef".
A bientôt
Le jpeg2000 comme en parlait kewsi semble prometteur mais le browser sur ce terminal est de type mozilla (1....) et donc trop ancien pour afficher correctement ce type de fichier par ailleur même mon photoshop cs n'est ps capable de traiter ce genre d'image (pour l'instant !!!).
Il faut voir s'il n'y a pas des plugin aussi pour le browser. Le gain sur le rapport qualité/taille est très intéressant par rapport à Jpeg dct classique.
cybergg
Je ne pensais pas revenir en ces lieux bien sympathiques, retrox voilà ce que j'appelle une argumentation bien ficellée, un tout grand merci d'avoir pris la peine de répondre. Voilà qui me réconcilie avec l'esprit de partage d'un forum. Je devais rentrer mon rapport demain voilà un complément d'information qui tombe à pique et qui devrait conclure ce chapitre. Encore un tout grand merci à tous, même à la mouche qui a su garder de l'humour pour sa dernière touche. Au plaisir de vous relire un de ces 4 et de vous retrouver dans un de ces forums. Je vous souhaite à tous le meilleur du meilleur...
retrox
Alors voila les arguments pour ton patron :
Le standard JPEG est publié en tant que norme ISO 10918-1. Il définit un procédé de compression pour images dans un espace de couleurs continu (non-indexées). Cette norme est completée par un standard "de fait" appelé JFIF.
Alors maintenant on a 2 documents de référence. On prend le premier, la norme JPEG.
Section 4.7 (page 19) : "Sample precision"
"For DCT-based processes, two alternative sample precisions are specified: either 8 bits or 12 bits per sample."
Dans la pratique on ne trouve que du DCT-based process, l'autre mode étant le lossless qui est encombré par des brevets et donc introuvable. Donc 8 ou 12 bits par composant, on est mal barrés pour faire du 16 bits...
Deuxieme document : JFIF v1.02
"Standard color space" (page 2) : "The color space to be used is YCbCr as defined by CCIR 601 (256 levels). [...] If only one component is used, that component shall be Y."
256 levels <=> 8 bits par couche (ce qui est conforme au standard JPEG qui autorise 8 ou 12 bits par composant comme on l'a vu).
3*8 = 24 le compte est bon.
Au revoir et à la semaine.... prochaine! :D
Je ne parle pas du TIFF/JPEG, mais je doute fortement que Mozilla sache se débrouiller avec ça. De plus etant bloqué par le standard (JPEG) à 8 bits par couche mini, on ne peut jouer que sur le nombre de composants (1 à 4) et la fréquence de sampling des différentes couches.
Pour le nombre de composants, je ne connais pas d'espace de couleur compatible avec RGB qui n'utiliserait que 2 couches (2*8 = 16). Donc 3 couches mini. Pour la fréquence de sampling des couches c'est déja utilisé par la majorité des softs, qui ajustent ça en fonction du "facteur qualité" proposé à l'utilisateur (l'autre parametre se cachant la dessous étant la table de quantification).
De toutes façons les logiciels qui font du JPEG n'offrent jamais de controle explicite la dessus.
Donc y a pas de miracle à attendre du JPEG.
Effectivement JPEG2000 est tres performant en haute compression (c'est d'ailleurs l'un des seuls avantages). Mais comme deja dit, c'est pas tres répandu (pour des histoires de gros sous).
