Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

flipflip
2008-10-24 08:44:02

Un détail à prendre en compte pour le redimensionnement des images, c'est la qualité de l'image en elle même. Imaginions que j'utilise des images en 800x600 à 72 dpi, un utilisateur décide dans une idée totalement farfelue paramètre l'image à 1024x768 toujours en 72 dpi (augmenter les dpi ne sert à rien). A quoi va bien pouvoir ressembler l'image, un truc avec des gros pixels...

Tout comme le reste de l'équipe je suis totalement contre l'idée que le serveur est à traiter les images. Et en tant qu'administrateur système c'est totalement absurde, VDigital l'a dit :

Aujourd'hui les fonctions graphiques de php pour arriver à quelque chose de correct imposent un niveau minimal de php strictement supérieur à 5.2.5.

Même si dans le meilleur des mondes tout les webmasters étaient en php 5.2.5, tout les protocoles de communication utilisé dans le cadre du web ne sont pas adapté à ce genre d'utilisation.

Les images doivent être préparées sur un ordinateur et ensuite envoyé, le serveur stock les fichiers, le serveur web répond au requête du client pour afficher les images et les textes mais c'est tout il n'applique aucun traitement.

pierreL
2008-10-24 05:19:04

Bonjour,

Je suis en train de faire le tour des propositions  pro, et je ne suis pas pour cette solution, facile à gérer par ailleurs.


Par contre " une préexistence dans le code " de plusieurs versions d'une même image me semble intéressant , exemple:

La vignette l'image, et la HD ( qui n'est pas présente systématiquement )
La vignette l'image et la HD cadrée en 2X3 pour le client


Mais ce sont des fonctions pour pros, me semble-t-il .

VDigital
2008-10-21 17:45:30

Je m'en doutais un peu quand même...
8-)

Si d'autres ont des idées différentes mais justifiées... Il faut nous le dire!
Merci.
8-)

vimages
2008-10-21 17:41:33

Cher Vincent ! si si !!

Il ne s'agit pas pour moi de vous faire changer d'avis... .

Et c'est aussi parce que je sais que tu n'es jamais bien loin, que tes réponses sont riches d'enseignement que je pose quelques fois ce genre de question.

Mon but est de trouver les bonnes idées, d'avancer pour demeurer précurseur et pas copieur.. de proposer pour obtenir des avis contradictoires et en tirer des conclusions pertinentes, ... de réfléchir pour mieux comprendre et aborder les problèmes du meilleur côté.  bla bla bla...  ;o),
Le forum est pour moi aussi le moyen de d'opposer la perception d'une idée à ses contraintes techniques.. (pas très clair mais tu comprendras..)

Donc, pas de soucis, je partage assez ton point de vue.. c'est juste une ouverture de débat gratuite sur un sujet actuel.

amicalement,
éric.

VDigital
2008-10-21 17:30:52

A contrario, de nombreux webmaster font appel à un hébergement gracieux ou payant mais mutualisé, ce qui signifie:

1 - Que l'espace disque est limité.
2 - Que la consomation CPU est surveillée et que tout abus est disqualifiant.
3 - Que la bande passante est limitée.
4 - Et que les contraintes ne s'arrêtent pas là.

Aujourd'hui les fonctions graphiques de php pour arriver à quelque chose de correct imposent un niveau minimal de php strictement supérieur à 5.2.5.

Cela fait beaucoup de contraintes et donc très certainement beaucoup d'exclus.

Devons-nous privilégier les heureux webmasters qui ne subissent pas ces contraintes?
Où devons-nous voler au secours de ceux qui n'ont pas cette chance?
En espérant être en ligne avec le sujet.

Pour être clair:
1 - pLoader arrive. Il assure la rotation des images et le redimmensionnement avant le transfert. Alors, pourquoi faire bosser inutilement le serveur?
2 - J'ai un site plein à 96%, je fais quoi? Aurais-je l'intention de m'amuser au redimensionnement en ligne?

Oui, je sais que tu sais que nous ne sommes pas d'accord avec toi, et je ne vois pas dans quelle mesure, tu vas réussir à nous faire changer d'avis.
A mon avis, tu n'as pas encore gagné.

Par contre, nous irons certainement vers une application de type pLoader pour préparer des lots d'originaux à adresser... Mais ce n'est pas pour tout de suite.

8-)

PS: Demain, les serveurs seront encore plus puissants mais les images encore plus énormes. Il y a quelques années, l'image numérique à débuter avec moins d'un méga, aujourd'hui c'est 15 Megas, et on ne s'arrêtera pas là. Je traite 2 images de 12 Megas, et un bi-processeur est à genoux, il ne répond plus aux requêtes http.

vimages
2008-10-21 15:55:10

Bonjour.

Oui je sais, nombre d'entre vous sont contre tout ce qui est traitement d'images par le serveur. J'accepte ce point de vue, l'ai partagé longtemps d'ailleurs.

Ceci entendu, je voudrais dire que les machines évoluent, les puissances disponibles aussi. Donc je souhaite aborder ce point.

Certains programmes proposent le redimensionnement d'images à la volée, en ligne. Je ne dis pas qu'il faut y venir, mais nous pouvons en discuter.

Pour moi, les avantages et inconvénients :

Avantages :
- Seuls les fichiers HD sont à héberger et donc envoyés sur le serveur.
- L'arborescence est nettoyée des fichiers médium et des thumbnails
- Nous ne serons plus prisonnier de la taille des fichiers envoyés. Chaque utilisateur peut, par ses paramétrages, et dans les limites imposées par l'admin, choisir la taille de l'image médium.

Inconvénients :
- Le calcul est à faire lors de la consultation, c'est une charge serveur supplémentaire.
- l'ajout d'un marquage éventuel doit ce faire par un système de watermark.

=> solutions :
- Une image calculée peut être mise en cache durant un certain temps (le temps de la session ou une durée par défaut?) , ce qui éviterait au programme de la recalculer à chaque fois.
- pour gagner du temps à l'affichage, le programme peut "pré-calculer" les images suivantes ou précédentes de la catégorie en cours de visite


à suivre....

amicalement,
éric.

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact