leneant

Membre
  • Compteur de contenus

    290
  • Inscription

  • Dernière visite

  • Pays

    France

Réputation sur la communauté

9 Neutre

À propos de leneant

  • Rang
    Membre actif

Informations personnelles

  • Centres d'intérêt
    Data Processing, Drawing, Asto photo
  1. Choix objectif photo très grand champ

    Exemple du triplet 6D samyang heq5 Empilement DSS, posts traitements Tim.
  2. Choix objectif photo très grand champ

    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....
  3. Calibrage d'ecran avec sonde spyderpro5

    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.
  4. Calibrage d'ecran avec sonde spyderpro5

    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é.
  5. Tim V1.x vs Tim v2.x

    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.
  6. Tim V1.x vs Tim v2.x

    Parmi vous y aurait il des personnes qui pourraient nous aider à créer les symboles selon les fonctions qu'ils permettraient de déclencher ?
  7. Tim V1.x vs Tim v2.x

    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.
  8. Tim V1.x vs Tim v2.x

    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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.