Reprise du message précédent :
Je suis sur http://www.nodebeginner.org/#hello-world
 
Les cotés asynchrone / monothread sont un peu chaud à appréhendé mais je m'accroches...
 
Ça peut cohabiter avec un serveur PHP / mysql Classique ou pas (logiquement oui si je met un port à la con je pourrais l'utiliser que pour la génération d'image) ?

(j'avais pas vu ton post avant de partir bouffer )

Oula calmos, j'affirme rien sur ce qui se passe dans ton ancienne boîte/la boîte actuelle de 0x90. Je parle en général, parce que oui, il arrive de bosser avec des gens pas fiables.

Là encore ba c'est bien pour vous Je ne dis pas que l'approche de filer les clés aux devs n'est pas viable, je dis juste que c'est à manier avec précaution : pas partout, pas avec tout le monde.
D'ailleurs, je trouve que c'est super pour apprendre plein de trucs et avoir (justement) un point de vue sur comment ça se passe en front. Mais c'est comme pour tout, tu peux pas le généraliser à toutes les boîtes qui ont besoin de dev.

La réponse de chef de chantier du BTP QUand je dis "il dev pas", je parle de dev de l'appli/des services fonctionnels qui intéressent le client. Je parle du gars responsable de la prod, donc monitoring, livraisons des devs, modifs systèmes (hardware/software, que ce soit pour changer la RAM ou upgrader la version d'Apache). Je dis pas que le gars doit pas savoir faire du dev, mais c'est du dev orienté admin ou "devops", si tu préfères.

Là encore, je ne dis pas que l'approche ne fonctionne jamais ou n'a pas d'avantage. Bien sûr que c'est super pratique de pouvoir redimensionner l'archi pour dépanner la prod Mais faut voir qui a cette responsabilité aussi. En l'occurrence, dans ton cas, sur tous les mecs qui flippaient, tu penses pas qu'y en aurait pas eu un pour utiliser le redimensionnement en guise de parapluie pour planquer le problème ? Les gens sont capables de plein de grosses de conneries pour pas être coupable aux yeux des autres, donc il me semble nécessaire de faire attention à qui on file les clés et comment. Quand t'es responsable de l'équipe, que t'as quasiment fondé le truc et que t'as confiance en tout le monde (cf exemple de nraynaud), c'est quand même plus simple que quand tu débarques au milieu d'infras dégueulasses avec 10 ans d'historique au cul et 3-4 devs peu scrupuleux pour ce qui est de corriger les bugs

non, mais disons que dans mon utopie aussi, comme le dev n'est pas seul, il va moins déraper seul. Je crois fortement à l'équipe pour ces trucs là. Un peu de consensus sur les outils et un peu de consensus sur les valeurs, la qualité, ce qui est urgent ou important etc.
 

C'est clair qu'il y a des gens avec qui je ne retournerais pas bosser, et que je ne leur filerai pas les clefs du camion. Mais dans la mesure du possible, je prends le pouvoir maintenant, et j'essaye de former la bonne équipe pour pouvoir bosser comme ça. En tout cas la dernière fois c'était moi le plus con dans l'équipe produit, c'est pas toujours facile pour le moral de se sentir le boulet, mais y'a aussi un certain sentiment de sécurité dans le boulot accompli.
 

ben justement, devops c'est ce que j'ai fait, les même mecs qui développent le produit le mettent en prod.
 

ouais, il faut parfois passer un peu les RH au lance-flames en arrivant ...

hep les boulets, comment on attrape les coordonnées du coin en haut à gauche dans raphael.js ?
je vois width et height en propriété directes sur l'objet, mais je vois _left et _top qui ont l'air un peu privées

Ah mais ça ouais, +10 000 C'est vraiment bien quand t'es dans un groupe de gens qui "parlent le même langage" en termes de techno mais aussi de vision, etc...

Oué, t'as moins peur de déléguer, c'est clair.

Ah. Pour moi, devops stait le gars qui faisait du dev mais orienté pour l'exploit, pas sur le produit. Wikipedia parle d'un mouvement ou d'une organisation, spa super clair. Je comprends la confusion, j'vais aller revoir ma définition

Dat debate

x - width  
y - height
 
 

http://nodeguide.com/convincing_the_boss.html#TOC

Ce truc me fait un peu peur... :- /
 
Sinon avec ImageMagick

 
Comment fais-tu pour transformer l'image en tableau? Je devine que le problème est plus le processus que le language.
Si tu peux transformer ton image en bmp en temps raisonnable par ex, tu peux ensuite directement travailler dans le fichier bmp car le format est trivial.

ça doit etre vendredi, la fatigue etc...
 
je sèche... pour rendre rendre obligatoire au moins 1 checkbox... comment on fait ?
 

<label class="checkbox">
    <input type="checkbox" value="" required>
    Yo
</label>
<label class="checkbox">
    <input type="checkbox" value="" required>
    Bien?
</label>
<label class="checkbox">
    <input type="checkbox" value="" required>
    Sisi
</label>
<label class="checkbox">
    <input type="checkbox" value="" required>
    Tavu
</label>

A l'heure actuel :

Et après je mix mes pixels provenant de mes différentes images suivants certain paramètres choisit par l'utilisateur avec des boucles for puis j’écris dans le canvas avec context.putImageData(buffer, 0, 0);
 
 
Mais dans php seul, je vais aps bien loin si je me contente de $rgb = imagecolorat($im, $x, $y); et $colors = imagecolorsforindex($im, $rgb); :- /

<label class="checkbox">
    <input type="checkbox" value="" required>
    Yo
</label>
<label class="checkbox">
    <input type="checkbox" value="" required>
    Bien?
</label>
<label class="checkbox">
    <input type="checkbox" value="" required>
    Sisi
</label>
<label class="checkbox">
    <input type="checkbox" value="" required>
    Tavu
</label>

Utiliser un radio button et en sélectionner 1 par defaut ?
Pas sur que ce soit possible en html pur, par contre la plupart des librairies javascript propose un validateur "one-required"
http://mootools.net/docs/more/Form [...] e-required

 
Si tu donnes a tes radio boutons des name identiques tu en auras un et un seul de cochable. D'après ce que je comprends lui il en veut au moins un de coché, donc des checkbox.

Allez, je degage raphael, ça me saoule de pas supporter les groupes et les matrices au niveau papier, et comme maintenant svg est dans ie, c'est juste pour me faire chier.

C'est pas l'outil qui cachait une partie des problèmes de perfs rencontrés par rap genius par hasard ?

si

 
on peut pas faire en html pur ? quel dommage
 

 
Oui voilà, choix multiples mais au moins un de coché

Des navigateurs de tous bords (mobile autant que desktop), qui font une requête XHR 'en trop' (sur la même url que la page en cours, sans le query string, comment si on faisait un $.get('.')), que j'arrive pas à reproduire chez moi, ça vous dit quelque chose ?
 
Ça le fait sur toutes les langues, avec de gens de tous pays, même sur des plateformes où on peut pas mettre d'extensions, y'a le header X-Requested-With donc je pense que c'est fait par une lib ajax, et le referrer de la requête est bien la page en cours.

un proxy

Un proxy qui arrive à être devant des gens qui sont éparpillés partout dans le monde, alors qu'on a cloudflare devant (donc que les points d'entrée dans cloudflare sont bien répartis dans le monde aussi) ?

Pour les freelances... net-entreprises, c'est une blague du gouvernement, ou un stagiaire mal recruté ?

Je pensais qu'on ne voyait ce genre de code que sur les vieux sites multimania.

 
Ils sont restés en 2000, sûrement  

Je vais tester en mettant mes pixels dans une base de donnée et en adaptant l'algo en SQL... :- /

En fait non, mon image en base de donnée c'est + de 2 million de lignes et 60 Mo ! :- /
 
Tain mais doit bien y'avoir un truc plus performant que le javascript pour de la manipulation de tableau de pixels FFS !

du c ? de l'asm ? acceleration materielle?
oui il y a plein de trucs performants mais ca depend de jusqu'ou tu es pret a aller et ou est le goulot.
 
si c'est le traitement complet tu peux tenter imagemagick deja coté serveur ou opencv via python c'est simple et tu te pose pas de questions.
 
si c'est la manipulation tu peux aussi la faire en opengl/cuda/opencl si il y a un gpu coté serveur.
 
si c'est la projection d'une image vers un array qui prends le plus de temps a toi de voir si le format cible est le bon parfois ca tient juste au typage des pixel et/ou a la facon dont c'est traité (par tiles/stream ? en fin de load complet ? copie ou référence?)  

Je ne sais pas, à mon avis un  goulot c'est déjà de convertir les 10 images en tableau de pixels pour pouvoir les lires (sur mon chrome avec les images dans le cache ça prend dans les 3 secondes)...
En JS coté client, on ne le fait qu'une seul fois et après on tappe dedans (je prends environ 100 Mo de RAM en plus dans chrome, ce qui me semble plutôt bas par rapport à mes autres essais de stockage / récupération) à chaque modification de paramètre...
 
Si au lieu de stocker des images, on stockait directement des tableaux de pixels (que de toute façon on devra lire), ça me semble en théorie un bon début, l'espace que ça prend n'est pas vraiment un facteur pertinent, par contre il faut que la vitesse de récupération le justifie...
 
Par exemple, en python mouliner une première fois avec t_data = Image.open("fichier_1.png" ).load(); et le stocker avec pickle pour pouvoir le charger plus rapidement, est-ce plus intéressant que de charger systématiquement depuis l'image...
http://stackoverflow.com/questions [...] lly#138260
http://stackoverflow.com/questions [...] le#3685295
 
Si je traites coté serveur et que pour chaque requête j'ai ces 3 secondes de conversion / récupération alors que coté client c'est instant, c'est super mal barré !
 

Nan mais ce que je pige pas c'est que tu veuilles absolument stocker et manipuler des tableaux de pixels (donc du bitmap, quoi). C'est obligatoire ? Parce que si oui et que t'as des images relativement grandes, c'est normal d'avoir des trucs monstrueux en base (temps de récup de la mort, etc...) et que tes perfs se fassent défoncer.
Tu peux pas manipuler tes images directement avec ce que proposent les libs de base ? Si c'est un algo complet, tu peux pas étendre les-dites libs de base ?
 
Et comme le suggérait pop-pan plus haut, niveau calcul, c'est ton GPU qui va savoir faire ça super bien et super vite : vois du côté d'un langage qui saura discuter avec le GPU et s'il est possible d'avoir un GPU correct sur le serveur.

Honnêtement, les couches d’images et les algos ne sont pas de moi, et j'y comprends pas grand chose, je me suis contenté d’appliquer son modèle théorique en javascript...
 
...en gros et a vue de nez je dirais que son algo fonctionne un peu comme des calques photoshop :
 - 1 couches peut venir en produit sur une autre
 - 1 peu être utiliser en fonction de la valeur de ses pixels comme un masque de sélection pour agir ou non sur une (ou plusieurs) autre(s) couche(s)
 - etc.
 
A mon niveau tout ce que je vois c'est des calculs sur des pixels, j'ignore complétement à quoi on peut rattacher ça au niveau d'une lib, mais ça me semble tendu...
 
C'est pas possible dans un langage (pas en php en tout cas) de mobiliser 1 giga de RAM pour stocker ses %£¤§@&?! de tableau et les avoirs sous la main ?

tu as deux problemes et c'est a toi de prendre une decision.
 
client side js : chaque load hors cache rajoute du delai / manipulations simplifiées une fois que c'est chargé (sous reserve de conf correcte coté end-user)/ load leger server side / sources img et code visibles
 
server side whatever: charge cpu/gpu centralisée / envoi reguliers de fichiers donc delai / sources cachées
 
ca depends de l'usage, si il n'y a que quelques personnes et que l'environnement est controlé tu t'en fous un peu de fournir le source, sinon tu peux partir sur un truc fermé genre AIR voire flash ou une applet (huhuuh) et/ou rajouter une clef lors de l'echange
de meme, la qualité de sortie acceptable influe directement sur l'approche.
 
sinon un mix-up : tu peux par exemple envoyer des preview mid/lo-res ou des layers alphas pour manipulation client side et effectuer le rendu final/intermediaire server side (genre selection et deplacement client side, rendu server side et update)
ou alors utiliser un systeme tile-based pour chunker des le depart tes sources images et faire tes rendus en tiles, mais bon avec du XGA c'est un peu overkill.

Pour le AIR / Flash, non merci, on préfère encore se faire piquer le process que de se couper des smartphones / tablettes...
 
Ce qui est fou c'est qu'on se disait qu'avec des temps de rendu de 0.1 seconde sur PC et autour de la seconde sur IPAD 1, on ferait nettement mieux coté serveur...
 
...sauf que le calcul sur les pixels, ce n'est finalement pas le plus compliqué (dans le sens long et couteux en ressource) par rapport à la conversion des images en donnée utilisable.

si tu expliques pas c'est quoi tes cibles faut pas t'etonner non plus que je te propose des trucs moisis hein
 
d'ailleurs est ce que tu es sur que c'est le convert d'image=>array qui rame? t'as profilé? parce que comme dit plus haut si la taille des fichiers tu t'en fous tu fais un array de pixels type ppm. un header pourri, la data et c'est marre, rien de plus simple a loader.
 
[edit]
d'ailleurs t'aurais meme pas a convertir pendant les opérations, puisque le fichier EST une representation d'un array de pixels que tu peux meme stocker en ASCII

Moi chui sur d'une chose c'est que je suis sur de rien ! ^^
 
Après mes tests disent :
 - Dans la version js, chrome utilise 50 Mo de RAM sur la page de google et 150 sur ma page
 - Le premier affichage d'image prend 3 s (cache activé) et ensuite les rendus sont instantané
 - Quand j'ouvre une seule image en php et que je lit ses pixels pour les mettre dans un tableau, ça prend plus d'1 secondes
 - Si j’écris un fichier php de ce genre

pour pouvoir faire un require du fichier, le fichier fait 20 Mo
 - si je sérialise et que je met en base de donnée Mysql vas faire un tour (mysql has gone away)
 - si je met chaque pixel dans une base de donnée, ça à l'air encore plus tordu (1seul image => 60 Mo et + de 2 million de ligne)
 
Je regardes le PPM mais je le sens pas, la représentation des images semble être sur une palette de 65 000 couleurs, donc pas d'alpha or nous on part de png avec des transparences...
 
Je connais pas les technologie serveur mais avec NodeJs, chaque appel instanciera un serveur (et donc rechargera les images comme en php) ou pas ?

nan mais qu'est ce que tu veux aller foutre une image dans mysql ? c'est un non-sense. Ca se créé  une image et ça se stocke sur un CDN ou un endroit dédié pour ça

2 msg plus haut je disais que ca pouvait etre lié au typage.
 
et c'est normal que php alloue plein de ram, pour mysql aussi d'ailleurs
 
en php si tu affecte 0 ou 255 dans un [] tu as un overhead de 48bytes par byte que tu souhaites exploiter  (ca peut meme etre plus si tu l'a compilé en 64bits car la l'overhead... double)
 
c'est parce qu'en plus de stocker la value (en int et pas en byte), il stocke le hash, le type, la ref...
 
c'est pour ca que je te disais que tu pouvais exploiter directement un fichier en ascii (les chars ascii sont sur 8bits, 4 a la suite ca fait ton rgba 32bits) ou tu peux aussi les exploiter avec un int32 mais il faut alors travailler en bitwise avec des shift (<< et autres)

http://www.php.net/manual/en/class.splfixedarray.php ça peut aider pour la RAM
 
http://fr.slideshare.net/patrick.a [...] ucture-102

 C'est pas l'image que je veux mettre dans la abse de donnée mais les valeurs de chaque pixel (c'était dans l'idée de traduire mon algo en SQL)  

Oula, javais pas compris ça l''idée serait de déplacer un curseur virtuel et de lire les infos de mes 10 fichiers Ascii...
 
...mais on en revient au problème d'ouvrir et lire un fichier sur le disque dur VS avoir un truc déjà chargé dans la RAM ! :- /

Oui effectivement y'a beaucoup d'optimisation à faire du coté du type de donnée, d’ailleurs le t_data javascript est un tableau qui n'a qu'un niveau de profondeur et je boucles sur le pixels de cette façon :

rien ne t'empeche de charger une string ASCII dans la ram hein
bon apres t'es en mode tokenizer mais ca peut etre a creuser.
 
mais franchement utilise juste le php comme un broker pour faire des calls a un programme en C ou en asm ca sert a rien de te casser la tete.

Déjà, si tu stockes ton truc avec des valeurs en hexa tu vas beaucoup gagner. Notamment pour les valeurs dont on peut omettre la seconde partie de la paire.  
 
#fff vs 255, 255, 255
 

Ca n'a rien à voir avec hexa ou pas hexa (qui sont uniquement des représentation de nombre entiers)
Faut par contre profiter de la taille du type de données utilisé. Mettre des valeurs limitées à 256 (soit 8 bits) dans un entier qui doit être sur 32 ou 64 bits oui ça c'est pas optimal

Le problème c'est pas tant la vitesse du language dans votre truc, c'est plutôt le fait d'itérer sur les pixels (que ce soit itérer pour convertir manuellement vers un tableau ou itérer pour appliquer l'algo).
 
Python+PIL+numpy et l'application de l'algo sous une forme matricielle et ça tracera, pas besoin de faire du C ou des trucs absurdes comme isoler les pixels dans un sgbd.