Discussion :

[shanoc]

Bonjour.

Bon, pour résumer, suite à ma frustration, dans l'utilisation, d'un logiciel de rendue ne disposant pas de post-processing, et voulant expérimenter certaines idées de tone-maping, je me suis mis dans l'idée de créer une petit application en C++.

J'avais fais un peut de python avant, c'est une première pour mois.

Je me suis décidé à procéder par étapes:

-Regarder comment marche le C++

-Essayer de créer une application console

-Lire et écrire dans des fichiers textes.

-Lire et écrire des fichiers .bmp

-Appliquer des modifications mathématique aux fichiers images.

-Remplacer le .bmp par de l'openExr

-Voire si ont peut aller plus loin.


Lire et écrire dans des fichiers textes, pas de problème.

En revanche, je bloque sur les images, la plupart des réponses que j'ai trouvé se résument à utiliser CImg, il ne semble pas exister de tutoriaux de A a Z.

Comme en plus je veux comprendre comment cela marche pour l'adaptation à l'openEXR, je coince.

Bref, existe il un tutoriel complet sur le chargement d'image et leurs manipulation en C++, avec explication sur la gestion des header et autre?

Merci

[Bousk]

Salut,

pour enregistrer une image il te suffit de trouver la documentation sur son format, et écrire correctement les données dans un fichier. Pour la lire, tu fais l'inverse.
Et vue que les formats d'image changent pas mal, il y a une lib par format que tu peux utiliser pour t'aider, ou des trucs plus complets à la CImg qui englobent le tout.
Un tel tuto n'aurait aucun intérêt puisque c'est juste l'implémentation d'un format documenté. Ca doit exister quelque part, mais ça n'apporte pas grand chose.

[shanoc]

OKay merci, bon, j'ai regardé, et ya des trucs que je ne comprend pas.

Si je prend le code d'exemple de microsoft pour le bitmap, je trouve ça

Header File

A Windows Bitmap Header File consists of 14 bytes of information:

bfType: This field occupies 2 bytes which are allocated for the ASCII characters “BM”. bfSize: This field occupies 4 bytes which indicate the size of the Bitmap file. bfReserved: This field occupies 4 bytes which are reserved for future use and should be 0. bfOffBits: This field occupies 4 bytes which specify the number of bytes from the beginning of the file to the starting Pixel Data byte.

Suivie du code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 typedef struct BMP1   
{      
         unsigned short bfType;   
         unsigned long  bfSize;
         unsigned short bfReserved1;
         unsigned short bfReserved2;
         unsigned long  bfOffBits;
 
         BMP1() { bfSize = 0; }
  };

Header Information

The Header Information of a Windows BMP format occupies at least 40 bytes:

biSize : 4 Bytes – This field indicates the size of the Header Information structure given in bytes biWidth : 4 Bytes – indicates the width of the bitmap in pixels. biHeight : 4 Bytes – indicates the height of the bitmap in pixels biPlanes : 2 Bytes – indicates the number of planes contained in the bitmap and must be set to 1. biBitCount: 2 Bytes – indicates the bitdepth of the bitmap pixel or bits per pixel. biCompression: 4 Bytes – indicates whether the bitmap data is Run Length Encoding or not. It should be 0 for uncompressed images biSizeImage: 4 Bytes – contains the length of the bitmap image data in bytes. This value is not necessary equal to the width multiplied by the height. biXPelsPerMeter: 4 Bytes – describes the resolution of the bitmap in pixels per meter. biYPelsPerMeter: 4 Bytes – describes the resolution of the bitmap in pixels per meter. biClrUsed: 4 Bytes – indicates the number of colors that is used in the bitmap. biClrImportant: 4 Bytes – signifies the number of significant colors.

Suivie de:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
typedef struct BMP2  
 
{  
      unsigned long  biSize;
      unsigned long  biWidth;
      unsigned long  biHeight;
      unsigned short biPlanes;
      unsigned short biBitCount;
      unsigned long  biCompression;
      unsigned long  biSizeImage;
      unsigned long biXPelsPerMeter;
      unsigned long biYPelsPerMeter;
      unsigned long  biClrUsed;
      unsigned long  biClrImportant; 
 
      BMP2() 
        {  
                biWidth
                = biHeight
                = biCompression
                = biSizeImage
                = biXPelsPerMeter
                = biYPelsPerMeter
                = biClrUsed
                = biClrImportant
                = 0;
                biSize= sizeof(BMP2);
                biPlanes = biBitCount 
                = 0;
         }
 };

Le PDF d'origine est ici: http://www.osram-os.com/Graphics/XPi...nipulation.pdf

Et la, je ne comprend pas comment le programme sait la taille des éléments: comment il sait que telle élément est sur 4 bytes, et le suivant sur 2 bytes?

Et c'est pareil pour d'autre formats.

J'ai eu la même chose avec le format OpenEXR en essayant diverses choses pour ma petite applis: alors que je pensais qu'elle me lirait le premier byte, elle ma directement crachée les 4 premier bytes d'un coup, en revanche, elle est devenue barjos sur la suite et à refusée de lire les 4 bytes d'attributs.

Il me manque une info


J'ai essaye de trouver comment dire au programme de lire une information codée sur n byte à telle position, mais mes résultats furent....variables.

Je suis sure que c'est un truc con en plus, faut dire que débuter le C++ avec des images........je dois etre maso....

[Bousk]

Faudrait être plus clair sur ce que tu comprends pas, parce que tu as toute la documentation précise et détaillée, à ce niveau-là à part un problème de lecture de l'anglais je vois pas où le souci peut se poser.
J'ai moi-même joué avec bmp il y a plusieurs années, implémenter un reader et un writer m'avait pris au total peut-être 2j avec le format documenté genre https://en.wikipedia.org/wiki/BMP_file_format et autres résultats Google si besoin.

Et la, je ne comprend pas comment le programme sait la taille des éléments: comment il sait que telle élément est sur 4 bytes, et le suivant sur 2 bytes?

Parce que c'est précisé dans la doc et le programme il ne fait rien de magique mais exécute ce que tu lui demandes d'exécuter. Si tu dois lire 4 octets, tu lui demandes et il le fait comme un bon petit soldat qu'il est.

J'ai essaye de trouver comment dire au programme de lire une information codée sur n byte à telle position, mais mes résultats furent....variables.

Si tu ne sais pas comment traiter un fichier, si tu ne connais pas std::istream, std::ifstream, read etc, ou gérer un flux ou buffer, tu manques de base et as donc des connaissances préliminaires à avoir.

[shanoc]

Parce que c'est précisé dans la doc et le programme il ne fait rien de magique mais exécute ce que tu lui demandes d'exécuter. Si tu dois lire 4 octets, tu lui demandes et il le fait comme un bon petit soldat qu'il est.

Dans l'exemple mis en PDF, le programme ne contient AUCUNE données de taille, d'ou l'aspect magique........

Si tu ne sais pas comment traiter un fichier, si tu ne connais pas std::istream, std::ifstream, read etc, ou gérer un flux ou buffer, tu manques de base et as donc des connaissances préliminaires à avoir.

istream/ifstream/ofstream/read/write, c'est bon, je manque de pratique.

Le format Bitmap est simple , bon a part quelque cas particulier (je crois que le BMP gère le RLE).

Une image bmp c'est en gros du RVB (Rouge Vert Bleu) , chaqu'un codé sur un octet.
L’entête donne des infos comme la taille en octet de l'image ,sa longueur et sa largeur , la taille d'un pixel en l'octet , et avec toutes ces info on peut afficher une image.
Et donc on connaît la taille des éléments (le BMP indique ) et le nombre de pixel de ton image (soit c'est écrit soir tu fait le calcul de longueur * largeur * taille en octet du pixel ).

Et c'est pareil pour d'autre formats.
Alors en gros pour les autres format :
Le PCX : c'est par palette , chaque octet représente une palette ou une compression RLE.
Le JPG : plus complexe , il est compressé avec de la Quantification , on réduisant les couleurs (on stocke principalement la luminosité) , et avec un codage de huffman.
LE GIF : de ce que j'ai compris une palette comme le PCX mais sans compression RLE.
Le PNG : aucune idée de sa compression , mais j'ai l'impression qu'il utilise du RLE et la zlib

Après Bousk a raison l’intérêt est très faible et il y'a des lib deja faite , allez un autre secret il y'a du code source deja fait sur github pour charger ou écrire sur un format particulier

Ouais mais comme je me sert de ça pour apprendre...
Pour le reste, il n'existe pas 36000 solution pour encoder une couleurs, doit même exister un format ou seul la température de couleurs est enregistrée.

Cette source est totalement moisie.
A ses hardeux, quand ils se mettent en software, c'est jamais très beau.


Les hardeux pensent le savoir car ils utilisent toujours des compilateurs préhistoriques, avec une configuration contemporaine du Kernighan & Ritchie, ou presque.

Donc, vos interrogations sont toutes à légitimes, GG.

Plutôt que de prendre le code tout moisi d'un obscure hardeux, allez voir du coté des propriétaires du format.

https://msdn.microsoft.com/en-us/lib...or=-2147217396

Attention aussi au fait que c'est du format binaire et que le C++ est très piégeux dans ce cas de figure. La documentation est en C car on n'est plus proche du matériel cher à nos hardeux.

Aaaah, oui, effectivement, je suis très doué pour taper à cote de se qu'il faut.

Pourtant le projet fourni tout ce qu'il faut dont une API C++:

J'aime avoir mal

[Bousk]

Dans l'exemple mis en PDF, le programme ne contient AUCUNE données de taille, d'ou l'aspect magique........

Le PDF te détaille explicitement la taille en octet de chaque membre de la structure et définit précisément sa signification dans le format.
Et rien ne t'interdit de trouver d'autres sources via ton moteur de recherche préféré si celle-ci ne te convient pas.

biSize : 4 Bytes – This field indicates the size of the Header Information structure given in bytes

unsigned long biSize; On peut difficilement faire plus clair et limpide.
Sauf à ne pas connaître les bases niveau 0 du langage et les types de données primitifs...

[Kannagi]

Le format Bitmap est simple , bon a part quelque cas particulier (je crois que le BMP gère le RLE).

Une image bmp c'est en gros du RVB (Rouge Vert Bleu) , chaqu'un codé sur un octet.
L’entête donne des infos comme la taille en octet de l'image ,sa longueur et sa largeur , la taille d'un pixel en l'octet , et avec toutes ces info on peut afficher une image.
Et donc on connaît la taille des éléments (le BMP indique ) et le nombre de pixel de ton image (soit c'est écrit soir tu fait le calcul de longueur * largeur * taille en octet du pixel ).

Et c'est pareil pour d'autre formats.

Alors en gros pour les autres format :
Le PCX : c'est par palette , chaque octet représente une palette ou une compression RLE.
Le JPG : plus complexe , il est compressé avec de la Quantification , on réduisant les couleurs (on stocke principalement la luminosité) , et avec un codage de huffman.
LE GIF : de ce que j'ai compris une palette comme le PCX mais sans compression RLE.
Le PNG : aucune idée de sa compression , mais j'ai l'impression qu'il utilise du RLE et la zlib

Après Bousk a raison l’intérêt est très faible et il y'a des lib deja faite , allez un autre secret il y'a du code source deja fait sur github pour charger ou écrire sur un format particulier

[bacelar]

Le PDF d'origine est ici: http://www.osram-os.com/Graphics/XPi...nipulation.pdf

Cette source est totalement moisie.
A ses hardeux, quand ils se mettent en software, c'est jamais très beau.

Et la, je ne comprend pas comment le programme sait la taille des éléments: comment il sait que telle élément est sur 4 bytes, et le suivant sur 2 bytes?

Les hardeux pensent le savoir car ils utilisent toujours des compilateurs préhistoriques, avec une configuration contemporaine du Kernighan & Ritchie, ou presque.

Donc, vos interrogations sont toutes à légitimes, GG.

Plutôt que de prendre le code tout moisi d'un obscure hardeux, allez voir du coté des propriétaires du format.

https://msdn.microsoft.com/en-us/lib...or=-2147217396

Attention aussi au fait que c'est du format binaire et que le C++ est très piégeux dans ce cas de figure. La documentation est en C car on n'est plus proche du matériel cher à nos hardeux.

Et c'est pareil pour d'autre formats.

Oui, c'est les mêmes chausse-trappes que tend le C++.

J'ai eu la même chose avec le format OpenEXR en essayant diverses choses pour ma petite applis

Pourtant le projet fourni tout ce qu'il faut dont une API C++:
https://github.com/openexr/openexr