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.
je le reconnais - pour moi c'était clair, mais ce n'était sûrement pas universellement clair.
c'est marrant, tu aurais dû penser au "pinaillage sémantique" dans ton post précédent.
;)
[...] 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.
hmmm, sûrement, et je savais aussi un peu de quoi ... mais certes, je n'ai pas parlé comme toi. (ah ce manque de pédagogie !...)
... 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.
Magritte est heureusement passé par là. mais tu exagères un peu mon point.
Merci de ne pas les ("me", surtout) prendre pour un jambon.
??
Sylvain.
jean-marc Mannucci a écrit :
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.
je le reconnais - pour moi c'était clair, mais ce n'était sûrement
pas universellement clair.
c'est marrant, tu aurais dû penser au "pinaillage sémantique" dans ton
post précédent.
;)
[...] 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.
hmmm, sûrement, et je savais aussi un peu de quoi ... mais certes,
je n'ai pas parlé comme toi. (ah ce manque de pédagogie !...)
... 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.
Magritte est heureusement passé par là. mais tu exagères un peu
mon point.
Merci de ne pas les ("me", surtout) prendre pour un jambon.
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.
je le reconnais - pour moi c'était clair, mais ce n'était sûrement pas universellement clair.
c'est marrant, tu aurais dû penser au "pinaillage sémantique" dans ton post précédent.
;)
[...] 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.
hmmm, sûrement, et je savais aussi un peu de quoi ... mais certes, je n'ai pas parlé comme toi. (ah ce manque de pédagogie !...)
... 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.
Magritte est heureusement passé par là. mais tu exagères un peu mon point.
Merci de ne pas les ("me", surtout) prendre pour un jambon.
??
Sylvain.
mannucci_spamkiller
Sylvain SF wrote:
Magritte est heureusement passé par là. mais tu exagères un peu mon point.
Merci d'avoir passé un peu de temps à me donner toutes ces précisions. Je connais assez bien la compression, mais j'ai complètement négligé l'action des logiciels..... qui justement modifient le taux.
Maintenant c'est nettement plus clair, mais faut dire que je ne suis pas un fan de photo.
En fait, 2 raisons m'ont amené à poser cette question :
1) mettre sur mon site et éventuellement en ci-joint, des photos correctes à l'écran, mais le moins lourdes possible (y'a encore des gens en RTC !)
2) conseils qu'il m'arrive de donner à des débutants sur Internet et en photo numérique (dont ils tirent des photos monumentales), afin de les envoyer correctement sur Internet ou en mail privé.
Le conseil donné souvent un peu partout est de redimensionner la photo (ce que les gens arrivent assez facilement à faire)...... mais si c'est pour passer 303 ko à 436, cela ne présente aucun intérêt ! ;-(( Donc, c'est plus compliqué que ça et face à tous les neuneus qui utilisent un Apn, je continuerai à leur proposer de finir par Paint, car ils sont bien incapables de s'occuper de compression ! On passe quand même de 436 à 96 Ko pour une photo 800x600... c'est pas mal, et avec une perte négligeable (sinon nulle) en qualité à l'affichage à l'écran.
Si la question te titille, télécharge la version 3.15 de JpegOptimizer (<1.4 Mo).
J'ai déjà la version 3.06 installée qui est un shareware à durée d'utilisation illimitée, mais je l'ai oubliée et m'en sers peu. J'ai aussi la version 4.00 jamais installée.
Bon, va falloir que j'arrête d'aller ramasser des champignons et me pencher un peu plus sérieusement ! ;-))
En tout cas, merci à tout ceux qui ont répondu ...
-- L'Ours A toujours imaginer le pire, on est rarement déçu.. Photos, fleurs, champignons et choses étranges... http://perso.wanadoo.fr/rag/rg/
*<Papy Bernard>* écrivait :
Merci d'avoir passé un peu de temps à me donner toutes ces précisions.
Je connais assez bien la compression, mais j'ai complètement négligé
l'action des logiciels..... qui justement modifient le taux.
Maintenant c'est nettement plus clair, mais faut dire que je ne suis pas un
fan de photo.
En fait, 2 raisons m'ont amené à poser cette question :
1) mettre sur mon site et éventuellement en ci-joint, des photos correctes à
l'écran, mais le moins lourdes possible (y'a encore des gens en RTC !)
2) conseils qu'il m'arrive de donner à des débutants sur Internet et en
photo numérique (dont ils tirent des photos monumentales), afin de les
envoyer correctement sur Internet ou en mail privé.
Le conseil donné souvent un peu partout est de redimensionner la photo (ce
que les gens arrivent assez facilement à faire)...... mais si c'est pour
passer 303 ko à 436, cela ne présente aucun intérêt ! ;-((
Donc, c'est plus compliqué que ça et face à tous les neuneus qui utilisent
un Apn, je continuerai à leur proposer de finir par Paint, car ils sont bien
incapables de s'occuper de compression !
On passe quand même de 436 à 96 Ko pour une photo 800x600... c'est pas mal,
et avec une perte négligeable (sinon nulle) en qualité à l'affichage à
l'écran.
Si la question te titille, télécharge la version 3.15 de
JpegOptimizer (<1.4 Mo).
J'ai déjà la version 3.06 installée qui est un shareware à durée
d'utilisation illimitée, mais je l'ai oubliée et m'en sers peu.
J'ai aussi la version 4.00 jamais installée.
Bon, va falloir que j'arrête d'aller ramasser des champignons et me pencher
un peu plus sérieusement ! ;-))
En tout cas, merci à tout ceux qui ont répondu ...
--
L'Ours
A toujours imaginer le pire, on est rarement déçu..
Photos, fleurs, champignons et choses étranges...
http://perso.wanadoo.fr/rag/rg/
Merci d'avoir passé un peu de temps à me donner toutes ces précisions. Je connais assez bien la compression, mais j'ai complètement négligé l'action des logiciels..... qui justement modifient le taux.
Maintenant c'est nettement plus clair, mais faut dire que je ne suis pas un fan de photo.
En fait, 2 raisons m'ont amené à poser cette question :
1) mettre sur mon site et éventuellement en ci-joint, des photos correctes à l'écran, mais le moins lourdes possible (y'a encore des gens en RTC !)
2) conseils qu'il m'arrive de donner à des débutants sur Internet et en photo numérique (dont ils tirent des photos monumentales), afin de les envoyer correctement sur Internet ou en mail privé.
Le conseil donné souvent un peu partout est de redimensionner la photo (ce que les gens arrivent assez facilement à faire)...... mais si c'est pour passer 303 ko à 436, cela ne présente aucun intérêt ! ;-(( Donc, c'est plus compliqué que ça et face à tous les neuneus qui utilisent un Apn, je continuerai à leur proposer de finir par Paint, car ils sont bien incapables de s'occuper de compression ! On passe quand même de 436 à 96 Ko pour une photo 800x600... c'est pas mal, et avec une perte négligeable (sinon nulle) en qualité à l'affichage à l'écran.
Si la question te titille, télécharge la version 3.15 de JpegOptimizer (<1.4 Mo).
J'ai déjà la version 3.06 installée qui est un shareware à durée d'utilisation illimitée, mais je l'ai oubliée et m'en sers peu. J'ai aussi la version 4.00 jamais installée.
Bon, va falloir que j'arrête d'aller ramasser des champignons et me pencher un peu plus sérieusement ! ;-))
En tout cas, merci à tout ceux qui ont répondu ...
-- L'Ours A toujours imaginer le pire, on est rarement déçu.. Photos, fleurs, champignons et choses étranges... http://perso.wanadoo.fr/rag/rg/
L'Ours
*<Alexandre>* écrivait :
Détails à 100 % http://cjoint.com/data/lgxdxwHgbI.htm
Je vois très bien la différence sur mon moniteur lcd.
Désolé, je ne vois aucune différence sur mon écran cathodique qui date un peu !
Merci
-- L'Ours A toujours imaginer le pire, on est rarement déçu.. Photos, fleurs, champignons et choses étranges... http://perso.wanadoo.fr/rag/rg/
*<Alexandre>* écrivait :
Détails à 100 %
http://cjoint.com/data/lgxdxwHgbI.htm
Je vois très bien la différence sur mon moniteur lcd.
Désolé, je ne vois aucune différence sur mon écran cathodique qui date un
peu !
Merci
--
L'Ours
A toujours imaginer le pire, on est rarement déçu..
Photos, fleurs, champignons et choses étranges...
http://perso.wanadoo.fr/rag/rg/
Détails à 100 % http://cjoint.com/data/lgxdxwHgbI.htm
Je vois très bien la différence sur mon moniteur lcd.
Désolé, je ne vois aucune différence sur mon écran cathodique qui date un peu !
Merci
-- L'Ours A toujours imaginer le pire, on est rarement déçu.. Photos, fleurs, champignons et choses étranges... http://perso.wanadoo.fr/rag/rg/
Stephane Legras-Decussy
"jean-marc Mannucci" a écrit dans le message de news: 1ipzjml.uaa67iik88caN%
. La taille mémoire qui est occupée découle directement du nombre de ces pixels et de leur "profondeur de couleur" (codage).
parfaitement, mais en pratique un ordi manipule mieux et vite des blocs de 32 bit (ou 64 maintenant), donc quasi tous les softs mangent 4 octets par pixel quel que soit la profondeur de couleur... ou même carrèment 8...
la mémoire d'un ordi est ainsi un gruyère truffée d'octets non utilisés... c'est le padding...
avec un programme fait par des porcs, ça peut atteindre des sommets...
"jean-marc Mannucci" <mannucci_spamkiller@wild-works.net> a écrit dans le
message de news: 1ipzjml.uaa67iik88caN%
. La taille mémoire qui est
occupée découle directement du nombre de ces pixels et de leur
"profondeur de couleur" (codage).
parfaitement, mais en pratique
un ordi manipule mieux et vite des blocs
de 32 bit (ou 64 maintenant), donc quasi tous les
softs mangent 4 octets par pixel quel que soit la profondeur
de couleur... ou même carrèment 8...
la mémoire d'un ordi est ainsi un gruyère truffée
d'octets non utilisés... c'est le padding...
avec un programme fait par des porcs, ça
peut atteindre des sommets...
"jean-marc Mannucci" a écrit dans le message de news: 1ipzjml.uaa67iik88caN%
. La taille mémoire qui est occupée découle directement du nombre de ces pixels et de leur "profondeur de couleur" (codage).
parfaitement, mais en pratique un ordi manipule mieux et vite des blocs de 32 bit (ou 64 maintenant), donc quasi tous les softs mangent 4 octets par pixel quel que soit la profondeur de couleur... ou même carrèment 8...
la mémoire d'un ordi est ainsi un gruyère truffée d'octets non utilisés... c'est le padding...
avec un programme fait par des porcs, ça peut atteindre des sommets...
Stephane Legras-Decussy
"jean-marc Mannucci" a écrit dans le message de news: 1iq0fnu.j8uh6e1clmb42N%
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"...
d'autant plus que ton terme est parfaitement exact dans le niveau d'abstraction adéquate...
"jean-marc Mannucci" <mannucci_spamkiller@wild-works.net> a écrit dans le
message de news: 1iq0fnu.j8uh6e1clmb42N%
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"...
d'autant plus que ton terme est parfaitement exact
dans le niveau d'abstraction adéquate...
"Sylvain SF" a écrit dans le message de news: 49137bc4$0$880$
je n'ai pas dit ".bmp" (auquel des 2 pensais-tu) mais "BMP" (bitmap) ou "DIB" (device independant bitmap).
faut que tu fasses une cure de desintox de l'api win32...
c'est pas le truc le plus zen du monde...
mannucci_spamkiller
"Stephane Legras-Decussy" wrote:
parfaitement, mais en pratique un ordi manipule mieux et vite des blocs de 32 bit (ou 64 maintenant), donc quasi tous les softs mangent 4 octets par pixel quel que soit la profondeur de couleur... ou même carrèment 8...
ah ? moi, j'avais compris que l'arrivé des processeurs 32, puis de 64 bits, n'avait pas pour but de travailler avec des "plus gros paquets", mais bien de permettre la réalisation de plusieurs tâche "simultanément". mais j'avoue ne plus rien connaitre sur le sujet: dans les années 80, et pendant assez longtemps, je programmais et compilais en assembleur 8086, jusqu'au jour où ça m'a complètement gavé et j'ai lâché l'affaire aussitôt... pour reprendre mes boites de crayons et mes blocs de papier. ;-)
la mémoire d'un ordi est ainsi un gruyère truffée d'octets non utilisés... c'est le padding...
oui, c'est un peu comme le fonctionnement des mémoires de masse: y'a des blocs (ou clusters) qui font une certaine taille, laquelle devient de fait "le plus petit espace occupé comptabilisable". En gros: si, dans un système donné, un bloc fait 16Ko, et qu'on y met un fichier de 4Ko, l'espace occupé compabilisé sera de 16Ko. Et ce phénomène "dope" et accentue un autre phénomène, celui de la fragmentation.
Chez Apple, l'arrivée du HFS+ (de manière très simplifiée: blocs "à taille variable" a été une réelle avancée.
avec un programme fait par des porcs, ça peut atteindre des sommets...
oui, et il en existe. Et certains sont même, carrément, des "systèmes d'exploitation". ;-)
parfaitement, mais en pratique
un ordi manipule mieux et vite des blocs
de 32 bit (ou 64 maintenant), donc quasi tous les
softs mangent 4 octets par pixel quel que soit la profondeur
de couleur... ou même carrèment 8...
ah ? moi, j'avais compris que l'arrivé des processeurs 32, puis de 64
bits, n'avait pas pour but de travailler avec des "plus gros paquets",
mais bien de permettre la réalisation de plusieurs tâche
"simultanément".
mais j'avoue ne plus rien connaitre sur le sujet: dans les années 80, et
pendant assez longtemps, je programmais et compilais en assembleur 8086,
jusqu'au jour où ça m'a complètement gavé et j'ai lâché l'affaire
aussitôt... pour reprendre mes boites de crayons et mes blocs de papier.
;-)
la mémoire d'un ordi est ainsi un gruyère truffée
d'octets non utilisés... c'est le padding...
oui, c'est un peu comme le fonctionnement des mémoires de masse: y'a des
blocs (ou clusters) qui font une certaine taille, laquelle devient de
fait "le plus petit espace occupé comptabilisable".
En gros: si, dans un système donné, un bloc fait 16Ko, et qu'on y met un
fichier de 4Ko, l'espace occupé compabilisé sera de 16Ko.
Et ce phénomène "dope" et accentue un autre phénomène, celui de la
fragmentation.
Chez Apple, l'arrivée du HFS+ (de manière très simplifiée: blocs "à
taille variable" a été une réelle avancée.
avec un programme fait par des porcs, ça
peut atteindre des sommets...
oui, et il en existe. Et certains sont même, carrément, des
"systèmes d'exploitation". ;-)
parfaitement, mais en pratique un ordi manipule mieux et vite des blocs de 32 bit (ou 64 maintenant), donc quasi tous les softs mangent 4 octets par pixel quel que soit la profondeur de couleur... ou même carrèment 8...
ah ? moi, j'avais compris que l'arrivé des processeurs 32, puis de 64 bits, n'avait pas pour but de travailler avec des "plus gros paquets", mais bien de permettre la réalisation de plusieurs tâche "simultanément". mais j'avoue ne plus rien connaitre sur le sujet: dans les années 80, et pendant assez longtemps, je programmais et compilais en assembleur 8086, jusqu'au jour où ça m'a complètement gavé et j'ai lâché l'affaire aussitôt... pour reprendre mes boites de crayons et mes blocs de papier. ;-)
la mémoire d'un ordi est ainsi un gruyère truffée d'octets non utilisés... c'est le padding...
oui, c'est un peu comme le fonctionnement des mémoires de masse: y'a des blocs (ou clusters) qui font une certaine taille, laquelle devient de fait "le plus petit espace occupé comptabilisable". En gros: si, dans un système donné, un bloc fait 16Ko, et qu'on y met un fichier de 4Ko, l'espace occupé compabilisé sera de 16Ko. Et ce phénomène "dope" et accentue un autre phénomène, celui de la fragmentation.
Chez Apple, l'arrivée du HFS+ (de manière très simplifiée: blocs "à taille variable" a été une réelle avancée.
avec un programme fait par des porcs, ça peut atteindre des sommets...
oui, et il en existe. Et certains sont même, carrément, des "systèmes d'exploitation". ;-)
ah ? moi, j'avais compris que l'arrivé des processeurs 32, puis de 64 bits, n'avait pas pour but de travailler avec des "plus gros paquets", mais bien de permettre la réalisation de plusieurs tâche "simultanément". mais j'avoue ne plus rien connaitre sur le sujet: dans les années 80, et pendant assez longtemps, je programmais et compilais en assembleur 8086, jusqu'au jour où ça m'a complètement gavé et j'ai lâché l'affaire aussitôt... pour reprendre mes boites de crayons et mes blocs de papier. ;-)
Le 64 bits est arrivé sur le marché avec l'AS/400 (IBM) -début 1987-
Le principe (très schématique) : Analogue à faire Paris -Marseille, à la même vitesse, avec un gros camion de 64 tonnes plutôt qu'avec deux camions de 32 tonnes, le second ne quittant Paris que lorsque le premier est arrivé à destination.
Ca te va comme explication ?
Pour PLUS de détails, Google est toon ami. Processeur + 64 bits
-- A+ Papy Bernard
-- A+ Papy Bernard
Bonjour
De jean-marc Mannucci
ah ? moi, j'avais compris que l'arrivé des processeurs 32, puis de 64
bits, n'avait pas pour but de travailler avec des "plus gros paquets",
mais bien de permettre la réalisation de plusieurs tâche
"simultanément".
mais j'avoue ne plus rien connaitre sur le sujet: dans les années 80,
et pendant assez longtemps, je programmais et compilais en assembleur
8086, jusqu'au jour où ça m'a complètement gavé et j'ai lâché
l'affaire aussitôt... pour reprendre mes boites de crayons et mes
blocs de papier. ;-)
Le 64 bits est arrivé sur le marché avec l'AS/400 (IBM) -début 1987-
Le principe (très schématique) : Analogue à faire Paris -Marseille, à la
même vitesse, avec un gros camion de 64 tonnes plutôt qu'avec deux camions
de 32 tonnes, le second ne quittant Paris que lorsque le premier est arrivé
à destination.
Ca te va comme explication ?
Pour PLUS de détails, Google est toon ami. Processeur + 64 bits
ah ? moi, j'avais compris que l'arrivé des processeurs 32, puis de 64 bits, n'avait pas pour but de travailler avec des "plus gros paquets", mais bien de permettre la réalisation de plusieurs tâche "simultanément". mais j'avoue ne plus rien connaitre sur le sujet: dans les années 80, et pendant assez longtemps, je programmais et compilais en assembleur 8086, jusqu'au jour où ça m'a complètement gavé et j'ai lâché l'affaire aussitôt... pour reprendre mes boites de crayons et mes blocs de papier. ;-)
Le 64 bits est arrivé sur le marché avec l'AS/400 (IBM) -début 1987-
Le principe (très schématique) : Analogue à faire Paris -Marseille, à la même vitesse, avec un gros camion de 64 tonnes plutôt qu'avec deux camions de 32 tonnes, le second ne quittant Paris que lorsque le premier est arrivé à destination.
Ca te va comme explication ?
Pour PLUS de détails, Google est toon ami. Processeur + 64 bits
-- A+ Papy Bernard
-- A+ Papy Bernard
Papy Bernard
Bonjour
De L'Ours
Donc, c'est plus compliqué que ça et face à tous les neuneus qui utilisent un Apn, je continuerai à leur proposer de finir par Paint, car ils sont bien incapables de s'occuper de compression ! On passe quand même de 436 à 96 Ko pour une photo 800x600... c'est pas mal, et avec une perte négligeable (sinon nulle) en qualité à l'affichage à l'écran. merci à tout ceux qui ont répondu ...
Que soit une image papier ou une image à l'écran, sa qualité (son équilibre) s'apprécie avant tout dans sa totalité. Pour une iage papier, on a tout sous les yeux. Sur un écran, il est -AMHA- importaznt que TOUE l'image tienne sur l'éran, sans avoir à faire joujou avec les curseurs. Aussi, un format de 800x600 pixels me semble un bon compromis.
-- A+ Papy Bernard
Bonjour
De L'Ours
Donc, c'est plus compliqué que ça et face à tous les neuneus qui
utilisent un Apn, je continuerai à leur proposer de finir par Paint,
car ils sont bien incapables de s'occuper de compression !
On passe quand même de 436 à 96 Ko pour une photo 800x600... c'est
pas mal, et avec une perte négligeable (sinon nulle) en qualité à
l'affichage à l'écran.
merci à tout ceux qui ont répondu ...
Que soit une image papier ou une image à l'écran, sa qualité (son équilibre)
s'apprécie avant tout dans sa totalité. Pour une iage papier, on a tout sous
les yeux. Sur un écran, il est -AMHA- importaznt que TOUE l'image tienne sur
l'éran, sans avoir à faire joujou avec les curseurs. Aussi, un format de
800x600 pixels me semble un bon compromis.
Donc, c'est plus compliqué que ça et face à tous les neuneus qui utilisent un Apn, je continuerai à leur proposer de finir par Paint, car ils sont bien incapables de s'occuper de compression ! On passe quand même de 436 à 96 Ko pour une photo 800x600... c'est pas mal, et avec une perte négligeable (sinon nulle) en qualité à l'affichage à l'écran. merci à tout ceux qui ont répondu ...
Que soit une image papier ou une image à l'écran, sa qualité (son équilibre) s'apprécie avant tout dans sa totalité. Pour une iage papier, on a tout sous les yeux. Sur un écran, il est -AMHA- importaznt que TOUE l'image tienne sur l'éran, sans avoir à faire joujou avec les curseurs. Aussi, un format de 800x600 pixels me semble un bon compromis.
