leneant

Je remonte le fil. Nous aurions besoin d'un testeur sous Ubuntu avec l'environnement Gnome. Y aurait-il des volontaires ? Contactez moi en mp.

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.

Exemple du triplet 6D samyang heq5 Empilement DSS, posts traitements Tim.

Je pense qu'en rapport qualité/prix samyang est imbattable. Mais c'est du full manuel. Avec mon 6d je pratique le 35 et le 14 et j'en suis satisfait. Perso j'aime bien la dynamique et les teintes tendues par ces objo. Mais il faut connaître quelles astuces. Fermer un peu pour éviter les artéfacts de réflexion avec les lentilles. Prévoir sa Map de jour et l'affiner en conditions réelles avec des shoot à ISO élevés avant de shooter réellement....

Bonjour, Non pas de réglages différents jour nuit. Pour savoir si ton image tire sur une teinte, tu as les histogrammes. Perso un seul réglage me suffit. Mais j'ai des conditions d'éclairage qui ne changent que très peu. Pièce sombre. Donc je ne ressent pas le besoin d'avoir plusieurs réglages.

J'ai une spider 4. Je calibré de temps en temps. Il est impératif de faire le calibrage après un temps de chauffe. Histoire que l'électronique soit en régime de croisière. Ceci dit je ne vois pas trop de différences entre un calibrage à froid et un à chaud. Pour les rendus différents pleins de paramètres sont en jeux. Le principal étant le gamut (étendue colorimétrique) des écrans. Le point blanc aussi joue sur les réglages. De toutes façons un écran calibré c'est toujours mieux qu'un non calibré.

Bonjour, Je remonte ce fils car nous progressons un peu sur le projet. Mais nous souhaitons le mener avec l'aide de ses utilisateurs. Alors les curieux et les bonnes volontés sont les bienvenus pour tester et discuter de l'orientation du soft. Ceux qui sont intéressés peuvent me contacter.

Parmi vous y aurait il des personnes qui pourraient nous aider à créer les symboles selon les fonctions qu'ils permettraient de déclencher ?

Voilà un mois que l'aventure de la v2 a commencée. On a commencé à revoir intégralement la gestion mémoire. Ce chantier étant à la base de tous les calculs. Le principe du swap a bien été retenu. Mais il ne devrait se déclencher sur pour les très grosses images. Dans plus de 90% des cas il ne devrait pas y avoir de swap. Le principe du calcul parallèle est aussi retenu. Ce qui devrait améliorer les performances par rapport à la v1. À priori Tim v2 devrait aller environ 4 fois plus vite que la v1. Sur le chantier de l'ergonomie, nous nous orientons vers un ensemble de symboles qui remplaceront le menu de commande de la v1. Ce qui rendra directement accessible les commandes en un clique.

Bonjour, Les premiers pas sur le développement de la v2 ont commencés. Si vous avez des remarques, des propositions à faire pour la v2 faites le savoir. La v2 doit reprendre presque les mêmes fonctions que la v1. Seule une fonction ne devrait pas être reportée c'est le traitement indépendant des teintes. Ce module n'est jamais utilisé. Donc il ne sert à rien. Tim v2 passe en 32 bits en interne par canal rvb et alpha. Un swap est prévu de façon intelligente pour les très grosses images. Ainsi les performances du pc ne devraient pas tomber et le pc devrait rester utilisable. La taille maxi des images passe à 32768 * 32768 pixels. Nous allons également réfléchir à une nouvelle ergonomie pour faciliter l'utilisation de Tim. Si vous avez des propositions n'hésitez pas.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Bonjour,Après avoir utilisé des logiciels gratuits qui se figeaient, plantaient ou qui nécessitaient d'avoir une notice d'utilisation à côté de soi pour l'utiliser, j'ai essayé de faire un petit logiciel sans prétention orienté sur la facilité d'utilisation sans négliger la qualité du rendu.Il s'agit d'un petit logiciel de traitement d'images qui se veut simple d'utilisation et qui permet de traiter autant les photos classiques que les astro-photos (surtout planétaires).Je me suis lancé dans son développement car je n'arrivais pas à traiter simplement comme je le souhaitais certains shoots. Alors je l'ai réalisé pour qu'il répondre à mes besoins et qu'il me facilite la tâche dans les traitements après empilement ou sur des photos classiques.Il s'appelle Tim (tout bêtement pour Traitement d'images). Il tourne sous windows et linux. Et je cherche quelqu'un pour le compiler et si besoin faire les adaptations pour Mac OS X.Je le diffuse en OpenSource sous licence GPL.Voilà où il se trouve : http://traitement-d-images-tim.webnode.fr/ Et voici quelques exemples de ce qu'il peut faire :

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.

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

Bonsoir,Voici une reprise d'un shoot réalisé en septembre 2015. Traitement réalisé avec Tim, mais avec comme objectif de gérer le gradient et de faire ressortir la VL.Perso j'adore ce nouveau traitement qui donne un effet impressionnant.

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