Quelle config PC pour la photo. Proposition de cahier des charges
121 réponses
Fred le Barbu
Bonjour,
décidément, que de temps à attendre devant le PC lorque qu'on est en train
de à classer, "développer", corriger, diffuser, imprimer, -bref traiter- ses
photos numériques (remarquez, c'était bien pire dans la chambre noire, du
temps ingrat de l'argentique) !
Je n'ai pas très envie de changer de soft et mon PC n'est plus dans sa
première jeunesse (Athlon XP 2600+, 1 Go, avec une CG sur bus AGP2 et des
disques ATA): c'est lui que je songe à remplacer. (au fait vais-je vraiment
pouvoir trouver beaucoup beaucoup plus eficace ?)
Je souhaite utiliser Lightroom et Photoshop notamment. Mon APN est un 10 MP
qui me donne des RAW 12 bits. Je garde environ 3000 photos chaque année, en
déclenchant 3 fois plus. sans parler de scans, d'environ 12 MP 16 bits.
La question est quelle configuration acheter ?
J'ai essayé de contribuer à ce sujet en tentant de rédiger un petit cahier
des charges. Vous parait-il cohérent et complet ? Quels sont les éléments
critiques à privilégier ? Quelles sont les références des composants
matériels qui y répondent ?
Ce qui me parait critique:
1. Visualiser rapidement les photos les unes après les autres => disque
rapide + transfert vers carte mère rapide + CPU rapide + bus carte graphique
rapide ?
2. Pouvoir zoomer, dézoomer rapidement sur plusieurs photos à la suite, par
exemple pour évaluer la netteté de plusieurs photos => gros CPU ? mémoire
vive rapide + grosse capacité ?
3. Pouvoir visualiser rapidement l'effet de telle ou telle correction sur la
photo (par exemple dans le menu développement de lightroom) => gros CPU ?
mémoire vive rapide ?
4. Grosse capacité de stockage, fiable (le format raw prend de la place +
avec Toshop j'ai fréquemment des fichier de 200 Mo) => un gros disque ou
plusieurs moins gros ?
Mais aussi:
5. Des traitements par lots pas trop lents (mais là, c'est moins important,
car on peut aller faire autre chose pendant que ça mouline) => gros CPU ?
6. Un bon affichage (je ne pense pas changer mon écran 1280x1024 pour le
moment, mais quand ça sera abordable, j'achèterai un écran capable
d'afficher 4 ou 5 Mpixels), j'ai une sonde de calibration. La carte
graphique a-t-elle un influence sur la qualité de l'affichage ?
7. Possibilité d'ajouter un petit écran (le petit pour les menus, le grand
pour les images plein écran). Au fait, est-ce que c'est une bonne idée ?
8. Des capacités de sauvegarde => Là, j'ai l'impression qu'on est dans le
difficile. j'aurai tendance à penser à un autre gros disque, externe ou non,
mais bon, c'est cher et "peu évolutif"
9. Du silence ! Existe-t-il des alim silencieuses mais abordables ?
10. La configuration devrait être basée sur des standards qui ont un peu
d'avenir pour pouvoir faire évoluer le PC quand il y en aura besoin
11. Et bien sûr, tout le reste indispensable aujourd'hui: ethernet, Wifi,
plein de USB, etc ?
12. Avec un petit plus (mais ça n'a rien à voir avec notre sujet): un bon
convertisseur numérique /analogique audio pour une restitution de la musique
de bonne qualité.
Remarque: je ne pense pas utile d'acheter le top du top hyper cher. Sauf
peut-être si les derniers composants sortis permettent vraiment de franchir
une marche importante. Et encore, il suffit souvent de patienter quelques
mois qu'ils se démocratisent.
Questions complémentaires probablement utiles pour répondre au cahier des
charges précédant:
La puissance de la carte graphique a-t-elle un impact ? (vitesse et quantité
de mémoire)
Lightroom exploite-t-il le multicore (quelles versions de LR) ?
Lightroom exploite-t-il le 64 bits (quelles versions de LR) ?
Pour l'OS: XP ou Vista ?
J'ajoute que je compte -à priori- assembler le PC (ou le faire assembler) à
partir des éléments répondant à mon besoin spécifique.
Donc, selon vous:
quel processeur ?
quelle RAM (et quantité)
quelle carte mère ?
quel disque (vitesse, marque, capacité)
quelle carte graphique ?
et aussi:
quel alim, quel boitier, quel moyen de sauvegarde, etc...
Merci d'avoir pris le temps de lire ce long message.
Et merci de vos réponses, qui intéresseront un grand nombre de photographes.
mais rien n'empêche de faire une couche logicielle qui se sert de la carte comme d'une calculatrice à tout faire ou presque...
Du côté de la POmme on parle de OpenCL.
Juste une lettre qui devrait changer beaucoup de choses. A suivre dans les mois qui viennent.
François Jouve
Sylvain SF wrote:
Stephane Legras-Decussy wrote on 12/06/2008 00:59:
. c'est vrai si tu raisonnes à travers directX ou openGL qui pilote une CG pour faire ça.
oui.
mais rien n'empêche de faire une couche logicielle qui se sert de la carte comme d'une calculatrice à tout faire ou presque...
en théorie non, en pratique si, tout empêche de le faire, ou encore rien ne permet aisément de le faire.
"Aisément" c'est toujours très relatif. Photoshop n'a pas été écrit "aisément". Mais rien n'empêche de le faire, et beaucoup ne s'en privent pas : http://www.gpgpu.org/cgi-bin/blosxom.cgi/Scientific%20Computing/index.html
-- F.J.
Sylvain SF wrote:
Stephane Legras-Decussy wrote on 12/06/2008 00:59:
.
c'est vrai si tu raisonnes à travers directX
ou openGL qui pilote une CG pour faire ça.
oui.
mais rien n'empêche de faire une couche
logicielle qui se sert de la carte comme d'une
calculatrice à tout faire ou presque...
en théorie non, en pratique si, tout empêche de le faire,
ou encore rien ne permet aisément de le faire.
"Aisément" c'est toujours très relatif. Photoshop n'a pas
été écrit "aisément". Mais rien n'empêche de le faire,
et beaucoup ne s'en privent pas :
http://www.gpgpu.org/cgi-bin/blosxom.cgi/Scientific%20Computing/index.html
Stephane Legras-Decussy wrote on 12/06/2008 00:59:
. c'est vrai si tu raisonnes à travers directX ou openGL qui pilote une CG pour faire ça.
oui.
mais rien n'empêche de faire une couche logicielle qui se sert de la carte comme d'une calculatrice à tout faire ou presque...
en théorie non, en pratique si, tout empêche de le faire, ou encore rien ne permet aisément de le faire.
"Aisément" c'est toujours très relatif. Photoshop n'a pas été écrit "aisément". Mais rien n'empêche de le faire, et beaucoup ne s'en privent pas : http://www.gpgpu.org/cgi-bin/blosxom.cgi/Scientific%20Computing/index.html
-- F.J.
Thierry B.
--{ Anne a plopé ceci: }--
Ceci dit, le plus puissant des ordi est un cluster de PS3... Ce fut un cluster de xServe à base de G5 qui a aussi boxé dans la cours des (très) grands
Je n'en suis pas sûr... http://www.top500.org/
-- "Il vaut mieux pomper même s'il ne se passe rien que risquer qu'il se passe quelque chose de pire en ne pompant pas." --{ Devise Shadok }--
--{ Anne a plopé ceci: }--
Ceci dit, le plus puissant des ordi est un cluster de PS3... Ce fut un
cluster de xServe à base de G5 qui a aussi boxé dans la cours des (très)
grands
Je n'en suis pas sûr... http://www.top500.org/
--
"Il vaut mieux pomper même s'il ne se passe rien que risquer qu'il se passe
quelque chose de pire en ne pompant pas."
--{ Devise Shadok }--
merci de redonner des liens déjà cités et répondant exactement aux critères que j'ai énoncé: hard dédié et/ou code tordu.
btw, tu as acheté et lu au moins un de ces articles ?
Sylvain.
Ofnuts
YouDontNeedToKnowButItsNoëlle wrote:
Moi mes doutes viendraient plutôt de l'existence d'API uniformes avec un résultat homogène, vu la variété des modèles de cartes, et le fait que c'est bien joli de faire appel à une api comme service pour le code client, mais il faut bien que le code fourni derrière soit écrit, de préférence implanté en microcode pour que ça pédale.
Ces APIs existent: DirectX et OpenGL... (surtout DirectX, car les cartes sont pratiquement faites pour implémenter le DirectX en hardware)
-- Bertrand
YouDontNeedToKnowButItsNoëlle wrote:
Moi mes doutes viendraient plutôt de l'existence d'API uniformes avec un
résultat homogène, vu la variété des modèles de cartes, et le fait que
c'est bien joli de faire appel à une api comme service pour le code
client, mais il faut bien que le code fourni derrière soit écrit, de
préférence implanté en microcode pour que ça pédale.
Ces APIs existent: DirectX et OpenGL... (surtout DirectX, car les
cartes sont pratiquement faites pour implémenter le DirectX en hardware)
Moi mes doutes viendraient plutôt de l'existence d'API uniformes avec un résultat homogène, vu la variété des modèles de cartes, et le fait que c'est bien joli de faire appel à une api comme service pour le code client, mais il faut bien que le code fourni derrière soit écrit, de préférence implanté en microcode pour que ça pédale.
Ces APIs existent: DirectX et OpenGL... (surtout DirectX, car les cartes sont pratiquement faites pour implémenter le DirectX en hardware)
-- Bertrand
YouDontNeedToKnowButItsNoëlle
Ces APIs existent: DirectX et OpenGL... (surtout DirectX, car les cartes sont pratiquement faites pour implémenter le DirectX en hardware)
DirectX fournit les primitives de traitement photo ?
Noëlle Adam.
Ces APIs existent: DirectX et OpenGL... (surtout DirectX, car les
cartes sont pratiquement faites pour implémenter le DirectX en hardware)
DirectX fournit les primitives de traitement photo ?
Ces APIs existent: DirectX et OpenGL... (surtout DirectX, car les cartes sont pratiquement faites pour implémenter le DirectX en hardware)
DirectX fournit les primitives de traitement photo ?
Noëlle Adam.
François Jouve
Sylvain SF wrote:
François Jouve wrote on 12/06/2008 08:59:
Photoshop n'a pas été écrit "aisément".
ah bon ?! donc tu imagines qu'il pourrait contenir des routines codées en dizaines d'exemplaires spécifiques pour utiliser tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique pour chaque GPU. L'interface peut se faire par exemple avec OpenGL : http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
merci de redonner des liens déjà cités et répondant exactement aux critères que j'ai énoncé: hard dédié et/ou code tordu.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ??? Je commence à m'intéresser à la chose pour d'autres applications. D'après ce que j'ai compris les instructions propres aux GPU sont bien adaptées aux calculs matriciels. Leur gros défaut pour les applications de calcul est de se faire en simple précision. Mais justement les traitements d'image se font bien en simple précision.
-- F.J.
Sylvain SF wrote:
François Jouve wrote on 12/06/2008 08:59:
Photoshop n'a pas été écrit "aisément".
ah bon ?!
donc tu imagines qu'il pourrait contenir des routines
codées en dizaines d'exemplaires spécifiques pour utiliser
tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique
pour chaque GPU. L'interface peut se faire par exemple
avec OpenGL :
http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
merci de redonner des liens déjà cités et répondant exactement
aux critères que j'ai énoncé: hard dédié et/ou code tordu.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
Je commence à m'intéresser à la chose pour d'autres applications.
D'après ce que j'ai compris les instructions propres aux GPU
sont bien adaptées aux calculs matriciels. Leur gros défaut pour
les applications de calcul est de se faire en simple précision.
Mais justement les traitements d'image se font bien en simple précision.
ah bon ?! donc tu imagines qu'il pourrait contenir des routines codées en dizaines d'exemplaires spécifiques pour utiliser tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique pour chaque GPU. L'interface peut se faire par exemple avec OpenGL : http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
merci de redonner des liens déjà cités et répondant exactement aux critères que j'ai énoncé: hard dédié et/ou code tordu.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ??? Je commence à m'intéresser à la chose pour d'autres applications. D'après ce que j'ai compris les instructions propres aux GPU sont bien adaptées aux calculs matriciels. Leur gros défaut pour les applications de calcul est de se faire en simple précision. Mais justement les traitements d'image se font bien en simple précision.
-- F.J.
Sylvain SF
François Jouve wrote on 12/06/2008 21:46:
ah bon ?! donc tu imagines qu'il pourrait contenir des routines codées en dizaines d'exemplaires spécifiques pour utiliser tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique pour chaque GPU. L'interface peut se faire par exemple avec OpenGL : http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
on tourne en rond là, non ?
le fil s'accorde sur le fait que: - les GPU possèdent des primitives mathémaiques intéressantes - elles sont utilisées globalement pour créer tel ou tel effet (anti-aliasing, reflet, brouillard, fumée, ...) accessible via les APIs DirectX ou OpenGL MAIS quasi jamais via des points d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder des routines spécifiques à chacun de ces procs-graphiques - en supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq petits autres trucs) il ne permet pas de faire de la retouche photo.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ? (je parlais de "machines de laboratoires") ces articles sont (généralement) disponibles entre bibliothèques universitaires qui ont des abonnements croisés, ou à l'achat.
Mais justement les traitements d'image se font bien en simple précision.
?? je crains que l'amalgame induit par ce "les traitements" soit source d'erreur - certains traitements sont fait via du calcul entier 8, 16 ou 32 bits (seuil sur intensité de couleur, luminance, etc), d'autres sont fait en flottant et utilisent quelque 'float' (simple préc.) mais surtout des 'double' (double préc.) tel un encodage JPG.
Sylvain.
François Jouve wrote on 12/06/2008 21:46:
ah bon ?!
donc tu imagines qu'il pourrait contenir des routines
codées en dizaines d'exemplaires spécifiques pour utiliser
tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique
pour chaque GPU. L'interface peut se faire par exemple
avec OpenGL :
http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
on tourne en rond là, non ?
le fil s'accorde sur le fait que:
- les GPU possèdent des primitives mathémaiques intéressantes
- elles sont utilisées globalement pour créer tel ou tel effet
(anti-aliasing, reflet, brouillard, fumée, ...) accessible via
les APIs DirectX ou OpenGL MAIS quasi jamais via des points
d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées
par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent
être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer
que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder
des routines spécifiques à chacun de ces procs-graphiques - en
supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq
petits autres trucs) il ne permet pas de faire de la retouche photo.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ?
(je parlais de "machines de laboratoires") ces articles sont
(généralement) disponibles entre bibliothèques universitaires
qui ont des abonnements croisés, ou à l'achat.
Mais justement les traitements d'image se font bien en simple précision.
?? je crains que l'amalgame induit par ce "les traitements" soit
source d'erreur - certains traitements sont fait via du calcul
entier 8, 16 ou 32 bits (seuil sur intensité de couleur, luminance,
etc), d'autres sont fait en flottant et utilisent quelque 'float'
(simple préc.) mais surtout des 'double' (double préc.) tel
un encodage JPG.
ah bon ?! donc tu imagines qu'il pourrait contenir des routines codées en dizaines d'exemplaires spécifiques pour utiliser tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique pour chaque GPU. L'interface peut se faire par exemple avec OpenGL : http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
on tourne en rond là, non ?
le fil s'accorde sur le fait que: - les GPU possèdent des primitives mathémaiques intéressantes - elles sont utilisées globalement pour créer tel ou tel effet (anti-aliasing, reflet, brouillard, fumée, ...) accessible via les APIs DirectX ou OpenGL MAIS quasi jamais via des points d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder des routines spécifiques à chacun de ces procs-graphiques - en supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq petits autres trucs) il ne permet pas de faire de la retouche photo.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ? (je parlais de "machines de laboratoires") ces articles sont (généralement) disponibles entre bibliothèques universitaires qui ont des abonnements croisés, ou à l'achat.
Mais justement les traitements d'image se font bien en simple précision.
?? je crains que l'amalgame induit par ce "les traitements" soit source d'erreur - certains traitements sont fait via du calcul entier 8, 16 ou 32 bits (seuil sur intensité de couleur, luminance, etc), d'autres sont fait en flottant et utilisent quelque 'float' (simple préc.) mais surtout des 'double' (double préc.) tel un encodage JPG.
Sylvain.
eric
Sylvain SF wrote:
François Jouve wrote on 12/06/2008 21:46:
ah bon ?! donc tu imagines qu'il pourrait contenir des routines codées en dizaines d'exemplaires spécifiques pour utiliser tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique pour chaque GPU. L'interface peut se faire par exemple avec OpenGL : http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
on tourne en rond là, non ?
le fil s'accorde sur le fait que: - les GPU possèdent des primitives mathémaiques intéressantes - elles sont utilisées globalement pour créer tel ou tel effet (anti-aliasing, reflet, brouillard, fumée, ...) accessible via les APIs DirectX ou OpenGL MAIS quasi jamais via des points d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder des routines spécifiques à chacun de ces procs-graphiques - en supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq petits autres trucs) il ne permet pas de faire de la retouche photo.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ? (je parlais de "machines de laboratoires") ces articles sont (généralement) disponibles entre bibliothèques universitaires qui ont des abonnements croisés, ou à l'achat.
Mais justement les traitements d'image se font bien en simple précision.
?? je crains que l'amalgame induit par ce "les traitements" soit source d'erreur - certains traitements sont fait via du calcul entier 8, 16 ou 32 bits (seuil sur intensité de couleur, luminance, etc), d'autres sont fait en flottant et utilisent quelque 'float' (simple préc.) mais surtout des 'double' (double préc.) tel un encodage JPG.
Sylvain.
Tu parles de photo là, eh ben... eric
Sylvain SF wrote:
François Jouve wrote on 12/06/2008 21:46:
ah bon ?!
donc tu imagines qu'il pourrait contenir des routines
codées en dizaines d'exemplaires spécifiques pour utiliser
tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique
pour chaque GPU. L'interface peut se faire par exemple
avec OpenGL :
http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
on tourne en rond là, non ?
le fil s'accorde sur le fait que:
- les GPU possèdent des primitives mathémaiques intéressantes
- elles sont utilisées globalement pour créer tel ou tel effet
(anti-aliasing, reflet, brouillard, fumée, ...) accessible via
les APIs DirectX ou OpenGL MAIS quasi jamais via des points
d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées
par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent
être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer
que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder
des routines spécifiques à chacun de ces procs-graphiques - en
supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq
petits autres trucs) il ne permet pas de faire de la retouche photo.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ?
(je parlais de "machines de laboratoires") ces articles sont
(généralement) disponibles entre bibliothèques universitaires
qui ont des abonnements croisés, ou à l'achat.
Mais justement les traitements d'image se font bien en simple
précision.
?? je crains que l'amalgame induit par ce "les traitements" soit
source d'erreur - certains traitements sont fait via du calcul
entier 8, 16 ou 32 bits (seuil sur intensité de couleur, luminance,
etc), d'autres sont fait en flottant et utilisent quelque 'float'
(simple préc.) mais surtout des 'double' (double préc.) tel
un encodage JPG.
ah bon ?! donc tu imagines qu'il pourrait contenir des routines codées en dizaines d'exemplaires spécifiques pour utiliser tel ou tel GPU ?
Il n'est pas besoin de coder de façon spécifique pour chaque GPU. L'interface peut se faire par exemple avec OpenGL : http://www.mathematik.tu-dortmund.de/~goeddeke/gpgpu/tutorial.html
on tourne en rond là, non ?
le fil s'accorde sur le fait que: - les GPU possèdent des primitives mathémaiques intéressantes - elles sont utilisées globalement pour créer tel ou tel effet (anti-aliasing, reflet, brouillard, fumée, ...) accessible via les APIs DirectX ou OpenGL MAIS quasi jamais via des points d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder des routines spécifiques à chacun de ces procs-graphiques - en supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq petits autres trucs) il ne permet pas de faire de la retouche photo.
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ? (je parlais de "machines de laboratoires") ces articles sont (généralement) disponibles entre bibliothèques universitaires qui ont des abonnements croisés, ou à l'achat.
Mais justement les traitements d'image se font bien en simple précision.
?? je crains que l'amalgame induit par ce "les traitements" soit source d'erreur - certains traitements sont fait via du calcul entier 8, 16 ou 32 bits (seuil sur intensité de couleur, luminance, etc), d'autres sont fait en flottant et utilisent quelque 'float' (simple préc.) mais surtout des 'double' (double préc.) tel un encodage JPG.
Sylvain.
Tu parles de photo là, eh ben... eric
François Jouve
Sylvain SF wrote:
on tourne en rond là, non ?
On dirait :)
le fil s'accorde sur le fait que: - les GPU possèdent des primitives mathémaiques intéressantes - elles sont utilisées globalement pour créer tel ou tel effet (anti-aliasing, reflet, brouillard, fumée, ...) accessible via les APIs DirectX ou OpenGL MAIS quasi jamais via des points d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder des routines spécifiques à chacun de ces procs-graphiques - en supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq petits autres trucs) il ne permet pas de faire de la retouche photo.
En court : utiliser les capacités de calcul des GPU est devenu très à la mode dans un domaine que je connais bien, pour des applications a priori beaucoup plus complexes que ce qu'on trouve dans les soft de retouche photo. Je ne vois pas ce qui empêcherait techniquement les grosses boîtes de se lancer là dedans. Mais en fait je pense que la vitesse est le dernier de leurs soucis. Il n'y a qu'à voir l'efficacité de vista ;)
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ? (je parlais de "machines de laboratoires") ces articles sont (généralement) disponibles entre bibliothèques universitaires qui ont des abonnements croisés, ou à l'achat.
C'est toi qui n'a pas remarqué mon email...
-- F.J.
Sylvain SF wrote:
on tourne en rond là, non ?
On dirait :)
le fil s'accorde sur le fait que:
- les GPU possèdent des primitives mathémaiques intéressantes
- elles sont utilisées globalement pour créer tel ou tel effet
(anti-aliasing, reflet, brouillard, fumée, ...) accessible via
les APIs DirectX ou OpenGL MAIS quasi jamais via des points
d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées
par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent
être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer
que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder
des routines spécifiques à chacun de ces procs-graphiques - en
supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq
petits autres trucs) il ne permet pas de faire de la retouche photo.
En court : utiliser les capacités de calcul des GPU est devenu très
à la mode dans un domaine que je connais bien, pour des applications
a priori beaucoup plus complexes que ce qu'on trouve dans les soft
de retouche photo. Je ne vois pas ce qui empêcherait techniquement
les grosses boîtes de se lancer là dedans. Mais en fait je pense que
la vitesse est le dernier de leurs soucis. Il n'y a qu'à voir
l'efficacité de vista ;)
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ?
(je parlais de "machines de laboratoires") ces articles sont
(généralement) disponibles entre bibliothèques universitaires
qui ont des abonnements croisés, ou à l'achat.
le fil s'accorde sur le fait que: - les GPU possèdent des primitives mathémaiques intéressantes - elles sont utilisées globalement pour créer tel ou tel effet (anti-aliasing, reflet, brouillard, fumée, ...) accessible via les APIs DirectX ou OpenGL MAIS quasi jamais via des points d'entrés direct (des API very low level).
d'où mon point: ces primitives n'étant pas supposées être utilisées par un éditeur de soft (puisqu'il DOIT utiliser DirectX) peuvent être différentes entre un GPU 72xx, 78xx, 88xx, 98xx (pour ne citer que qlq chips nvidia) et donc un éditeur "jouant" à cela devra coder des routines spécifiques à chacun de ces procs-graphiques - en supposant déjà qu'il en obtienne la doc.
en court: on l'a déjà dit, OpenGL permet de faire des jeux (et qlq petits autres trucs) il ne permet pas de faire de la retouche photo.
En court : utiliser les capacités de calcul des GPU est devenu très à la mode dans un domaine que je connais bien, pour des applications a priori beaucoup plus complexes que ce qu'on trouve dans les soft de retouche photo. Je ne vois pas ce qui empêcherait techniquement les grosses boîtes de se lancer là dedans. Mais en fait je pense que la vitesse est le dernier de leurs soucis. Il n'y a qu'à voir l'efficacité de vista ;)
btw, tu as acheté et lu au moins un de ces articles ?
acheté ???
tu n'as pas remarqué que ce sont des articles universitaires ? (je parlais de "machines de laboratoires") ces articles sont (généralement) disponibles entre bibliothèques universitaires qui ont des abonnements croisés, ou à l'achat.
