Am 05.09.2026 führt die offizielle QuPath-Seite v0.7.0 als aktuelle stabile Version und bietet macOS-Pakete für Intel und Apple Silicon an; das Apple-Silicon-Paket ist dort als Beta gekennzeichnet (QuPath-Website). Daraus folgt für diese Woche: Laden Sie auf einem Apple-Silicon-Mac zuerst arm64, testen Sie aber sofort Ihre echten Schnittformate. Sobald die Bio-Formats-Kette oder ein wichtiges CZI scheitert, wechseln Sie für diesen Arbeitsschritt zur Intel-Version unter Rosetta. Bei gemischten Datenquellen installieren Sie beide Versionen getrennt.

Dieser Leitfaden ist für drei Gruppen gedacht:

  • Pathologie- und Biomedizin-Studierende, die kostengünstig ganze Objektträger bearbeiten müssen.
  • Bildanalyse-Teams mit mehreren Mikroskop- und Scannerformaten.
  • Technische Betreuung in Hochschullaboren, die eine reproduzierbare QuPath-Umgebung auf einem lokalen oder entfernten Mac bereitstellen müssen.
01

Architekturstatus und Auswahlkriterien

Die Prozessorarchitektur ist der erste Prüfpunkt, aber kein ausreichendes Auswahlkriterium. Auf einem Apple-Silicon-Gerät ist arm64 der naheliegende Startpunkt. Für die langfristige Entscheidung zählen jedoch die tatsächlich verwendeten Bildformate, Erweiterungen, Skripte und Exportwege.

Die stabile QuPath-Version 0.7.0 stellt beide macOS-Varianten bereit. In der offiziellen Installationsdokumentation wird die Apple-Silicon-Ausgabe als Beta beschrieben. Außerdem weist die Dokumentation auf Einschränkungen bei der Unterstützung bestimmter Bio-Formats-Dateien hin (stabile Installationsdokumentation). QuPath 0.8.0 darf deshalb nicht als bereits verfügbare stabile Lösung eingeplant werden. Ein Entwicklungsstand ist kein belastbarer Ersatz für eine validierte Laborumgebung.

Sollten Sie auf einem Apple-Silicon-Mac arm64 oder Intel herunterladen?
Beginnen Sie mit arm64, wenn Ihre wichtigsten Formate und Erweiterungen in dieser Variante funktionieren. Halten Sie Intel bereit, wenn Ihre Daten auf eine Bio-Formats-Lesekette angewiesen sind, die arm64 derzeit nicht vollständig abdeckt. Die Intel-Version kann auf Apple Silicon über Rosetta ausgeführt werden; dadurch erhalten Sie einen zweiten Prüfpfad, aber keine Garantie, dass jedes externe Plugin oder Skript unverändert arbeitet.

Benötigt die Intel-Version auf Apple Silicon Rosetta?
Ja, für Intel-Programme auf Apple-Silicon-Macs wird Rosetta benötigt. Apple beschreibt Rosetta als Kompatibilitätsschicht für Intel-Anwendungen auf Apple-Silicon-Geräten (Apple-Dokumentation zu Rosetta). Prüfen Sie nach der Installation den Namen der Anwendung und ihre Architektur. Sonst testen Sie möglicherweise Intel und arm64, halten aber die Ergebnisse für eine einzige QuPath-Installation.

Für eine saubere Prüfung sollten Sie die beiden Ausgaben nicht über dieselbe Projektkopie verändern. Verwenden Sie eine schreibgeschützte Ausgangskopie und jeweils ein separates Arbeitsverzeichnis. So vermeiden Sie, dass ein Projektwechsel, eine automatisch gespeicherte Einstellung oder ein verändertes Messschema den Vergleich verfälscht.

02

Formatmatrix und Bio-Formats-Grenzen

Bei ganzen Objektträgern ist die Dateiendung allein kein ausreichendes Kompatibilitätskriterium. Entscheidend sind unter anderem Scannerquelle, Container, Kompression, Pyramidenstruktur, Kanalaufbau und der verwendete Lesepfad. Ein gewöhnliches TIFF kann sich problemlos öffnen, während ein für Ihr Labor wichtiges CZI mit anderer Kompression scheitert.

Die offizielle Formatanleitung beschreibt die von QuPath unterstützten Bildtypen und die Rolle von Bio-Formats (QuPath-Formatübersicht). Daraus sollten Sie vor dem Download eine kleine, aber repräsentative Testmenge ableiten:

  1. Einen typischen vollständig gescannten Objektträger.
  2. Eine Datei mit mehreren Kanälen.
  3. Eine Datei mit der im Labor häufigsten Kompression.
  4. Eine CZI-Datei, falls dieses Format in Ihrem Projekt vorkommt.
  5. Eine Datei, deren Metadaten für Maßstab, Kanalnamen oder Bildhierarchie benötigt werden.

Warum lassen sich manche CZI-Schnitte mit arm64 nicht öffnen?
Der kritische Punkt ist nicht „CZI“ als bloße Endung, sondern die konkrete Kombination aus Dateistruktur, Kompression und Bio-Formats-Unterstützung. Die QuPath-Dokumentation nennt eine Grenze der Bio-Formats-Unterstützung auf Apple Silicon. Dazu können bestimmte JPEG-XR-komprimierte CZI-Dateien gehören. Behandeln Sie einen solchen Fall als Format- und Backend-Problem, nicht als allgemeines Urteil über alle CZI-Dateien.

Für jedes Testobjekt müssen Sie dieselben vier Ergebnisse prüfen:

  • Öffnet QuPath die Datei ohne Fehlermeldung?
  • Funktionieren kontinuierliches Zoomen und die Auswahl verschiedener Auflösungsebenen?
  • Werden Kanäle, Farben und Maßstab korrekt angezeigt?
  • Sind relevante Metadaten vorhanden und plausibel?

Ein Fehlschlag bei einem Kernformat beendet die Entscheidung für „nur arm64“. Dann haben Sie drei belastbare Optionen: Intel unter Rosetta, eine getrennte Doppelinstallation oder eine Änderung des vorgelagerten Konvertierungsprozesses. Letzteres sollte nur erfolgen, wenn Sie nachweisen können, dass die Konvertierung keine für die Analyse benötigten Informationen entfernt.

03

Messbare Arbeitsabläufe statt Startzeit

Die Frage „Welche Version ist schneller?“ ist für ein Forschungslabor zu grob. Ein schneller Programmstart hilft wenig, wenn das Öffnen eines repräsentativen Objektträgers, die Kanaldarstellung oder ein Skriptlauf instabil ist. Vergleichen Sie daher denselben Arbeitsablauf auf demselben Remote-Mac oder derselben lokalen Hardware.

Die Testreihenfolge sollte unverändert bleiben:

  1. Öffnen Sie dieselbe Kopie der Testdatei.
  2. Warten Sie auf die vollständige Anzeige der niedrigsten Übersichtsebene.
  3. Zoomen Sie nacheinander in dieselben Regionen.
  4. Erstellen Sie dieselbe Annotation.
  5. Starten Sie dieselbe Detektionsvorschau.
  6. Wechseln Sie in dasselbe Projekt.
  7. Exportieren Sie dasselbe Ergebnis.

Notieren Sie nicht nur die Dauer. Bewerten Sie auch Fehlermeldungen, Darstellungsfehler, eingefrorene Ansichten, falsche Kanalnamen und verlorene Projektzustände. Eine belastbare Entscheidung lautet deshalb nicht „arm64 ist schneller“, sondern etwa: „arm64 erfüllt den vollständigen Arbeitsablauf mit den geprüften Formaten; Intel bleibt für CZI-Dateien mit JPEG-XR-Kompression erforderlich.“

Bei einer Remote-Sitzung müssen Sie zusätzlich die Netzwerkstrecke isolieren. Die Bilddaten werden auf dem Host gelesen und verarbeitet. Die Benutzeroberfläche wird dagegen als Bildstrom an Ihren Rechner übertragen. VNC-Verzögerung ist deshalb kein Beweis für eine langsame QuPath-Berechnung.

Achtung: Prüfen Sie die Interaktion zuerst mit einer kleinen, vollständig freigegebenen Testdatei. Eine ruckelnde Remote-Anzeige kann durch Netzwerklatenz, Bildschirmkodierung oder eine überlastete Sitzung entstehen. Wiederholen Sie denselben Schritt lokal oder mit einer zweiten Verbindung, bevor Sie die Architektur bewerten.

04

Erweiterungen, Skripte und Reproduzierbarkeit

Ein QuPath-Projekt ist nicht nur eine Bilddatei. Für die Migration müssen Sie mindestens diese Bestandteile erfassen:

  • installierte Erweiterungen,
  • Groovy-Skripte,
  • Modelle und Modellpfade,
  • externe Kommandozeilenwerkzeuge,
  • Projektordner und Zugriffsrechte,
  • Tabellenstruktur der Messwerte,
  • Exportformate und Dateinamenregeln.

Prüfen Sie jede Erweiterung in beiden Versionen. Eine Installation ist erst dann als erfolgreich bewertet, wenn die Erweiterung geladen wird und die für Ihr Projekt benötigte Funktion tatsächlich ausführbar ist. Verlassen Sie sich nicht auf den bloßen Eintrag in einem Menü.

Für Skripte verwenden Sie eine minimale, reproduzierbare Aufgabe: Projekt öffnen, eine definierte Region auswählen, Messungen erzeugen und eine Ergebnisdatei exportieren. Vergleichen Sie anschließend die Spaltennamen, Objektanzahl, Klassennamen und Dateipfade. Wenn ein Skript nur in einer Architektur läuft, dokumentieren Sie die Abhängigkeit und lassen Sie die funktionierende Version für diesen Prozess bestehen.

Die offiziellen QuPath-Dokumente beschreiben die Kommandozeilennutzung und liefern damit einen prüfbaren Ansatz für automatisierte Abläufe (QuPath-Kommandozeilendokumentation). Wenn Sie Deep-Learning-Modelle oder Erweiterungen einsetzen, prüfen Sie zusätzlich die dokumentierten Laufzeitvoraussetzungen. Die QuPath-Dokumentation zu DJL und Deep Learning ist dafür eine relevante Quelle (DJL- und Deep-Learning-Dokumentation).

Eine GPU-Angabe allein entscheidet ebenfalls nicht über den Erfolg. QuPath dokumentiert die GPU-Unterstützung getrennt von den Dateiformaten (offizielle GPU-Hinweise). Wenn Ihr Workflow hauptsächlich vom Lesen großer Schnitte, von Bio-Formats oder von einem Skript abhängt, ist eine theoretische GPU-Unterstützung kein Ersatz für einen vollständigen Abnahmetest.

05

Remote-Zugriff, Datenschutz und Datenwege

Ein entfernter Mac ist für die Architekturprüfung interessant, weil Sie arm64 und Intel testen können, ohne sofort Hardware für das Labor anzuschaffen. Der Nutzen entsteht aber nur, wenn Datenzugriff und Rückgabe kontrolliert sind.

Prüfen Sie den Ablauf mit anonymisierten oder synthetischen Beispielen:

  1. Laden Sie eine freigegebene Testdatei über den vorgesehenen Übertragungsweg hoch.
  2. Legen Sie Projektdatei, Bilddaten und Skripte in getrennten Verzeichnissen ab.
  3. Testen Sie, ob QuPath die benötigten Ordner lesen und schreiben darf.
  4. Trennen Sie die Remote-Sitzung kontrolliert.
  5. Verbinden Sie sich erneut und prüfen Sie den Projektzustand.
  6. Exportieren Sie Messungen und Annotationen.
  7. Laden Sie die Ergebnisse auf einen freigegebenen lokalen Speicher zurück.
  8. Löschen Sie temporäre Kopien nach den Regeln Ihres Instituts.

Bei patientenbezogenen oder anderweitig geschützten Pathologiedaten müssen Sie die Freigabe durch Hochschule, Klinik oder Datenschutzbeauftragte klären. DSGVO-Konformität folgt nicht automatisch daraus, dass eine Anwendung wissenschaftlich genutzt wird. Prüfen Sie Speicherort, Zugriffskonten, Protokollierung, Aufbewahrung, Löschung und Übertragungsweg. Verwenden Sie für den ersten Architekturvergleich ausschließlich Daten, deren Nutzung für diesen Zweck genehmigt ist.

Für die Remote-Interaktion sollten Sie getrennt dokumentieren:

  • Anzeigeverzögerung beim Zoomen,
  • Stabilität der Verbindung,
  • Verhalten nach einer Unterbrechung,
  • Vollständigkeit der Ergebnisdatei,
  • Möglichkeit, die Sitzung ohne offene Zugangsdaten zu übergeben.

Damit unterscheiden Sie einen QuPath-Fehler von einem Zugriffs- oder Netzwerkproblem. Die Trennung ist besonders wichtig, wenn mehrere Personen im Labor dieselbe Umgebung nutzen.

06

Vergleich der drei Betriebswege

Die folgende Matrix ist kein Ersatz für einen Test. Sie hilft Ihnen, die Konsequenz eines Testergebnisses festzuhalten.

Betriebsweg Geeignet, wenn Hauptrisiko Abnahmekriterium
Nur arm64 Kernformate, Erweiterungen und Skripte funktionieren vollständig Beta-Hinweise und Bio-Formats-Grenzen werden übersehen Alle repräsentativen Dateien öffnen, zoomen, messen und exportieren korrekt
Nur Intel unter Rosetta Ein wichtiges Format oder Plugin auf arm64 scheitert, Intel aber funktioniert Zusätzliche Kompatibilitätsschicht und getrennte Pflege Rosetta startet QuPath stabil, Projekt- und Skripttest bestehen
Beide Versionen getrennt Formate, Mitarbeitende oder Skripte unterschiedliche Wege erfordern Falsche Version wird geöffnet oder Projekte werden vermischt App-Namen, Arbeitsordner und Testergebnisse sind eindeutig dokumentiert

Können Sie QuPath arm64 und x64 gleichzeitig installieren?
Sie können beide Varianten getrennt vorhalten, sofern Sie sie eindeutig benennen, getrennte Arbeitsordner verwenden und nicht dieselbe Projektkopie unkontrolliert verändern. Bei Intel ist auf Apple Silicon die Rosetta-Laufzeit relevant. Die Doppelinstallation ist besonders sinnvoll, wenn Ihr Labor heterogene Scannerformate verarbeitet oder mehrere Mitarbeitende mit unterschiedlichen Projektvoraussetzungen arbeiten.

07

Abnahmecheckliste für Ihr Labor

Führen Sie die Entscheidung nicht anhand des Downloadnamens durch. Haken Sie jeden Punkt erst nach einem echten Test ab:

  • [ ] Die verwendete QuPath-Version ist auf der offiziellen Seite als stabile Version bestätigt.
  • [ ] Der Status des Apple-Silicon-Pakets als Beta wurde dokumentiert.
  • [ ] Die arm64- und Intel-Anwendung sind eindeutig voneinander unterscheidbar.
  • [ ] Die Testmenge enthält jede für das Projekt wichtige Schnittquelle.
  • [ ] CZI-Dateien mit der real verwendeten Kompression wurden geprüft.
  • [ ] Öffnen, Zoomen, Kanalanzeige und Metadaten wurden je Datei getestet.
  • [ ] Die wichtigsten QuPath-Erweiterungen laden und führen ihre Kernfunktion aus.
  • [ ] Ein repräsentatives Groovy-Skript erzeugt vergleichbare Messspalten und Ausgaben.
  • [ ] Ein altes Projekt wurde aus einer schreibgeschützten Kopie geöffnet.
  • [ ] Export, Dateiübertragung und lokale Rückgabe wurden mit anonymisierten Daten getestet.
  • [ ] Eine getrennte Arbeitskopie wurde nach einer Remote-Unterbrechung erfolgreich fortgesetzt.
  • [ ] Die Entscheidung arm64, Intel oder beide wurde mit konkreten Dateinamen und Skripten dokumentiert.

Die Entscheidung ist arm64, wenn alle Punkte für Ihre Kernaufgaben erfüllt sind. Sie lautet Intel, wenn mindestens ein unverzichtbares Format oder Werkzeug nur dort zuverlässig funktioniert. Sie lautet beide, wenn die Datenquellen komplex sind, die Arbeitsgruppe unterschiedliche Anforderungen hat oder die Umstellung eines bestehenden Projekts noch nicht vollständig nachgewiesen ist.

08

Wochenplan und nächste Entscheidung

Diese Woche, Tag 1: Erstellen Sie die Format- und Skriptliste. Bewahren Sie das Originalprojekt unverändert auf.

Tag 2: Installieren Sie arm64 und prüfen Sie die komplette Testmenge. Protokollieren Sie jede Abweichung bei Öffnen, Zoom, Kanälen und Metadaten.

Tag 3: Installieren Sie Intel. Falls Rosetta noch nicht vorhanden ist, richten Sie die Laufzeit nach der Apple-Anleitung ein. Wiederholen Sie exakt dieselben Tests.

Tag 4: Prüfen Sie Erweiterungen, Groovy-Skripte, Modelle und Exporte. Vergleichen Sie nicht nur sichtbare Bilder, sondern auch Messspalten und Projektzustände.

Tag 5: Wiederholen Sie die bestanden Aufgaben in einer Remote-Sitzung. Testen Sie Trennung, Wiederverbindung und Ergebnisrückgabe.

Danach entscheiden Sie nicht nach dem Chipnamen, sondern nach der kleinsten funktionierenden Umgebung. Wenn arm64 alle Kernaufgaben abdeckt, ist es der einfachere Standard. Wenn ein wichtiges Format nur mit Intel funktioniert, bleibt Intel der kontrollierte Sonderweg. Bei gemischten Datenquellen ist eine dokumentierte Doppelinstallation oft sicherer als ein erzwungener Wechsel.

Wenn Ihnen für diese Prüfung kein Apple-Silicon-Mac zur Verfügung steht, ist ein kurzfristig gemieteter Remote-Mac ein sinnvoller Zwischenschritt. Sie können dieselben anonymisierten Schnitte und Skripte zunächst in beiden QuPath-Varianten testen, statt eine teure Laborentscheidung auf eine einzelne Downloadprüfung zu stützen. Die verfügbaren Mac-Mietpreise von VpsMesh sollten Sie dabei gegen die Dauer Ihres Validierungszyklus und die Anforderungen Ihrer Hochschule abgleichen.

Ein eigener Mac bleibt sinnvoll, wenn Sie dauerhaft und täglich mit denselben Projekten arbeiten oder lokale Anschlüsse und institutionelle Speicherwege benötigen. Ein Remote-Mac ist dagegen oft die passendere Übergangslösung, wenn die vorhandene Windows- oder Linux-Ausstattung kein macOS bereitstellt, Sie nur für eine Migrationsprüfung Zugriff brauchen oder das Budget einer Arbeitsgruppe begrenzt ist. Informationen zur Mac-Umgebung von VpsMesh können Sie dann gemeinsam mit Ihrer IT- und Datenschutzstelle bewerten. Entscheidend ist, dass Sie erst nach bestandenem QuPath-Test festlegen, ob Sie eine kurze Mietphase, eine längere Forschungsumgebung oder zwei getrennte Versionen benötigen.