forked from tTh/FloatImg
encore un peu de mieux dans la doc
This commit is contained in:
parent
6d0e6d9b0c
commit
db715485a2
|
|
@ -110,9 +110,10 @@ basiques en C, gérant la structure des données d'image en mémoire
|
|||
et sur disque. Ça a été imaginé de façon presque empirique,
|
||||
mais nous sommes tous là pour améliorer les choses, dans
|
||||
la mesure de nos moyens.
|
||||
Nous allons donc directement rentrer au cœur du problème.
|
||||
Nous allons donc directement rentrer au cœur du problème,
|
||||
en écrivant quelques lignes de code.
|
||||
|
||||
Pour commencer par quelques chose de simple,
|
||||
Pour commencer par quelque chose de simple,
|
||||
nous allons créer une image RGB\index{RGB} complètement noire,
|
||||
puis l'enregistrer dans un fichier \texttt{.fimg}\index{.fimg},
|
||||
un format complètement inconnu, puisque je viens de l'inventer
|
||||
|
|
@ -295,9 +296,9 @@ pas être la même chose dans l'avenir.
|
|||
|
||||
\subsection{Les fondations}\index{lib/}
|
||||
|
||||
La première chose à voir est la gestion dynamique de la mémoire occupée
|
||||
par tous ces pixels flottants, ce est un sujet parois
|
||||
délicat\footnote{GC}.
|
||||
La première chose que nous devons absolument voir est la gestion
|
||||
dynamique de la mémoire qui sera occupée par tous ces pixels flottants,
|
||||
ce qui est un sujet parfois délicat\footnote{GC or not GC ?}.
|
||||
Elle est donc faite, à la base, par ces deux fonctions~:
|
||||
|
||||
\begin{verbatim}
|
||||
|
|
@ -306,7 +307,7 @@ int fimg_destroy(FloatImg *fimg);
|
|||
\end{verbatim}
|
||||
|
||||
L'appelant doit lui-même gérer le descripteur d'image (une structure
|
||||
C décrite plus haur) en le considérant comme un type semi-opaque dont
|
||||
C décrite plus haut) en le considérant comme un type semi-opaque dont
|
||||
la forme peut varier. Certains membres de cette structure sont
|
||||
documentés dans ce document, et les autres sont dangereux à
|
||||
toucher. Les types d'images actuellement gérés sont les trois grands
|
||||
|
|
@ -326,18 +327,27 @@ Recharger une image depuis un fichier nécessite que celle-ci et
|
|||
l'image de destination en mémoire
|
||||
ait précisément les mêmes caractéristiques
|
||||
(taille, type...), donc l'image en ram doit être
|
||||
pré-allouée. Mias comment peut-on connaitre ces valeurs ?
|
||||
|
||||
\begin{verbatim}
|
||||
int fimg_fileinfos(char *fname, int datas[3]);
|
||||
\end{verbatim}
|
||||
pré-allouée. On peut connaitre ces valeurs en appelant
|
||||
\texttt{int fimg\_fileinfos(char *fname, int datas[3])}.
|
||||
|
||||
Si tout s'est bien passé (valeur retournée égale à 0),
|
||||
on va trouver la largeur dans \texttt{datas[0]},
|
||||
la hauteur dans \texttt{datas[1]} et le type dans \texttt{datas[2]}.
|
||||
la hauteur dans \texttt{datas[1]} et le type dans
|
||||
\texttt{datas[2]}\footnote{La fonction
|
||||
\texttt{fimg\_type\_is\_valid(int type)} peut vous aider}.
|
||||
|
||||
Je sais aussi que certains d'entre vous aiment la facilité, aussi
|
||||
je vais vous révéler l'existence d'un nouveau truc bien plus
|
||||
simple, une fonction qui enchaine ces deux actions
|
||||
(allocation, puis lecture), et s'utilise
|
||||
comme ça :
|
||||
|
||||
\begin{verbatim}
|
||||
FloatImg head;
|
||||
memset(&head, 0, sizeof(FloatImg));
|
||||
foo = fimg_create_from_dump("lena.fimg", &head);
|
||||
\end{verbatim}
|
||||
|
||||
La fonction \texttt{fimg\_type\_is\_valid(int type)} peut
|
||||
vous aider.
|
||||
|
||||
% _________
|
||||
|
||||
|
|
@ -436,22 +446,26 @@ Et le résultat est très moyen : il n'y a pas d'interpolation.
|
|||
|
||||
% ----------------------------------
|
||||
|
||||
\subsection{Exportation}\index{export}\label{export}
|
||||
\subsection{Exportation \& Importation}\index{export}\label{export}
|
||||
|
||||
Notre format de fichier étant totalement inconnu, il nous
|
||||
faut bien exporter nos images en quelque chose de plus
|
||||
connu. Bien entendu, c'est toujours affaire de compromis
|
||||
entre précision de valeurs et taille des fichiers.
|
||||
|
||||
Il faut aussi reconnaitre que c'est un peu la jungle dans les
|
||||
formats de fichiers d'image\dots
|
||||
Et dans le sens inverse, il serait bien de savoir importer
|
||||
le monde extérieur dans nos sombres caves à pixel.
|
||||
Il faut quand même reconnaitre que c'est un peu la jungle dans les
|
||||
formats de fichiers d'image, ce qui explique le retard
|
||||
dans ce domaine\dots
|
||||
|
||||
\subsubsection{Vers PNM}\index{PNM}
|
||||
|
||||
Nous avons ici 16 bits par composante, mais au prix
|
||||
d'une taille énorme sur les fichiers. D'autre coté,
|
||||
d'une taille énorme sur les fichiers. D'un autre coté,
|
||||
l'utilisation du codage \textsc{ascii}\index{ascii}
|
||||
(alors qu'on pourrait mettre du binaire, plus compact) y est pour quelque chose.
|
||||
(alors qu'on pourrait mettre du binaire, plus compact) y est
|
||||
pour quelque chose.
|
||||
|
||||
\begin{verbatim}
|
||||
int fimg_save_as_pnm(FloatImg *head, char *fname, int flags);
|
||||
|
|
@ -463,29 +477,58 @@ Le bit \texttt{0} du paramètre \texttt{flags} mis à \texttt{1} demande
|
|||
Et si il est à zéro, c'est la fonction de recherche de valeur
|
||||
maximale (cf page \pageref{contraste}) qui est utilisée.
|
||||
|
||||
Le bit \texttt{1} permettra bientôt\index{vaporware} de demander
|
||||
l'enregistrement de métadonnées\index{metadata} pertinentes, telle
|
||||
que l'epochtime de l'enregistrement.
|
||||
|
||||
Les autres bits ne sont pas utilisés et doivent être à zéro.
|
||||
|
||||
\subsubsection{Vers PNG}\index{PNG}
|
||||
|
||||
Actuellement, on peut enregistrer uniquement en mode RGB, 8 bits par composante,
|
||||
mais on a quand même une bonne compression, ça compense.
|
||||
J'utilise \textsl{libpnglite} avec qui j'ai un peu de mal à suivre.
|
||||
Mais je me soigne. Le mode 16 bits va bientôt arriver.
|
||||
|
||||
\begin{verbatim}
|
||||
int fimg_save_as_png(FloatImg *src, char *outname, int flags);
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\subsubsection{Vers TIFF}\index{TIFF}
|
||||
|
||||
Le format canonique de la PAO\index{PAO} du siècle dernier. Il permet
|
||||
de gérer une foultitude de formats numériques. C'est aussi un format
|
||||
classique proposé par les scanners corporates.
|
||||
|
||||
To be done\index{XXX}
|
||||
|
||||
\subsubsection{Vers FITS}\index{FITS}
|
||||
|
||||
Essentiellement des images d'astronomie.
|
||||
|
||||
To be done\index{XXX}
|
||||
|
||||
|
||||
\subsection{Utilitaires}
|
||||
|
||||
Commençons par quelques petits trucs pour nous faciliter la vie
|
||||
dans des domaines annexes,
|
||||
tels que l'interprétation d'arguments dans la ligne de commande ou un
|
||||
fichier de configuration.
|
||||
|
||||
\begin{verbatim}
|
||||
int parse_WxH(char *str, int *pw, int *ph)
|
||||
int parse_double(char *str, double *dptr)
|
||||
int format_from_extension(char *fname)
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
La fonction \texttt{int format\_from\_extension(char *fname)} examine un
|
||||
nom defichier tel que \texttt{lena.xxx}, et retourne, si la partie
|
||||
\texttt{xxx} un éventuel nombre positif, dont les valeurs sont dans floatimg.h
|
||||
le valeureux.
|
||||
Les extensions connues sont : fimg, png, pnm et tiff.
|
||||
|
||||
To be continued\index{XXX}
|
||||
|
||||
|
||||
|
|
@ -504,7 +547,8 @@ int fimg_killcolors_b(FloatImg *fimg, float fval);
|
|||
|
||||
\subsection{Filtrages}
|
||||
|
||||
To be done\index{XXX}
|
||||
To be done\index{XXX}, et il faut que je réfléchisse au traitement
|
||||
des bords d'image.
|
||||
|
||||
|
||||
% ----------------------------------
|
||||
|
|
|
|||
|
|
@ -160,6 +160,11 @@ FimgFileHead filehead;
|
|||
fprintf(stderr, ">>> %-25s ( '%s' %p )\n", __func__, fname, head);
|
||||
#endif
|
||||
|
||||
/*
|
||||
* may be we can crash coredump here if the head
|
||||
* descriptor is not blank ?
|
||||
*/
|
||||
|
||||
fp = fopen(fname, "r");
|
||||
if (NULL==fp) {
|
||||
perror(fname);
|
||||
|
|
|
|||
Loading…
Reference in New Issue