scipion tests singleparticle.tests.test_protocols_classic_workflow --run --log run.log
This takes 5min to run.
License: GNU General Public License v3.0
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:
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
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.
Orthoslicer | Annotations par box | |
---|---|---|
LabKit (se base sur BigDataViewer) | non | non |
Weka | non | non |
ImageJ | Oui | oui, mais pas en ortho. Impossible de rajouter un plugin d'annotation |
ICY (déconseillé par Denis) | Oui | plugin existant |
napari | Non mais plugin | Non mais plugin |
ITK | oui? | ? |
3DSlicer | oui | oui |
NiBabel | oui | non |
Imaris | oui | ? |
Installation napari très facile dans un env Python, cross-platform, en développement actif.
Plugins pour notre besoin :
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 :
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).
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.
Développer une interface de zéro. Ce serait dommage sachant tout le travail qui a déjà été réalisé dans napari
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
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:
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
Un protocole d'import de PSF devra être fait
voir /home/plumail/bug-blinddeconv
Dans le manual picking:
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.
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:
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:
callback
de Form.addParam
. Pas documenté, même Pablo n'a pas l'air de savoir comment ça marche...Presque tous.
ProtSPFluoPickingTrain
, ProtSPFluoPickingTrain
, ProtSPFluoAbInitio
. Ajouter un champs avec une combobox au lieu d'un champs texte.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:
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.
See #2
SetOfCoordinates3D
SetOfFluoImages
SetOfParticles
AverageParticle
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.