Shadowrun en français
Vous n’êtes pas identifié.
Jazz a écrit:
Namergon a écrit:
un peu bcp HS, oui (c'est dur à c't'heure )
Oh l'autre hé, pourquoi lui il a l'droit et pas nous ? Et ça, tu connais : "compiler, c'est tester" ?
On parlais de tissage et de jargon informatique au départ, mais pas grand chose d'autre à dire.
compiler c'est effectivement un test (même s'il est loin d'être suffisant), on va même jusqu'à compiler des interfaces seules avant de les livrer, chez nous
Hors ligne
Bah, en fait, c'est très ironique...
Je bosse sur mainframe, où le moindre bug peux vite coûter des sous (en 4 ans là dedans, j'ai déja corrigé deux bug à 10m d'euros...)... Et sur le genre de système sur lequel les ingés sont recrutés parce qu'il ont des bac+5... En bio, en chimie...
Y a pas mal de gens qui fonctionnent comme ça, peut-être 10% (ce qui est déjà beaucoup), c'est du gros foutage de gueule, au niveau professionnel
Ton truc, là, raster/vectoriel, c'est pour indiquer le format de l'image quand elle est décompressée, mais vous bosser jamais directement sur les formats compressés ?
Hors ligne
Perso je bosse dans le traitement d'images (en fait acquisition d'image depuis le sensor sur téléphones portables) mais des gens de mon équipe bossent aussi sur les algos, et on ne bosse jamais sur les formats compressés. En fait aucun algorithme ne bosse sur format compressé, par contre ca ne veux pas dire qu'il faut d'abord sauver le fichier en format non compressé...
Hors ligne
C'est zarbi quand même, vous perdriez moins de place en ram... Et de cpu a décoder l'image... Et de cpu a traiter l'image... Et de cpu a recoder l'image...
J'en ai fait du traitement du signal pendant mes études, j'adorais ça. J'aurais revé de bvosser là dedans (mais maintenant, c'est fichu pour moi)
Hors ligne
Quand tu dis directement, tu veux dire ne pas décompresser les données pour les traiter ?
C'est en fait difficile de s'en passer.
Hors ligne
Namergon a écrit:
Quand tu dis directement, tu veux dire ne pas décompresser les données pour les traiter ?
C'est en fait difficile de s'en passer.
Je serai même curieux de connaitre un seul algorithme capable de travailler sur du jpg.
Pour info quand tu fais une retouche sous photoshop, il se passe a peu près ça (bon c'est pas 100% garanti, mais c'est l'idée):
- photoshop décompresse le jpg pour obtenir une image YUV
- photoshop convertit le YUV en RGB
- tu fais tes retouches et tu cliques sur "save"
- photoshop convertit le RGB en YUV
- photoshop recompresse le YUV en jpg
Hors ligne
Impossible de rendre l'ordi "myope", même si ça bave un peu ? Allons, allons !
Pour les applications, temps réel sur des "petits" cpus (genre téléphone portables), sur lequel temps de traitement et conso sont importantes à optimiser.
-edit- euh.... je raconte pê des conneries en fait... Quand un jpeg est affiché, je me souviens plus s'il y a déja décompression... MMm... S'il y a IFFT, je crois que oui en fait...
Dernière modification par Jazz (19/04/2010 19:49:31)
Hors ligne
Soit T le traitement que tu veux appliquer à l'image originale I, il faudrait trouver le traitement T' à appliquer à l'image compressée I' pour que, une fois décompressée I' = T(I).
C'est peut-être plus couteux de déterminer T' que de décompresser I, d'appliquer T puis de recompresser I ... non ?
Dernière modification par Nurw0d4sh (19/04/2010 19:58:32)
Hors ligne
Soyons précis, c'est T'(C(I)), avec C la compression. La précision, c'est que C ici n'est pas une bijection pour un jpeg.
Et, si, tout, absolument tout indique que les traitements d'image sont moins couteux dans l'espace de Fourrier que dans l'espace du signal non compressé... Moi j'dis ça, j'dis rien, mais tente une petite convolution par un filtre sans transfo de Fourrier juste pour voir...
Elle est drôlement jolie ton intégrale dis donc ^^
Dans l'espace de Fourrier, c'est une multiplication : T' devrait être une multiplication. Ton T une convolution par un filtre : une méchante intégrale toute moche que tu va filer aux dsp de ton ordi/tel portable parce que tu voudra pas la calculer au cpu (et au passage, eux vont faire une fft hardware, faire le calcul en 1 cycle (c'est pas mytho, j'ai déja prog en asm dsp) et te la rendre en IFFT hardware).
Après, je sais plus trop, je suis plus dans le bain depuis 2003 donc je vulgarise à la louche et à la va-comme-j'te-pousse. Mais je crois que la FFT/IFFT dsp c'est 4 et 5 cycles. Alors qu'on pourrais s'en passer mais bon (+ les cycles de décompression destructive pré traitement T + les cycles de recompression post traitement)
Dernière modification par Jazz (19/04/2010 21:25:19)
Hors ligne
Jazz a écrit:
Pour les applications, temps réel sur des "petits" cpus (genre téléphone portables), sur lequel temps de traitement et conso sont importantes à optimiser.
-edit- euh.... je raconte pê des conneries en fait... Quand un jpeg est affiché, je me souviens plus s'il y a déja décompression... MMm... S'il y a IFFT, je crois que oui en fait...
1/ Quand un JPG est affiché il est evidemment décompressé : ton écran ne comprend pas le jpg (et tes yeux non plus), mais le RGB !
2/ Pour les telephones portables (et (je suis prêt à mettre ma main au feu) aussi sur les appareils photo compacts et les reflexes) ca n'est pas un cpu mais du hardware dédié. Le cpu n'est la que pour controler le HW. Cela est vrai aussi bien pour le traitement de l'image que pour l'encodage/décodage image/video.
Hors ligne
1/ N'empêche qu'il devrait être possible de traiter le signal directement en jpeg sans l'afficher...
2/ Oui, c'est des puces de dsp... Dès que tu as du traitement du signal, tu as des dsp qui sont des agrégats de millier/million d'unités de traitement de calcul en parallèle. Tu trouve aussi des dsp dans les gpu des pc.
Je suis chanceux, j'ai mis un 's' à cpu ^^... Mais tu as raison, j'ai aussi mis un 'c' à pu
Hors ligne
Jazz a écrit:
1/ N'empêche qu'il devrait être possible de traiter le signal directement en jpeg sans l'afficher...
2/ Oui, c'est des puces de dsp... Dès que tu as du traitement du signal, tu as des dsp qui sont des agrégats de millier/million d'unités de traitement de calcul en parallèle. Tu trouve aussi des dsp dans les gpu des pc.
Je suis chanceux, j'ai mis un 's' à cpu ^^... Mais tu as raison, j'ai aussi mis un 'c' à pu
1/ Probablement, mais j'imagine que ca couterai plus de ressources que de décompresser, traiter, recompresser
2/ Non meme pas des DSP (= digital signal processor, un processeur spécialisé dans le traitement du signal) mais bien du HW dédié à une seule tache (ex: dematricage, application de gains, collecte de statistiques pour l'autofocus ou l'auto exposition, ou dans le cas de l'encodage/decodage video: quantization ...)
Il faut voire qu'entre un DSP et du HW dédié il y a un rapport 50-100 sur les performances... par contre le HW dedié est beaucoup moins flexible et ne sert à rien lorsque la camera est éteinte.
Hors ligne
Carmody a écrit:
DSP (= digital signal processor, un processeur spécialisé dans le traitement du signal)
Merci Carmody, ça m'a évité une recherche
Hors ligne
En fait, dans ma partie, y a toujours besoin de décompresser au final (pour dire aux têtes où mettre les gouttes sur le papier), mais le reste se fait au maximum sur les données compressées (voire on compresse nous-mêmes dans certains cas).
Hors ligne
Je l'savais que j'étais pas un génie !
Carmody a écrit:
Jazz a écrit:
1/ N'empêche qu'il devrait être possible de traiter le signal directement en jpeg sans l'afficher...
2/ Oui, c'est des puces de dsp... Dès que tu as du traitement du signal, tu as des dsp qui sont des agrégats de millier/million d'unités de traitement de calcul en parallèle. Tu trouve aussi des dsp dans les gpu des pc.
Je suis chanceux, j'ai mis un 's' à cpu ^^... Mais tu as raison, j'ai aussi mis un 'c' à pu1/ Probablement, mais j'imagine que ca couterai plus de ressources que de décompresser, traiter, recompresser
2/ Non meme pas des DSP (= digital signal processor, un processeur spécialisé dans le traitement du signal) mais bien du HW dédié à une seule tache (ex: dematricage, application de gains, collecte de statistiques pour l'autofocus ou l'auto exposition, ou dans le cas de l'encodage/decodage video: quantization ...)
Il faut voire qu'entre un DSP et du HW dédié il y a un rapport 50-100 sur les performances... par contre le HW dedié est beaucoup moins flexible et ne sert à rien lorsque la camera est éteinte.
1/ Non, non. Je suis catégorique.
2/ Oui, pourquoi pas. 50-100, non, tu exagère grandement. Par contre, les prix, c'est x50-100 effectivement
Dernière modification par Jazz (20/04/2010 21:35:42)
Hors ligne
Jazz a écrit:
2/ Oui, pourquoi pas. 50-100, non, tu exagère grandement. Par contre, les prix, c'est x50-100 effectivement
Non, non j'insiste, on a fait l'étude !
Hors ligne