Bonjour,
Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-windows):
http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivre-par-microsoft-pour-effacer-l-echec-vista/?di=2&play=0#debutDiaporama
" A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que
4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa version 64 bits
peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de
128 Go de RAM pour les éditions Intégral, Professionnel et Entreprise."
Ils veulent en venir ou avec ces limitation à la con?
Attention: Suivi là ou il faut.
PS: qui veut lancer les paris (sur Usenet) sur l'année de sortie
publique du successeur de Vista?
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde.
Bien sûr...
JKB
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde.
Bien sûr...
J'ai les deux sous la main actuellement et je fais des benchs de bases de données pour savoir si je dois prendre un serveur Integrity ou un x86_64. La base de données est une base de cartographie (MySQL, je n'ai pas cherché à compiler autre chose) et je puis affirmer tests à l'appui que l'IA64 sous OpenVMS est largement plus véloce que le x86_64 sous Linux. Les serveurs Integrity ont fait énormément de progrès depuis l'Itanium I (qui était effectivement une bouse). C'est encore plus flagrant lorsqu'on teste les accès concurrents où le serveur x86_64 s'écroule dès qu'on a plus de threads parallèles que de threads processeurs, ce qui pour un serveur montant en charge est assez problématique.
On peut être un intégriste du 64 bits sur x86_64, mais il ne faut pas être de mauvaise foi.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 29-05-2008, à propos de
Re: les versions de vista: limitations à la con,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrng3u68v.il3.knatschke@rayleigh.systella.fr>, a
écrit :
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du
monde.
Bien sûr...
J'ai les deux sous la main actuellement et je fais des benchs de
bases de données pour savoir si je dois prendre un serveur Integrity
ou un x86_64. La base de données est une base de cartographie (MySQL,
je n'ai pas cherché à compiler autre chose) et je puis affirmer
tests à l'appui que l'IA64 sous OpenVMS est largement plus véloce
que le x86_64 sous Linux. Les serveurs Integrity ont fait énormément
de progrès depuis l'Itanium I (qui était effectivement une bouse).
C'est encore plus flagrant lorsqu'on teste les accès concurrents où
le serveur x86_64 s'écroule dès qu'on a plus de threads parallèles
que de threads processeurs, ce qui pour un serveur montant en charge
est assez problématique.
On peut être un intégriste du 64 bits sur x86_64, mais il ne faut
pas être de mauvaise foi.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde.
Bien sûr...
J'ai les deux sous la main actuellement et je fais des benchs de bases de données pour savoir si je dois prendre un serveur Integrity ou un x86_64. La base de données est une base de cartographie (MySQL, je n'ai pas cherché à compiler autre chose) et je puis affirmer tests à l'appui que l'IA64 sous OpenVMS est largement plus véloce que le x86_64 sous Linux. Les serveurs Integrity ont fait énormément de progrès depuis l'Itanium I (qui était effectivement une bouse). C'est encore plus flagrant lorsqu'on teste les accès concurrents où le serveur x86_64 s'écroule dès qu'on a plus de threads parallèles que de threads processeurs, ce qui pour un serveur montant en charge est assez problématique.
On peut être un intégriste du 64 bits sur x86_64, mais il ne faut pas être de mauvaise foi.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les applications.
Tu te trompes.
Ah ouaips... Si tu le dis... Le mécanisme de changement de page sous Flex/UniFLEX était _intégré_ à l'OS et les applications ne faisaient qu'un appel système (dont j'ai oublié l'adresse) dont la gestion était laissée à la discrétion de l'OS (et il y avait intérêt parce que le code était relogeable). Le compilo avait juste à prévoir la page et l'adresse dans la page (ainsi que le timeout du registre fusible), c'est tout. Le reste ne le regardait pas, ça regardait l'OS (et le matériel).
Il ne faut surtout pas confondre un truc comme le MS-DOS où toute gestion de la mémoire était dévolue aux applications et des systèmes évolués où la gestion de la mémoire était le domaine réservé de l'OS.
Je n'ai _jamais_ fait de segmentation mémoire explicite dans un de mes codes
Alors tes codes ne devaient pas manipuler plus de 64 ko à la fois.
Non, jamais... Des tableaux de nombres complexes qui je peux te l'assurer ne tenaient pas dans 64 Ko.
J'aimerais bien te mettre le nez dans ls sources de Flex/UniFLEX, mais j'ai la flemme de recopier les listings assembleurs. Et si on faisait ça en 1984 sur Goupil G3 (Flex9 3.04 du mois d'avril 1984), il n'y a _aucune_ raison que cela n'existe pas sous d'autres OS.
Le fait de dévoluer ce genre de gestion aux applications est le signe d'un OS particulièrement mal foutu (et permissif). Cela simpifie l'écriture du système et le rend instable vis à vis d'applications écrites par des pieds. Maintenant, c'est un choix, et c'est peut-être ce qui explique qu'un OS comme MS-DOS coûtait largement moins cher qu'un OS de type UniFLEX (sans compter que je ne suis pas sûr qu'on puisse implanter un mécanisme de gestion de la mémoire de type FLEX/UniFLEX sur un PC avant au moins le 80286 voire le 80386 car celui-ci s'appuie sur un contrôleur mémoire spécifique.).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 29-05-2008, à propos de
Re: les versions de vista: limitations à la con,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrng3u6gd.il3.knatschke@rayleigh.systella.fr>, a
écrit :
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les
applications.
Tu te trompes.
Ah ouaips... Si tu le dis... Le mécanisme de changement de page sous
Flex/UniFLEX était _intégré_ à l'OS et les applications ne faisaient
qu'un appel système (dont j'ai oublié l'adresse) dont la gestion
était laissée à la discrétion de l'OS (et il y avait intérêt parce
que le code était relogeable). Le compilo avait juste à prévoir la
page et l'adresse dans la page (ainsi que le timeout du registre
fusible), c'est tout. Le reste ne le regardait pas, ça regardait l'OS
(et le matériel).
Il ne faut surtout pas confondre un truc comme le MS-DOS où toute
gestion de la mémoire était dévolue aux applications et des systèmes
évolués où la gestion de la mémoire était le domaine réservé de
l'OS.
Je n'ai _jamais_ fait de segmentation mémoire
explicite dans un de mes codes
Alors tes codes ne devaient pas manipuler plus de 64 ko à la fois.
Non, jamais... Des tableaux de nombres complexes qui je peux te
l'assurer ne tenaient pas dans 64 Ko.
J'aimerais bien te mettre le nez dans ls sources de Flex/UniFLEX,
mais j'ai la flemme de recopier les listings assembleurs. Et si on
faisait ça en 1984 sur Goupil G3 (Flex9 3.04 du mois d'avril 1984),
il n'y a _aucune_ raison que cela n'existe pas sous d'autres OS.
Le fait de dévoluer ce genre de gestion aux applications est le
signe d'un OS particulièrement mal foutu (et permissif). Cela
simpifie l'écriture du système et le rend instable vis à vis
d'applications écrites par des pieds. Maintenant, c'est un choix, et
c'est peut-être ce qui explique qu'un OS comme MS-DOS coûtait
largement moins cher qu'un OS de type UniFLEX (sans compter que je
ne suis pas sûr qu'on puisse implanter un mécanisme de gestion de la
mémoire de type FLEX/UniFLEX sur un PC avant au moins le 80286 voire
le 80386 car celui-ci s'appuie sur un contrôleur mémoire spécifique.).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Sauf qu'à l'époque, c'est l'OS qui se tapait ça, et pas les applications.
Tu te trompes.
Ah ouaips... Si tu le dis... Le mécanisme de changement de page sous Flex/UniFLEX était _intégré_ à l'OS et les applications ne faisaient qu'un appel système (dont j'ai oublié l'adresse) dont la gestion était laissée à la discrétion de l'OS (et il y avait intérêt parce que le code était relogeable). Le compilo avait juste à prévoir la page et l'adresse dans la page (ainsi que le timeout du registre fusible), c'est tout. Le reste ne le regardait pas, ça regardait l'OS (et le matériel).
Il ne faut surtout pas confondre un truc comme le MS-DOS où toute gestion de la mémoire était dévolue aux applications et des systèmes évolués où la gestion de la mémoire était le domaine réservé de l'OS.
Je n'ai _jamais_ fait de segmentation mémoire explicite dans un de mes codes
Alors tes codes ne devaient pas manipuler plus de 64 ko à la fois.
Non, jamais... Des tableaux de nombres complexes qui je peux te l'assurer ne tenaient pas dans 64 Ko.
J'aimerais bien te mettre le nez dans ls sources de Flex/UniFLEX, mais j'ai la flemme de recopier les listings assembleurs. Et si on faisait ça en 1984 sur Goupil G3 (Flex9 3.04 du mois d'avril 1984), il n'y a _aucune_ raison que cela n'existe pas sous d'autres OS.
Le fait de dévoluer ce genre de gestion aux applications est le signe d'un OS particulièrement mal foutu (et permissif). Cela simpifie l'écriture du système et le rend instable vis à vis d'applications écrites par des pieds. Maintenant, c'est un choix, et c'est peut-être ce qui explique qu'un OS comme MS-DOS coûtait largement moins cher qu'un OS de type UniFLEX (sans compter que je ne suis pas sûr qu'on puisse implanter un mécanisme de gestion de la mémoire de type FLEX/UniFLEX sur un PC avant au moins le 80286 voire le 80386 car celui-ci s'appuie sur un contrôleur mémoire spécifique.).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
pehache-tolai
On 25 mai, 01:49, Stephane TOUGARD wrote:
Processeur AMD 64b avec Ubuntu 64b. 2GB de ram. Fichier DNG de 14Mpx venant d'un Pentax K20d (un des boitiers modernes avec l'un des plus gros fichiers).
Traitement du fichier RAW (DNG) par Raw Therapee (sans doute le meilleur et definitivement le meilleur sous Linux)
Concernant les possibilités de réglages et la qualité des images en sortie, c'est certainement un très bon logiciel.
Par contre il n'a aucune capacité de traitement par lot, ce qui pour un derawtiseur est assez génant.
Donc dire que c'est "le meilleur" tout court, non...
version 64b. Taille max du process en RAM pdt le traitement : 409Mb en memoire Virtuelle.
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce fichier : 891Mb en memoire Virtuelle.
Je ne sais pas comment se débrouillent Raw Therapee et encore plus Gimp, mais à mon avis assez mal: une image de 14Mpix, même en 16bits/ canal, n'occupe que 84Mo de mémoire.
Bref, pour le traitement du RAW, nul besoin de 2GB. Pour le post traitement dans Gimp (incluant des filtres assez lourd), 2GB suffisent TRES largement et nul besoin de 4 ou de 8Gb.
Même 1Go suffit. C'est ce que j'ai, et je manipule des fichiers de cette taille sans problème.
-- pehache
On 25 mai, 01:49, Stephane TOUGARD <steph...@unices.org> wrote:
Processeur AMD 64b avec Ubuntu 64b. 2GB de ram. Fichier DNG de 14Mpx
venant d'un Pentax K20d (un des boitiers modernes avec l'un des plus gros
fichiers).
Traitement du fichier RAW (DNG) par Raw Therapee (sans doute le meilleur
et definitivement le meilleur sous Linux)
Concernant les possibilités de réglages et la qualité des images en
sortie, c'est certainement un très bon logiciel.
Par contre il n'a aucune capacité de traitement par lot, ce qui pour
un derawtiseur est assez génant.
Donc dire que c'est "le meilleur" tout court, non...
version 64b. Taille max du
process en RAM pdt le traitement : 409Mb en memoire Virtuelle.
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce
fichier : 891Mb en memoire Virtuelle.
Je ne sais pas comment se débrouillent Raw Therapee et encore plus
Gimp, mais à mon avis assez mal: une image de 14Mpix, même en 16bits/
canal, n'occupe que 84Mo de mémoire.
Bref, pour le traitement du RAW, nul besoin de 2GB. Pour le post
traitement dans Gimp (incluant des filtres assez lourd), 2GB suffisent
TRES largement et nul besoin de 4 ou de 8Gb.
Même 1Go suffit. C'est ce que j'ai, et je manipule des fichiers de
cette taille sans problème.
Processeur AMD 64b avec Ubuntu 64b. 2GB de ram. Fichier DNG de 14Mpx venant d'un Pentax K20d (un des boitiers modernes avec l'un des plus gros fichiers).
Traitement du fichier RAW (DNG) par Raw Therapee (sans doute le meilleur et definitivement le meilleur sous Linux)
Concernant les possibilités de réglages et la qualité des images en sortie, c'est certainement un très bon logiciel.
Par contre il n'a aucune capacité de traitement par lot, ce qui pour un derawtiseur est assez génant.
Donc dire que c'est "le meilleur" tout court, non...
version 64b. Taille max du process en RAM pdt le traitement : 409Mb en memoire Virtuelle.
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce fichier : 891Mb en memoire Virtuelle.
Je ne sais pas comment se débrouillent Raw Therapee et encore plus Gimp, mais à mon avis assez mal: une image de 14Mpix, même en 16bits/ canal, n'occupe que 84Mo de mémoire.
Bref, pour le traitement du RAW, nul besoin de 2GB. Pour le post traitement dans Gimp (incluant des filtres assez lourd), 2GB suffisent TRES largement et nul besoin de 4 ou de 8Gb.
Même 1Go suffit. C'est ce que j'ai, et je manipule des fichiers de cette taille sans problème.
-- pehache
pehache-tolai
On 28 mai, 00:35, Jérémy JUST wrote:
Le Sun, 25 May 2008 07:49:02 +0800,
Traitement du fichier RAW (DNG) par Raw Therapee (sans doute le meilleur et definitivement le meilleur sous Linux) version 64b. Taille max du process en RAM pdt le traitement : 409Mb en memoire Virtuelle.
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce fichier : 891Mb en memoire Virtuelle.
Bref, pour le traitement du RAW, nul besoin de 2GB.
L'ordre de grandeur est le même; il suffit d'ouvrir deux images en même temps pour être limite (cas fréquent), ou d'être à deux utilisateurs (rare en contexte domestique mais fréquent dans un petit bureau). Sans compter qu'on a toujours un ou deux Firefox ouverts en plus, ce qui suffira pour commencer à swapper.
2 images de 14Mpix en 16bits en mémoire, ça fait 170Mo. Un historique de 5 traitements gardés en mémoire pour les 2 images, ça porte à 850Mo. Mettons 1,2Go avec l'OS et le logiciel lui-même. Ca laisse 800Mo pour firefox.
-- pehache
On 28 mai, 00:35, Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
Le Sun, 25 May 2008 07:49:02 +0800,
Traitement du fichier RAW (DNG) par Raw Therapee (sans doute le
meilleur et definitivement le meilleur sous Linux) version 64b.
Taille max du process en RAM pdt le traitement : 409Mb en memoire
Virtuelle.
Chargement du fichier Tiff resultant par Gimp et traitement normal
sur ce fichier : 891Mb en memoire Virtuelle.
Bref, pour le traitement du RAW, nul besoin de 2GB.
L'ordre de grandeur est le même; il suffit d'ouvrir deux images en
même temps pour être limite (cas fréquent), ou d'être à deux
utilisateurs (rare en contexte domestique mais fréquent dans un petit
bureau). Sans compter qu'on a toujours un ou deux Firefox ouverts en
plus, ce qui suffira pour commencer à swapper.
2 images de 14Mpix en 16bits en mémoire, ça fait 170Mo. Un historique
de 5 traitements gardés en mémoire pour les 2 images, ça porte à
850Mo. Mettons 1,2Go avec l'OS et le logiciel lui-même. Ca laisse
800Mo pour firefox.
Traitement du fichier RAW (DNG) par Raw Therapee (sans doute le meilleur et definitivement le meilleur sous Linux) version 64b. Taille max du process en RAM pdt le traitement : 409Mb en memoire Virtuelle.
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce fichier : 891Mb en memoire Virtuelle.
Bref, pour le traitement du RAW, nul besoin de 2GB.
L'ordre de grandeur est le même; il suffit d'ouvrir deux images en même temps pour être limite (cas fréquent), ou d'être à deux utilisateurs (rare en contexte domestique mais fréquent dans un petit bureau). Sans compter qu'on a toujours un ou deux Firefox ouverts en plus, ce qui suffira pour commencer à swapper.
2 images de 14Mpix en 16bits en mémoire, ça fait 170Mo. Un historique de 5 traitements gardés en mémoire pour les 2 images, ça porte à 850Mo. Mettons 1,2Go avec l'OS et le logiciel lui-même. Ca laisse 800Mo pour firefox.
-- pehache
remy
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde. Bien sûr...
J'ai les deux sous la main actuellement et je fais des benchs
j'ai un teste a la con de puissance de calcul pure
http://remyaumeunier.chez-alice.fr/alea.html
crée aller 1 Mo
remy
Le 29-05-2008, à propos de
Re: les versions de vista: limitations à la con,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrng3u68v.il3.knatschke@rayleigh.systella.fr>, a
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du
monde.
Bien sûr...
J'ai les deux sous la main actuellement et je fais des benchs
j'ai un teste a la con de puissance de calcul pure
Le 29-05-2008, à propos de Re: les versions de vista: limitations à la con, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a
C'est faux, les Integrity sous VMS détrônent tous les x86_64 du monde. Bien sûr...
J'ai les deux sous la main actuellement et je fais des benchs
j'ai un teste a la con de puissance de calcul pure
http://remyaumeunier.chez-alice.fr/alea.html
crée aller 1 Mo
remy
cauchemar
Jour,
On 24 mai, 20:08, "Rakotomandimby (R12y) Mihamina" vociféré :
Bonjour, Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-window s):http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivr... " A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que 4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa version 64 bit s peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de 128 Go de RAM pour les éditions Intégral, Professionnel et Entreprise. "
Ils veulent en venir ou avec ces limitation à la con?
Que serait linux sans microsoft ?
Cauchemar
Jour,
On 24 mai, 20:08, "Rakotomandimby (R12y) Mihamina"
<miham...@infogerance.us> vociféré :
Bonjour,
Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-window s):http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivr...
" A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que
4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa version 64 bit s
peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de
128 Go de RAM pour les éditions Intégral, Professionnel et Entreprise. "
Ils veulent en venir ou avec ces limitation à la con?
On 24 mai, 20:08, "Rakotomandimby (R12y) Mihamina" vociféré :
Bonjour, Lu ici (apres suivi d'un lien donné par MELMOTH sur fr.comp.os.ms-window s):http://www.01net.com/editorial/380253/windows-seven-10-pistes-a-suivr... " A titre d'exemple, Windows Vista en 32 bits ne supporte en théorie que 4 Go de RAM, légèrement plus de 3 Go dans les faits. Sa version 64 bit s peut utiliser 8 Go pour l'édition Basic, 16 Go pour la Premium à plus de 128 Go de RAM pour les éditions Intégral, Professionnel et Entreprise. "
Ils veulent en venir ou avec ces limitation à la con?
Que serait linux sans microsoft ?
Cauchemar
Thierry B.
--{ pehache-tolai a plopé ceci: }--
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce fichier : 891Mb en memoire Virtuelle.
Je ne sais pas comment se débrouillent Raw Therapee et encore plus Gimp, mais à mon avis assez mal: une image de 14Mpix, même en 16bits/ canal, n'occupe que 84Mo de mémoire.
Certes, mais tu rajoutes le buffer d'affichage, une copie de travail, la pile des undos, le moindre début de calque, et ça montre très rapidement. Là, en ce moment, j'ai une image 6000x4500 chargée dans Gimp avec juste deux calques: fichier d'échange 650Mo et occupation mémoire ~280Mo.
-- Por faire un "" je tape "c: windows" dans google puis un copier-coller sur les resultat. J'aime les macs.
--{ pehache-tolai a plopé ceci: }--
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce
fichier : 891Mb en memoire Virtuelle.
Je ne sais pas comment se débrouillent Raw Therapee et encore plus
Gimp, mais à mon avis assez mal: une image de 14Mpix, même en 16bits/
canal, n'occupe que 84Mo de mémoire.
Certes, mais tu rajoutes le buffer d'affichage, une copie de travail,
la pile des undos, le moindre début de calque, et ça montre très
rapidement. Là, en ce moment, j'ai une image 6000x4500 chargée
dans Gimp avec juste deux calques: fichier d'échange 650Mo et
occupation mémoire ~280Mo.
--
Por faire un "" je tape "c: windows" dans google puis un
copier-coller sur les resultat. J'aime les macs.
Chargement du fichier Tiff resultant par Gimp et traitement normal sur ce fichier : 891Mb en memoire Virtuelle.
Je ne sais pas comment se débrouillent Raw Therapee et encore plus Gimp, mais à mon avis assez mal: une image de 14Mpix, même en 16bits/ canal, n'occupe que 84Mo de mémoire.
Certes, mais tu rajoutes le buffer d'affichage, une copie de travail, la pile des undos, le moindre début de calque, et ça montre très rapidement. Là, en ce moment, j'ai une image 6000x4500 chargée dans Gimp avec juste deux calques: fichier d'échange 650Mo et occupation mémoire ~280Mo.
-- Por faire un "" je tape "c: windows" dans google puis un copier-coller sur les resultat. J'aime les macs.
Thierry B.
--{ cauchemar a plopé ceci: }--
Que serait linux sans microsoft ?
La même chose ?
-- ( La devise du LL c'est faite se que je dis, mais se que je fais ...) --{ Ptilou, équivoque dans fcol.debats }--
--{ cauchemar a plopé ceci: }--
Que serait linux sans microsoft ?
La même chose ?
--
( La devise du LL c'est faite se que je dis, mais se que je fais ...)
--{ Ptilou, équivoque dans fcol.debats }--
