///Par contre, enregistrer une image sous un facteur de compression "supérieur/inférieur" (entendre par là compressant moins => "meilleure qualité") doit *générer* des pixels par interpolation, d'où une augmentation du poids du fichier (Manip's faites sur l'image enregistrée sous Paint, je l'ai "gonflée" à 129 ko sous JpegOptimizer en passant du facteur de compression de 75 à 100 L'image de base passe de 302 ko à 630 ko en passant d'un facteur Q = 90 à 100)./////
Bien entendu, il ne s'agit pas d'une augmentation du nombre des pixels. Il n'en reste pas moins que dans les faits, le fichier est plus lourd.
-- A+ Papy Bernard
Bonjour
De Papy Bernard
///Par contre, enregistrer une image sous un facteur de compression
"supérieur/inférieur" (entendre par là compressant moins => "meilleure
qualité") doit *générer* des pixels par interpolation, d'où une augmentation
du poids du fichier (Manip's faites sur l'image enregistrée sous Paint, je
l'ai "gonflée" à 129 ko sous JpegOptimizer en passant du facteur de
compression de 75 à 100 L'image de base passe de 302 ko à 630 ko en passant
d'un facteur Q = 90 à 100)./////
Bien entendu, il ne s'agit pas d'une augmentation du nombre des pixels. Il
n'en reste pas moins que dans les faits, le fichier est plus lourd.
///Par contre, enregistrer une image sous un facteur de compression "supérieur/inférieur" (entendre par là compressant moins => "meilleure qualité") doit *générer* des pixels par interpolation, d'où une augmentation du poids du fichier (Manip's faites sur l'image enregistrée sous Paint, je l'ai "gonflée" à 129 ko sous JpegOptimizer en passant du facteur de compression de 75 à 100 L'image de base passe de 302 ko à 630 ko en passant d'un facteur Q = 90 à 100)./////
Bien entendu, il ne s'agit pas d'une augmentation du nombre des pixels. Il n'en reste pas moins que dans les faits, le fichier est plus lourd.
-- A+ Papy Bernard
mannucci_spamkiller
Sylvain SF wrote:
la taille du fichier est fonction du facteur de qualité qui n'a aucune raison d'être le même entre tous les softs cités, ce point est certain *mais* l'interpolation n'est pas le résultat d'un réenregistrement avec un taux différent, cette interpolation est systématique à l'ouverture du JPG et s'appelle simplement le décodage JPG (ou "déquantization"), tous softs d'image travaillent avec des BMP en mémoire
non. la notion même de "format de fichier" lorsqu'on parle de "mémoire" est un non-sens. Une image chargée en mémoire (qu'elle soit originellement un JPG, TIF, EPS ou n'importawouak) reste une "IMAGE" de "tant" de pixels de large et "tant" de pixels de haut. La taille mémoire qui est occupée découle directement du nombre de ces pixels et de leur "profondeur de couleur" (codage).
exemple: on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un TIFF de 9000Ko Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont chargés en RAM, pas le "format de fichier". Le codage étant de 8bits/couche (ou 1 octet/couche), cette image occupera TOUJOURS 14.400.000 octets (480.000 x 3)
ou bien 1406,25 kilo-octets: (14.400.000 / 1024) = 1406,25 Ko
ou bien 1,37 mega-octets: [(14.400.000 / 1024) / 1024] = 1,37Mo
A noter que le mécanisme reste le même avec un fichier audio: j'ai la flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio un fichier de 3 minutes, il occupera aux alentours d'une trentaine de Mo, même s'il s'agit d'un mp3 de 3 Mo.
la taille du fichier est fonction du facteur de qualité qui n'a
aucune raison d'être le même entre tous les softs cités, ce point
est certain *mais* l'interpolation n'est pas le résultat d'un
réenregistrement avec un taux différent, cette interpolation
est systématique à l'ouverture du JPG et s'appelle simplement
le décodage JPG (ou "déquantization"), tous softs d'image
travaillent avec des BMP en mémoire
non.
la notion même de "format de fichier" lorsqu'on parle de "mémoire" est
un non-sens. Une image chargée en mémoire (qu'elle soit originellement
un JPG, TIF, EPS ou n'importawouak) reste une "IMAGE" de "tant" de
pixels de large et "tant" de pixels de haut. La taille mémoire qui est
occupée découle directement du nombre de ces pixels et de leur
"profondeur de couleur" (codage).
exemple:
on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un
TIFF de 9000Ko
Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont
chargés en RAM, pas le "format de fichier".
Le codage étant de 8bits/couche (ou 1 octet/couche), cette image
occupera TOUJOURS 14.400.000 octets (480.000 x 3)
ou bien 1406,25 kilo-octets: (14.400.000 / 1024) = 1406,25 Ko
ou bien 1,37 mega-octets: [(14.400.000 / 1024) / 1024] = 1,37Mo
A noter que le mécanisme reste le même avec un fichier audio: j'ai la
flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio
un fichier de 3 minutes, il occupera aux alentours d'une trentaine de
Mo, même s'il s'agit d'un mp3 de 3 Mo.
la taille du fichier est fonction du facteur de qualité qui n'a aucune raison d'être le même entre tous les softs cités, ce point est certain *mais* l'interpolation n'est pas le résultat d'un réenregistrement avec un taux différent, cette interpolation est systématique à l'ouverture du JPG et s'appelle simplement le décodage JPG (ou "déquantization"), tous softs d'image travaillent avec des BMP en mémoire
non. la notion même de "format de fichier" lorsqu'on parle de "mémoire" est un non-sens. Une image chargée en mémoire (qu'elle soit originellement un JPG, TIF, EPS ou n'importawouak) reste une "IMAGE" de "tant" de pixels de large et "tant" de pixels de haut. La taille mémoire qui est occupée découle directement du nombre de ces pixels et de leur "profondeur de couleur" (codage).
exemple: on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un TIFF de 9000Ko Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont chargés en RAM, pas le "format de fichier". Le codage étant de 8bits/couche (ou 1 octet/couche), cette image occupera TOUJOURS 14.400.000 octets (480.000 x 3)
ou bien 1406,25 kilo-octets: (14.400.000 / 1024) = 1406,25 Ko
ou bien 1,37 mega-octets: [(14.400.000 / 1024) / 1024] = 1,37Mo
A noter que le mécanisme reste le même avec un fichier audio: j'ai la flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio un fichier de 3 minutes, il occupera aux alentours d'une trentaine de Mo, même s'il s'agit d'un mp3 de 3 Mo.
Tu peux montrer/expliquer comment on voit ça, car moi je ne vois strictement rien.. pourtant j'ai ragardé plusieurs fois.
Incroyable. Moi non plus, je ne vois pas de différence à l'écran ;-( -- @rian
ast
"L'Ours" a écrit dans le message de news: 4911e833$0$874$
Bonsoir...
Un truc que je n'arrive pas a m'expliquer et qui se reproduit chaque fois :
Un exemple :
Une photo prise avec un Nikon 4500 en 1024x768 : http://cjoint.com/?lftD2mcahb
Elle fait *303* ko ================== > Redimensionnée en 800x600 avec Acdsee 3.0 et enregistrée en asterr.jpg :
http://cjoint.com/?lftE4J54hM
Elle fait *436* ko, pourtant plus petite ! ================== > Cette dernière ouverte avec Paint en enregistrée en asterp.jpg : http://cjoint.com/?lftFNZtlK3
Elle ne fait plus que *92* ko ! =================== > Comment ce-fait-ce ?
C'est la compression qui est à chaque fois différente.
"L'Ours" <xxraymg@wanadoo.invalid> a écrit dans le message de news: 4911e833$0$874$ba4acef3@news.orange.fr...
Bonsoir...
Un truc que je n'arrive pas a m'expliquer et qui se reproduit chaque fois :
Un exemple :
Une photo prise avec un Nikon 4500 en 1024x768 :
http://cjoint.com/?lftD2mcahb
Elle fait *303* ko
================== >
Redimensionnée en 800x600 avec Acdsee 3.0 et enregistrée en asterr.jpg :
http://cjoint.com/?lftE4J54hM
Elle fait *436* ko, pourtant plus petite !
================== >
Cette dernière ouverte avec Paint en enregistrée en asterp.jpg :
http://cjoint.com/?lftFNZtlK3
Elle ne fait plus que *92* ko !
=================== >
Comment ce-fait-ce ?
C'est la compression qui est à chaque fois différente.
"L'Ours" a écrit dans le message de news: 4911e833$0$874$
Bonsoir...
Un truc que je n'arrive pas a m'expliquer et qui se reproduit chaque fois :
Un exemple :
Une photo prise avec un Nikon 4500 en 1024x768 : http://cjoint.com/?lftD2mcahb
Elle fait *303* ko ================== > Redimensionnée en 800x600 avec Acdsee 3.0 et enregistrée en asterr.jpg :
http://cjoint.com/?lftE4J54hM
Elle fait *436* ko, pourtant plus petite ! ================== > Cette dernière ouverte avec Paint en enregistrée en asterp.jpg : http://cjoint.com/?lftFNZtlK3
Elle ne fait plus que *92* ko ! =================== > Comment ce-fait-ce ?
C'est la compression qui est à chaque fois différente.
André
L'Ours nous fait part de ce qui suit
Bonsoir...
Un truc que je n'arrive pas a m'expliquer et qui se reproduit chaque fois :
Compression Minimun 445 K http://cjoint.com/?lgpsZKHBL5
Compression Max 22 K http://cjoint.com/?lgpxqx0Cc1
Y a une différence de qualité !!
-- André http://perso.orange.fr/le-chateau-de-nantes http://andre.racinoux.free.fr http://andre.racinoux.free.fr/express-cotier/
L'Ours nous fait part de ce qui suit
Bonsoir...
Un truc que je n'arrive pas a m'expliquer et qui se reproduit chaque
fois :
Compression Minimun 445 K
http://cjoint.com/?lgpsZKHBL5
Compression Max 22 K
http://cjoint.com/?lgpxqx0Cc1
Y a une différence de qualité !!
--
André
http://perso.orange.fr/le-chateau-de-nantes
http://andre.racinoux.free.fr
http://andre.racinoux.free.fr/express-cotier/
Un truc que je n'arrive pas a m'expliquer et qui se reproduit chaque fois :
Compression Minimun 445 K http://cjoint.com/?lgpsZKHBL5
Compression Max 22 K http://cjoint.com/?lgpxqx0Cc1
Y a une différence de qualité !!
-- André http://perso.orange.fr/le-chateau-de-nantes http://andre.racinoux.free.fr http://andre.racinoux.free.fr/express-cotier/
Ofnuts
jean-marc Mannucci wrote:
exemple: on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un TIFF de 9000Ko Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont chargés en RAM, pas le "format de fichier". Le codage étant de 8bits/couche (ou 1 octet/couche), cette image occupera TOUJOURS 14.400.000 octets (480.000 x 3)
Pas forcément... le soft peut décider que pour avoir un peu de marge (calculs de transparence, additions d'image) il stocke les valeurs de couleurs en 16 voire 32 bits. Et supposer que le fichier est géré comme une matrice est aussi un poil péremptoire, il peut être stocké par morceaux, en particulier pour avoir un comportement correct côté accès mémoire (cache(s) dur processeur, et pagination).
ou bien 1406,25 kilo-octets: (14.400.000 / 1024) = 1406,25 Ko
ou bien 1,37 mega-octets: [(14.400.000 / 1024) / 1024] = 1,37Mo
A noter que le mécanisme reste le même avec un fichier audio: j'ai la flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio un fichier de 3 minutes, il occupera aux alentours d'une trentaine de Mo, même s'il s'agit d'un mp3 de 3 Mo.
Non, parce rien n'impose que ton son soit échantilloné à 44KHz. Ca n'est vrai que si ton fichier MP3 est produit à partir d'un CD (car tous les CD sont échantillonnés à 44KHz), mais si c'est l'extraction de la piste son d'une vidéo l'échantillonnage peut être plus faible.
-- Bertrand
jean-marc Mannucci wrote:
exemple:
on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un
TIFF de 9000Ko
Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont
chargés en RAM, pas le "format de fichier".
Le codage étant de 8bits/couche (ou 1 octet/couche), cette image
occupera TOUJOURS 14.400.000 octets (480.000 x 3)
Pas forcément... le soft peut décider que pour avoir un peu de marge
(calculs de transparence, additions d'image) il stocke les valeurs de
couleurs en 16 voire 32 bits. Et supposer que le fichier est géré comme
une matrice est aussi un poil péremptoire, il peut être stocké par
morceaux, en particulier pour avoir un comportement correct côté accès
mémoire (cache(s) dur processeur, et pagination).
ou bien 1406,25 kilo-octets: (14.400.000 / 1024) = 1406,25 Ko
ou bien 1,37 mega-octets: [(14.400.000 / 1024) / 1024] = 1,37Mo
A noter que le mécanisme reste le même avec un fichier audio: j'ai la
flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio
un fichier de 3 minutes, il occupera aux alentours d'une trentaine de
Mo, même s'il s'agit d'un mp3 de 3 Mo.
Non, parce rien n'impose que ton son soit échantilloné à 44KHz. Ca n'est
vrai que si ton fichier MP3 est produit à partir d'un CD (car tous les
CD sont échantillonnés à 44KHz), mais si c'est l'extraction de la piste
son d'une vidéo l'échantillonnage peut être plus faible.
exemple: on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un TIFF de 9000Ko Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont chargés en RAM, pas le "format de fichier". Le codage étant de 8bits/couche (ou 1 octet/couche), cette image occupera TOUJOURS 14.400.000 octets (480.000 x 3)
Pas forcément... le soft peut décider que pour avoir un peu de marge (calculs de transparence, additions d'image) il stocke les valeurs de couleurs en 16 voire 32 bits. Et supposer que le fichier est géré comme une matrice est aussi un poil péremptoire, il peut être stocké par morceaux, en particulier pour avoir un comportement correct côté accès mémoire (cache(s) dur processeur, et pagination).
ou bien 1406,25 kilo-octets: (14.400.000 / 1024) = 1406,25 Ko
ou bien 1,37 mega-octets: [(14.400.000 / 1024) / 1024] = 1,37Mo
A noter que le mécanisme reste le même avec un fichier audio: j'ai la flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio un fichier de 3 minutes, il occupera aux alentours d'une trentaine de Mo, même s'il s'agit d'un mp3 de 3 Mo.
Non, parce rien n'impose que ton son soit échantilloné à 44KHz. Ca n'est vrai que si ton fichier MP3 est produit à partir d'un CD (car tous les CD sont échantillonnés à 44KHz), mais si c'est l'extraction de la piste son d'une vidéo l'échantillonnage peut être plus faible.
-- Bertrand
Alexandre
L'Ours a écrit :
Redimensionnée en 800x600 avec Acdsee 3.0 et enregistrée en asterr.jpg : http://cjoint.com/?lftE4J54hM
Elle fait *436* ko, pourtant plus petite ! ================== >>>> Cette dernière ouverte avec Paint en enregistrée en asterp.jpg : http://cjoint.com/?lftFNZtlK3
Elle ne fait plus que *92* ko ! =================== >
Plein d'artefacts de compression sur la deuxième, notamment autour des pétales.
Tu peux montrer/expliquer comment on voit ça, car moi je ne vois strictement rien.. pourtant j'ai ragardé plusieurs fois.
Mais pas obligé hein.... ça semble avoir peu d'intérêt et je laisse tomber.
.. Visibles sans avoir besoin de grossir à 600 % !
Il n'était bien sûr pas question de grossir... où cela doit être évident.
Détails à 100 % http://cjoint.com/data/lgxdxwHgbI.htm Je vois très bien la différence sur mon moniteur lcd.
L'Ours a écrit :
Redimensionnée en 800x600 avec Acdsee 3.0 et enregistrée en
asterr.jpg :
http://cjoint.com/?lftE4J54hM
Elle fait *436* ko, pourtant plus petite !
================== >>>>
Cette dernière ouverte avec Paint en enregistrée en asterp.jpg :
http://cjoint.com/?lftFNZtlK3
Elle ne fait plus que *92* ko !
=================== >
Plein d'artefacts de compression sur la deuxième, notamment autour
des pétales.
Tu peux montrer/expliquer comment on voit ça, car moi je ne vois
strictement rien.. pourtant j'ai ragardé plusieurs fois.
Mais pas obligé hein.... ça semble avoir peu d'intérêt et je laisse
tomber.
.. Visibles sans avoir besoin de grossir à 600 % !
Il n'était bien sûr pas question de grossir... où cela doit être
évident.
Détails à 100 %
http://cjoint.com/data/lgxdxwHgbI.htm
Je vois très bien la différence sur mon moniteur lcd.
Redimensionnée en 800x600 avec Acdsee 3.0 et enregistrée en asterr.jpg : http://cjoint.com/?lftE4J54hM
Elle fait *436* ko, pourtant plus petite ! ================== >>>> Cette dernière ouverte avec Paint en enregistrée en asterp.jpg : http://cjoint.com/?lftFNZtlK3
Elle ne fait plus que *92* ko ! =================== >
Plein d'artefacts de compression sur la deuxième, notamment autour des pétales.
Tu peux montrer/expliquer comment on voit ça, car moi je ne vois strictement rien.. pourtant j'ai ragardé plusieurs fois.
Mais pas obligé hein.... ça semble avoir peu d'intérêt et je laisse tomber.
.. Visibles sans avoir besoin de grossir à 600 % !
Il n'était bien sûr pas question de grossir... où cela doit être évident.
Détails à 100 % http://cjoint.com/data/lgxdxwHgbI.htm Je vois très bien la différence sur mon moniteur lcd.
Sylvain SF
Papy Bernard a écrit :
tous softs d'image travaillent avec des BMP en mémoire.
En mémoire , l'image n'est pas plus en *.jpg qu'en *.BMP Les pixels codés en 1, 4, 8 ou 24 bits.
je n'ai pas dit ".bmp" (auquel des 2 pensais-tu) mais "BMP" (bitmap) ou "DIB" (device independant bitmap).
POINT.
tout à fait.
Sylvain.
Papy Bernard a écrit :
tous softs d'image travaillent avec des BMP en mémoire.
En mémoire , l'image n'est pas plus en *.jpg qu'en *.BMP
Les pixels codés en 1, 4, 8 ou 24 bits.
je n'ai pas dit ".bmp" (auquel des 2 pensais-tu) mais "BMP"
(bitmap) ou "DIB" (device independant bitmap).
tous softs d'image travaillent avec des BMP en mémoire.
En mémoire , l'image n'est pas plus en *.jpg qu'en *.BMP Les pixels codés en 1, 4, 8 ou 24 bits.
je n'ai pas dit ".bmp" (auquel des 2 pensais-tu) mais "BMP" (bitmap) ou "DIB" (device independant bitmap).
POINT.
tout à fait.
Sylvain.
Sylvain SF
jean-marc Mannucci a écrit :
non.
ah bon ?!
la notion même de "format de fichier" lorsqu'on parle de "mémoire" est un non-sens. Une image chargée en mémoire (qu'elle soit originellement un JPG, TIF, EPS ou n'importawouak) reste une "IMAGE" de "tant" de pixels de large et "tant" de pixels de haut. La taille mémoire qui est occupée découle directement du nombre de ces pixels et de leur "profondeur de couleur" (codage).
ce que l'on appelle une "bitmap"
exemple: on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un TIFF de 9000Ko Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont chargés en RAM, pas le "format de fichier".
ils sont "créés" en RAM, pas "chargés", un chargement JPG consiste à "charger" des matrices par exemple. la "création" est ce que l'on appelle une "bitmap", une "image" c'est sur la rétine, pas dans la RAM.
Le codage étant de 8bits/couche (ou 1 octet/couche), cette image occupera TOUJOURS 14.400.000 octets (480.000 x 3)
ainsi est une bitmap.
A noter que le mécanisme reste le même avec un fichier audio: j'ai la flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio un fichier de 3 minutes, il occupera aux alentours d'une trentaine de Mo, même s'il s'agit d'un mp3 de 3 Mo.
non là c'est incorrect, un flux audio contient son propre échantillionage, la décompression pour relecture peut réechantillioner à loisir - alors qu'un n'importe-quoi 24 bits est (très généralement) décodé en 24 bits, pas en 12 ni en 48.
Sylvain.
jean-marc Mannucci a écrit :
non.
ah bon ?!
la notion même de "format de fichier" lorsqu'on parle de "mémoire" est
un non-sens. Une image chargée en mémoire (qu'elle soit originellement
un JPG, TIF, EPS ou n'importawouak) reste une "IMAGE" de "tant" de
pixels de large et "tant" de pixels de haut. La taille mémoire qui est
occupée découle directement du nombre de ces pixels et de leur
"profondeur de couleur" (codage).
ce que l'on appelle une "bitmap"
exemple:
on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un
TIFF de 9000Ko
Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont
chargés en RAM, pas le "format de fichier".
ils sont "créés" en RAM, pas "chargés", un chargement JPG
consiste à "charger" des matrices par exemple.
la "création" est ce que l'on appelle une "bitmap",
une "image" c'est sur la rétine, pas dans la RAM.
Le codage étant de 8bits/couche (ou 1 octet/couche), cette image
occupera TOUJOURS 14.400.000 octets (480.000 x 3)
ainsi est une bitmap.
A noter que le mécanisme reste le même avec un fichier audio: j'ai la
flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio
un fichier de 3 minutes, il occupera aux alentours d'une trentaine de
Mo, même s'il s'agit d'un mp3 de 3 Mo.
non là c'est incorrect, un flux audio contient son propre
échantillionage, la décompression pour relecture peut réechantillioner
à loisir - alors qu'un n'importe-quoi 24 bits est (très généralement)
décodé en 24 bits, pas en 12 ni en 48.
la notion même de "format de fichier" lorsqu'on parle de "mémoire" est un non-sens. Une image chargée en mémoire (qu'elle soit originellement un JPG, TIF, EPS ou n'importawouak) reste une "IMAGE" de "tant" de pixels de large et "tant" de pixels de haut. La taille mémoire qui est occupée découle directement du nombre de ces pixels et de leur "profondeur de couleur" (codage).
ce que l'on appelle une "bitmap"
exemple: on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un TIFF de 9000Ko Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont chargés en RAM, pas le "format de fichier".
ils sont "créés" en RAM, pas "chargés", un chargement JPG consiste à "charger" des matrices par exemple. la "création" est ce que l'on appelle une "bitmap", une "image" c'est sur la rétine, pas dans la RAM.
Le codage étant de 8bits/couche (ou 1 octet/couche), cette image occupera TOUJOURS 14.400.000 octets (480.000 x 3)
ainsi est une bitmap.
A noter que le mécanisme reste le même avec un fichier audio: j'ai la flemme de faire le calcul exact, mais si on ouvre avec un éditeur audio un fichier de 3 minutes, il occupera aux alentours d'une trentaine de Mo, même s'il s'agit d'un mp3 de 3 Mo.
non là c'est incorrect, un flux audio contient son propre échantillionage, la décompression pour relecture peut réechantillioner à loisir - alors qu'un n'importe-quoi 24 bits est (très généralement) décodé en 24 bits, pas en 12 ni en 48.
Sylvain.
mannucci_spamkiller
et Sylvain SF wrote:
ce que l'on appelle une "bitmap"
oui. Mais j'espère que tu auras l'honneteté de reconnaitre qu'en rédigeant "BMP", la confusion avec le format de fichier du même nom etait possible.
> exemple: > on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un > TIFF de 9000Ko > Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont > chargés en RAM, pas le "format de fichier".
ils sont "créés" en RAM, pas "chargés", un chargement JPG consiste à "charger" des matrices par exemple.
c'est marrant, tu aurais dû penser au "pinaillage sémantique" dans ton post précédent. Cela dit, la rigueur dans la définition, c'est aussi très bien, mais alors il faut être rigoureux "partout"... et ne pas laisser la moindre approximations grossières à une distance d'à peine un post. Je sens bien que tu es agacé, mais bon... reprendre mon post "mot par mot", je crois qua ça n'est une bonne idée, ni très crédible.
Mais bon, c'est pas grave... ma (très) petite expérience en formation me laisse continuer de croire que la plupart du temps, l'emploi de "mots simples" a un meilleur effet pédagogique qu'une sequence de pignole... je vais t'épargner du "couplet de desperado" (tu sais, le genre "j'ai 42 ans d'experience et les meilleures références du Monde", etc, etc)... mais saches quand même qu'il doit certainement y avoir une poignée de contributeurs "anciens" (et plus que ça) qui savent que... je sais *un peu* de quoi je parle.
Je continue également de penser qu'une écrasante majorité comprendra plus facilement "charger une image en mémoire" que "créer une bitmap en RAM"...
une "image" c'est sur la rétine, pas dans la RAM.
... et pas un d'entre eux (et moi encore moins) ne croira que qu'il faut essayer de faire rentrer de force dans une barette de mémoire l'Ours polaire qui se trouve sur les photos du Safari en Alaska.
Merci de ne pas les ("me", surtout) prendre pour un jambon.
oui.
Mais j'espère que tu auras l'honneteté de reconnaitre qu'en rédigeant
"BMP", la confusion avec le format de fichier du même nom etait
possible.
> exemple:
> on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un
> TIFF de 9000Ko
> Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont
> chargés en RAM, pas le "format de fichier".
ils sont "créés" en RAM, pas "chargés", un chargement JPG
consiste à "charger" des matrices par exemple.
c'est marrant, tu aurais dû penser au "pinaillage sémantique" dans ton
post précédent.
Cela dit, la rigueur dans la définition, c'est aussi très bien, mais
alors il faut être rigoureux "partout"... et ne pas laisser la moindre
approximations grossières à une distance d'à peine un post.
Je sens bien que tu es agacé, mais bon... reprendre mon post "mot par
mot", je crois qua ça n'est une bonne idée, ni très crédible.
Mais bon, c'est pas grave... ma (très) petite expérience en formation me
laisse continuer de croire que la plupart du temps, l'emploi de "mots
simples" a un meilleur effet pédagogique qu'une sequence de pignole...
je vais t'épargner du "couplet de desperado" (tu sais, le genre "j'ai 42
ans d'experience et les meilleures références du Monde", etc, etc)...
mais saches quand même qu'il doit certainement y avoir une poignée de
contributeurs "anciens" (et plus que ça) qui savent que... je sais *un
peu* de quoi je parle.
Je continue également de penser qu'une écrasante majorité comprendra
plus facilement "charger une image en mémoire" que "créer une bitmap en
RAM"...
une "image" c'est sur la rétine, pas dans la RAM.
... et pas un d'entre eux (et moi encore moins) ne croira que qu'il faut
essayer de faire rentrer de force dans une barette de mémoire l'Ours
polaire qui se trouve sur les photos du Safari en Alaska.
Merci de ne pas les ("me", surtout) prendre pour un jambon.
oui. Mais j'espère que tu auras l'honneteté de reconnaitre qu'en rédigeant "BMP", la confusion avec le format de fichier du même nom etait possible.
> exemple: > on "ouvre" une image RVB de 800x600, qu'elle soit un JPEG de 200Ko ou un > TIFF de 9000Ko > Cette image comprend donc 480 000 pixels, et ce sont bien "eux" qui sont > chargés en RAM, pas le "format de fichier".
ils sont "créés" en RAM, pas "chargés", un chargement JPG consiste à "charger" des matrices par exemple.
c'est marrant, tu aurais dû penser au "pinaillage sémantique" dans ton post précédent. Cela dit, la rigueur dans la définition, c'est aussi très bien, mais alors il faut être rigoureux "partout"... et ne pas laisser la moindre approximations grossières à une distance d'à peine un post. Je sens bien que tu es agacé, mais bon... reprendre mon post "mot par mot", je crois qua ça n'est une bonne idée, ni très crédible.
Mais bon, c'est pas grave... ma (très) petite expérience en formation me laisse continuer de croire que la plupart du temps, l'emploi de "mots simples" a un meilleur effet pédagogique qu'une sequence de pignole... je vais t'épargner du "couplet de desperado" (tu sais, le genre "j'ai 42 ans d'experience et les meilleures références du Monde", etc, etc)... mais saches quand même qu'il doit certainement y avoir une poignée de contributeurs "anciens" (et plus que ça) qui savent que... je sais *un peu* de quoi je parle.
Je continue également de penser qu'une écrasante majorité comprendra plus facilement "charger une image en mémoire" que "créer une bitmap en RAM"...
une "image" c'est sur la rétine, pas dans la RAM.
... et pas un d'entre eux (et moi encore moins) ne croira que qu'il faut essayer de faire rentrer de force dans une barette de mémoire l'Ours polaire qui se trouve sur les photos du Safari en Alaska.
Merci de ne pas les ("me", surtout) prendre pour un jambon.
