Je me lance

J'ai lu les différents posts où il était question de développeurs qui voulaient faire des programmes eux mêmes.

Je ne sais pas si je serai crédible ou pas, mais vos remarques sur mon logiciel seront les bienvenues.

Il s'agit d'un petit logiciel de retraitement 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 à retraiter 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 :

Salut,

Excellente initiative bravo !

Je ne l'ai que survolé mais je pense que comme première remarque je peux dire ceci :

il ne reconnait pas mes images .FIT (en sortie de DSS)

jpettit

Oui en effet et il ne reconnait pas les fit pas plus que les raw (propriétaires). Mais il accepte le png et les tiff (tiff à partir de AS!2 2.3.0.19. Pour DSS je ne sais pas). Ne faisant pas de CP je n'ai pas essayé avec DSS.

Bravo!

super initiative, je test ce weekend!

Attention c'est un petit logiciel.

L'idée étant qu'il puisse être facilement utilisé par des non spécialistes du traitement des images.

Son champ de possibilités est restreint par rapport à des logiciels comme PI,Iris et Siril.

Mais à titre personnel, je le préfère à registax et Iris pour les traitements planétaires. Mais je ne suis pas bien placé pour juger puisque je l'ai fais pour répondre à mes attentes. Ceci dit j'ai essayé de le rendre très simple d'utilisation.

Pour les fichiers Fits je ne trouve pas de documentation simple expliquant clairement la structure des fichiers.

Bravo pour ton initiative, et pour

Je le diffuse en OpenSource sous licence GPL

Bravo pour ton initiative, et pour

 

!

Il est développé sous Lazarus en Free Pascal.

Ca permet de limiter les adaptations entre les différentes plateformes. Mais j'ai beaucoup moins de librairies déjà faites de disponibles qui fonctionnent autant sous Linux, Windows et peut être sous Mac OS X.

Actuellement Tim offre les fonctionnalités suivantes :

- Gestion de la luminance avec contrôle de la plage de lumière, gamma

ante gamma (opposée du gamma) et mixe (un mixe paramétrable du

gamma et de l'ante gamma.

- Gestion du contraste global

- Gestion de la saturation globale

- Gestion de la saturation des couleurs teintes par teintes avec décalage

d'une teinte vers une autre

- Modification de la température des couleur

- Ajout/suppression d'une couleur

- Filtres par matrice de convolution pré paramétrées

- Masque flou

- Wavelets

- Alignement rvb.

Voici un exemple de traitement avec les wavelets sous Tim :

Voici un exemple de la soustraction d'un signal couleur (avec en prime une petite astuce pour dynamiser une image : soustraire du noir ;-) ):

Merci pour ce travail.

J'ai fait un court essais avec une image signalée dans le fil de discussion sur Siril (adresse image : http://lerautal.lautre.net/journal/AAI/pallas/somme_diximages.jpg).

Il s'agit de champs stellaires (pas la bonne cible pour TIM) et n'ai pas obtenu pour le moment un résultat convaincant... mais il faudrait lire la les exemples et la doc ce que je n'ai pas eu le temps de faire.

Un point positif relevé pendant mes essais : la double fenêtre "avant/après" est une bonne idée. Cela permet de visualiser le résultat de son travail par comparaison immédiate.

Il est développé sous Lazarus en Free Pascal.

...

Bonjour,

Cela m'aurais beaucoup intéressé de participer à ce développement mais malheureusement je ne manie convenablement que le C/C++.

Je suivrai avec très grand intérêt ce produit.

Cordialement

YAC5

Bravo, belle réalisation !

Je me suis moi-même lancé dans un logiciel de développement d'astrophoto, mais plutôt orienté ciel profond.

Le support des RAW est "facile" à mettre en place : http://www.libraw.org/

ça s'appuie sur le célèbre logiciel dcraw.

L'avantage est qu'on maitrise le dé-matriçage, et donc peut-etre plus de controle/finesse sur l'alignement, la superposition.

J'ai hâte de le tester en détail ce soir

En espérant pouvoir échanger de nombreux conseils,

Luc

Merci pour ce travail.

J'ai fait un court essais avec une image signalée dans le fil de discussion sur Siril (adresse image : http://lerautal.lautre.net/journal/AAI/pallas/somme_diximages.jpg).

Il s'agit de champs stellaires (pas la bonne cible pour TIM) et n'ai pas obtenu pour le moment un résultat convaincant... mais il faudrait lire la les exemples et la doc ce que je n'ai pas eu le temps de faire.

Un point positif relevé pendant mes essais : la double fenêtre "avant/après" est une bonne idée. Cela permet de visualiser le résultat de son travail par comparaison immédiate.

Pour du grand champ j ai deja essaye Tim. Je ne connais pas Siril suis sous windows mais j ai deja traite certaines de mes photos avec Tim. On y arrive mais pas de façon tres orthodoxe.

Hier soir j ai traité une M51 d'un copain qui a jeté 1 frame sur 2 a l empilement. Donc un rapport signal bruit pas top. J ai reussi a en tirer quelque chose. Je vais voir si je peux poster la source et le resultat cote a cote...

Pour ceux qui ne sont pas rebutés par facebook j'ai un groupe dédié à Tim. Toute labsuite de manip ayant permis d'obtenir ce résultat se trouve sur le groupe. Dès que je peux j'en fais un article sur le site web. En attendant voici l'adresse du groupe pour les curieux https://www.facebook.com/groups/311692215646315/

Pour y arriver j ai utilise la version linux de tim dans une vm virtualbox sous mageia (je ne recule pas devant la difficulté).

Sinon j'ai des idées poir ouvrir tim au grands champs et au CP. Mais je suis seul sur le coup. Donc ca va prendre un peu de temps....

Pour du grand champ j ai deja essaye Tim. Je ne connais pas Siril suis sous windows mais j ai deja traite certaines de mes photos avec Tim. On y arrive mais pas de façon tres orthodoxe.

 

Hier soir j ai traité une M51 d'un copain qui a jeté 1 frame sur 2 a l empilement. Donc un rapport signal bruit pas top. J ai reussi a en tirer quelque chose. Je vais voir si je peux poster la source et le resultat cote a cote...

 

 

Pour ceux qui ne sont pas rebutés par facebook j'ai un groupe dédié à Tim. Toute labsuite de manip ayant permis d'obtenir ce résultat se trouve sur le groupe. Dès que je peux j'en fais un article sur le site web. En attendant voici l'adresse du groupe pour les curieux https://www.facebook.com/groups/311692215646315/

 

Pour y arriver j ai utilise la version linux de tim dans une vm virtualbox sous mageia (je ne recule pas devant la difficulté).

 

Sinon j'ai des idées poir ouvrir tim au grands champs et au CP. Mais je suis seul sur le coup. Donc ca va prendre un peu de temps....

Ca y est j'ai posté l'article sur le site Web :

http://traitement-d-images-tim.webnode.fr/news/tim-essai-sur-du-cp-avec-un-faible-rapport-signal-bruit/

Bravo, belle réalisation !

Le support des RAW est "facile" à mettre en place : http://www.libraw.org/

ça s'appuie sur le célèbre logiciel dcraw.

L'auteur de Tim code en Pascal.

Certaines bibliothèques de fonctions (par exemple l'accès au format FITS via cfistsio) ne sont pas (facilement) accessibles comme en C ou en Python.

Personne ne developpe sous Mac ? Tim est développé avec Lazarus 1.2.2. Avec beaucoup de chance il suffirait de recompiler les sources Linux pour avoir une version OS X. Mais j'y crois pas trop..

Bonjour,

Ben c'est pour cette question de portage que perso je fait tout en c/c++.

Désolé.

YAC5

J'ai repris la M51 avec Tim en ayant une approche différente :

J'en conclu que Tim est apte pour le CP mais que c'est beaucoup moins évident que pour le planétaire.

Personne ne developpe sous Mac ? .

Tu poses la bonne question.

Les personnes qui achètent, plus cher, un Mac, le font parce que l'ergonomie leur convient davantage ou parce que le marketting de la marque est plus efficace que celui de la concurrence.

Le développement logiciel, en Pascal en plus, ne doit pas être leur priorité.

Même si autrefois, j'ai eu fait du Pascal UCSD sur Apple II...

Mais c'était un autre monde, bien avant les intefaces graphiques.

Tien moi aussi apple IIe basic applesoft et l'uscd Pascal....

Avec l'arrivée des Macintosh et la fermeture des becanes je suis tombé dans le monde PC avant Linux.

Et avec l'astro je suis revenu a Windows....

Tien moi aussi apple IIe basic applesoft et l'uscd Pascal....

Avec l'arrivée des Macintosh et la fermeture des becanes je suis tombé dans le monde PC avant Linux.

Et avec l'astro je suis revenu a Windows....

Windows et Mac ne passeront pas par moi :-)

J'ai appris à me passer de ce que je ne pouvais pas avoir... sans pactiser avec ce que je réprouve.

Il ne faut pas voir les choses de cette façon.

[HS]

Le standard n'est pas forcément le meilleur mais c'est le standard. Il faut faire avec.

L'important est de toucher un maximum de gens et non pas de s'enfermer dans sa chambre pour ne pas être confronté à la réalité.

Beaucoup de magnifiques projets sont morts-nés faute de n'avoir pu s'imposer comme standard. Dura lex sed lex.[/HS]

cordialement

YAC5

J'ai eu une approche assez pragmatique. Je suis allé au plus simple. As! 2 registax et iris sont des appli windows. J ai opte pour windows plutot que wine.

Pour tim plutot que proposer de l executer sous wine j ai fais une version Linux.

J aimerai faire pareil avec Mac mais n ayant pas de Mac je vais avoir un peu de mal.

Il va falloir que je retouche un peu les ecrans de Tim car le comportement de certains composants differe entre windows et linux. Du coup sous linux certains indicateurs de pixels bouches ou crames ne fonctionnent pas.

Je vais revoir ma copie pour obtenir un comportement similaire sous windows et linux. Les modifs n impactent que l ihm et pas le coeur de Tim.

L'auteur de Tim code en Pascal.

Certaines bibliothèques de fonctions (par exemple l'accès au format FITS via cfistsio) ne sont pas (facilement) accessibles comme en C ou en Python.

Je ne connais pas le pascal, mais je suis sûr qu'on peut lancer un executable (sous windows et sous linux) depuis un code un pascal : dcraw se compile en 2 lignes de commande sous linux, et presque pas plus sous windows. On obtient un executable capable de faire "convertir" des fichiers RAW en tiff. Ensuite, je n'ai pas encore eu le temps de regarder en détails, mais je suis sûr que Tim peut ouvrir des tiff.

La où ça demande un peu de travail, c'est la maitrise des options de dcraw : dcraw se lance en ligne de commandes, et les paramètres qu'on lui fournit vont gérer son comportement. Lors de l'execution, il n'y a aucune intervention humaine, tout est défini depuis les paramètres de la ligne de commande. Dcraw peut faire du dématriçage simple, faire des mises à l'échelle, des corrections gamma et même gérer du débruitage avec des darks. En revanche, il me semble que le plus simple dans le cas présent serait de faire faire uniquement le dématriçage à dcraw, eventuellement une mise à l'échelle linéaire, enregistrer en tiff 16bits, puis laisser le reste à Tim (gamma, balances de couleurs, et autres ajustages sur l'image).

Merci. Ou traduire le C en pascal s il n'y a pas 3600 fichiers. A voir. Pour les tiff, tim a certaines limitaations lies aux composants utilises. Tim lit les tifs qui sortent de the gimp as2 2.3.0.19 mais pas ceux de dss. Je ne sais pas pourquoi.

Merci. Ou traduire le C en pascal...

Le code de Dcraw a la réputation d'être hermétique.

Le temps que vous passerez à ceci (qui risque d'être peu exaltant) serait probablement mieux utilisé à coder en Pascal ce qui vous plaît et qui a motivé la réalisation de Tim.

Quand on développe "en bénévole", il faut se faire plaisir.

D'autant plus qu'il existe des "moulinettes" pour faire le travail qui ne vous emballe pas.

Le code de Dcraw a la réputation d'être hermétique.

Le temps que vous passerez à ceci (qui risque d'être peu exaltant) serait probablement mieux utilisé à coder en Pascal ce qui vous plaît et qui a motivé la réalisation de Tim.

Quand on développe "en bénévole", il faut se faire plaisir.

D'autant plus qu'il existe des "moulinettes" pour faire le travail qui ne vous emballe pas.

Je suis d'accord, j'ai jeté un oeil au code de dcraw : plus de 9000 lignes de C dans un seul et unique fichier... Je crois qu'il n'y a que l'auteur qui sait bien ce qu'il se passe dedans

mais je pense sérieusement qu'utiliser un autre executable pour faire un bout du travail doit être envisageable : il suffit de trouver une interface commune, un format de fichier (de mémoire, dcraw peut créer des tiffs 8 et 16 bits, et de ppm ?)

Pleins de logiciels fonctionnent ainsi : par exemple le processus de compilation fait souvent intervenir 'make' pour séquencer les opérations, 'gcc' pour créer le code binaire, 'ld' pour linker entre eux les différents bout de code binaire en un executable. Le tout se fait de manière transparente pour l'utilisateur.

Pour les tiff, tim a certaines limitaations lies aux composants utilises. Tim lit les tifs qui sortent de the gimp as2 2.3.0.19 mais pas ceux de dss. Je ne sais pas pourquoi.

Gimp fonctionne actuellement en 8 bits / couleur. DSS peut exporter des tiff en 16 bits et 32 bits / couleur. Ce qui pose d'ailleurs des soucis si on veut utiliser dans gimp un tiff créé depuis DSS.

Peut-être que les composants utilisés dans Tim se limitent au 8 bits / couleur ? ce serait surprennant, mais de nbreux logiciels s'en contentent.

Ce serait d'ailleurs dommage pour un logiciel de traitement de photos, qui plus est astro, car les clichés ont en général une dynamique assez faible et le surplus de quantification proposé par nos capteurs (APN, capteurs CCD dédiés) est appréciable pour offrir une marge de retouche importante.

dcraw permettant la création de fichiers PPM, peut-être existe-t-il un composant en pascal permettant d'exploiter ce format à son plein potentiel, à voir

Cela fait en effet un bail qu'on attend un Gimp 3 avec la gestion en 16 bit des couleurs...

Actuellement je suis sur gimp 2.9 (version instable) qui gère le 16bits

Et je trouve pas qu'elle plante spécialement.

Sinon si vous voulez gérer plein de types de format de fichier en 16bits sous linux, Siril le fait

Je suis d'accord, j'ai jeté un oeil au code de dcraw : plus de 9000 lignes de C dans un seul et unique fichier... Je crois qu'il n'y a que l'auteur qui sait bien ce qu'il se passe dedans

Oui...

En plus il semble avoir en partie levé le pied.

A partir de Dcraw un projet nouveau a émergé : libraw.

Voir http://www.libraw.org/

Je ne sais si c'est utilisable sous Windows ou Mac OS

Pleins de logiciels fonctionnent ainsi : par exemple le processus de compilation fait souvent intervenir 'make' pour séquencer les opérations, 'gcc' pour créer le code binaire, 'ld' pour linker entre eux les différents bout de code binaire en un executable. Le tout se fait de manière transparente pour l'utilisateur.

C'est la "philosophie UNIX" :

- un programme ne fait qu'une chose et la fait le mieux possible.

- un interpréteur de commande qui lance successivement tous les programmes nécessaires au traitement. en se débrouillant pour que les échanges de données soient possibles.

Point complémentaire :

--------------------------------

Tim est, semble-t-il, pensé "Post traitements".

Siril est très bon pour passer des RAW au FIT puis au TIFF.

Pourquoi ne pas imaginer commencer avec Siril et, pour certains traitements, reprendre les clichés sous TIM ?