Shapeworks: Emballage shapworkspy et restructuration des cas d'utilisation

Du #818

Repensez les utilitaires de groom afin qu'ils puissent être exécutés de manière interactive plutôt que par lots.
Cela fera en sorte que les fichiers de nettoyage intermédiaires n'auront pas à être enregistrés (problème n° 598) et les étapes pourront être ignorées (problème n° 507)

Utilisons ce problème comme problème parent/moteur pour l'emballage python de shapeworks et la conception de cas d'utilisation associée. Nous pouvons ajouter des problèmes plus ciblés plus tard et les relier à celui-ci. J'ai fermé les problèmes liés en conséquence.

@jadie1 @iyerkrithika21, veuillez rejoindre le slot GC pour en discuter dans le cadre des API python. A déplacé cela sur l'ordre du jour pour vous permettre de partir plus tôt si nécessaire.

J'étudie maintenant l'empaquetage du module Python. S'il vous plaît ping moi si vous avez des suggestions ou des pensées.

Quelques instructions que j'ai trouvées :

• pip : https://python-packaging-tutorial.readthedocs.io/en/latest/setup_py.html
• ...et : https://packaging.python.org/tutorials/packaging-projects/
• conda : https://python-packaging-tutorial.readthedocs.io/en/latest/conda.html
• roues : https://realpython.com/python-wheels/

Jusqu'à présent, je suis plus intéressé par conda pour une spécification de dépendance réputée meilleure, mais je serais heureux d'avoir n'importe quoi.
La raison de conda est que nous devrions pouvoir tout installer avec ce package : ligne de commande, module python et studio. Mais nous allons commencer par notre module python.

Ma plus grande crainte, ce sont les problèmes multiplateformes qui nous gâchent la vie, alors je vais essayer de faire fonctionner OSX en premier et partir de là.

Les cas d'utilisation ne fonctionnaient pas pour moi sur Ubuntu 18.04, je devais :

1. dans RunUseCase.py, j'ai ajouté en haut sys.path.append('../../build/cmake-build-release/bin/')
2. définissez la variable d'environnement LD_LIBRARY_PATH=../../dependencies/install/lib/ (sinon, il se plaint d'un "libvcl.so" manquant)

Pour avoir la possibilité d'enregistrer des sorties intermédiaires, pouvons-nous inclure l'option d'écriture dans chaque opération plutôt qu'une fonction d'écriture/sauvegarde distincte ?
Ce que j'imagine c'est :

img.binarize(write=False)
img.resample(write=True).binarize(write=True)

À la place de

img.binarize()
img.write()
img.resample()
img.write()

Cela aura probablement besoin d'un nom de fichier comme argument d'entrée
par exemple, img.binarize(write=True, filename='blabla')

@archanasri @cchriste pensées?

Pour avoir la possibilité d'enregistrer des sorties intermédiaires, pouvons-nous inclure l'option d'écriture dans chaque opération plutôt qu'une fonction d'écriture/sauvegarde distincte ?
Ce que j'imagine c'est :

img.binarize(write=False)
img.resample(write=True).binarize(write=True)

À la place de

img.binarize()
img.write()
img.resample()
img.write()

Image.write est chaînable comme tout le reste. Il suffit de le mettre dans la chaîne si
tu le veux.

img.binarize().write(<path>)
img.resample().write(<path>).binarize()

Le mardi 19 janvier 2021 à 16h58 Shireen Elhabian [email protected]
a écrit:

Cela aura probablement besoin d'un nom de fichier comme argument d'entrée
par exemple, img.binarize(write=True, filename='blabla')

@archanasri https://github.com/archanasri @cchriste
https://github.com/cchriste pensées?

Pour avoir la possibilité de sauvegarder les sorties intermédiaires, pouvons-nous inclure les
option d'écriture dans chaque opération plutôt qu'une écriture/sauvegarde séparée
fonction?
Ce que j'imagine c'est :

img.binarize(write=False)
img.resample(write=True).binarize(write=True)

À la place de

img.binarize()
img.write()
img.resample()
img.write()

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/865#issuecomment-763221837 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJT3EP3HDOHQGC54NMWSJDS2YMA7ANCNFSM4U3KV45Q
.

Image.write est chaînable comme tout le reste. Mettez-le simplement dans la chaîne si vous le voulez. img.binarize().write(<path>) img.resample().write(<path>).binarize()
…

Je comprends que la fonction d'écriture est également chaînable ; mon but en suggérant une option d'écriture dans chaque opération était d'avoir une seule fonction et de passer le drapeau si nous voulons enregistrer les images intermédiaires ou non et simplifier les cas d'utilisation.
Exemple de code sudo :

function groom(write_flag):
    img.binarize(write = write_flag).resize(write = write_flag).crop(write=write_flag)
groom(write_flag = True)
groom(write_flag = False)

De cette façon, nous pouvons éviter de répéter le même morceau de code. Je veux juste savoir la faisabilité de cette idée.

L'une des raisons pour lesquelles nous essayons de démanteler l'ensemble de GroomUtils.py de
fonctions "d'aide" est de rendre nos opérations de toilettage plus transparentes.
Sans conditionner ces opérations en fonctions monolithiques, rendues flexibles
uniquement en passant des paramètres, il est beaucoup plus facile de créer directement,
démonstrations de cas d'utilisation compréhensibles. Si nous n'utilisons pas (beaucoup) de chaînage dans
nos exemples, il sera très simple de transmettre la capacité d'écrire
résultats intermédiaires lorsque cela est jugé nécessaire. En ce moment, ils semblent tous
nécessaire car nous avons des cas d'utilisation qui nécessitent ces résultats puisque
une fonction GroomUtils exécute un ensemble (peut-être arbitraire) de
opérations, enregistre son résultat, puis la fonction suivante lit ces résultats
et continue le traitement.

Je suggère de tout aplatir pour commencer, et pour tous les cas d'utilisation, non
juste les ellipsoïdes. Je crois que ce que nous verrons est relativement
ensemble simple d'opérations qui diffère notablement pour certains cas
(ex : lorsque les images originales sont « accompagnées de la balade »). Ce que les utilisateurs vont
obtenir de nos exemples est une compréhension beaucoup plus claire de ce qui peut et/ou
devrait être fait pour leurs propres ensembles de données.

Voici un exemple de ce que je voudrais émuler si j'étais un utilisateur :

for img in images:

# since we're starting with fuzzy data, we first need to ensure it's a
binary (black and white) image in order to <explain>
img.binarize()

# next, we must ensure images all have the same logical dimensions since
<explain>
img.resize()

# now we'll crop these images using the bounds we computed earlier so they
all encompass the data without leftover space (since it can be costly and
pointless to compute)
img.crop(bounds)

Nous pouvons fournir des exemples d'écriture de chaînage à l'une de ces opérations, telles que
comme en ajoutant .write(<path> après l'un d'eux. Ce que nous ne voulons pas, c'est
fonction qui "fait juste" puisque "ce" n'est pas le même pour chaque
base de données. Au lieu,
nous allons responsabiliser les utilisateurs en leur montrant que ce qui est fait n'est pas tout
que compliqué et est très facile à changer. Plutôt que de leur donner un
interface boîte noire avec un zillion de paramètres, donnez-leur les clés et laissez
eux conduisent. J'espère que cela aide à clarifier toute l'idée derrière se débarrasser
de GroomUtils.

Le lundi 25 janvier 2021 à 9h49 Krithika Iyer [email protected]
a écrit:

Image.write est chaînable comme tout le reste. Il suffit de le mettre dans la chaîne si
tu le veux. img.binarize().write()
img.resample().write().binarize()
… <#m_-7433729883366947300_>

Je comprends que la fonction d'écriture est également chaînable ; mon point avec
suggérer une option d'écriture au sein de chaque opération était d'avoir un seul
fonction et passer le drapeau si nous voulons enregistrer les images intermédiaires
ou non et simplifier les cas d'utilisation.
Exemple de code sudo :

fonction groom(write_flag):

img.binarize(write = write_flag).resize(write = write_flag).crop(write=write_flag)

marié(write_flag = True)

marié(write_flag = False)

De cette façon, nous pouvons éviter de répéter le même morceau de code.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/865#issuecomment-766952032 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJT3EJND2F3EDVU75NB6ITS3WOIPANCNFSM4U3KV45Q
.

@iyerkrithika21 @jadie1

Je suis d'accord avec @cchriste. N'utilisons pas le chaînage à moins que cela ne soit sémantiquement raisonnable (par exemple, le rééchantillonnage d'images binaires), même dans ces cas, nous n'avons pas à écrire chaque sortie intermédiaire de cette étape de rééchantillonnage (combo). Rendons les cas d'utilisation faciles à suivre, auto-documentés et faciles à adapter et à personnaliser pour les utilisateurs.

L'écriture (en particulier temporairement pour le débogage) d'images est un excellent exemple de
lorsque l'enchaînement est raisonnable.

# let's see what happened
img.operation(...) -> img.operation(...).write(<path>)

Alors que, lorsqu'il s'agit d'une étape importante, il vaut peut-être mieux la mettre sur son
propre ligne avec un commentaire.

...
# now let's write the results
img.write(<path>)

Le lundi 25 janvier 2021 à 10h34 Shireen Elhabian [email protected]
a écrit:

@iyerkrithika21 https://github.com/iyerkrithika21 @jadie1
https://github.com/jadie1

Je suis d'accord avec @cchriste https://github.com/cchriste . n'utilisons pas
chaînage à moins que cela ne soit sémantiquement raisonnable (par exemple, le rééchantillonnage
images binaires), même pour ces cas, nous n'avons pas à écrire chaque
sortie intermédiaire de cette étape de rééchantillonnage (combo). Faisons des cas d'utilisation
facile à suivre, auto-documenté et facile à adapter et à personnaliser pour les utilisateurs.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/865#issuecomment-766983878 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJT3EKKARLKY4VKBRPHJWLS3WTSNANCNFSM4U3KV45Q
.

Étapes de la restructuration :

1. Incluez toutes les fonctions d'assistance utilisées dans les blocs-notes Jupyter dans le module python ShapeWorks.
2. Mettez à jour les notebooks pour utiliser les fonctions d'assistance du module python.
3. Réécrivez les cas d'utilisation de python à l'aide du module python et des commandes API python sans utiliser GroomUtils.

N'oubliez pas que nous avons une branche python_module dans laquelle cela a déjà commencé. Il n'a pas été fusionné depuis une minute, mais tenez-nous au courant si quelqu'un s'attaque à cela. C'est en haut de ma liste de priorités.