leneant

Membre
  • Compteur de contenus

    282
  • Inscription

  • Dernière visite

Réputation sur la communauté

3 Neutre

À propos de leneant

  • Rang
    Membre actif

Informations personnelles

  • Centres d'intérêt
    Data Processing, Drawing, Asto photo
  1. Tim V1.x vs Tim v2.x

    Bonsoir, je remonte ce fil pour poser la question d'une collaboration avec quelqu'un sous MAC. y aurait-il quelqu'un d'intéressé ? L'idée étant de réaliser la compilation et les tests sous MAC. Pas forcément de participer directement aux développements.
  2. Tim V1.x vs Tim v2.x

    OK je te fais un zip ce soir et je t'envoie ça. Du coup on est tout les deux sous linux moi debian 9. Par contre la majorité des utilisateurs de Tim est sous Windows. Et ça serait pas mal d'avoir un Maceux pour faire les 3 plateformes.
  3. Tim V1.x vs Tim v2.x

    J'imagine que tu es sous Windows. Ça serait pas mal de faire directement le développement multi plateformes. Ça éviterait d'avoir de tes mauvaises surprises lors du portage.
  4. Tim V1.x vs Tim v2.x

    Volontier centauri. Quand j'ai commencé Tim je n'y connaissais rien en traitement d'image. J'ai appris sur le net et en analysant des softs comme iris. Pour que tu découvres les threads je peux te passer un projet Lazarus d'essai. Ultra simple quatres compteurs en parallèle. Il faut savoir qu'avec l'objet Tthread j'ai systématiquement des erreurs. Donc je passe par le niveau le plus bas. En plus je trouve que c'est plus simple. Des fois l'objet compliqué inutilement le code.
  5. Tim V1.x vs Tim v2.x

    Le Pascal est un langage algorithmique. Sans rentrer dans les arcanes de celui ci, son accès est assez facile. Perso je n'ai pas eu trop de problème pour passer du c au Pascal (j'aime pas le c++ je lui préfère l'ADA ou le Pascal objet). Donc si tu travailles l'algorithmique en pseudo langage, le passage au Pascal est extrêmement simple. Sinon attention n'importe quelle librairie ne sera pas optimale. En effet mes algo descendent les colonnes une par une. Pour faire simple j'ai une première boucle sur les lignes et une seconde boucle imbriquée sur les colonnes. Donc mon swap sur disque se fait d'une manière précise pour optimiser les flux entre RAM et disque. De la même manière les fenêtres en RAM sont conçues de façon à être optimales avec la conceptions des calculs. Si tu veux voir l'idée qui oriente la conception vas sur github et regarde (de mémoire) l'unité IU_Frames.pas dans images32. Tout est expliqué sous forme de commentaires au début de l'unité. Pareil pour IU_TemporaryPixFiles.pas. Je dois corriger quelques trucs. Mais l'idée y est.
  6. Tim V1.x vs Tim v2.x

    En y réfléchissant je pense mettre plante dans mon estimation de l'occupation mémoire. Ensuite tout dépend si les images ont un canal alpha ou non. La v2 pouvant traiter un canal alpha ou non selon le choix de l'utilisateur. En prenant 52Mpixels les plus grosses résolutions d'apn aujourd'hui j'obtiens 1,6 Go de RAM. Donc un peu plus de la moitié pour les systèmes à 3Go de RAM. 1,6 avec canal alpha et l'image source et l'image résultat en RAM. Ça me semble plus raisonnable. Et ça ne devrait pas grever l'efficacité des calculs dans la majorité des cas. Par contre je ne tiens pas compte des autres conso mémoire comme les previews par exemple.
  7. Tim V1.x vs Tim v2.x

    Bonjour centauri. Non l'aide ne serait pas limitée qu'à la reprise des algos. Je pense que leur portage ne sera pas trop compliqué. Il faudra les adapter aux 32 bits par canal actuellement 8bits. Compte tenue de la conception envisagée l'adaptation aux multi threads ne devrait pas générer trop de complexité. Par contre l'adaptation des unités de gestion des images en interne est en cours de refonte complète. Dans la v1.x tout est monté en mémoire. Ce qui pose le problème de sa consommation. Pour le passage en 32bits par canal tout ne sera pas en mémoire. Seules 3 fenêtres de l'images devraient être en mémoire. Le reste sera dans des fichiers temporaires sur disques. Pourquoi 3 ? Pour faire un compromis entre la consommation mémoire, le multi threads et éviter trop d'aller retours mémoire disque pour la majorité des images. D'après mes premières estimations Tim devrait pouvoir traiter des images de 50M Pix dans virtualisation sur disque de l'image. Le tout en évitant swap. Ce qui amènerait environ 2,4 GOctets de mémoire réservée pour l'image. J'ai pris une base de 3Go de RAM pour les plus petites configurations. Ça c'est le premier enjeu dont va dépendre la rapidité de calcul de Tim. Ensuite il y y l'ihm. Aujourd'hui la gestion des évènements utilisateurs est complexe pour éviter ce que j'appelle la ré-entrance. Lorsqu'en calcul de preview st en cours les évènements rappel les fonctions de calculs en cours. Ce qui amène du n'importe quoi comme résultat. J'ai donc du protéger les fonctions pour que rien ne se passe lorsqu'un calcul est en cours. Je veux changer cette approche. De plus j'ai eu pas mal de remontées sur l'ergonomie qui est déroutante. J'aimerais aussi la revoir. Mais le plus important reste la gestion de la mémoire et le multi threads. Voilà je crois avoir fait le tour des ambitions de cette V2.
  8. Tim V1.x vs Tim v2.x

    Pour le projet tu peux te référer au site web. Tim.hexperceptio.fr qui présente la branche v1. Grosso modo il y aura les mêmes fonctionnalités mais avec 32 bits par canal en interne et une interface revue. Pour les binaires j'ai pas fais gaffe. Lazarus créé automatiquement le répertoire lib et l'exécutable dans le répertoire du projet. Du coup gitkraken les push dans le repository. Tu n'en a pas besoin pour compiler. Mais là il ne se passe pas grand chose. Ce n'est que du débug.
  9. Tim V1.x vs Tim v2.x

    Merci. Je vais y aler à mon rythme. Les algo de traitement d'images ne changeront pas. Le traitement mémoire va être intégralement revu pour pouvoir traiter des images lourdes mais surtout passer en 32 bits par canal en interne. Et je vais paralléliser les traitements pour améliorer les temps de calculs. L'IHM aussi sera revu. Je ne sais pas encore quelle forme il prendra. Je sais juste que le principe de comparaison avant et après traitement sera conservé. Pour le moment j'en suis à coder la gestion mémoire des images et c'est du boulot.
  10. Tim V1.x vs Tim v2.x

    Voilà Tim Branche V1 a vécu. Je ne compte plus le maintenir. J'ai cherché des personnes qui pourraient m'aider à le maintenir, mais j'ai fais choux blancs. Mais, je suis entrain de travailler sur la V2. Cette V2 ne fonctionnerait que sur les plateformes 64bits. Elle traiterait les images en 32Bits/canal en interne et ne limiterait la taille des images qu'à 32767*32767 pixels maxi. Je cherche toujours des personnes qui seraient intéressées par cette aventure. Mais je compte la mener à mon rythme, c'est à dire lentement, quand j'aurai envie d'y travailler. Pour ceux qui sont intéressés voici un lien github. https://github.com/leneant/Tim-V2.0 Voici le site de Tim V1.x. : http://tim.hexperceptio.fr/ Je compte porter la presque totalité des fonctionnalités. Que ceux qui le souhaitent prennent contact avec moi.
  11. Je me lance

    Après les versions Linux 64 bits et 32 bits, voici les versions windows 32 et 64 bits :-)Windows 64 bits : https://sourceforge.net/projects/traitementdimagestim/files/V1.1/Alpha/Tim-Windows-X64-V1.1.0-14a-c1.zip/downloadWindows 32 bits : https://sourceforge.net/projects/traitementdimagestim/files/V1.1/Alpha/Tim-Windows-X86-V1.1.0-14a-c1.zip/download
  12. Je me lance

    Je remonte le post qui date un peu.Depuis le temps, je me suis offert un serveur 8Go de RAM avec un I7 sous nunux. Delà je vous propose la toute nouvelle version de Tim sous nunux 64 bit et 32 bits.J'ai testé rapidement (sous debian testing 64bit et mageia 32 bits). Ca semble fonctionner.Vous pouvez tester voici les liens :X64 : https://sourceforge.net/projects/tra...1.zip/downloadX86 : https://sourceforge.net/projects/tra...1.zip/downloadLes ajouts : Paramétrage de la résolution des preview pour les adapter à la puissance de la configuration Intégration de la gestion du signal de fond pour réaliser des effets spéciaux, mais qui peut servir d'anti gradient. Modification du masque flou qui ne modifie plus la luminance de la photo...etc.Amusez-vous bien et n'hésitez pas à me faire part de vos remarques.
  13. Ultra grand champ VL

    En regardant bien, en bas à gauche des Pleiades, on devine la California. Cette photo est riche en objets.
  14. Ultra grand champ VL

    @NUNKY : Oui j'adore :-)[Ce message a été modifié par leneant (Édité le 28-08-2016).]
  15. Ultra grand champ VL

    Je post une photo de la série qui m'a permis d'obtenir cette image :