Si tu es un média et que tu veux passer des contrats avec des partenaires ou des marques, t'as intérêt à sortir tes chiffres d'autre part que de ton access_log. Pas pour rien que beaucoup de sites sont obligés de se farcir un contrat avec médiamétrie...
Donc si c'est pour des besoins internes en effet, les données tu les as. La fouille de donnée peut être plus ou moins pratique et je comprends que des petits sites utilises des outils tout fait. Si c'est pour communiquer tes stats, alors c'est beaucoup mieux vu d'utiliser un presta reconnu et officiel.
> Et puis comme c'est libre, si Oracle décide de « tuer » le projet ça ne changera rien. D'ailleurs, il y a déjà une multitude de forks.
Tu peux me rappeler le nombre de contributeurs externes et le volume de leurs contributions ? C'était d'ailleurs un des chantiers de Sun; avoir des contributeurs...
Les personnes publiques ont une vie privée et ne vont pas s'arrêter de téléphoner. Les communications d'entreprises reposent énormément sur les portables etc.
Dans la vraie vie il n'y a pas que des informations à 3 milliards et des informations dont tout le monde se fout. Si on savait déjà que le GSM n'était pas fiable, le problème c'est que ca risque de devenir suffisamment abordable financièrement et techniquement pour que n'importe qui parte à la pèche aux infos qui l'intéresse. Ça peut aller du journaliste people, à ton voisin en passant par la petite boite qui aimerait bien savoir le chiffre qu'à mis son concurrent sur un appel d'offre. Il existe d'autres moyens de récupérer ces informations et tout et tout; mais le problème il est là si tu n'arrives pas à le voir.
Tu veux dire que selon la théorie de l'évolution on sera débarrassé des macounets et des déssaïdors d'ici quelques centaines de milliers d'années ? \o/
Enfin là t'es obligé de quitter la route des yeux pour taper sur le clavier avec la souris. Dans la vraie vie tu tapes entièrement à l'aveugle autrement t'es effectivement un gros danger... C'est pas pire que chercher sa route, régler son autoradio, chercher un truc dans la bagnole, égorger les lutins qui braillent à l'arrière, mater la blonde sur le trottoir, regarder si il faut freiner pour ce **** de radar etc.
Bin en fait c'est très simple et peut se résumer par un schema bête comme chou. D'ailleurs Mike Melanson avait fait ledit schéma il y a quelques années: http://blogs.adobe.com/penguin.swf/linuxaudio.png
Allez rattrape toi en lui signalant qu'il a fait une bête faute de frappe dans le nom de sa boite sur linkedin :-) Par contre le couplet sur les logiciels libres dans le summary est du plus bel effet !
Merci pour ce grand moment de rigolade et de prendre tout le monde pour des débiles profonds :-) J'espère sincèrement que vous ferez un peu de bénéfice pour te payer une formation en communication !
Comme je l' ai dit ca ne m'intéresse pas de discuter avec toi. C'est sans fin et tu utilises toujours la même rhétorique.
Maintenant pour que le lecteur intéresse et non photographe se fasse une idée, voici un test simple que je viens d'effectuer. Il s'agit de reproduire l'exemple donne en lien un peu plus bas: http://www.giroptic.com//_data_/8/88b6c5d7dc15/360/pano_5987(...) Faire un panoramique d'une pièce du peu moins de 30m2 un ayant un bonne partie du sol et les murs jusqu'au plafond. Les prix sont indicatifs pour donner un ordre de grandeur, (amazon sans chasser la promo).
Solution de notre ami:
- cout: 570 (kit 1000d + objectif standard) + 200 (trépied) -> ~ 800 euros
- nombre de photos: 23 a 18mm focale minimale
Solution avec un fisheye 8mm:
- cout: 350 (1000d) + 260 (8mm fisheye) + 50 (trépied) -> ~700 euros
- nombre de photos: 4 (en bonus on a tout le sol comme sur l'exemple alors que pour avoir la même couverture avec la solution précédente il faut rajouter 3 photos)
Dans les deux cas on obtient un meilleur résultat avec un tête de trépied spécialisée (voir http://wiki.panotools.org/Hardware#Panoramic_Heads ). Et plus on a de photos, plus le besoin d'une tete panoramique est grand (on doit faire une rotation sur deux axes au lieu d'un seul), plus il faut faire attention a l'alignement, et plus le traitement sur ordinateur prend du temps a l'homme comme a la machine
Même si la solution fisheye était 50% plus onéreuse, personnellement j'ai vite fait mon choix. Ne pas perdre son temps pour rien vaut bien quelques euros... Par contre le luxe d'avoir un autofocus inutile a 8mm puisque c'est net de 2m a l'infini, je suis pas certain que ca vaille les 500 euros différence entre un peleng et un canon/sigma/nikkor pour notre usage ici...
Bon comme d'hab tu chercheras a avoir raison, donc je m'arrêterais la.
> Non, regarde le prix d'un vrai trépied correct concu pour durer
Ce n'est pas par ce que manfrotto vend de très bon trépieds hors de prix qu'il n'existe pas du bon matos a un prix abordable et surtout en adéquation avec son utilisation.
Même si il existe mieux, la question est pourquoi conseiller un tel trépied a quelqu'un qui n'est pas photographe pro ? On parle d'une utilisation occasionnelle avec 500 grammes dessus. C'est complètement con de conseiller un trépied qui vaut 1/3 du prix boitier+objo ! D'autant plus que l'objo est totalement inadapté a l'utilisation.
Un très bon trépied pour poser un obusier type 400 f/2.8 ou 600 f/4.0 ou pour un besoin bien particulier ok; mais ca n'a rien a voir avec le sujet...Et note que j'ai plein de potes qui posent des x0D/5D/1D/1Ds/D700/D3X avec du 8mm jusqu'au 70-200 2.8 sur des trépieds coutant entre 40 et 80 euros et tous sont très content. Quelques photographes pro, beaucoup qui font de la montagne et du sport avec, de la photo de nuit. Bref faut pas trop se palucher non plus... Un trepied a 50 euros c'est fiable, c'est robuste, ca marche, ca répond aux besoins de 99% des photographes, y'a mieux mais beaucoup plus cher, faut en avoir besoin....
> Un fisheye à 150€ ?
Ta fourchette c'est 150/200. Pour 180$ (125 euros) t'as un Zenitar 16mm si t'es en full frame. Pour 370$ (260 euros) t'as un peleng 8mm si t'es en APS-C. Ça c'est les prix neufs, en occasion ils rentrent tout les deux dans ton budget trépied. Y'a des milliers de photographes qui trouvent leur qualité très satisfaisante et adapte au panorama (et en tout cas très largement supérieur a l'appareil dont on parle dans le journal).
Même si c'était plus cher, je doute que qui que ce soit ait la patience suffisante pour faire un 360/180 avec un 18mm sur APS-C. Ça demande au minimum 32 prises de vues avec un recouvrement de 25%. Faut être super précis sur les angles, se souvenir de tout. Ca demande une tête panoramique aussi cher qu'un fisheye. Ca prend trois plombes a la prise de vue. C'est chiant a aligner en postprod. L'image prend aussi trois plombes a générer vu le volume de donnée. Tout ca pour un résultat qui ne sera pas forcement meilleur, par ce que ton logiciel va interpoler a mort pour réussir a aligner toutes ces images. Et hors cas très spécifique; avoir une meilleure reso est inutile, ca ne rentre déjà pas sur ton écran et tu peux faire des tirages d'un mètre carre sans soucis. Bref faut être masochiste.
Maintenant puisque tu donnes comme conseil de faire un pano 360/180 avec un 18-55 de kit. Je t'invite a m'en faire un; et de m'envoyer le résultat ainsi que les images initiales. Au passage tu me diras si ca t'as pris plus de 2h ou non...
Si tu veux faire un 360° x 180° comme le laisse penser le journal alors l'arme ultime est clairement le fisheye 8mm. Tu peux évidement le faire avec n' importe quel objo mais le nombre de prise explose rapidement:
- 3 images avec un 8mm fish eye sur APS-C
- 18 photos mini avec un 10mm sur APS-C
- 32 photos mini avec un 18mm sur APS-C (souvent focale mini de l'objo de base que tu recommandes...)
Tu plaisantes ? Pour ce prix la autant te payer un objo pour les panos. Y'a beaucoup de tres bon trépieds a ~50 euros, pas trop lourd, transportable, >170cm et qui supporte plus de 5Kg de matos (dans la neige par 70km/h de vent sans bouger de nuit en pose longue...). Faut rajouter une tête panoramique que l'on peut facilement faire soit même dessus.
Ca dépend énormément des options que tu utilises. Je viens de tester très rapidement sur mon laptop (c2d@2.40, 4Go de ram et un hd merdique qui est le facteur limitant). Pano en equirectangular de 12068x3479 à partir de 8 TIFF de 2336x3504 à 14mm en mode portrait.
- Export HDR: 7 minutes
- Export LDR: 2 minutes
Avec, un panorama plus modeste de 4 images (si t'es en fisheye à très courte focale tu en as pas besoin de plus); entre le moment ou je lance hugin et le moment ou j'ai mon TIFF final, c'est vraiment 4 minutes montre en main. Le rendu prenant moins de 30 secondes.
Après les cas où j'utilise le HDR sont assez rares, il faut en avoir besoin... Et même quand c'est le cas, les outils libres sont absolument merdiques que ca fait facilement passer l'envie. Hormis passer 1h à essayer des paramètres au hasard pour finir avec un rendu absolument irréaliste et qui ne correspond jamais à ce que tu veux, faut avoir la foi et du temps à perdre.
Tu as entièrement raison, c'est d'ailleurs très bien expliqué dans le document que je link ;-)
Si on refait le calcul correctement ca fait encore un facteur ~2, et plus simplement les raw auraient une taille fixe si ils n'étaient pas compressés (modulo quelques ko pour les metadata & miniatures).
> (il l'est pour les photographie RAW, en format non compressé)
Juste une précision, le RAW est compressé mais non destructif (+ le boitier n'applique pas trop de postprod aux données issues du capteur). Dans le CR2 de Canon tu trouves du JPEG loseless par exemple: http://lclevy.free.fr/cr2/
Un RAW de 15Mpixel devrait faire plus de 15*10^6 * 3 * 14 bits si il n'était pas compressé, c'est ce que tu retrouves quand tu passes RAW -> TIFF 16 bits non compressé pour retoucher tes photos et les images deviennent assez conséquentes...
Pour le JPEG ca doit s'expliquer facilement par ce que c'est un format qui offre:
- Une taille raisonnable
- Une qualité suffisamment bonne pour qu'il soit très difficile/impossible de voir les artefacts
- Très rependu, donc possibilité de publier/voir ce format partout sans conversion
Le seul problème c'est qu'il résiste mal à plusieurs phases d'édition et que c'est moins souple en post-prod.
Je ne pense pas que ca concerne le photographe amateur mais le grand publique. Le photographe amateur il met un objo fisheye 8mm sur son boitier, il achète (ou il se construit c'est pas dur) une tête panoramique pour son trépied et après tu peux prendre tes panoramas 360 horizontal, 180 vertical en 3/4 photos. La postprod prend 3 minutes montre en main avec hugin. Le résultat est nickel, tu peux tirer parti de ton boitier, bracketer comme tu veux, tu peux choisir le mode de projection, tu peux choisir en champs de vue plus petit etc. C'est aussi possible sans trépied mais ca demande plus de photos et de travail en postprod.
Tu as une très bonne qualité d'image, c'est pas cher (200 à 300 euros pour l'objo), ca utilise des logiciels libres et c'est suffisamment facile pour être accessible à toute personne faisant de la photo...
Aucune idée pour les produits grand publique "en un clic" cela dit.
Ton information me semble peu intelligente/pertinente; et je ne suis pas certain de ce que tu veux faire passer comme message.
Je ne doute pas que ce soit très lucratif, mais personnellement je ne pense pas avoir une idée suffisamment précise des divers coûts pour me faire une idée de la marge des différents acteurs.
Tu as demandé le prix où ton boulanger achète sa farine, sa levure et son eau ? Ou alors combien un supermarché paye à la centaine de tonne ce qu'il te revend à l'unité ? Tu es au courant qu'un petit magasin marge classiquement à >40% ? Ça aussi c'est un chiffre sensationnel. Bon une fois que tu fais le vrai calcul, tu te rends compte que 40% c'est pas vraiment ce qu'il reste dans la poche à la fin du mois. Tu balances un chiffre, et après ?
Posté par ckyl .
En réponse au journal SongBird.
Évalué à 3.
> Donc tu donnes bien du blé a Apple pour ton Nano.
C'est exactement ce que j'ai dit. Tu es très fort en conclusion !
> Ca te fais pas tant chier que ça visiblement.
Je choisis un produit en fonction de plusieurs critères et de mes besoins. Définir l'importance de chacun d'eux c'est mon problème. Mon approche n'est pas moins cohérente que la tienne. Pour ce produit, je mets juste "répondre à mes besoins" au dessus "libre/ouvert/interopérable", que je considère comme un critère de sélection parmi ceux qui ont survécu à la première sélection. Si une autre alternative correspondant à mes besoins et plus ouverte existait, le pognon ne serait pas aller dans la poche d'Apple.
Posté par ckyl .
En réponse au journal SongBird.
Évalué à 5.
- Ce n'est pas l'autoradio d'origine
- La liaison ipod c'est du "bonus". Si ça te plait pas, tu peux rester pur en utilisant l'entrée AUX, une carte SD ou une clé USB. Chaque solution à ses avantages et ses inconvénients.
- Oui ça fait grave chier qu'il existe pas une prise et un protocole standard pour contrôler les lecteurs. C'est ultra super pratique...
En même temps si tout les autres fabricants sont trop cons pour se mettre ensemble pour pousser un standard qui pourrait peut être leur permettre de vendre plus de 4 lecteurs par an, bin tant pis pour eux... et pour nous.
Posté par ckyl .
En réponse au journal SongBird.
Évalué à 1.
> D'une manière générale, j'aurais tendance à considérer que le support des IBidules par les projets libres est une fausse bonne idée et ce pour plusieurs raisons:
En même temps les mecs qui bossent sur la libgpod s'en cogne grave de ton avis. Ils font bien ce qui leur plait sans avoir besoin de recevoir de leçon.
Du côté utilisateur, y'a rien qui me fait plus chier que de donner du blé à Apple pour un truc complètement fermé et verrouillé. Mais en même temps si tu veux un truc qui marche nickel, robuste, bien fini, et que tu peux brancher dans ta caisse sans passer par le son merdique de l'AUX et avoir les commandes sur l'autoradio. Bin t'as pas beaucoup de choix... Donc merci aux dev de la libgpod, grâce à eux mon nano n'a jamais vu la couleur d'itunes et ça marche au poil.
> Je te la fais simple: les mécanismes qu'offre TCP par rapport à IP ne me sont pas utiles, car ils sont dupliqués par rapport à ceux que je dois forcément implémenter dans mon protocole
Ton protocole peut aussi simplement utiliser les services par la couche transport comme tout le monde. Tu peux me donner la liste des services qui sont dommageables pour ton utilisation, celle des services que tu vas devoir réimplementer, et en quoi ce que tu vas niveau applicatif sera redondant ou meilleur que ce que fourni TCP ?
(Étant donné que tu n'as même pas de spec fonctionnelles de ton produit, cela me semble assez étrange)
> Puis c'est pas comme si certains on pensé à passer bittorent en udp il n'y a pas si longtemps hein…
Je n'ai pas dit que c'était stupide d'utiliser UDP. J'ai dit qu'il est stupide d'utiliser UDP sans bonne raison et que ça demande beaucoup de connaissances, d'expériences, et de temps pour faire un protocole potable. Et afaik tu n'as aucun des trois. Fait un protocole merdique en UDP et au mieux tu vas trasher tout les réseaux que tu traverse...
Puisque tu parles d'uTP. Tu peux m'expliquer en quoi ce protocole est pertinent (il l'est) et les problème qu'il essai d'adresser ? Après des analyses que j'ai vu (puisque le protocole n'est pas publique) c'est pas non plus brillant uTP, et pourtant les mecs sont pas des billes. On peut en discuter quand tu auras répondu a ma question.
Après si tu penses pouvoir abattre ce travail en 2 mois... Pense tout de même a décider des specs de ton produit avant d'avoir un avis arrêté sur les solutions techniques à utiliser. Utiliser TCP par défaut, c'est juste du bon sens.
Tu mélanges allègrement couche 4 et couche 7. Toute communication réseau est point à point et client/serveur (on oublie le multicast on est sur Internet). La couche transport, TCP ou UDP, te permet juste d'envoyer des données d'un point A à un point B. Y'en a un des deux qui initie la connexion, le client, et l'autre qui écoute, le serveur. Après c'est de la logique applicative de savoir si tu fais du p2p ou du client/serveur mais tes communications sont toujours pap et client/serveur.
Tu confonds aussi checksum et offset couche transport et applicative.
Pour du transport de donnée les services qu'offrent TCP sont très adaptés: contrôle de flux, contrôle de congestion, connexion fiable. Tu as besoin de ces mécanismes et tu n'arriveras pas à égaler 1/10 de la qualité de TCP tant au niveau design qu'implémentation. Pour faire très simple on passe en UDP quand on se fou de la fiabilité ou qu'on préfère l'assurer au niveau applicatif (streaming, jeux vidéos etc.).
Bref fais quelque chose de très simple par ce que tu semble partir de très loin en réseau. De plus les algorithmes applicatifs de P2P c'est un tout autre domaine qui n'a aucun rapport à la programmation réseau, et ça n'a rien de trivial (il y a de très bon papier sur l'analyse et le fonctionnement du protocole bittorrent par exemple) .
Peux tu expliquer quel est le rapport entre le fait qu'un opérateur puisse vouloir filtrer un protocole P2P et le fait qu'il soit sur TCP ? En quoi un protocole reposant sur UDP serait techniquement plus difficile à filtrer ou en quoi le fait que ce soit du TCP/UDP pourrait changer la politique de l'opérateur ?
Je rejoins le commentaire du dessus. Développer un protocole en UDP il faut vraiment avoir de bonnes raisons de le faire et une très bonne connaissance en protocole réseau. Tu te retrouves à réimplanter beaucoup de fonctions de TCP et c'est totalement hors de porté de nos 4 étudiants (ou alors tu fais un gros protocole moisi qui nique tout le réseau ou qui fonctionne carrément moins bien).
Autrement c'est un projet étudiant de deux mois, rêvez pas trop. Je pense que le but de l'exercice c'est de savoir écrire un client/serveur correctement et il y a déjà beaucoup à faire (surtout si le simple fait de passer de C# à Java ou C vous pose problème). Écrire un protocole réseau correct, c'est je pense; hors sujet, un peu hors de votre portée et surtout d'ici un mois t'aura à peine fini ton état de l'art sur les protocoles existants. Là tu pourras commencer à réfléchir à concevoir quelque chose, puis le coder...
Bref sois tu t'inventes un jouet, soit tu fais du vrai boulot d'ingé c'est à dire faire une implémentation robuste de specs qui existent déjà. Comprendre les objectifs d'un travail/exercice, c'est aussi important...
À la vue de tout les commentaires condescendants sur mme Michu et sur l'idiotie crasse dont il faut faire preuve pour utiliser des dépôts non officiels je me demande combien de nos amis linuxfriens tellement supérieurs n'ont jamais téléchargé de paquet non packagés par la distrib, de logiciel non packagés (les sources en tgz ça compte aussi), appliqué des patchs sans les relire, utilisé des applications utilisées par 3 pelés dans le monde développé par je ne sais qui, ajouté des dépôts qui ont le logiciel qu'on veut, utilisé un plugin trouvé à l'arrache sur internet etc. J'ai un peu l'impression que c'est l'hôpital qui se fou de la charité.
Le seul modèle de défense est la confiance et miser sur le fait que si y'a un truc vilain la masse des utilisateurs finira par le voir. Quand on y réfléchi, la chaine de confiance n'est pas bien solide....
J'anticipe deux réponses: gagner le root sur une station de travail n'est pas ce qui embête l'utilisateur ça permet juste de faire plus de choses à l'attaquant; et gagner le compte utilisateur sur une station de travail, c'est gagner le root d'ici 5 minutes à 1 semaines.
Moi ce qui m'étonne c'est qu'en 2009 des gens s'étonnent encore que les choix architecturaux, algorithmiques et de structure de données ont plus d'impact que les optimisations de code.
La duplication de donnée, les indirections pourries et mal pensées, le code pas extensible, pas modularisable ou externalisable, ne pas pouvoir séparer les traitements, les abstractions chiottiques etc. ça coute beaucoup beaucoup plus cher en perf à terme... Après si tu appliques les même design/algorithme/structure de données avec un langage plus performant, ça ira plus vite, mais ça risque de couter un peu plus cher à faire ou un peu plus longtemps à stabiliser.
Bref rien de nouveau sous le soleil depuis le début de l'informatique !
Ils ont fait des progrès lors de l'arrêt brutal des disques ? J'avais arrêté d'utiliser XFS il y a un paquet d'années suite à de nombreux fichiers qui se sont retrouvés avec une taille de 0 octet à cause d'un arrêt violent de la machine. Je me souviens que j'étais pas vraiment le seul à avoir rencontré ce genre de problème.
C'était un très bon FS, mais ce détail était éliminatoire pour moi sur un laptop ou une machine de bureau où les coupures violentes sont fréquentes.
[^] # Re: Commercial et vie privée.
Posté par ckyl . En réponse au journal Personas, l'extension de personnalisation graphique de Firefox. Évalué à 4.
Donc si c'est pour des besoins internes en effet, les données tu les as. La fouille de donnée peut être plus ou moins pratique et je comprends que des petits sites utilises des outils tout fait. Si c'est pour communiquer tes stats, alors c'est beaucoup mieux vu d'utiliser un presta reconnu et officiel.
[^] # Re: MySQL est fonctionnel, évolutif et crédible
Posté par ckyl . En réponse à la dépêche Sauvons MySQL !. Évalué à 5.
Tu peux me rappeler le nombre de contributeurs externes et le volume de leurs contributions ? C'était d'ailleurs un des chantiers de Sun; avoir des contributeurs...
[^] # Re: Demi-mesure
Posté par ckyl . En réponse au journal Le chiffrement du GSM cassé ?. Évalué à 9.
Dans la vraie vie il n'y a pas que des informations à 3 milliards et des informations dont tout le monde se fout. Si on savait déjà que le GSM n'était pas fiable, le problème c'est que ca risque de devenir suffisamment abordable financièrement et techniquement pour que n'importe qui parte à la pèche aux infos qui l'intéresse. Ça peut aller du journaliste people, à ton voisin en passant par la petite boite qui aimerait bien savoir le chiffre qu'à mis son concurrent sur un appel d'offre. Il existe d'autres moyens de récupérer ces informations et tout et tout; mais le problème il est là si tu n'arrives pas à le voir.
[^] # Re: C'est quoi ce site ou on peut meme pas mettre d'images...
Posté par ckyl . En réponse au journal [HS] Testez votre capacité à conduire et répondre à un SMS.... Évalué à 10.
# C'est quoi ce site ou on peut meme pas mettre d'images...
Posté par ckyl . En réponse au journal [HS] Testez votre capacité à conduire et répondre à un SMS.... Évalué à 3.
Enfin là t'es obligé de quitter la route des yeux pour taper sur le clavier avec la souris. Dans la vraie vie tu tapes entièrement à l'aveugle autrement t'es effectivement un gros danger... C'est pas pire que chercher sa route, régler son autoradio, chercher un truc dans la bagnole, égorger les lutins qui braillent à l'arrière, mater la blonde sur le trottoir, regarder si il faut freiner pour ce **** de radar etc.
[^] # Re: OSS4 est aux autres ce que Linux est à Windows
Posté par ckyl . En réponse au journal Le son sous Linux : du pure n'importe quoi. Évalué à 4.
Enjoy !
[^] # Re: Gros Troll Velu
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 2.
[^] # Re: Gros Troll Velu
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 10.
Merci pour ce grand moment de rigolade et de prendre tout le monde pour des débiles profonds :-) J'espère sincèrement que vous ferez un peu de bénéfice pour te payer une formation en communication !
PS: change de nom ou assume ta position au moins... http://www.notetonentreprise.com/company.php?id=4099&ent(...)
PS2: C'est cool tu vas pouvoir répondre aux questions posées plus haut
[^] # Re: Belle reussite, du bon journal trolleur comme il faut!
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 2.
Maintenant pour que le lecteur intéresse et non photographe se fasse une idée, voici un test simple que je viens d'effectuer. Il s'agit de reproduire l'exemple donne en lien un peu plus bas: http://www.giroptic.com//_data_/8/88b6c5d7dc15/360/pano_5987(...) Faire un panoramique d'une pièce du peu moins de 30m2 un ayant un bonne partie du sol et les murs jusqu'au plafond. Les prix sont indicatifs pour donner un ordre de grandeur, (amazon sans chasser la promo).
Solution de notre ami:
- cout: 570 (kit 1000d + objectif standard) + 200 (trépied) -> ~ 800 euros
- nombre de photos: 23 a 18mm focale minimale
Solution avec un fisheye 8mm:
- cout: 350 (1000d) + 260 (8mm fisheye) + 50 (trépied) -> ~700 euros
- nombre de photos: 4 (en bonus on a tout le sol comme sur l'exemple alors que pour avoir la même couverture avec la solution précédente il faut rajouter 3 photos)
Dans les deux cas on obtient un meilleur résultat avec un tête de trépied spécialisée (voir http://wiki.panotools.org/Hardware#Panoramic_Heads ). Et plus on a de photos, plus le besoin d'une tete panoramique est grand (on doit faire une rotation sur deux axes au lieu d'un seul), plus il faut faire attention a l'alignement, et plus le traitement sur ordinateur prend du temps a l'homme comme a la machine
Même si la solution fisheye était 50% plus onéreuse, personnellement j'ai vite fait mon choix. Ne pas perdre son temps pour rien vaut bien quelques euros... Par contre le luxe d'avoir un autofocus inutile a 8mm puisque c'est net de 2m a l'infini, je suis pas certain que ca vaille les 500 euros différence entre un peleng et un canon/sigma/nikkor pour notre usage ici...
[^] # Re: Belle reussite, du bon journal trolleur comme il faut!
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 3.
> Non, regarde le prix d'un vrai trépied correct concu pour durer
Ce n'est pas par ce que manfrotto vend de très bon trépieds hors de prix qu'il n'existe pas du bon matos a un prix abordable et surtout en adéquation avec son utilisation.
Même si il existe mieux, la question est pourquoi conseiller un tel trépied a quelqu'un qui n'est pas photographe pro ? On parle d'une utilisation occasionnelle avec 500 grammes dessus. C'est complètement con de conseiller un trépied qui vaut 1/3 du prix boitier+objo ! D'autant plus que l'objo est totalement inadapté a l'utilisation.
Un très bon trépied pour poser un obusier type 400 f/2.8 ou 600 f/4.0 ou pour un besoin bien particulier ok; mais ca n'a rien a voir avec le sujet...Et note que j'ai plein de potes qui posent des x0D/5D/1D/1Ds/D700/D3X avec du 8mm jusqu'au 70-200 2.8 sur des trépieds coutant entre 40 et 80 euros et tous sont très content. Quelques photographes pro, beaucoup qui font de la montagne et du sport avec, de la photo de nuit. Bref faut pas trop se palucher non plus... Un trepied a 50 euros c'est fiable, c'est robuste, ca marche, ca répond aux besoins de 99% des photographes, y'a mieux mais beaucoup plus cher, faut en avoir besoin....
> Un fisheye à 150€ ?
Ta fourchette c'est 150/200. Pour 180$ (125 euros) t'as un Zenitar 16mm si t'es en full frame. Pour 370$ (260 euros) t'as un peleng 8mm si t'es en APS-C. Ça c'est les prix neufs, en occasion ils rentrent tout les deux dans ton budget trépied. Y'a des milliers de photographes qui trouvent leur qualité très satisfaisante et adapte au panorama (et en tout cas très largement supérieur a l'appareil dont on parle dans le journal).
Même si c'était plus cher, je doute que qui que ce soit ait la patience suffisante pour faire un 360/180 avec un 18mm sur APS-C. Ça demande au minimum 32 prises de vues avec un recouvrement de 25%. Faut être super précis sur les angles, se souvenir de tout. Ca demande une tête panoramique aussi cher qu'un fisheye. Ca prend trois plombes a la prise de vue. C'est chiant a aligner en postprod. L'image prend aussi trois plombes a générer vu le volume de donnée. Tout ca pour un résultat qui ne sera pas forcement meilleur, par ce que ton logiciel va interpoler a mort pour réussir a aligner toutes ces images. Et hors cas très spécifique; avoir une meilleure reso est inutile, ca ne rentre déjà pas sur ton écran et tu peux faire des tirages d'un mètre carre sans soucis. Bref faut être masochiste.
Maintenant puisque tu donnes comme conseil de faire un pano 360/180 avec un 18-55 de kit. Je t'invite a m'en faire un; et de m'envoyer le résultat ainsi que les images initiales. Au passage tu me diras si ca t'as pris plus de 2h ou non...
[^] # Re: Belle reussite, du bon journal trolleur comme il faut!
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 3.
Si tu veux faire un 360° x 180° comme le laisse penser le journal alors l'arme ultime est clairement le fisheye 8mm. Tu peux évidement le faire avec n' importe quel objo mais le nombre de prise explose rapidement:
- 3 images avec un 8mm fish eye sur APS-C
- 18 photos mini avec un 10mm sur APS-C
- 32 photos mini avec un 18mm sur APS-C (souvent focale mini de l'objo de base que tu recommandes...)
Cf: http://www.vrwave.com/panoramic/photography/lens_database.ht(...) par exemple.
Après c'est toi qui voit hein...
> un trépied correct, on va dire 150-200€
Tu plaisantes ? Pour ce prix la autant te payer un objo pour les panos. Y'a beaucoup de tres bon trépieds a ~50 euros, pas trop lourd, transportable, >170cm et qui supporte plus de 5Kg de matos (dans la neige par 70km/h de vent sans bouger de nuit en pose longue...). Faut rajouter une tête panoramique que l'on peut facilement faire soit même dessus.
[^] # Re: Photographe amateur
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 4.
- Export HDR: 7 minutes
- Export LDR: 2 minutes
Avec, un panorama plus modeste de 4 images (si t'es en fisheye à très courte focale tu en as pas besoin de plus); entre le moment ou je lance hugin et le moment ou j'ai mon TIFF final, c'est vraiment 4 minutes montre en main. Le rendu prenant moins de 30 secondes.
Après les cas où j'utilise le HDR sont assez rares, il faut en avoir besoin... Et même quand c'est le cas, les outils libres sont absolument merdiques que ca fait facilement passer l'envie. Hormis passer 1h à essayer des paramètres au hasard pour finir avec un rendu absolument irréaliste et qui ne correspond jamais à ce que tu veux, faut avoir la foi et du temps à perdre.
[^] # Re: Solution alternative
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 4.
Si on refait le calcul correctement ca fait encore un facteur ~2, et plus simplement les raw auraient une taille fixe si ils n'étaient pas compressés (modulo quelques ko pour les metadata & miniatures).
[^] # Re: Solution alternative
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 3.
Juste une précision, le RAW est compressé mais non destructif (+ le boitier n'applique pas trop de postprod aux données issues du capteur). Dans le CR2 de Canon tu trouves du JPEG loseless par exemple: http://lclevy.free.fr/cr2/
Un RAW de 15Mpixel devrait faire plus de 15*10^6 * 3 * 14 bits si il n'était pas compressé, c'est ce que tu retrouves quand tu passes RAW -> TIFF 16 bits non compressé pour retoucher tes photos et les images deviennent assez conséquentes...
Pour le JPEG ca doit s'expliquer facilement par ce que c'est un format qui offre:
- Une taille raisonnable
- Une qualité suffisamment bonne pour qu'il soit très difficile/impossible de voir les artefacts
- Très rependu, donc possibilité de publier/voir ce format partout sans conversion
Le seul problème c'est qu'il résiste mal à plusieurs phases d'édition et que c'est moins souple en post-prod.
# Photographe amateur
Posté par ckyl . En réponse au journal Une liberté sur 360°. Évalué à 4.
Tu as une très bonne qualité d'image, c'est pas cher (200 à 300 euros pour l'objo), ca utilise des logiciels libres et c'est suffisamment facile pour être accessible à toute personne faisant de la photo...
Aucune idée pour les produits grand publique "en un clic" cela dit.
[^] # Re: Une très bonne nouvelle !
Posté par ckyl . En réponse au journal And then they were four .... Évalué à 2.
Je ne doute pas que ce soit très lucratif, mais personnellement je ne pense pas avoir une idée suffisamment précise des divers coûts pour me faire une idée de la marge des différents acteurs.
Tu as demandé le prix où ton boulanger achète sa farine, sa levure et son eau ? Ou alors combien un supermarché paye à la centaine de tonne ce qu'il te revend à l'unité ? Tu es au courant qu'un petit magasin marge classiquement à >40% ? Ça aussi c'est un chiffre sensationnel. Bon une fois que tu fais le vrai calcul, tu te rends compte que 40% c'est pas vraiment ce qu'il reste dans la poche à la fin du mois. Tu balances un chiffre, et après ?
[^] # Re: AP
Posté par ckyl . En réponse au journal SongBird. Évalué à 3.
C'est exactement ce que j'ai dit. Tu es très fort en conclusion !
> Ca te fais pas tant chier que ça visiblement.
Je choisis un produit en fonction de plusieurs critères et de mes besoins. Définir l'importance de chacun d'eux c'est mon problème. Mon approche n'est pas moins cohérente que la tienne. Pour ce produit, je mets juste "répondre à mes besoins" au dessus "libre/ouvert/interopérable", que je considère comme un critère de sélection parmi ceux qui ont survécu à la première sélection. Si une autre alternative correspondant à mes besoins et plus ouverte existait, le pognon ne serait pas aller dans la poche d'Apple.
[^] # Re: AP
Posté par ckyl . En réponse au journal SongBird. Évalué à 5.
- La liaison ipod c'est du "bonus". Si ça te plait pas, tu peux rester pur en utilisant l'entrée AUX, une carte SD ou une clé USB. Chaque solution à ses avantages et ses inconvénients.
- Oui ça fait grave chier qu'il existe pas une prise et un protocole standard pour contrôler les lecteurs. C'est ultra super pratique...
En même temps si tout les autres fabricants sont trop cons pour se mettre ensemble pour pousser un standard qui pourrait peut être leur permettre de vendre plus de 4 lecteurs par an, bin tant pis pour eux... et pour nous.
[^] # Re: AP
Posté par ckyl . En réponse au journal SongBird. Évalué à 1.
En même temps les mecs qui bossent sur la libgpod s'en cogne grave de ton avis. Ils font bien ce qui leur plait sans avoir besoin de recevoir de leçon.
Du côté utilisateur, y'a rien qui me fait plus chier que de donner du blé à Apple pour un truc complètement fermé et verrouillé. Mais en même temps si tu veux un truc qui marche nickel, robuste, bien fini, et que tu peux brancher dans ta caisse sans passer par le son merdique de l'AUX et avoir les commandes sur l'autoradio. Bin t'as pas beaucoup de choix... Donc merci aux dev de la libgpod, grâce à eux mon nano n'a jamais vu la couleur d'itunes et ça marche au poil.
[^] # Re: Pourquoi UDP ?
Posté par ckyl . En réponse au journal Application de P2P moderne. Évalué à 5.
Ton protocole peut aussi simplement utiliser les services par la couche transport comme tout le monde. Tu peux me donner la liste des services qui sont dommageables pour ton utilisation, celle des services que tu vas devoir réimplementer, et en quoi ce que tu vas niveau applicatif sera redondant ou meilleur que ce que fourni TCP ?
(Étant donné que tu n'as même pas de spec fonctionnelles de ton produit, cela me semble assez étrange)
> Puis c'est pas comme si certains on pensé à passer bittorent en udp il n'y a pas si longtemps hein…
Je n'ai pas dit que c'était stupide d'utiliser UDP. J'ai dit qu'il est stupide d'utiliser UDP sans bonne raison et que ça demande beaucoup de connaissances, d'expériences, et de temps pour faire un protocole potable. Et afaik tu n'as aucun des trois. Fait un protocole merdique en UDP et au mieux tu vas trasher tout les réseaux que tu traverse...
Puisque tu parles d'uTP. Tu peux m'expliquer en quoi ce protocole est pertinent (il l'est) et les problème qu'il essai d'adresser ? Après des analyses que j'ai vu (puisque le protocole n'est pas publique) c'est pas non plus brillant uTP, et pourtant les mecs sont pas des billes. On peut en discuter quand tu auras répondu a ma question.
Après si tu penses pouvoir abattre ce travail en 2 mois... Pense tout de même a décider des specs de ton produit avant d'avoir un avis arrêté sur les solutions techniques à utiliser. Utiliser TCP par défaut, c'est juste du bon sens.
[^] # Re: Pourquoi UDP ?
Posté par ckyl . En réponse au journal Application de P2P moderne. Évalué à 4.
Tu mélanges allègrement couche 4 et couche 7. Toute communication réseau est point à point et client/serveur (on oublie le multicast on est sur Internet). La couche transport, TCP ou UDP, te permet juste d'envoyer des données d'un point A à un point B. Y'en a un des deux qui initie la connexion, le client, et l'autre qui écoute, le serveur. Après c'est de la logique applicative de savoir si tu fais du p2p ou du client/serveur mais tes communications sont toujours pap et client/serveur.
Tu confonds aussi checksum et offset couche transport et applicative.
Pour du transport de donnée les services qu'offrent TCP sont très adaptés: contrôle de flux, contrôle de congestion, connexion fiable. Tu as besoin de ces mécanismes et tu n'arriveras pas à égaler 1/10 de la qualité de TCP tant au niveau design qu'implémentation. Pour faire très simple on passe en UDP quand on se fou de la fiabilité ou qu'on préfère l'assurer au niveau applicatif (streaming, jeux vidéos etc.).
Bref fais quelque chose de très simple par ce que tu semble partir de très loin en réseau. De plus les algorithmes applicatifs de P2P c'est un tout autre domaine qui n'a aucun rapport à la programmation réseau, et ça n'a rien de trivial (il y a de très bon papier sur l'analyse et le fonctionnement du protocole bittorrent par exemple) .
[^] # Re: Pourquoi UDP ?
Posté par ckyl . En réponse au journal Application de P2P moderne. Évalué à 4.
Je rejoins le commentaire du dessus. Développer un protocole en UDP il faut vraiment avoir de bonnes raisons de le faire et une très bonne connaissance en protocole réseau. Tu te retrouves à réimplanter beaucoup de fonctions de TCP et c'est totalement hors de porté de nos 4 étudiants (ou alors tu fais un gros protocole moisi qui nique tout le réseau ou qui fonctionne carrément moins bien).
Autrement c'est un projet étudiant de deux mois, rêvez pas trop. Je pense que le but de l'exercice c'est de savoir écrire un client/serveur correctement et il y a déjà beaucoup à faire (surtout si le simple fait de passer de C# à Java ou C vous pose problème). Écrire un protocole réseau correct, c'est je pense; hors sujet, un peu hors de votre portée et surtout d'ici un mois t'aura à peine fini ton état de l'art sur les protocoles existants. Là tu pourras commencer à réfléchir à concevoir quelque chose, puis le coder...
Bref sois tu t'inventes un jouet, soit tu fais du vrai boulot d'ingé c'est à dire faire une implémentation robuste de specs qui existent déjà. Comprendre les objectifs d'un travail/exercice, c'est aussi important...
# Mouai
Posté par ckyl . En réponse au journal MALWARE LINUX. Évalué à 7.
Le seul modèle de défense est la confiance et miser sur le fait que si y'a un truc vilain la masse des utilisateurs finira par le voir. Quand on y réfléchi, la chaine de confiance n'est pas bien solide....
J'anticipe deux réponses: gagner le root sur une station de travail n'est pas ce qui embête l'utilisateur ça permet juste de faire plus de choses à l'attaquant; et gagner le compte utilisateur sur une station de travail, c'est gagner le root d'ici 5 minutes à 1 semaines.
[^] # Re: Belle initiative
Posté par ckyl . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 10.
La duplication de donnée, les indirections pourries et mal pensées, le code pas extensible, pas modularisable ou externalisable, ne pas pouvoir séparer les traitements, les abstractions chiottiques etc. ça coute beaucoup beaucoup plus cher en perf à terme... Après si tu appliques les même design/algorithme/structure de données avec un langage plus performant, ça ira plus vite, mais ça risque de couter un peu plus cher à faire ou un peu plus longtemps à stabiliser.
Bref rien de nouveau sous le soleil depuis le début de l'informatique !
[^] # Re: Et XFS ?
Posté par ckyl . En réponse au journal Fini les fsck au boot !. Évalué à 2.
C'était un très bon FS, mais ce détail était éliminatoire pour moi sur un laptop ou une machine de bureau où les coupures violentes sont fréquentes.