31 Oct
2003
31 Oct
'03
4:02 p.m.
le champs max de l'entête doit être la valeur max du codage
et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le
niveau est 12 => champs max à 255 (et non 12)
31 Oct
31 Oct
5:15 p.m.
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud wrote:
le champs max de l'entête doit être la valeur max du codage
et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le
niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes
pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur
pourrait aussi etre presente):
Index: olena/oln/io/pnm_write_2d.hh
--- olena/oln/io/pnm_write_2d.hh Sat, 27 Sep 2003 18:30:39 +0200 burrus_n
(oln/u/44_pnm_write_ 1.4 600)
+++ olena/oln/io/pnm_write_2d.hh Fri, 31 Oct 2003 16:13:02 +0100 jb (oln/u/44_pnm_write_
1.4 600)
@@ -129,9 +129,7 @@
pnm2d_info info;
info.cols = im.ncols();
info.rows = im.nrows();
- oln::utils::f_minmax<oln_value_type(I)> f;
- traverse(f, im);
- info.max_val = f.max();
+ info.max_val = ntg_max_val(oln_value_type(I));
if (info.max_val > ntg::to_ntg(65535U))
return false;
2 Nov
2 Nov
6:10 p.m.
mandor <mandor(a)lrde.epita.fr> writes:
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud
wrote:
Non, il n'y a pas de vrai problème. Juste la sauvegarde des images sur
32 bits n'est plus possible (pgm ne va pas jusque la), mais c'est plus
sain d'obliger l'utilisateur a convertir en 16 bits lui même si il
veut sauver, plutôt que d'accepter puis de refuser de temps en temps
si il a une valeur trop grande.
le champs max de l'entête doit être la valeur max du codage
et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le
niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes
pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur
pourrait aussi etre presente):
3 Nov
3 Nov
10:41 a.m.
Nicolas Burrus wrote:
mandor <mandor(a)lrde.epita.fr> writes:
si !
prenons une image dont tous les pixels valent 127 et dont le type des
données est int_u8 :
- qd le header est 255, on sait donc en re-chargeant l'image qu'elle
contient des int_u8 et elle apparaît en gris moyen (avec xv, gimp, etc.)
- qd le header est 127, on ne connaît plus son codage et elle apparaît
en blanc sous xv, gimp, etc. !!!
pour les codages "non signés entiers", le champ max doit valoir
max< int_u<n> >::ret
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud
wrote:
Non, il n'y a pas de vrai problème. le champs max de l'entête doit être la valeur
max du codage
et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le
niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes
pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur
pourrait aussi etre presente): Juste la sauvegarde des images sur
32 bits n'est plus possible (pgm ne va pas jusque la), mais c'est plus
les images en 32 bits ne resou rien bien au contraire
c'est un format batard que les logiciels gèrent mal ou ne gèrent pas ;
en revanche, c'est possible qu'on les sauvegarde en pnm de façon
homogène.
sain d'obliger l'utilisateur a convertir en 16
bits lui même si il
veut sauver, plutôt que d'accepter puis de refuser de temps en temps
si il a une valeur trop grande.
l'option "sauver quand même en pnm sachant que seule olena pourra les
relire" est très acceptable sachant qu'olena peut fournir une conversion
32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
11:12 a.m.
Thierry Géraud <thierry.geraud(a)lrde.epita.fr> writes:
Mouais, si on veut sauver ces images la directement, autant dire
clairement que c'est notre propre format d'image (qui peut etre du pgm
etendu, par exemple .opgm pour olena pgm ?), et gerer aussi les images
de float, de complexes, etc. Mais faire semblant d'etre du pnm
classique avec une extension en .pgm, je trouve pas ca terrible.
Nicolas Burrus wrote:
On est d'accord, je disais juste qu'il n'y avait pas de vrai probleme
a appliquer le patch de mandor ! :)
mandor <mandor(a)lrde.epita.fr> writes:
si !
prenons une image dont tous les pixels valent 127 et dont le type des
données est int_u8 :
- qd le header est 255, on sait donc en re-chargeant l'image qu'elle
contient des int_u8 et elle apparaît en gris moyen (avec xv, gimp, etc.)
- qd le header est 127, on ne connaît plus son codage et elle apparaît
en blanc sous xv, gimp, etc. !!!
pour les codages "non signés entiers", le champ max doit valoir
max< int_u<n> >::ret
On Fri, 31 Oct 2003 16:02:49 +0100, Thierry Géraud
wrote:
Non, il n'y a pas de vrai problème. le champs max de l'entête doit être la valeur
max du codage
et non du contenu.
ex : une image2d<int_u8> réduite à un unique point dont le
niveau est 12 => champs max à 255 (et non 12)
Petit patch (non checkin car il me parait sain d'attendre le retour de Nes
pour apprendre pourquoi cela avait ete fait comme ca et ou l'erreur
pourrait aussi etre presente): Juste la
sauvegarde des images sur
32 bits n'est plus possible (pgm ne va pas jusque la), mais c'est plus
les images en 32 bits ne resou rien bien au contraire
c'est un format batard que les logiciels gèrent mal ou ne gèrent pas ;
en revanche, c'est possible qu'on les sauvegarde en pnm de façon
homogène.
sain d'obliger l'utilisateur a convertir
en 16 bits lui même si il
veut sauver, plutôt que d'accepter puis de refuser de temps en temps
si il a une valeur trop grande.
l'option "sauver quand même en pnm sachant que seule olena pourra les
relire" est très acceptable sachant qu'olena peut fournir une conversion
32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
11:44 a.m.
Nicolas Burrus wrote:
[...]
Thierry Géraud <thierry.geraud(a)lrde.epita.fr> writes:
on est d'accord ; pnm = { pbm, pgm, ppm } tels que définis partout.
je n'ai pas dit qu'on voulait les écrire en "pgm" (avec le 'g')
!
mais si, sur le modèle des formats existants, on crée par exemple des pfm
pour les images en flottants, des pcm pour les complexes, etc.
on se retrouve avec un format "p*m". Sachant que le 'n' de
"pnm" veut
dire "any", j'ai confondu "pnm" et "pnm étendu".
rmq : il faut qu'on s'intéresse à "pam" ; la solution est peut-être
par là :
http://netpbm.sourceforge.net/doc/pam.html
[...]
l'option "sauver quand même en pnm sachant que seule olena pourra les
relire" est très acceptable sachant qu'olena peut fournir une conversion
32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
Mouais, si on veut sauver ces images la directement, autant dire
clairement que c'est notre propre format d'image (qui peut etre du pgm
etendu, par exemple .opgm pour olena pgm ?), et gerer aussi les images
de float, de complexes, etc. Mais faire semblant d'etre du pnm
classique avec une extension en .pgm, je trouve pas ca terrible. 
7 Nov
7 Nov
4:26 p.m.
Thierry Géraud <thierry.geraud(a)lrde.epita.fr> writes:
Nicolas Burrus wrote:
J'ai mis ca dans
http://www.lrde.epita.fr/cgi-bin/twiki/view/Projects/OlenaSuggestions
vu qu'il n'est pas prévu d'ajouter de fonctionnalités importantes pour
l'instant.
[...]
Thierry Géraud <thierry.geraud(a)lrde.epita.fr> writes:
on est d'accord ; pnm = { pbm, pgm, ppm } tels que définis partout.
je n'ai pas dit qu'on voulait les écrire en "pgm" (avec le 'g')
!
mais si, sur le modèle des formats existants, on crée par exemple des pfm
pour les images en flottants, des pcm pour les complexes, etc.
on se retrouve avec un format "p*m". Sachant que le 'n' de
"pnm" veut
dire "any", j'ai confondu "pnm" et "pnm étendu".
rmq : il faut qu'on s'intéresse à "pam" ; la solution est peut-être
par là :
http://netpbm.sourceforge.net/doc/pam.html [...]
l'option "sauver quand même en pnm sachant que seule olena pourra les
relire" est très acceptable sachant qu'olena peut fournir une conversion
32 -> 16 -> 8 sous la forme d'une routine et/ou d'un exec.
Mouais,
si on veut sauver ces images la directement, autant dire
clairement que c'est notre propre format d'image (qui peut etre du pgm
etendu, par exemple .opgm pour olena pgm ?), et gerer aussi les images
de float, de complexes, etc. Mais faire semblant d'etre du pnm
classique avec une extension en .pgm, je trouve pas ca terrible.
7479
days inactive
7486
days old
6 comments
4 participants
participants (4)
-
mandor -
Nicolas Burrus -
Nicolas Burrus -
Thierry Géraud