Comment réduire le nombre de couleurs d'une image

[Marc56]

L'originale faisait 126ko en png

Pour faire des tests objectifs, partir plutôt d'un BMP ou autre format non-compressé.
(même en PNG sans compression, une image n'a pas la même taille qu'en BMP sans compression)

[Ar-S]

L'originale faisait 126ko en png

Pour faire des tests objectifs, partir plutôt d'un BMP ou autre format non-compressé.
(même en PNG sans compression, une image n'a pas la même taille qu'en BMP sans compression)

Mon PNG 24 bits était tout à fait ressemblant au rendu bpg. De toutes façons la différence de qualité entre le jpg et bpg dans ce dernier test ne souffre d'aucune discution. Je doute que la conversion bmp/jpg/bpg puisse donner un résultat complètement différent.

[djes]

L'originale faisait 126ko en png

Pour faire des tests objectifs, partir plutôt d'un BMP ou autre format non-compressé.
(même en PNG sans compression, une image n'a pas la même taille qu'en BMP sans compression)

Mon PNG 24 bits était tout à fait ressemblant au rendu bpg. De toutes façons la différence de qualité entre le jpg et bpg dans ce dernier test ne souffre d'aucune discution. Je doute que la conversion bmp/jpg/bpg puisse donner un résultat complètement différent.

Je pense qu'il parlait du BMP pour avoir la taille "brute" de l'image, sans compression du tout.

[Zorro]

@Ar-s ; là oui, sur le nuancier les artefacts Jpg apparaissent bien mieux

apres, je sais pas si BPG n'ajoute pas un "lissage" type Flou gaussien pour arriver a ce stade
et eviter le "carrelage" du Jpg ...
mais ça semble pas mal en effet ...

[Ar-S]

Dernier test en montant un peu la qualité du BPG.
Ici 4 formats : L'original BMP, sa conversion PNG puis le BPG et je JPG
Je mets pas l'image directement car elle fait 2000 px de haut mais la voici en lien : http://share.ldvmultimedia.com/testbpg-3.png

[Shadow]

BPG est réellement un format d'avenir je pense, ya aucun doute sur son efficacité !
J'ai fais des Test, pour rester en qualité le plus proche, j'ai mis:

15 (quantizer)
Chroma format = 444 -> pour conserver les couleurs
Prefered color space: RGB (Je sais pas si YCBCR reste ok)
Compression Level: Max -> 9
Bit depth: 8

Avec ça sur un test d'une image, elle fais quand même 2 fois moins en taille
que JPG qualité maximale.

De toute façon c'est indiscutable, le BPG est le format du futur je pense.
Je comprends quedale comment ça fonctionne.

Oui avec BPG tu pers en détail si tu force trop et en résolution, l'image semble flou.

[Shadow]

Voici une traduction du BPG fais par Micoute lui même:

Spécification BPG

Version 0.9.5

Copyright (c) 2014-2015 Fabrice Bellard

1. Introduction
---------------

BPG est un format de compression d'image sans perte et sans perte basé sur HEVC
[1]. Il prend en charge les niveaux de couleurs YCbCr, RGB et YCgCo avec un
Canal alpha facultatif. CMYK est pris en charge en réutilisant la chaîne alpha
pour coder un composant blanc supplémentaire. La profondeur de bit de chaque
composant est de 8 à 14 bits. Les valeurs de couleur sont stockées soit dans
la gamme complète (boîtier JPEG) ou gamme limitée (boîtier vidéo). L'espace de couleur
YCbCr est soit BT 601 (boîtier JPEG), BT 709 ou BT 2020.

La chroma peut être sous-échantillonnée d'un facteur deux en horizontale ou les deux
dans les directions horizontale et verticale (4: 4: 4, 4: 2: 2 ou 4: 2: 0
les formats chroma sont pris en charge). Afin de pouvoir transcoder les images JPEG
ou des images vidéo sans modification de la chroma, JPEG et
Les positions de l'échantillon de chroma MPEG2 sont prises en charge.

Le décodage progressif et l'affichage sont pris en charge par l'entrelacement des
données alpha et couleur.

Les métadonnées arbitraires (telles que EXIF, profil ICC, XMP) sont prises en charge.

Les animations sont prises en charge en tant que fonctionnalité facultative. Les décodeurs
ne suportent pas l'affichage de la première image de l'animation.

2) conventions de bitstream
------------------------

Le flux de bits est aligné sur les octets et les champs de bits sont lus de la plupart
des bits significatifs aux bits moins significatifs dans chaque octet.

- u (n) est un entier non signé stocké sur n bits.

- ue7 (n) est un entier non signé d'au plus n bits stocké sur une variable
  nombre d'octets. Tous les octets sauf le dernier ont un '1' comme
  premier bit. L'entier non signé est représenté comme la
  Concaténation des mots-clés des 7 bits restants. Seulement le plus court
  codage pour un entier non signé donné sera accepté par le
  décodeur (c'est-à-dire le premier octet n'est jamais 0x80). Exemple:

  Octets encodés Valeur entière non signée
  0x08 8
  0x84 0x1e 542
  0xac 0xbe 0x17 728855

- ue (v): entier non signé 0-ième ordre Exp-Golomb-codé (voir
  spécification HEVC).

- b (8) est un octet arbitraire.

3) Format de fichier
--------------

3.1) Syntaxe
-----------

heic_file() {

file_magic u(32)

pixel_format u(3)
alpha1_flag u(1)
bit_depth_minus_8 u(4)

color_space u(4)
extension_present_flag u(1)
alpha2_flag u(1)
limited_range_flag u(1)
animation_flag u(1)

picture_width ue7(32)
picture_height ue7(32)

picture_data_length ue7(32)
if (extension_present_flag)
extension_data_length ue7(32)
extension_data()
}

hevc_header_and_data()
}

extension_data()
{
while (more_bytes()) {
extension_tag ue7(32)
extension_tag_length ue7(32)
if (extension_tag == 5) {
animation_control_extension(extension_tag_length)
} else {
for(j = 0; j < extension_tag_length; j++) {
extension_tag_data_byte b(8)
}
}
}
}

animation_control_extension(payload_length)
{
loop_count ue7(16)
frame_period_num ue7(16)
frame_period_den ue7(16)
while (more_bytes()) {
dummy_byte b(8)
}
}

hevc_header_and_data()
{
if (alpha1_flag || alpha2_flag) {
hevc_header()
}
hevc_header()
hevc_data()
}

hevc_header()
{
hevc_header_length ue7(32)
log2_min_luma_coding_block_size_minus3 ue(v)
log2_diff_max_min_luma_coding_block_size ue(v)
log2_min_transform_block_size_minus2 ue(v)
log2_diff_max_min_transform_block_size ue(v)
max_transform_hierarchy_depth_intra ue(v)
sample_adaptive_offset_enabled_flag u(1)
pcm_enabled_flag u(1)
if (pcm_enabled_flag) {
pcm_sample_bit_depth_luma_minus1 u(4)
pcm_sample_bit_depth_chroma_minus1 u(4)
log2_min_pcm_luma_coding_block_size_minus3 ue(v)
log2_diff_max_min_pcm_luma_coding_block_size ue(v)
pcm_loop_filter_disabled_flag u(1)
}
strong_intra_smoothing_enabled_flag u(1)
sps_extension_present_flag u(1)
if (sps_extension_present_flag) {
sps_range_extension_flag u(1)
sps_extension_7bits u(7)
}
if (sps_range_extension_flag) {
transform_skip_rotation_enabled_flag u(1)
transform_skip_context_enabled_flag u(1)
implicit_rdpcm_enabled_flag u(1)
explicit_rdpcm_enabled_flag u(1)
extended_precision_processing_flag u(1)
intra_smoothing_disabled_flag u(1)
high_precision_offsets_enabled_flag u(1)
persistent_rice_adaptation_enabled_flag u(1)
cabac_bypass_alignment_enabled_flag u(1)
}
trailing_bits u(v)
}

hevc_data()
{
for(i = 0; i < v; i++) {
hevc_data_byte b(8)
}
}

frame_duration_sei(payloadSize)
{
frame_duration u(16)
}


3.2) Sémantique
--------------

     'File_magic' est défini comme 0x425047fb.

     'Pixel_format' indique le sous-échantillonnage chroma:

       0: Niveaux de gris
       1: 4: 2: 0. Chroma à la position (0.5, 0.5) (position chroma JPEG)
       2: 4: 2: 2. Chroma à la position (0.5, 0) (position chroma JPEG)
       3: 4: 4: 4
       4: 4: 2: 0. Chroma en position (0, 0,5) (position chroma MPEG2)
       5: 4: 2: 2. Chroma en position (0, 0) (position chroma MPEG2)

       Les autres valeurs sont réservées.
       
     'Alpha1_flag' et 'alpha2_flag' donnent des informations sur l'avion alpha:

       Alpha1_flag = 0 alpha2_flag = 0: pas de plan alpha.

       Alpha1_flag = 1 alpha2_flag = 0: alpha présent. La couleur n'est pas
       prémultipliée.
        
       Alpha1_flag = 1 alpha2_flag = 1: alpha présent. La couleur est
       prémultipliée. Les résultantes R', G', B' non prémultipliées
       peuvent être récupérées comme suit:
          
         if A! = 0
           R '= min (R / A, 1), G' = min (G / A, 1), B '= min (B / A, 1)
         else
           R '= G' = B '= 1.
         
       Alpha1_flag = 0 alpha2_flag = 1: le plan alpha est présent et
       contient la composante de couleur W (couleur CMJN). Le CMJN résultant
       des données peuvent être récupérées comme suit:

         C = (1 - R), M = (1 - G), Y = (1 - B), K = (1 - W).
     
       Dans le cas où aucun profil de couleur n'est spécifié, la couleur sRGB R'G'B'
       voit être calculée comme suit:

         R '= R * W, G' = G * W, B '= B * W.

     'Bit_depth_minus_8' est le nombre de bits utilisés pour chaque composante
     moins 8. Dans cette version de la spécification, la profondeur de bit_moins_8
     <= 6.

     'extension_present_flag' indique que les données d'extension sont
     présentes.

     'color_space' spécifie comment convertir les plans de couleur en
     RVB. Il doit être 0 lorsque pixel_format = 0 (niveaux de gris):

       0: YCbCr (BT 601, identique à JPEG et HEVC matrix_coeffs = 5)
       1: RGB (ordre des composants: G B R)
       2: YCgCo (identique à HEVC matrix_coeffs =
       3: YCbCr (BT 709, identique à HEVC matrix_coeffs = 1)
       4: YCbCr (système de luminance non constante BT 2020, identique à HEVC
       coefficient matrice = 9)
       5: réservé au système de luminance constante BT 2020, non
       prise en charge dans cette version de la spécification.

       Les autres valeurs sont réservées.

       YCbCr est défini à l'aide de la matrice de conversion BT 601, BT 709 ou BT 2020
       
       Pour RGB, G est mémorisé en tant que plan Y. B dans le plan Cb et R dans
       le plan Cr.

       YCgCo est défini comme HEVC matrix_coeffs = 8. Y est stocké dans le plan
       Y. Cg dans le plan Cb et Co dans le plan Cr.
       
       Si aucun profil de couleur n'est présent, les données de sortie RVB sont supposées
       être dans l'espace couleur sRGB [6].

     'Limited_range_flag': en face du HEVC video_full_range_flag.
     La valeur zéro indique que la gamme complète de chaque composante couleur
     est utilisée. La valeur un indique qu'une gamme limitée
     est utilisée:

          - (16 << (bit_depth - à (235 << (bit_depth - ) pour Y
     et G, B, R,
          - (16 << (bit_depth - à (240 << (bit_depth - ) pour Cb et Cr.

     Pour l'espace de couleur YCgCo, la limitation de portée doit être effectuée sur
     les données RVB.

     Le plan alpha (ou W) utilise toujours la gamme complète.

     'Animation_flag'. La valeur '1' indique que plusieurs
     images sont codées dans les données hevc. L'extension de contrôle de l'animation
     doit être présente. Si le décodeur ne supporte pas
     les animations, il décodera la première frame seulement et ignorera
l'Information sur l'animation.

     'Picture_width' est la largeur de l'image en pixels. La valeur 0 est
     interdite.

     'Picture_height' est la hauteur de l'image en pixels. La valeur 0 est
     interdite.

     'Image_data_length' est la longueur de la donnée de l'image en octets.
     La valeur spéciale de zéro indique que les données d'image vont jusqu'à
     la fin du fichier.

     'Extension_data_length' est la longueur des données d'extension en octets.

     'Extension_data ()' est la donnée d'extension.

     'Extension_tag' est la balise d'extension. Les valeurs suivantes sont définies:

       1: données EXIF.

       2: profil ICC (voir [4])

       3: XMP (voir [5])

       4: Miniature (la miniature doit être une version à résolution plus basse
       de l'image et stockée au format BPG).

       5: données de contrôle d'animation.

     Le décodeur doit ignorer les balises qu'il ne supporte pas.

     'Extension_tag_length' est la longueur en octets de la balise d'extension.

     'Loop_count' donne le nombre de fois que l'animation doit être
     jouée. La valeur de 0 signifie infinie.
     
     'Frame_period_num' et 'frame_period_den' encodent la valeur par défaut
     le délai entre chaque image sous la forme frame_period_num/frame_period_en
     secondes. La valeur de 0 pour 'frame_period_num' ou
     'Frame_period_den' est interdit.
     
     'Hevc_header_length' est la longueur en octets des données suivantes
     Jusqu'à et incluant 'trailing_bits'.

'Log2_min_luma_coding_block_size_minus3',
     'Log2_diff_max_min_luma_coding_block_size',
     'Log2_min_transform_block_size_minus2',
     'Log2_diff_max_min_transform_block_size',
     'Max_transform_hierarchy_depth_intra',
     'Sample_adaptive_offset_enabled_flag', 'pcm_enabled_flag',
     'Pcm_sample_bit_depth_luma_minus1',
     'Pcm_sample_bit_depth_chroma_minus1',
     'Log2_min_pcm_luma_coding_block_size_minus3',
     'Log2_diff_max_min_pcm_luma_coding_block_size',
     'Pcm_loop_filter_disabled_flag',
     'Strong_intra_smoothing_enabled_flag', 'sps_extension_flag'
     'Sps_extension_present_flag', 'sps_range_extension_flag'
     'Transform_skip_rotation_enabled_flag',
     'Transform_skip_context_enabled_flag',
     'Implicit_rdpcm_enabled_flag', 'explicit_rdpcm_enabled_flag',
     'Extended_precision_processing_flag',
     'Intra_smoothing_disabled_flag',
     'High_precision_offsets_enabled_flag',
     'Persistent_rice_adaptation_enabled_flag',
     'Cabac_bypass_alignment_enabled_flag' sont
     Les champs correspondants de l'élément de syntaxe HEVC SPS.
         
     'Trailing_bits' a une valeur de 0 et a une longueur de 0 à 7
     Bits pour que les données suivantes soient alignées sur les octets.

     'Hevc_data ()' contient les données d'image HEVC correspondantes,
     À l'exclusion du premier code de début NAL (c'est-à-dire le premier 0x00 0x00 0x01
     Ou 0x00 0x00 0x00 0x01 octets). Les NAL VPS et SPS ne doivent pas être
     Inclus dans les données d'image HEVC. Le décodeur peut récupérer le
     Champs nécessaires de l'en-tête en effectuant les opérations suivantes
     hypothèses:

     - vps_video_parameter_set_id = 0
     - sps_video_parameter_set_id = 0
     - sps_max_sub_layers = 1
     - sps_seq_parameter_set_id = 0
     - chroma_format_idc: pour les données d'image:
         Chroma_format_idc = pixel_format
       pour les données alpha:
         Chroma_format_idc = 0.
     - separate_colour_plane_flag = 0
     - pic_width_in_luma_samples = ceil (picture_width / cb_size) * cb_size
     - pic_height_in_luma_samples = ceil (picture_height / cb_size) * cb_size
       Avec cb_size = 1 << log2_min_luma_coding_block_size
     - bit_depth_luma_minus8 = bit_depth_minus_8
     - bit_depth_chroma_minus8 = bit_depth_minus_8
     - max_transform_hierarchy_depth_inter = max_transform_hierarchy_depth_intra
     - scaling_list_enabled_flag = 0
     - log2_max_pic_order_cnt_lsb_minus4 = 4
     - amp_enabled_flag = 1
     - sps_temporal_mvp_enabled_flag = 1
     

     Codage de données Alpha:

     - Si des données alpha sont présentes, tous les NAL correspondants ont
       Nuh_layer_id = 1. Les NAL pour les données de couleur doivent avoir nuh_layer_id =
       0.
     - Les données Alpha doivent utiliser les mêmes tailles que les données de couleur et
       doivent avoir la même valeur entropy_coding_sync_enabled_flag que
       les données couleur.
     - Les couches Alpha doivent utiliser le même nombre d'unités de codage que la couleur
       des couches et doivent être intercalées avec des couches de couleur. Les NAL alpha
       doivent venir avant les couleurs NAL correspondants.

Codage d'animation:

     - Le préfixe optionnel SEI avec payloadType = 257 (défini dans
       Frame_duration_sei ()) spécifie que l'image doit être répétée
       le temps 'frame_duration'. 'Frame_duration' ne doit pas être nul. Si
       la durée du cadre SEI n'est pas présente pour un cadre donné,
       Frame_duration = 1 doit être assumé par le décodeur. Si les données alpha
       sont présentes, la durée de la trame SEI doit être présente uniquement
       Pour les données de couleur.
     
3.3) Profil HEVC
-----------------

Les flux de bits HEVC conformes doivent être conformes aux Principales 4: 4: 4 16 Toujours
Image, niveau 8.5 de la spécification HEVC avec les modifications des éléments suivants.

- separate_colour_plane_flag doit être 0 lorsque présent.

- bit_depth_luma_minus8 <= 6

- bit_depth_chroma_minus8 = bit_depth_luma_minus8

- explicit_rdpcm_enabled_flag = 0 (peu importe pour intra frames)

- extended_precision_processing_flag = 0

- cabac_bypass_alignment_enabled_flag = 0

- high_precision_offsets_enabled_flag = 0 (peu importe pour intra frames)

- Si l'image codée est supérieure à la taille indiquée par
Image_width et image_height, la partie inférieure droite de
l'image décodée doit être recadrée. Si une décimation horizontale (resp. Verticale) par
deux est faite pour la chroma et que la largeur (resp. height) est n
pixels, ceil(n/2) pixels doivent être conservés comme l'information chroma résultante.

Lorsque les animations sont présentes, les cadres suivants doivent être encodés avec les
modifications suivantes:

- Les couches P sont autorisées (mais les couches B ne sont pas autorisées).

- Seule l'image précédente peut être utilisée comme référence (d'où une taille DPB
  de 2 photos).

4) Choix de conception
-----------------

(Cette section est informative)

- Notre principe de conception était de garder le format aussi simple que possible
  tout en prenant le codec HEVC comme base. Notre principale mesure pour évaluer
  la simplicité était la taille d'un décodeur logiciel qui produit 32
  bit RGBA pixel data.

- Formats de pixels: nous voulions pouvoir convertir des images JPEG en BPG
  avec autant de perte que possible. Donc supportant le même espace de couleur
  (BT 601 YCbCr) avec la même gamme (gamme complète) et la plupart des
  formats de chroma JPEG autorisés (4: 4: 4, 4: 2: 2, 4: 2: 0 ou niveaux de gris) était
  obligatoire pour éviter de revenir à RGB ou faire un sous-échantillonnage ou
  interpolation.

- Support Alpha: le support alpha est obligatoire. Nous avons choisi d'utiliser un
  plan monochrome HEVC séparé pour le manipuler au lieu d'un autre
  format pour simplifier le décodeur. La couleur est soit
  non prémultipliée ou prémultipliée. L'alpha prémultiplié habituellement
  donne une meilleure compression. L'alpha non prémultiplié est pris en charge dans
  ce cas, aucune perte n'est nécessaire sur les composants de couleur. Afin de permettre
  l'affichage progressif, les données alpha et couleur sont entrelacées (la
  Nuh_layed_id Le champ NAL est 0 pour les données de couleur et 1 pour les données alpha).
  Les couches alpha et de couleur devraient contenir le même nombre
  d'unités de codage et chaque couche alpha devrait être avant la
  couche de couleur correspondante. Étant donné que les couches alpha sont généralement plus petites
  que les couches de couleur, il permet un affichage progressif, même s'il existe
  une seule couche.

- Espaces de couleur: En plus de YCbCr, RGB est pris en charge pour la haute qualité
  ou sans perte la plupart des cas. YCgCo est pris en charge car il peut donner
  des résultats légèrement meilleurs que YCbCr pour des images de haute qualité. CMJN est
  pris en charge afin que les fichiers JPEG contenant cet espace de couleur puissent être
  convertis. Le plan alpha est utilisé pour stocker le plan W (1-K).
  Les données sont stockées avec des composantes inversées (1-X) afin que la conversion
  en RGB soit simplifiée. Le soutien de BT 709 et BT 2020 (Luminance non
  constante) l'encodages YCbCr et les valeurs de la couleur de gamme limitée
  ont été ajoutées pour réduire les pertes lors de la conversion des images vidéo.

- Profondeur de bits: nous avons décidé de supporter les profondeurs de bits HEVC 8 à 14.
  La complexité ajoutée est faible et elle permet de supporter une qualité élevée
  des images provenant de caméras.

- Format du fichier image: garder un flux HEVC complètement standard
  a entraîné une analyse plus difficile de l'en-tête de l'image qui est
  un problème pour les différents utilitaires d'image pour obtenir l'informations de l'image
  de base (format de pixel, largeur, hauteur). Nous avons donc ajouté une petite
  en-tête avant le flux de bits HEVC. L'en-tête de l'image est un octet
  par conséquent, il est facile à analyser.

- flux de bits HEVC: les en-têtes HEVC standard (les NAL VPS et SPS)
  donne un frais plafond d'environ 60 octets sans valeur ajoutée dans le cas de
  compression d'image. Puisque le plan alpha utilise un flux de bit HEVC différent,
  il ajoute également le même plafond. Nous avons donc supprimé le VPS
  et SPS NALs et ajouté une très petite en-tête avec les informations équivalentes
  (généralement 4 octets). Nous avons également supprimé le premier code de démarrage NAL
  qui n'est pas utile. Il est encore possible de reconstruire un
  flux HEVC standard pour alimenter un décodeur matériel non modifié si nécessaire.

- Extensions: les métadonnées sont stockées au début du fichier afin
  qu'ils puissent être lus en même temps que l'en-tête. Depuis les métadonnées
  ont tendance à évoluer plus rapidement que les formats d'image, nous avons laissé une place pour
  l'extension à l'aide d'une représentation (tag, lengh). Le décodeur peut
  sauter facilement toutes les métadonnées parce que leur longueur est explicitement
  stockée dans l'en-tête de l'image.

- Animations: elles sont intéressantes par rapport aux xidéos courtes WebM ou MP4
  pour les raisons suivantes:
    * La transparence est prise en charge
    * Le codage sans perte est pris en charge
    * Les ressources de décodage sont plus petites qu'avec une vidéo générique
      parce que seules deux images doivent être stockées (taille DPB = 2).
    * Les animations devraient être petites, de sorte que le décodeur puisse mettre en cache
      tous les cadres décodés en mémoire.
    * L'animation peut être décodée comme une image fixe si le décodeur
      ne prend pas en charge les animations.
  Par rapport aux autres formats d'image animés (GIF, APNG, WebP), le
  taux de compression est habituellement beaucoup plus élevé en raison de l'interaction de prédiction
de trameHEVC
  .

5) Références
-------------

[1] Codage vidéo haute efficacité (HEVC) version 2 (Recommandation UIT-T H.265)

[2] JPEG File Interchange Format version 1.02 (http://www.w3.org/Graphics/JPEG/jfif3.pdf)

[3] EXIF ??version 2.2 (JEITA CP-3451)

[4] Le Consortium international de couleurs (http://www.color.org/)

[5] Plate-forme de métadonnées extensibles (XMP) http://www.adobe.com/devnet/xmp.html

[6] espace de couleur sRGB, CEI 61966-2-1

[Shadow]

Perso je comprends quedale, si quelqu'un veux être plus précis se serais super

[Ar-S]

Ahlala... Merci pour l'effort Micoute mais vous aimez bien mettre des pavés pour rien hein..
Tout d'abord quand on traduit quelque chose, on indique la SOURCE, l'url de base en V.O histoire qu'on puisse aller voir la page originale si on sent des coquilles dans la traduction.

A partir du point 3.1 ça ne sert pas à grand chose... du code est du code :

Code : Tout sélectionner

{
for(i = 0; i < v; i++) {
hevc_data_byte b(8)
}
}

frame_duration_sei(payloadSize)
{
frame_duration u(16)
}

et si vous postez du code, mettez le entre balise code aussi.

Second point il y a des choses que vous ne "quotez" pas donc les symboles sont remplacés par des smiley ce qui ne veut plus rien dire..
Ensuite des trucs comme :

'Alpha1_flag' et 'alpha2_flag' donnent des informations sur l'avion alpha:

Vous êtes sérieux ?
Enfin vous voulez des infos sur les commandes, vous lancez bpgenc.exe , bpgview.exe et bpgdec.exe

[falsam]

Quand le format JPEG 2000 (Natif avec PureBasic) est sorti en 1997 tout le monde à crié au miracle. C'était le format qui allait remplacé le JPG car même en cas de forte compression la qualité de l'image était respectée.
JPEG 2000 - la nouvelle norme pour le codage d'images

Vingt ans après le constat : Ce format n'a pas réussit à s'imposer. Le web l'ignore ainsi que la plupart des applications de traitements d'images. Je pense que l'avenir du BPG me semble lui aussi compromis bien que meilleurs que le JPG.

Perso je comprends quedale, si quelqu'un veux être plus précis se serais super

Trois fois que tu fais cette demande ! A mon avis tu n'en saura pas plus.

Enfin vous voulez des infos sur les commandes, vous lancez bpgenc.exe , bpgview.exe et bpgdec.exe

Ar-S a sorti les doigts de ses moufles et a chercher à comprendre.

Tu n'as pas la compétence (et moi non plus) pour recréer algorithme de compression / décompression de ce format d'image. Utilise ce qui existe déja comme l'a fait Ar-S.

[TazNormand]

@Shadow : tu as aussi le format FLIF

[djes]

Complètement d'accord avec Falsam.

Par contre, je peux te donner une piste, si tu veux t'amuser. Tu la connais peut-être, c'est une des équations de la droite, à partir de laquelle on peut faire quantité de choses.

y = Ax + B

Vu comme ça, ça ne te dit peut-être rien. En fait, c'est une équation qui permet, à partir d'un seul coefficient, de créer plusieurs valeurs...

Par exemple, mettons que B soit ton premier nombre. Disons B = 10. A est ton coefficient, mettons A = 0.1. Tu appliques l'équation 5 fois, et tu obtiens 10, 10.1, 10.2, 10.3, 10.4, 10.5. Tu vois l'intérêt ?

Maintenant, la difficulté, ça va être de trouver ces coefficients.

Prenons une image, disons que tous les 10 pixels, tu calcules la différence de couleur pour le rouge, pour le vert, et pour le bleu. Par exemple :

Code : Tout sélectionner

différence pour le rouge = rouge du pixel 10 - rouge du pixel 1.

et donc

Code : Tout sélectionner

coefficient pour le rouge = différence pour le rouge / 10

Pourquoi 10 ? Parce que 10 pixels... Donc, en prenant par exemple la valeur 64 pour le rouge du premier pixel, la valeur 128 pour le rouge du dixième pixel, on a :

Code : Tout sélectionner

A = (128 - 64) / 10 = 6.4

Et on obtient pour les dix pixels 64, 64+6.4 = 70.4, 70.4+6.4 = 76.8, etc. Le dernier pixel (128) devient le premier de la série suivante.

Si tu fais ça pour toute l'image, tu vas pouvoir créer une approximation de celle-ci, sous forme de dégradés de 10 pixels de large. Si ton image est faite d'aplats ou de dégradés, ce sera très efficace ! Par contre, pour les images très détaillés, il faudra augmenter la précision, 3 pixels au lieu de 10 par exemple...

Enfin, il va falloir trouver un moyen pour stocker ces valeurs dans un fichier, sans que cela prenne trop de place. Souvent, on utilise une "marque", c'est à dire un nombre qui va servir à dire ce que l'on stocke (coefficient, ou autre). Le format binaire est évidemment le plus adapté pour gagner de l'espace.

Je te laisse réfléchir à tout ça...

[Zorro]

j'essaie de comprendre :
tu lui proposes en fait une compression avec perte qui ressemble a une forme de lissage
ça risque de creer un effet "carreau" non ?
car ça va supprimer par la moyenne des différences de teintes entre les verts par exemple

pour mon prg de reduction de couleurs j'utilise une truc tres similaire , en uniformisant les pixels qui serai "proche" en couleur de la couleur de mon crayon (palette)

1- je genere une palette en partant des couleurs de l'image (si l'image d'origine a 16 millions de couleur , ma palette en fera autant !)
2- ensuite je redessine mon image en utilisant les crayons de ma palette reduite a X couleurs en fonction de ce qu'on veux....

mon prg calcul la "distance" qu'il y a entre la couleur du pixel de l'image d'origine , et l'une des couleurs de ma palette nouvellement recréé
si c'est assez proche (avec une tolerance reglable) , j'utilise ce crayon precis pour dessiner le point sur la nouvelle image de sortie

le defaut, il faut que la tolerance soit suffisante, sinon risque de "trou" dans le dessin, puisque n'ayant pas trouvé le bon crayon ...

mais étonnamment, la reduction de couleur donne de bon résultat !!
en clair ça reviens a dire a un robot , voici 16 crayons de couleur varié
redessine moi cette image en les utilisants !

et lui prends le crayon qui se raproche le plus du point de l'image d'origine , et dessine avec

ps: j'ai meme ajouté la possibilité de lui imposer des couleurs qu'on choisi nous meme dans l'image

[djes]

Oui, c'est ça, en fait, c'est une base pour comprendre le JPEG, et ses carreaux (blocs) de 8x8, 16x16 ou autres pixels
A partir de ça, il peut créer un très bon algo, qui lui sera propre...

Comme les effets d'images et ce genre d'algo de compression sont très proches, pas étonnant que ton truc donne de bons résultats, des deux côtés... L'algorithmique est une forme d'art