Shapeworks: Verpackung von shapworkspy und Umstrukturierung von Anwendungsfällen

Erstellt am 14. Dez. 2020  ·  13Kommentare  ·  Quelle: SCIInstitute/ShapeWorks

Hilfreichster Kommentar

Schritte zur Restrukturierung:

  1. Fügen Sie alle in den Jupyter-Notebooks verwendeten Hilfsfunktionen in das ShapeWorks-Python-Modul ein.
  2. Aktualisieren Sie die Notebooks, um die Hilfsfunktionen des Python-Moduls zu verwenden.
  3. Schreiben Sie Python-Anwendungsfälle mit dem Python-Modul und den Python-API-Befehlen um, ohne GroomUtils zu verwenden.

Alle 13 Kommentare

Ab #818

Gestalten Sie die Groom-Utilitys neu, damit sie interaktiv und nicht chargenweise ausgeführt werden können.
Dadurch müssen keine Zwischenpflegedateien gespeichert werden (Ausgabe #598) und Schritte können übersprungen werden (Ausgabe #507).

Lassen Sie uns dieses Problem als übergeordnetes / treibendes Problem für das Shapeworks-Python-Packaging und das zugehörige Anwendungsfalldesign verwenden. Wir können später fokussiertere Themen hinzufügen und sie mit diesem in Verbindung bringen. Ich habe verwandte Themen entsprechend geschlossen.

@jadie1 @iyerkrithika21 Bitte treten Sie dem GC-Slot bei, um dies als Teil der Python-APIs zu diskutieren. Dies wurde auf die Tagesordnung verschoben, damit Sie bei Bedarf früher gehen können.

Ich beschäftige mich jetzt mit der Paketierung von Python-Modulen. Bitte pingen Sie mich an, wenn Sie Anregungen oder Ideen haben.

Einige Anleitungen die ich gefunden habe:

Bisher interessiere ich mich am meisten für Conda für angeblich bessere Abhängigkeitsspezifikationen, aber ich würde mich freuen, alles zu haben.
Der Grund für Conda ist, dass wir mit diesem Paket alles installieren können sollten: Befehlszeile, Python-Modul und Studio. Aber wir beginnen mit unserem Python-Modul.

Meine größte Angst sind Multi-Plattform-Probleme, die uns das Leben rauben, also werde ich versuchen, OSX zuerst zum Laufen zu bringen und dann weiterzumachen.

Die Anwendungsfälle funktionierten bei mir unter Ubuntu 18.04 nicht, ich musste:

  1. in RunUseCase.py habe ich oben sys.path.append('../../build/cmake-build-release/bin/') hinzugefügt
  2. setze die Umgebungsvariable LD_LIBRARY_PATH=../../dependencies/install/lib/ (sonst beschwert sie sich über ein fehlendes "libvcl.so")

Um die Möglichkeit zu haben, Zwischenausgaben zu speichern, können wir die Schreiboption in jede Operation anstelle einer separaten Schreib-/Speicherfunktion einschließen?
Was ich mir vorstelle ist:

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

Anstatt von

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

Dies wird wahrscheinlich einen Dateinamen als Eingabeargument benötigen
zB img.binarize(write=True, filename='blabla')

@archanasri @cchriste Gedanken?

Um die Möglichkeit zu haben, Zwischenausgaben zu speichern, können wir die Schreiboption in jede Operation anstelle einer separaten Schreib-/Speicherfunktion einschließen?
Was ich mir vorstelle ist:

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

Anstatt von

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

Image.write ist wie alles andere verkettebar. Einfach in die Kette legen, wenn
du willst es.

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

Am Di, 19. Januar 2021 um 16:58 Shireen Elhabian [email protected]
schrieb:

Dies wird wahrscheinlich einen Dateinamen als Eingabeargument benötigen
zB img.binarize(write=True, filename='blabla')

@archanasri https://github.com/archanasri @cchriste
https://github.com/cchriste Gedanken?

Um die Möglichkeit zu haben, Zwischenausgaben zu speichern, können wir die
Schreiboption innerhalb jeder Operation anstelle eines separaten Schreibens/Speicherns
Funktion?
Was ich mir vorstelle ist:

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

Anstatt von

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


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/SCIInstitute/ShapeWorks/issues/865#issuecomment-763221837 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAJT3EP3HDOHQGC54NMWSJDS2YMA7ANCNFSM4U3KV45Q
.

Image.write ist wie alles andere verkettebar. Legen Sie es einfach in die Kette, wenn Sie es wollen. img.binarize().write(<path>) img.resample().write(<path>).binarize()

Ich verstehe, dass die Schreibfunktion auch verkettebar ist; Mein Punkt mit dem Vorschlag einer Schreiboption innerhalb jeder Operation war, nur eine Funktion zu haben und das Flag zu übergeben, ob wir die Zwischenbilder speichern möchten oder nicht, und die Anwendungsfälle vereinfachen.
Beispiel-Sudo-Code:

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)

Auf diese Weise können wir vermeiden, den gleichen Codeabschnitt zu wiederholen. Ich möchte nur die Machbarkeit dieser Idee wissen.

Einer der Gründe, warum wir versuchen, das GroomUtils.py-Set von . zu demontieren
"Helfer"-Funktionen soll unseren Pflegebetrieb transparenter machen.
Ohne diese Operationen in monolithische Funktionen zu packen, flexibel gemacht
nur durch Parameterübergabe ist es viel einfacher, unkomplizierte,
verständliche Use-Case-Demonstrationen. Wenn wir nicht (viel) Verkettung verwenden
unseren Beispielen wird es sehr geradlinig sein, die Schreibfähigkeit zu vermitteln
Zwischenergebnisse, wenn es für notwendig erachtet wird. Im Moment scheinen sie alle
notwendig, weil wir Anwendungsfälle haben, die diese Ergebnisse
eine GroomUtils-Funktion führt einen (vielleicht willkürlichen) Satz von
Operationen, speichert ihr Ergebnis, dann liest die nächste Funktion diese Ergebnisse
und setzt die Verarbeitung fort.

Ich schlage vor, alles zu glätten, um zu beginnen, und für alle Anwendungsfälle nicht
nur die Ellipsoide. Ich glaube, was wir sehen werden, ist ein relativ
einfache Reihe von Operationen, die sich in bestimmten Fällen deutlich unterscheiden
(Beispiel: wenn Originalbilder "mitfahren"). Was die Nutzer wollen
von unseren Beispielen zu bekommen, ist ein viel klareres Verständnis dessen, was kann und/oder
sollten für ihre eigenen Datensätze durchgeführt werden.

Hier ist ein Beispiel dafür, was ich emulieren möchte, wenn ich ein Benutzer wäre:

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)

Wir können Beispiele für die Verkettung von Schreibvorgängen für jede dieser Operationen bereitstellen, z
B. durch Hinzufügen von .write(<path> nach einem von ihnen. Was wir nicht wollen, ist etwas
Funktion, die "einfach macht", da "es" nicht für alle gleich ist
Datensatz. Stattdessen,
Wir werden die Benutzer stärken, indem wir ihnen zeigen, dass das, was getan wird, nicht alles ist
das kompliziert und ist sehr einfach zu ändern. Anstatt ihnen eine
Blackbox-Schnittstelle mit unzähligen Parametern, gib ihnen die Schlüssel und lass
sie fahren. Ich hoffe, das hilft, die ganze Idee hinter dem Loswerden zu verdeutlichen
von GroomUtils.

Am Mo, 25. Januar 2021 um 09:49 Krithika Iyer [email protected]
schrieb:

Image.write ist wie alles andere verkettebar. Einfach in die Kette legen, wenn
du willst es. img.binarize().write()
img.resample().write().binarize()
… <#m_-7433729883366947300_>

Ich verstehe, dass die Schreibfunktion auch verkettebar ist; mein Punkt mit
eine Schreiboption innerhalb jeder Operation vorzuschlagen, war nur eine zu haben
Funktion und übergeben das Flag ob wir die Zwischenbilder speichern wollen
oder nein und vereinfachen die Anwendungsfälle.
Beispiel-Sudo-Code:

Funktion Bräutigam(write_flag):

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

Bräutigam(write_flag = True)

Bräutigam(write_flag = False)

Auf diese Weise können wir vermeiden, den gleichen Codeabschnitt zu wiederholen.


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/SCIInstitute/ShapeWorks/issues/865#issuecomment-766952032 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAJT3EJND2F3EDVU75NB6ITS3WOIPANCNFSM4U3KV45Q
.

@iyerkrithika21 @jadie1

Ich stimme @cchriste zu. Lassen Sie uns keine Verkettung verwenden, es sei denn, es ist semantisch sinnvoll (z. B. Resampling von Binärbildern), selbst in diesen Fällen müssen wir nicht jede Zwischenausgabe dieses Resampling-(Kombi-)Schritts schreiben. Lassen Sie uns Anwendungsfälle leicht verständlich, selbstdokumentiert und für Benutzer leicht anzupassen und anzupassen machen.

Das Schreiben (insbesondere vorübergehend zum Debuggen) von Bildern ist ein großartiges Beispiel für
wenn eine Verkettung sinnvoll ist.

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

Wenn es jedoch ein wichtiger Schritt ist, ist es möglicherweise besser, ihn auf seine Seite zu legen
eigene Zeile mit Kommentar.

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

Am Mo, 25. Januar 2021 um 10:34 Shireen Elhabian [email protected]
schrieb:

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

Ich stimme @cchriste https://github.com/cchriste zu . Lass uns nicht benutzen
Verkettung, es sei denn, es ist semantisch sinnvoll (z. B. Resampling
Binärbilder), auch für diese Fälle müssen wir nicht alle schreiben
Zwischenausgabe dieses Resampling-(Kombi-)Schritts. Lass uns Anwendungsfälle machen
leicht verständlich, selbstdokumentiert und für Benutzer leicht anzupassen und anzupassen.


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/SCIInstitute/ShapeWorks/issues/865#issuecomment-766983878 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAJT3EKKARLKY4VKBRPHJWLS3WTSNANCNFSM4U3KV45Q
.

Schritte zur Restrukturierung:

  1. Fügen Sie alle in den Jupyter-Notebooks verwendeten Hilfsfunktionen in das ShapeWorks-Python-Modul ein.
  2. Aktualisieren Sie die Notebooks, um die Hilfsfunktionen des Python-Moduls zu verwenden.
  3. Schreiben Sie Python-Anwendungsfälle mit dem Python-Modul und den Python-API-Befehlen um, ohne GroomUtils zu verwenden.

Denken Sie daran, dass wir einen python_module-Zweig haben, in dem dies bereits gestartet wurde. Es wurde seit einer Minute nicht zusammengeführt, aber halte uns auf dem Laufenden, wenn jemand das anpackt. Es steht ganz oben auf meiner Prioritätenliste.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen