jplumail / scipion-fluo-singleparticle Goto Github PK

Prend en entrée un SetOfParticles qui contient des particules et leurs orientations/translations.

Renvoie une AverageParticle.

Ce protocole devra gérer le multi-canal

Plusieurs options:

• napari avec slider faire défiler particules
• napari grid mode: particules stockées dans une image avec N canaux. Grid mode permet de visualiser en mosaique
• dans scipion, fenêtre avec liste à défiler avec prévisualisation. A voir comment prévisualiser

Le besoin

Pour ne plus reposer sur EMAN (voir #3) et être cross-platform, il faut développer une nouvelle interface de picking.

Notre besoin pour l'interface de picking : vue ortho (vues XY, XZ, YZ en côte à côte) + annotations bounding box 3D

Revue de logiciels existants

• Which software are used for ground-truth annotation on microscopic image samples? : Ilastik, LabKit, WEKA, Qupath and others

• LabKit se base sur BigDataViewer . Cross-platform, pas de vue ortho. La plupart des logiciels propose des vues 2D avec slider pour naviguer sur des images 3D+. La vue ortho est assez rare.

Focus sur Napari

Installation napari très facile dans un env Python, cross-platform, en développement actif.
Plugins pour notre besoin :

• https://github.com/gatoniel/napari-3d-ortho-viewer : assez buggé tout de même
• https://github.com/bauerdavid/napari-bbox

Pour l'ortho-viewer pas facile de faire qqchose de propre : il faudrait modifier napari en profondeur pour faire un bon viewer ortho (voir les issues github https://forum.image.sc/t/napari-visualization-in-3-planes/57768/2). Une issue github existe sur la réalisation d'un Multicanvas viewer, c'est un gros changement ça implique de repenser l'interface utilisateur. Un certain melonora est sur le coup...

Ce que je pourrais faire :

1. M'impliquer dans le développement du Multicanvas viewer de napari, mais peut être plus difficile qu'il n'y paraît (je ne connais pas bien le code source de napari).

2. Forker napari et implémenter moi-même la feature de manière non optimale. Si les devs de napari implémente l'orthoviewer, on pourra reswitcher sur leur branche.

3. Développer une interface de zéro. Ce serait dommage sachant tout le travail qui a déjà été réalisé dans napari

4. paraît raisonnable. Potentiellement 1. si j'ai du temps et si je prends bien en main le code source de napari.

Créer un protocol d'estimation de la PSF

• Widefield: code Java Epidemic
• confocal: petite modif de widefield
• autre: code Ferréol

Les biologistes travaillent sur Windows, il faudrait adapter scipion à Windows, voir à du cross-platform.

Comme l'interface graphique de scipion-app est basé sur tkinter, cross-platform nativement, pas de problème. Pour ce qui y est de la gestion interne de Scipion, il y a sûrement un peu de travail.

Le protocole ProtSPFluoPickingNapari n'est pas interactif pour le moment. Il faudrait pouvoir revenir sur un picking déjà fait pour ajouter/supprimer des particules.

S'inspirer de : https://github.com/scipion-em/scipion-em-emantomo/blob/devel/emantomo/protocols/protocol_tomo_boxing.py

Requiert:

• #19

1-2min pour extraire 200 particules de 2 images 1024x1024x128.

Le protocole d'import utilisé actuellement est le ProtImportTomograms de scipion-em-tomo. Il lit des fichiers MRC.

Le nouveau protocole devra

• importer plusieurs images TIF
• avoir en ouput une classe spécifique à la fluo
• associer des paramètres à cette classe comme la taille des voxels

Un protocole d'import de PSF devra être fait

• définir les paramètres associés à la PSF (taille de voxel)
• créer une classe PSF

voir /home/plumail/bug-blinddeconv

Dans le manual picking:

• ouvrir une image
• régler le diamètre
• fermer l'image
• rouvrir une autre

• mauvais diamètre !

Au lieu des angströms

L'ajout de dépendances pour éviter de s'appuyer sur Xmipp (voir la PR #1) alourdit l'environnement Scipion qui doit rester léger pour que tous les plugins communiquent facilement entre eux.

Il faudrait donc déplacer du code vers https://github.com/jplumail/SPFluo_stage_reconstruction_symmetryC.

C'est un peu embêtant car il faut pouvoir communiquer entre les deux environnements Python. Voici la manière standard de faire dans Scipion :

L'utilisateur veut lire un fichier Tiff. Il renseigne le chemin dans Scipion. Scipion exécute une commande qui lit le fichier dans un autre environnement Python et lui retourne sous la forme d'un fichier texte les informations demandées (métadonnées...).

C'est beaucoup plus compliqué que ce qu'on a actuellement mais ça a l'avantage de séparer la librairie d'image et l'environnement Scipion.

Plan d'action

Il faut enlever aicsimageio des dépendances.

aicsimageio contient tout ce qui permet de lire des images. Réimplémenter une sorte d'ImageHandler qui sert à Scipion de communiquer avec Xmipp mais avec notre propre librairie d'image qui tournerait dans un autre env Python. Comment communiquer ? La question est ouverte

https://en.wikipedia.org/wiki/Inter-process_communication

Les socket paraissent une bonne solution. Ils sont cross-platform de base, sont inclus dans Python.

Également possible de passer par le système de fichiers.

Pour l'instant je n'arrive pas à lancer de tests... Une fois fait, il faudrait:

• créer des tests qui couvrent suffisamment le code (couvrent partiellement import + ab initio + align axis + refinement)
• créer systématiquement des tests à chaque PR
• lancer tous les tests automatiquement à chaque PR

L'objet SamplingRate est utilisé comme le voxel size, qui est l'inverse du sampling rate...

Besoin de renommer ça

Suit #20

Le protocole permettant le downsampling renvoie des images qui n'ont pas de lien dans la DB avec les images sources.

Cela pose problème quand on veut revenir dans notre pipeline à des images hautes résolutions.

Exemple du protocole d'extraction de particules.

Pablo m'a indiqué https://github.com/scipion-em/scipion-em/blob/bea520ea146a6cc9fda08d06f69691a906d9eddb/pwem/protocols/protocol_extract_coordinates.py

A creuser

Quand un protocole est initialisé, l'utilisateur doit remplir des champs. Parfois, certains champs peuvent être remplis automatiquement.

Il y aurait plusieurs manières de faire:

• Créer un wizard

• Utiliser le paramètre callback de Form.addParam. Pas documenté, même Pablo n'a pas l'air de savoir comment ça marche...

Protocoles qui pourraient bénéficier de l'amélioration

Presque tous.

• les protocoles mono-canaux: ProtSPFluoPickingTrain, ProtSPFluoPickingTrain, ProtSPFluoAbInitio. Ajouter un champs avec une combobox au lieu d'un champs texte.
• les protocoles d'import: ProtFluoImportFiles. Pouvoir remplir automatiquement les champs d'acquisition en lisant l'image dès que l'utilisateur la renseigne.

Devrait simplement pouvoir ouvrir chaque image du Set dans des layers napari différents.

Si on détecte plusieurs canaux dans l'image, il faut pouvoir:

• choisir un canal si besoin pour les protocoles mono-canaux. Fait pour la reconstruction ab-initio #25. Fait pour le raffinement aussi.
• pouvoir appliquer à tous les canaux des transformations obtenues sur un canal #28. reconstruction_L2 multicanal ?

Il n'y a pour l'instant aucun moyen de visualiser les objets Fluo dans Scipion. Il est prévu d'avoir l'option de visualiser dans ImageJ. napari serait la deuxième option.

ImageJ

See #2

• SetOfCoordinates3D
• SetOfFluoImages
• SetOfParticles
• AverageParticle

Napari

• SetOfCoordinates3D #17
• #33
• #27
• AverageParticle #22

Il faudrait que le SetOfParticles renvoyé contiennent les orientations des particules.

Il faudra s'assurer que les conventions sont les bonnes.

En lien avec #28.

Le package repose actuellement sur Xmipp pour l'import /export des images et EMAN pour le picking.

Retirer ces dépendances est nécessaire pour rendre le projet cross-platform: Xmipp et EMAN tournent seulement sur Linux.

Sous-tâches :

• #1
• #6

Bug observé par Thibaut. A reproduire.

Actuellement, lorsque l'utilisateur ouvre une 2ème image dans la fenêtre, la taille des cercles est remise à 10.

Il faut qu'elle soit remise à la taille spécifiée lors du traitement de la 1ère image.

Prend en entrée un SetOfCoordinates3D, renvoie un SetOfParticles.

Les particules seraient extraites des SetOfImages de l'attribut Precedents du SetOfCoordinates3D.

Problème: il peut s'agir d'un SetOfImages dégradé, qui a été downsamplé. Or on voudrait l'image originale!

Une solution serait d'ajouter l'entrée SetOfImages, l'utilisateur pourrait alors spécifier ses images non downsamplées. Viendrait alors un autre problème: ces images n'ont pas le même ImgId que ceux contenus dans les coordonnées ! Il faudrait créer une nouvelle clé qui réunit les images de différentes résolutions ?

La visualisation des images avant picking se fait actuellement avec les viewers de la classe SetOfTomograms: Imod, Chimera, Eman.

ImageJ est plus adapté dans notre cas. Il faudra créer un viewer associé à classe adaptée aux volumes Fluo qui lance ImageJ.

J'ai envoyé un message sur le discord Scipion