Choisissez d’abord arm64 sur un Mac Apple Silicon, mais conservez une version Intel exécutée avec Rosetta si vos lames représentatives dépendent d’une chaîne Bio-Formats encore limitée sur arm64. Si les formats, extensions ou scripts varient fortement dans votre laboratoire, installez les deux versions dans des environnements séparés et validez le flux réel avant toute migration.

Cette recommandation concerne les étudiants et chercheurs en pathologie qui doivent traiter des lames entières avec un budget limité, les équipes d’analyse biomédicale utilisant plusieurs formats de microscope, ainsi que les personnes chargées de livrer un environnement QuPath reproductible sur un Mac distant.

Dernière mise à jour : 5 septembre 2026. Les informations de version et de compatibilité ont été vérifiées à partir du site officiel de QuPath, de sa documentation d’installation, de sa documentation des formats et de la page de publication de QuPath 0.7.0.

01

Le choix d’architecture dépend d’abord de la lame réellement utilisée

Au moment de cette vérification, le site officiel présente QuPath 0.7.0 comme la version stable actuelle et propose une distribution macOS Intel ainsi qu’une distribution Apple Silicon. Le paquet Apple Silicon est encore indiqué comme bêta dans la documentation officielle ; il ne faut donc pas assimiler « application native » et « compatibilité garantie avec tout votre flux ». Consultez la page officielle de QuPath et la publication de QuPath 0.7.0 avant de télécharger.

La décision pratique se résume ainsi :

  • arm64 : premier choix pour un Mac Apple Silicon lorsque vos formats, extensions et scripts passent les tests ;
  • Intel avec Rosetta : solution de repli lorsque la lecture d’une lame ou d’un composant dépend d’une chaîne non disponible sur arm64 ;
  • double installation isolée : choix prudent pour une équipe travaillant avec plusieurs scanners, des projets historiques et des scripts hétérogènes.

Le nom du processeur ne suffit pas. Vous devez aussi vérifier le nom de l’application, son architecture effective et l’emplacement des projets. Un résultat obtenu avec Intel ne doit pas être attribué par erreur à arm64. Cette confusion fausse ensuite les rapports de compatibilité et les décisions du laboratoire.

La documentation d’Apple explique que Rosetta permet d’exécuter des applications Intel sur Apple Silicon, mais cela ne transforme pas automatiquement les extensions, bibliothèques natives ou outils externes en composants arm64 compatibles. La documentation Apple sur Rosetta doit être considérée comme la référence pour cette couche de traduction.

02

Une comparaison initiale pour éviter le mauvais téléchargement

Critère de décision Version arm64 Version Intel avec Rosetta Deux versions séparées
Mac Apple Silicon Choix prioritaire Compatible via Rosetta Approche de validation
Formats complexes À vérifier avec des fichiers réels Peut servir de repli Adaptée aux sources multiples
Bio-Formats Limites documentées sur Apple Silicon Chaîne Intel à tester Réduit le risque de blocage
Extensions et scripts Validation obligatoire Validation indépendante Isolement recommandé
Projet ancien Copie de test indispensable Peut faciliter la continuité Permet une comparaison contrôlée
Travail distant Bon point de départ Utile pour un cas précis Plus simple à livrer par scénario

Cette table ne remplace pas un test. Elle indique seulement dans quel ordre examiner les options. La version arm64 peut être la meilleure base pour un nouveau projet, tandis que la version Intel reste nécessaire pour une famille de fichiers donnée.

03

Les formats de lames constituent le premier critère d’arrêt

Ne testez pas uniquement un fichier TIFF ordinaire. Une lame entière est liée à son scanner, à son extension, à sa compression, à son organisation en pyramide et au lecteur utilisé par QuPath. Une démonstration réussie avec un seul fichier simple ne prouve donc pas que votre corpus est exploitable.

La documentation stable de QuPath décrit les formats pris en charge et les dépendances de lecture dans sa référence officielle des formats d’image. Elle doit être rapprochée de la documentation d’installation, qui signale les limites propres au support Bio-Formats sur Apple Silicon. Consultez également la documentation d’installation de QuPath avant de conclure que l’échec vient du fichier lui-même.

Certains fichiers CZI, notamment lorsqu’ils utilisent une compression JPEG-XR, peuvent nécessiter un essai avec la version Intel. Il s’agit d’un critère de validation, pas d’une règle permettant d’affirmer que tous les CZI échoueront sur arm64. Votre laboratoire doit tester ses propres exports, car le suffixe seul ne décrit pas l’ensemble de la chaîne de lecture.

Pour chaque format représentatif, vérifiez les éléments suivants :

  • ouverture complète du fichier, sans message d’erreur silencieux ;
  • affichage correct de la pyramide lors des changements de niveau ;
  • présence des canaux et des couleurs attendus ;
  • récupération des métadonnées utiles au projet ;
  • navigation vers plusieurs régions éloignées ;
  • export d’une région ou d’un résultat dans le format prévu.

Un échec sur un format central du protocole doit arrêter la migration vers arm64 seul. Ne masquez pas le problème en convertissant immédiatement les données : la conversion peut supprimer des métadonnées, modifier la compression ou rendre impossible la comparaison avec les résultats produits par les autres membres de l’équipe.

Pourquoi certains fichiers CZI posent-ils problème sur arm64 ?

Le point sensible est la combinaison entre le format de la lame et le lecteur logiciel mobilisé. Bio-Formats n’est pas une simple option d’interface ; il intervient dans la lecture de nombreux formats scientifiques. La documentation de QuPath expose explicitement une limite concernant certains formats Bio-Formats dans l’environnement Apple Silicon. Vous devez donc traiter un fichier CZI compressé comme un cas à vérifier, et non comme une preuve générale d’incompatibilité.

Le test utile consiste à conserver une copie originale en lecture seule, puis à ouvrir exactement le même fichier dans arm64 et Intel. Comparez l’image, les canaux, les métadonnées et la navigation. Si seul Intel réussit les critères essentiels, gardez cette version pour cette famille de lames.

04

La vitesse utile se mesure sur une tâche identique

Comparer uniquement le temps de lancement donne une information faible pour un travail de pathologie numérique. Votre mesure doit porter sur la tâche scientifique : ouverture d’une lame, navigation, annotation, prévisualisation d’une détection, changement de projet et export.

Utilisez le même Mac distant, la même copie de fichier et la même séquence d’actions. Un affichage VNC ralenti par le réseau peut donner l’impression que QuPath calcule lentement, alors que le traitement de l’image est terminé côté hôte. Inversement, une application qui semble réactive dans un petit fichier peut devenir inutilisable avec votre lame entière habituelle.

Consignez séparément :

  1. le moment où la commande d’ouverture est lancée ;
  2. l’apparition de l’image exploitable ;
  3. la fluidité de plusieurs changements de zoom ;
  4. la précision d’une annotation sur une zone connue ;
  5. l’affichage de la prévisualisation d’une détection ;
  6. le changement vers un autre projet ;
  7. l’export du résultat.

Ne transformez pas ces observations en multiplicateur de performance sans mesure reproductible. Les documents officiels de QuPath présentent les fonctions et limites générales, mais ils ne fournissent pas un coefficient universel valable pour toutes les lames, toutes les extensions et toutes les connexions distantes. Le bon choix est celui qui reste fluide et stable sur votre séquence, pas celui qui lance l’application le plus vite.

Le GPU mérite aussi une vérification séparée. QuPath documente certaines fonctions GPU, mais leur disponibilité ne signifie pas que chaque étape d’analyse ou chaque modèle bénéficiera automatiquement d’une accélération. Consultez la documentation officielle du support GPU et testez votre opération précise.

05

Les extensions, modèles et scripts décident de la migration

Une installation peut ouvrir une lame tout en restant inutilisable pour le projet. La cause se trouve souvent dans une extension, un script Groovy, un modèle de détection ou une commande externe. La compatibilité doit donc être vérifiée composant par composant.

Établissez un inventaire avec :

  • les extensions QuPath réellement utilisées ;
  • les versions ou fichiers d’extension conservés par l’équipe ;
  • les scripts Groovy indispensables ;
  • les modèles de classification ou de détection ;
  • les commandes externes appelées par les scripts ;
  • les colonnes de mesures attendues dans les exports.

Ouvrez ensuite une copie d’un projet existant dans chaque architecture. Ne travaillez pas directement sur le projet original. Lancez un script minimal, puis un traitement représentatif sur une petite région ou un fichier de test. Vérifiez que les objets créés, les noms de mesures et les fichiers exportés restent exploitables par les analyses suivantes.

Pour les traitements sans interface, la documentation officielle de la ligne de commande de QuPath donne le cadre à utiliser. Si votre équipe emploie un modèle de profondeur, examinez aussi la documentation QuPath consacrée à DJL. Une extension chargée dans l’interface ne suffit pas à prouver qu’un lancement automatisé fonctionnera.

Évitez d’élever un cas signalé sur un forum ou dans une issue isolée au rang de règle générale. Notez la version de QuPath, l’architecture, l’extension, le fichier et l’action qui échoue. Cette fiche est beaucoup plus utile qu’une affirmation vague selon laquelle « arm64 ne fonctionne pas ».

06

Le travail distant ajoute des contrôles de données et de réseau

Un Mac distant peut résoudre l’absence de machine macOS dans un laboratoire, mais il introduit des étapes qui n’existent pas sur un poste local. Vous devez distinguer le calcul réalisé sur l’hôte, l’affichage transmis à votre ordinateur et le transfert des fichiers.

Avant d’utiliser des données de recherche, vérifiez les règles de votre établissement. Employez des lames désidentifiées lorsque cela est requis, obtenez l’autorisation du responsable des données et limitez les comptes aux droits nécessaires. Un accès distant ne vaut pas autorisation clinique et ne constitue pas, à lui seul, une validation réglementaire.

Dans un environnement VpsMesh, vous pouvez commencer par un échantillon désidentifié sur une configuration Mac distante destinée aux usages scientifiques, puis vérifier les opérations suivantes :

  • transfert d’un petit échantillon ;
  • création ou ouverture du dossier de projet ;
  • contrôle des permissions de lecture et d’écriture ;
  • ouverture des lames avec arm64 puis Intel ;
  • reprise après une coupure de session ;
  • export des annotations et des mesures ;
  • récupération locale des résultats ;
  • suppression des copies temporaires après validation.

La qualité de l’interaction dépend aussi du réseau. Une navigation saccadée en VNC ne prouve pas automatiquement une faiblesse de QuPath. Notez séparément les problèmes d’affichage, les délais de transfert et les erreurs de lecture. Cette séparation permet de savoir si vous devez changer d’architecture, de méthode d’accès ou de procédure de données.

07

La checklist d’acceptation produit une décision défendable

Utilisez cette liste sur un échantillon représentatif avant de changer l’environnement de toute l’équipe :

  • [ ] Conserver une copie originale en lecture seule du projet et des lames de référence.
  • [ ] Noter le modèle de scanner, l’extension, la compression et les métadonnées attendues pour chaque format.
  • [ ] Installer QuPath 0.7 arm64 et confirmer l’architecture de l’application utilisée.
  • [ ] Installer QuPath 0.7 Intel dans un espace séparé et vérifier Rosetta sur le Mac Apple Silicon.
  • [ ] Ouvrir chaque format essentiel dans les deux versions.
  • [ ] Vérifier la pyramide, les canaux, les métadonnées et la navigation sur plusieurs régions.
  • [ ] Charger les extensions, modèles et scripts réellement utilisés par le projet.
  • [ ] Exécuter un traitement minimal puis une tâche représentative dans chaque architecture.
  • [ ] Comparer les objets, mesures et fichiers exportés sans modifier les originaux.
  • [ ] Tester une déconnexion et la reprise de session sur le Mac distant.
  • [ ] Classer chaque opération comme réussie, utilisable avec réserve ou bloquante.
  • [ ] Décider arm64 seul, Intel pour certains formats ou double installation isolée.

Adoptez arm64 seul si tous les formats et outils essentiels passent la liste. Gardez Intel si une dépendance critique ne passe que dans cette version. Choisissez les deux si les sources sont complexes, si plusieurs scripts historiques doivent rester disponibles ou si les membres de l’équipe utilisent des environnements différents.

Cette méthode répond également à la question de l’installation simultanée : arm64 et x64 peuvent être conservés ensemble à condition de séparer les applications, les préférences, les extensions et les dossiers de test. Ne partagez pas aveuglément un répertoire de configuration entre deux architectures. Un projet peut être commun en lecture contrôlée, mais chaque modification doit être traçable.

08

Le choix final dépend de votre horizon de recherche

Pour un étudiant qui doit vérifier rapidement un protocole, une courte période sur un Mac distant permet de tester les formats et les scripts avant d’acheter une machine. Pour une équipe qui traite chaque semaine les mêmes lames, il faut ensuite comparer la stabilité, la gestion des données, les accès des collaborateurs et la conservation des environnements.

Si votre laboratoire ne possède aucun Mac, la location ponctuelle peut être plus rationnelle qu’un achat immédiat lorsque le besoin consiste à valider une version, reproduire un résultat ou exécuter un traitement limité. Vous pouvez examiner les tarifs de location de Mac, puis conserver l’achat d’un poste local pour un usage permanent, intensif ou nécessitant des périphériques physiques.

La solution actuelle fondée uniquement sur Windows ou Linux présente toutefois des limites concrètes : elle ne reproduit pas directement le comportement macOS, elle oblige parfois à convertir les lames ou à déplacer les données, et elle ne permet pas de vérifier fidèlement une extension ou une interface propre à Mac. Pour une équipe qui doit trancher entre arm64 et Intel, ces détours retardent la validation. Un Mac distant loué via VpsMesh offre un environnement macOS réel, avec un accès adapté aux essais de QuPath sans immobiliser immédiatement le budget dans une machine dédiée.

Ne retenez pas arm64 parce que le nom Apple Silicon paraît plus récent, ni Intel parce qu’un ancien projet s’ouvre déjà. Préparez vos lames désidentifiées, vos extensions et vos scripts, exécutez la checklist sur les deux architectures, puis choisissez l’environnement qui réussit votre travail complet. Pour une décision rapide et réversible, un essai distant court est le meilleur préalable ; pour un traitement lourd et permanent, évaluez ensuite l’achat ou l’équipement durable du laboratoire.