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.

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.