Bonjour à tous,
La question va peut-être vous semblez élémentaire pour certains mais pour moi c'est un vrai cauchemar. Je vous explique je dois produire pour mon boss des images jpeg (par défaut stockée sur 24 bits) j'ai optimisé au maximum ces photos, mais cela ne lui suffit pas encore trop lourd pour lui, il avance la théorie selon laquelle puisque ces images iront sur ecran 16 bits si au maximum de la compression on arrive encore a transformer le 24 bits en 16 bits on va gagner encore de la place, ce qui a première vue semble logique d'un point de vue informatique, mais dans les faits existe-t-il quelqu'un parmis vous qui ait entendu parler un logciel ou d'une methode qui permette de transformé un jpg 24 bits en jpg 16 bits?
D'avance merci de votre aide
Un infographiste qui ne dort plus !

24 bits c'est 8 bits par couche, tu peux demander à ton boss combien il compte mettre de bits par couche en 16 bits ?
 
Tu pourra réduire la taille en passant de 16M de couleurs à 65 000 mais il faut voir le résultat

16 bits c'est souvent du téléphone portable en RGB565 ... je ne suis pas sur que ca existe en jpg .

Merci poogz pour l'info, c'est vrai que tout cela à l'air iréel et pourtant là-dessus il m'a répondu, "comment crois-tu qu'un écran 16 bits affiche du 24 bits, il en met combien par couche ?" Et là rebelotte me voilà parti pour un casse-tête, en effet si notre difficulté vient de savoir comment un algorythme repartis du 24 bits jpg standard sur un écran 16 bits et que pourtant il affiche avec une certaine perte, qu'est ce qui nous empêche de penser que le même système ne puisse être appliqué au traitement d'une image ?

Calcoran, effectivement cela est possible, dans mon cas il s'agit d'écrans lcd constituant + de 6.000 terminaux répartis dans des points de vente. Les images sont transmises par un réseau téléphonique hyper lent et d'ou le soucis de vouloir optimiser au max tout en gardant une qualité d'affichage finale convenable
Merci de ton intervention. Si il y a d'autre piste qui puissent m'éclairer je suis tout ouie.
Merci de votre aide à tous, kà je sais que je suis plus tout seul. C'est la première fois que j'utilise un forum et franchement c'est cool !!!

Ben moi je suis dans la téléphonie, et nos jpg sont en 24 bits. C'est seulement a l'affichage qu'on les traduit en RGB565, qui est equivalent a du BMP, mais sur 2 octets au lieu de 3 (qui est donc relativement gourmand en place car pas de compression).
Une solution serait de réduire artificiellement la quantité de couleurs dans ton image, un peu comme la commande "indexed color" dans photoshop (malheureusement indexed colors ne marque que pour 256 couleurs ou moins ) ... une solution serait de séparer chaque coucher R, V, et B dans une image, de faire du indexed color sur 5 ou 6 bits (32/64) sur chacune, et remélanger tout ensuite. Compliqué, mais une fois qu'on a trouvé le coup ca doit etre scriptable. Par contre je ne sais pas si on y gagne beaucoup ...

Cela ne serait-il pas aussi intéressant pour toi d'arriver à solutionner le prob ? J'imagine que la téléphonie a aussi besoin d'un maximum de compression ? Je vais essayer cette voie-là je suis néanmoins un peu inquiet car la dernière fois lorsque j'ai voulu sauver une couche juste pour voir, à la réouverture il m'avait rajouter les 2 manquantes. Bon je replonge en apnée cette fois-ci et pourvu que ce soit le "grand bleu" et pas le "trou noir". Je vous reviens au plus vite pour vous tenir au courant de la suite de cette aventure rocambolesque ou les songes d'un "nain fou graphiste" qui ne dormait plus.

Ben en fait je travaillais chez M.ts.b.sh., un gros centre de R&D qui vient de fermer en Bretagne. Donc pour l'instant, la téléphonie, hein .
 
Par contre si j'avais eu a faire ca pour mon boulot, j'aurais transformé mes images en BMP et ecrit un petit programme qui aurait indexé les couleurs directement, pour  recompresser en JPG ensuite. Tu n'as pas de programmeurs dans ton bureau?

À ce stade il serait peut-être intéressant de définir ce qui pour ton boss est une image optimisée :
— quelle est la taille en pixels
— quel est le contenu (photo >jpg / graphique >emf/svg)
— quel niveau de détail faut-il conserver pour des photos (quelle niveau de compression)
 
Ex :  
image de produit textile multicolor détouré fond blanc 500x350 px qualité 50% : 20Ko / 4s à 56 Kbps
Il y a moyen de gâgner 1 seconde en descendant la qualité à 30% (Le vêtement est toujours présentable)
On tombe à 2 secondes pour la même image en 300px de haut
 
 

A mon avis, tu gagneras rien.
La principale raison est que l'algorithme jpg fait mieux que passer sur 16bits : il change lui même les couleurs localement (plus ou moins subtilement en fonction du taux de compression demandé) afin d'avoir plus de redondance dans les infos et de compresser mieux.  
Comme l'a dit luminilux, mieux vaut passer ton temps à cibler correctement tes objectifs plutot que de jouer les apprentis sorciers

Je m'étais posé la question, mais en un sens, passer les couleurs sur 5 bits chacune créera probablement des aplats plus facilement compressibles ... cela dit c'est difficile a dire sans tester avant .
Par contre tu as probablement raison, autant augmenter la compression jpeg, c'est largement plus simple et par forcément moins bon .

j'ai testé en 15 bits...
 
le poids ne change guerre, et il est toujours vu comme un 24 bits
 
attention l'algo d'ffichage en 16 bits pour cg ou tft n'a rien à voir... ce n'est pas à prendre" en compte pour une éventuelle comparaison !!!

Donc mieux vaut augmenter la compression jpeg .

pour une résolution donnée oui
 
sinon passer en 256 couleurs avec un excellent algo

 
Je reviens à mes produits (le premier qui me tombe sous la main)
500x422 détouré fond blanc :  
— GIF 256 couleurs : 86 Ko  
— JPEG 50% : 24 Ko  
— JPEG 30% : 15 Ko un peu moins détaillé
 
Reste à connaître l'utilisation :  
— les images seront-elles regardées « à la loupe » oubien est-ce juste pour avoir un aperçu du produit ?
— à partir d'où considère-t'on une image comme moins bonne ? dans la théorie avec une compression 50% elle est déjà moins bonne mais dans la pratique à 30% elle est toujours très bien (dans mon cas de figure, un produit genre polaire avec plein de poils et donc beaucoup plus de détails passerait sans doute moins bien)
— pour un opérateur dont l'œil est à 60 cm du terminal, à partir de quelle niveau de dégradation de l'image est-il à même de percevoir une différence ?
 
 
Il est clair qu'il faut quitter le cadre théorique et juger en fonction du besoin du moment
 
 
Quelques questions :
Dans la mesure où la sortie se fait sur un écran 16 bits, quel est le risque si la palette « produit » ne correspond pas à la palette « écran », comment va se faire l'adaptation des couleurs ?
La transforamtion en JPEG passe par une conversion YUV :  
— la transition par un RVB565 est elle bien intéressante ?  
— la convertion à partir de couleurs indexées est-elle possible ? (j'ai peur que photoshop ait déjà la réponse)
 

Bonsoir à tous me voilà de retour, je vais essayer de repondre à tout le monde,  
Calcoran: Ben en fait je travaillais chez M.ts.b.sh., un gros centre de R&D....
J'espère que t'auras l'occasion de retrouver un job qui te plaise, en tout cas en qui concerne les programmeurs chez nous, on me répond que c'est plutôt à nous dans un premier temps à trouver les soluces et qu'éventuellement après si ils ont le temps ils verront (sous entendu, compte toujours dessus) par ailleurs il sont plus spécialisé en programmation réseau d'en traitement d'image).
Luminlux: Quelle sont les contraintes ? Bonne queston aujourd'hui j'ai proposé un test d'acceptation de la qualité minimale. Quelques données à ce sujet:
la taille des images à produire sont en 800*600 px par 72 dpi. terminal 16 bits. Les images contiennent des produits pour la Loterie Nationale (voilà ça y est, vous savez tout, cela concerne tant des communications affiche (donc de la photo) que des produit par ex. à gratter donc plutôt du trait et de grands aplats.
Dans le cas des photos ils ont acceptés que je descende à du jpg 30% dans le cas de certains gif je peux descendre jusqu'a 64 couleurs. Les clients sont en général positionné à +- 1m de l'écran. Il n'empêche que l'on ne joue pas seulement sur la compression de l'image mais également sur le nombre d'images affichable durant un slideshow (et parfois comme cela s'est passé dernièrement tous les managers des différentes familles de produits veulent communiquer en même temps. Raison pour laquelle mon boss me relance en me disant au "meilleur de la compression, au seuil de ce qui est acceptable n'y a t-il pas moyen de réduire de24bits en 16bits on doit en théorie d'un point de vue informatique gagné 1/3 du poids non ?
Et vlan on est repartis.

De manière générale nous avons tous, me semble-t-il la même approche jouer sur le meilleur rapport compression/qualité acceptable visuellement, mais changer du 24 bits en 16 bits ne devrait-il pas en théorie réduire la gamme de couleurs dans les algorythmes de compression et donc on ne devrait pas perdre trop en qualité visuelle mais par contre on devrait gagner en poids ? Qu'en pensez-vous ?
 
Tharkie je pense aussi avoir fait un test dans ce sens mais tu gagnes pas grand chose parceque lorsque tu revient en jpg il recode tout sur 24 bits.
Il y a dans une cybercafé (apparemment cela existe encore) ou j'étais dernièrement occupé à noyer mon noir cauchemar dans un limonade bien dorée en racontant mes déboires à des voisins, une sorte de rasta blanc qui m'a dit vous oubliez un élément les gars le "colors quantisation process" et il s'en est allé nous laissant là bouche bééé l'air béa...
"Y a ti quéqun qui sai c'est quoi ?" vla autre chose... Cela devient la recherche du graal, le mystère de la matrix étrange, la quadrature du 24 bits ??? ....

Ooh amis du pixel, j'oubliais un détail mais qui a son importance le chargement du slideshow envoyé sur les 6000 terminaux passe par des lignes dont une partie de la bande passante est dédiée à cette tâche soit 9600 bauds (et oui retour à l'âge de la pierre) d'ou cette obsession à trouver un moyen d'aller encore plus bas que le meilleur rapport compression et qualité visuelle, jouer sur les bits et de se reposer la question JPG 16 bits, rêve ou réalité...

C'est simple, il suffit que tu étudies la norme jpg, et que tu sortes un jpg16 .
Ensuite, tu codes un encodeur/décodeur, tu fais accepter la norme, etc. . C'est pas gagné!
 
Malheureusement, même si dans le principe ton chef a raison, la norme jpeg ne prévoit pas ca ... tu pourrais chercher du coté des png, qui le supporte peut-etre, mais je ne pense pas que tu y gagnes etant donné que la compression est en général moins poussée (à priori c'est du lossless). Ou alors il embauche un informaticien qui lui développe ca en 3 mois ... et il se retrouve avec un truc certes particulièrement optimisé, mais entièrement propriétaire et donc absolument pas compatible avec le reste du monde, et super pas évolutif .

et le format png ?

Calcoran:
Ouais, ben à priori je pense que t'as raison "le chef à toujours raison et une fois de plus ici il aura raison" il a qua et j'ai qua... Bon ben me voilà le moral à zero et comme tu dis c'est pas gagné.  
 
Tharkie:
Je vais voir un peu le format png, mais je crois que le png doit être aussi bon que jpg puisqu'il est arrivé après sur le marché à moins que je confonde avec le svg. Par ailleurs les termniaux tournent sous linux et utilisent un browser de type mozilla 1.quelque chose, je vais essayé cela et je vous reviens demain vers 1h du mat  
Enocre merci à vous pour cet échange qui même si il n'a pas apporté de solution m'a permis de voir qu'un forum ça peut-être super cool
A demain !!!  

entre gens de bonne volonté
 
bonne chance

A moins que je dise des conneries, le png c'est du lossless, donc ca a peu de chances d'etre aussi efficace que du jpeg .

c'est très bizarre le png, bien que je n'en soit pas du tout spécialiste, j'ai juste fait quelques test pour notre ami, et les résultats vont de 30% à 350% suivant le type d'image

Le PNG est dramatiquement lourd, même en mode 8 bits
Si tes visuels sont de type vectoriels à la base (dessin de carte à gratter, main gâgante ou illustration) le SVG et mieux le SVGZ (version compressée du SVG) peut s'avérer le plus efficace d'autant que le Tux gère ça très bien
 
Quoi qu'il en soit, le mieux est de passer au tests avec des visuels concrets
 
Bonne chance

Dans le temps, j'avais un soft de compression par ondelette qui était trés efficace (faut que je vois si je retrouve ça)....
 
http://fr.wikipedia.org/wiki/Ondelette

J'ai rien dit, c'est la technique employée dans le Jpeg2000...
 
http://www.jpeg.org/jpeg2000/index.html?langsel=fr

tharkie: Comme le png est lossless, il est fortement lié au type de photo. De grands aplats pourront etre fortement compressés, une photo pleine de détails ou de bruit quasiment pas. C'est un peu pareil en jpg, mais la relation est moins directe, on fixe un taux de compression, par contre je pense que certaines photos pourront etre plus dégradées par la compression que d'autres.
 
kwesi: Bien vu l'idée du jpeg2000, il y a peut-etre de solutions de ce coté!

Bonjour à tous,
 
J'ai eu pas mal de boulot aujourdh'ui ce qui fait que je n'ai pas su faire tous les tets que j'aurais bien voulu entreprendre, ceci dit Calcoran et luminilux ont raison le png c'est pas top, que ce soit dans le type d'adplats que je rencontre voir les images de type photo dans la moyenne le png se situe entre le gif et jpg en terme de poids la qualité étant directement proportionnelle.
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 !!!).
Donc pour l'instant on cherche tous (et je vous en remercie encore) cela semble aujourd'hui un défi insurmontable, il y a personne qui a un copain anglophone ou indien et qui dans les forums étrangers aurait entendu parler d'un outil qui pourrait nous aider ?
Bon ben le "nain fou graphiste" s'en va encore passer une longue nuit blanche.
A demain si il reste encore des courageux pour creuser la question.
Purée le jpg 16 bits c'est pas de la tarte !!!

le png, c'est lourd si tu veux le faire travailler comme un jpeg, par contre, si tu reconstitues l'image en vrai vectoriel, normalement, c'est énorme la place que tu gagnes. d'ailleurs, je m'étonne qu'à la fxjxux ils aient pas tous ces graphiques en vectoriel quelque part...

 
Bon. Je réagis pq j'ai l'impression que tu fais n'importe quoi.
Deja t'écoutes pas ce qu'on te dit. Le jpg 16bits ca n'existe pas et même si ca existait ca n'aurait aucun n'interet par rapport au jpg classique. J'ai donné un argument plus haut. Donc de ce niveau là, c'est archi réglé depuis le début du topic, pas besoin de revenir toutes les 48h en espérant le jpg 16bits.
Ensuite tu nous sors maintenant que Mozilla doit être capable de lire tes images. Ca règle quand même bcp de pbs.  
Tu listes les 4 formats qu'il sait lire, tu fais quelques tests de compression et tu rédiges un rapport à ton patron pour qu'il prennes une décision. S'il est pas content tu lui demandes d'embaucher un mathématicien...

je crois que je suis un peu de l'avis du monsieur de dessus voire même complètement du même avis

Le probleme c'est que ce n'est pas n'importe quel "on" qui lui dit ca, c'est son chef. Et tu n'as peut-etre pas eu la chance d'avoir un chef dans ce style, mais quand un chef comme ca dit "ca doit bien etre possible" ... eh ben il a raison.
Ca c'est la regle numéro 1. Il a raison.
La regle numero 2 ... c'est de bien relire la regle numero 1.
 
Cela dit, il semble que l'on soit dans un des rares cas ou expliquer au chef qu'il a tort prendra moins de temps que d'essayer de faire ce que le chef demande, c'est un jour a marquer d'une pierre blanche .

ezzz: Franchement si le sujet t'énerve te fait pas de mouron, et surtout ne te sens pas obligé d'y participer quand a ton argument sur le jpg tu ne semble non plus pas avoir beaucoup lu ce que je disais plus haut. Effectivement l'algorythme va faire une synthèse des couleurs etc... mais affirmer qu'un fichier informatique codé sur24 bits (quelque soit sa compression) cela ne fait aucune différence avec du 16 bits (pour moi cela fait un tiers du poids en moins)me semble être plutôt léger en conclusion. Encore une fois, te biles pas hein, par ailleurs je n'ai pas dit que mon browser devait être capable de lire mes images mais bien des images dont le format (jpg 2000)encore en cours de standardisation n'est pas lisible sur le browser que je possède, je réagit par rapport à une suggestion qui m'a été faite et par l'échange ont tentent de faire avancer le schmilblic. Ta "solution" j'espère que t'a de bons patrons parscque je peux te dire que chez nous tu serais déjà dehors. Et les adeptes du "YAKA, YAPA, YAPLU" sont vite "out" chez nous.Il faut un petit peu creuser  et contre argumenter de façon valable en particulier d'un boss qui est informaticien de formation.
Maintenant ne le prend pas mal mais franchement ton argumentation sur le codage du jpeg qui fait tout et donc ont peu pas plus, YAKA... dès le début de ce topic, ne règle pas tout et c'est un peu facile comme réponse. Ceci dit merci quand même de ton intervention.

Calcoran, je suis plutôt d'accord avec toi tu est plus philosophe que la mouche ezzzzz et ton message fait plus mouche que l'agressivité de l'autre là, il a complètement oublié les règles de bienséance d'un forum, enfin dans chaque forum il y en a un comme ça. Encore merci à tous, je ne vais plus vous ennuyer considérer que le problème est résolu puisque ezzzz à décidé que...Dommage je vous trouvais tous bien sympathique et pour reprendre ta jolie formule Calcoran: ce jour est à marquer d'une pierre blanche pour moi comme pour d'autres sur ce forum ...
Bonne continuation à tous

c'est bien
 
mais comme je l'ai dit plus haut, le standard jpg c'est du 24 bits
 
que ton patron soit le pape où que ton emploi soit lié à ce problème, cela ne changera pas le fait que :
 
1) les visionneurs (browser dans ton cas) ne supporte qu'un type bien défini d'image
 
2) le jpg a ses propres caractéristiques que tu ne pourras pas changer.
 
la première chose à faire, c'est d'établir un cahier des charges en fonction de la destination des images. il faut précisément définir ce que tes navigateurs peuvent voir ou sont capables de ressortir.
 
une fois que tu auras cette réponse, elle conditionnera ta solution.
 
si tu fais un rapport logique et argumenté de la situation, ton patron ne pourra qu'accépter. à toi de lui faire un bon rapport, bien argumenté...
 
ex :
 
a) les images seront vues sur tel type de machine, tel type de navigateur, tel type de programme.
 
b) les formats d'images accéptés par ces programmes et ces navigateurs sont :
 
bmp, png, gif, jpg, etc.
 
c) il apparait que le meilleur rendu en rapport poid/rendu est le format jpg.
 
d) le format jpg reconnu par les navigateurs est jpg standard aux spécification décrites ci-après
 
http://www.jpg.com/french.htm
 
e) le format jpg de destination devant correspondre à la norme jpg telle qu'elle est définie (citer les sources) pour répondre aux limitations du format lui-même exploité par les destinataires de nos images, il apparait que seul le jpg standard peut être utilisé.
 
f) en fonction de nos besoins en qualité et de notre limitation en bande passante pour les envois des images, je préconise une résolution de X x Y et un taux de compression de 35%
 
voila, ce n'est qu'une idée pondue à 1H50 du matin en 5 minutes...
 
à creuser donc

Tharkie: merci pour ce beau dossier pondu à 1h50 du mat. Cela avait déjà été fait de la sorte lors du test d'acceptation dont je parle plus haut, j'espérait trouver l'introuvable et surtour Calcoran synthétise très bien l'idée du chef et surtout de celui-là. Je pense que nous en arriverons à cette situation là, à nouveau, un nouveau rapport sera rédigé encore plus complet et il faudra probablement que je lui donne un coup de boules parscque c'est un têtu qu'il faut parfois un peu secouer ;-)
Merci à toi Tharkie

je t'en prie

 
Nan mais là tu dois confondre avec Bastian
 

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!  
 
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).