Browse Source

encore un peu de mieux dans la doc

master
tth 2 years ago
parent
commit
db715485a2
  1. 86
      doc/the_floatimg_hack.tex
  2. 5
      lib/fimg-file.c

86
doc/the_floatimg_hack.tex

@ -110,9 +110,10 @@ basiques en C, gérant la structure des données d'image en mémoire @@ -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. @@ -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); @@ -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 @@ -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. @@ -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 @@ -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); @@ -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.
% ----------------------------------

5
lib/fimg-file.c

@ -160,6 +160,11 @@ FimgFileHead filehead; @@ -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…
Cancel
Save