INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le dispositif électronique 10 de mesure multivariée de présence de composés présents dans un fluide représenté schématiquement sur la est un exemple non limitatif de dispositif de mesure selon un premier mode de réalisation de la présente invention pour une application non limitative d’identification d’odeurs. Il comporte une chambre de mesure 12 destinée à recevoir un fluide, par exemple un gaz tel que de l’air ambiant. Pour ce faire, il comporte un dispositif d’aspiration 14 conçu pour aspirer l’air situé à l’intérieur de la chambre de mesure 12 et le faire sortir à l’extérieur. Il comporte en outre une entrée d’air 16 pouvant être sélectivement fermée pour garder l’air ambiant dans la chambre de mesure 12 ou bien ouverte pour permettre l’évacuation de l’air ambiant de la chambre de mesure 12 et son renouvellement par l’activation du dispositif d’aspiration 14. Il est ainsi doté de moyens de maîtrise des flux entrant et sortant.
Dans sa chambre de mesure 12, Le dispositif électronique de mesure multivariée 10 comporte plusieurs capteurs olfactifs 18, répartis respectivement sur autant de sites réactifs, par exemple une soixantaine, conçus pour interagir avec des composés susceptibles d’être présents dans la chambre de mesure 12 lorsque le dispositif 10 est placé à proximité d’un fluide à analyser émetteur de ces composés, notamment lorsque l’entrée d’air 16 est à proximité du fluide considéré. Les composés émis sont généralement des composés organiques volatils mais la présente invention ne se limite pas à de tels composés.
L’au moins une matrice de correction peut être calculée par un procédé ou un système de caractérisation selon l’invention.
Dans ce cas, l’au moins une matrice de correction préalablement calculée est chargée et mémorisée dans l’appareil.
Suivant des modes de réalisation, au moins une matrice de correction peut être calculée dans l’appareil réalisant l’acquisition de l’image.
Dans ce cas, la matrice de correction peut être calculée à partir : d’au moins une matrice d’aberration, d’une matrice noyau d’aberrations, ou d’une matrice noyau de correction.
Dans ces modes de réalisation, il n’est alors pas nécessaire de calculer toutes les matrices de correction préalablement à l’intégration de l’objectif optique dans l’appareil, et le calcul des matrices de corrections se fait dans l’appareil, dans l’environnement d’utilisation de l’objectif optique. Cela permet de prendre en compte des spécificités découlant, ou dépendant, des conditions d’intégration de l’objectif optique dans l’appareil, ce qui permet une plus grande précision.
Au moins une matrice de correction peut être calculée une seule fois puis mémorisée dans l’appareil pour être utilisée à de multiples reprises.
Par exemple, au moins une matrice de correction peut être calculée juste après l’intégration de l’objectif optique dans l’appareil, ou au moment de la configuration de l’appareil ou encore au moment d’une installation/configuration d’une application d’acquisition d’image, et être mémorisée dans l’appareil pour être utilisée dans le temps.
Au moins une matrice de correction peut être calculée, ou recalculée, à la volée à chaque acquisition d’une image, ou à chaque démarrage d’une application d’acquisition d’image.
Dans ce cas, il n’est pas nécessaire de mémoriser l’au moins une matrice de correction, cette dernière étant calculée à la volée.
Ce mode de réalisation permet d’éviter d’avoir à mémoriser toutes les matrices de corrections et calculer l’au moins une matrice de correction lorsqu’elle est utilisée.
Par exemple, lors de l’acquisition d’une image les distances DOC et DOS peuvent être déterminées et l’au moins une matrice de correction correspondante auxdites distances peut être déterminée à la volée.
Le procédé selon l’invention peut en outre comprendre une étape de détermination d’une distance, DOC, entre l’objectif optique et un plan d’image, la correction prenant en compte ladite distance DOC.
La distance DOC peut par exemple être mesurée par un capteur de distance, tel qu’un capteur optique, un capteur magnétique, un capteur capacitif, etc.
La distance DOC peut par exemple être calculée à partir d’information fournie par un mécanisme d’ajustement de la focalisation modifiant ou contrôlant la distance entre l’objectif et le capteur d’image.
Le procédé selon l’invention peut en outre comprendre une étape de détermination d’une distance, DOS, entre l’objectif optique et la scène, la correction prenant en compte ladite distance DOS.
La distance DOS peut par exemple être mesurée par un LIDAR, une caméra temps de vol, un capteur ultrason, une analyse d’image texturée, etc.
illustre un exemple de conception d’une application logicielle intégrable et exécutable par une plateforme d’imagerie médicale conforme à l’invention ;
illustre un procédé d’intégration et d’exécution d’une application logicielle par une plateforme d’imagerie médicale conforme à l’invention.
La illustre un exemple d’un système d’imagerie médicale S comportant un appareil d'imagerie 1. Celui-ci délivre une pluralité de séquences d'images numériques 12 d'une ou plusieurs parties du corps d'un patient, à titre d'exemples non limitatifs, le cerveau, le cœur, les poumons. L'appareil d'imagerie par résonance magnétique 1 est généralement commandé à l'aide d'une console 2. Un utilisateur 6, par exemple un opérateur, praticien ou chercheur, peut ainsi choisir des commandes 11 pour piloter l'appareil d’imagerie 1 à partir de paramètres ou de consignes 16 saisis via une interface homme-machine d'entrée 8 du système d'analyse S. Une telle interface homme-machine 8 peut consister par exemple en un clavier informatique, un dispositif de pointage, un écran tactile, un microphone ou, plus généralement, toute interface agencée pour traduire une gestuelle ou une consigne émise par un humain 6 en données de commande ou de paramétrage d’un appareil d’imagerie 1. A partir d'informations 10 produites par ledit appareil 1, on obtient une pluralité de séquences d'images numériques 12 d'une partie d'un corps d’un humain ou d’un animal.
Les séquences d'images 12 peuvent optionnellement être stockées au sein d'un serveur 3 ou PACS, c'est-à-dire un ordinateur doté de moyens de mémorisation propres et constituer un dossier médical 13 d'un patient. Un tel dossier 13 peut comprendre des images de différents types, telles que des images fonctionnelles mettant en évidence l'activité des tissus ou des images anatomiques reflétant les propriétés des tissus. Les séquences d'images 12 ou, plus généralement les données expérimentales, sont analysées par une plateforme d’imagerie médicale 4 agencée à cette fin pour produire des indicateurs textuels ou graphiques 14 visualisables via une interface homme-machine de sortie 5 par un personnel de santé 6 selon des consignes 16 adressées à ladite plateforme d’imagerie médicale 4.
La décrit un exemple d’architecture d’une plateforme d’imagerie médicale 4 conforme à l’invention et destinée à être intégrée dans un système d'analyse d'imagerie tel que le système S illustré par la . Une telle plateforme d’imagerie médicale 4 peut comporter une unité de traitement sous la forme d’un ou plusieurs microprocesseurs ou microcontrôleurs 41 mettant en œuvre des instructions de programmes d'applications idoines chargées dans des moyens de mémorisation ou mémoire 45 dudit système d'analyse d'imagerie S. L’accès en lecture et/ou écriture à ladite mémoire 45 par l’unité de traitement 41 peut être régi par un système de fichiers 42. Ladite unité de traitement 41 est avantageusement en communication avec un module d’entrée/sortie 43 chargé notamment de réceptionner les séquences d’images médicale 12, voire avec un module 44 chargé de déterminer, à partir desdites séquences d’images 12 réceptionnées, quelle est ou quelles sont les applications logicielles parmi des applications logicielles disponibles A1, A2, An qui méritent d’être mises en œuvre pour analyser lesdites séquences d’images 12 dans le but de produire des quantités d’intérêt pertinentes 14 à destination des personnels de santé 6. Lesdites applications logicielles A1 à An sont préalablement, ou plus précisément les instructions de programmes qui les caractérisent, chargées en mémoire 45 de la plateforme 4. Comme nous l’étudierons ultérieurement chaque application logicielle A1, A2, An est associée à un contenu numérique distinct de ladite application logicielle et qui est dédié à cette dernière, contenu numérique que nous nommons dans la suite « contrat » C1, C2, Cn. Ainsi, conjointement au chargement des instructions de programme de l’application logicielle A1, un contrat C1 sous la forme d’un contenu numérique comportant des informations exploitables ou interprétables par l’unité de traitement 41, plus précisément selon un procédé 100 d’intégration et d’exécution d’applications logicielles conforme à l’invention. Pour adapter le fonctionnement de la plateforme d’imagerie médicale 4, un programme d’ordinateur comportant les instructions exécutables par l’unité de traitement 41 de ladite plateforme 4 est chargé dans la mémoire 45, lesdites instructions de programme provoquant la mise en œuvre d’un tel procédé d’intégration et d’exécution 100.
La illustre un exemple de description fonctionnelle d’une application logicielle au sens de l’invention. Une telle application logicielle consiste en un traitement numérique portant sur une ou plusieurs données d’entrée pour produire une ou plusieurs données de sortie. A titre d’exemple, une telle première application logicielle peut consister en une application visant à catégoriser un flux d’images DICOM 12 acquises par un appareil d’imagerie à rayons X et produire des données de sortie triées par type, lesdites images étant enrichies par un ou plusieurs labels visant à qualifier lesdites images. De tels label pourraient être choisis parmi un ensemble d’acronymes « CTP », « CTA », « NCCT » d’expressions anglo-saxonnes « c omputed t omography p erfusion », « c omputed t omography a ngiography », « n on- c ontrast c omputed t omography » qualifiant des modalités d’acquisition. En variante, une telle première application logicielle pourrait exploiter des données d’entrée sous la forme d’images DICOM labélisées « CTP » et produire en sortie des données de sortie sous la forme de cartes illustrant un paramètre hémodynamique et un rapport de résultat exprimé sous une forme textuelle et destiné à être communiqué in f ine par courriel. Une deuxième application logicielle pourrait être conçue pour exploiter des données d’entrée sous la forme d’un flux 12 d’images DICOM acquises à partir d’un appareil d’imagerie à résonnance magnétique et produire des données de sortie triées par types, lesdites images étant enrichies par un ou plusieurs labels visant à qualifier lesdites images. De tels label pourraient être choisis parmi un ensemble d’acronymes « DWI », « PWI », « FLAIR » d’expressions anglo-saxonnes « diffusion- weighted i maging », « perfusion- weighted o maging », « f luid-attenuated inversion recovery » qualifiant des modalités d’acquisition de l’appareil d’imagerie.
De manière générale et comme l’illustre la , une application logicielle A1 produit des données de sortie OD1, …, ODj à partir de données d’entrée ED1, …, EDi. Lesdites données d’entrée et/ou de sortie peuvent respectivement être de différents formats, par exemple de types textuel, DICOM ou autres. Une application logicielle A1 peut en outre exploiter une ou plusieurs variables d’environnement E1, …, Ek. De telles variables d’environnement sont transmises à l’application logicielle lors de l’exécution de celle-ci dans le but de paramétrer ladite exécution de l’application logicielle ou les traitements mis en œuvre par celle-ci. Selon un mode de réalisation préférée, l’application A1 peut être définie sous la forme d’un conteneur informatique dont l’image se présente sous la forme d’un fichier statique refermant un code (c’est-à-dire un ensemble d’instructions de programme) exécutable et définissant les paramètres ou dépendances nécessaires à son exécution. Un tel choix technique de « conteneurisation » des applications logicielles permet notamment de simplifier l’étape de test du fonctionnement d’une application logicielle avant son déploiement sans pour autant nécessiter une configuration de test proche d’une plateforme d’imagerie médicale. En effet, le « pattern » de l’application logicielle est clairement défini, l’image du conteneur peut être mise en œuvre et testée telle un module applicatif autonome à l’instar d’une machine virtuelle légère et modulaire. Prenons l’exemple de la technologie « Docker » initialement conçue pour traiter les conteneurs Linux (famille de systèmes d'exploitation « open source » de type Unix (AT&T) créée par Linus Torvalds. Supposons que l’identificateur AID de l’image de l’application logicielle A1 illustrée par la désigne la version 1.0 de l’application logicielle « my_application ». Une exécution de ladite application logicielle A1 par un ordinateur pourrait être provoquée en invoquant manuellement la commande : « d ocker run \ - v / tmp /inputs/ED1 :/inputs/ED1 \ ( arg 1 ) - v / tmp /inputs/ED1:/inputs/ EDi \ ( arg 2) - v / tmp /outputs/OD1:/outputs/OD1 \ ( arg 3 ) - v / tmp /outputs/ ODj :/outputs/ ODj \ ( arg 4 ) - e E1=VALUE1 \ ( arg 5 ) - e E k = VALUE k \ ( arg 6 ) my_application:1.0 » ( arg 7)
L’argument (arg1) de la commande permet de définir ou résoudre un lien (opération également connue sous le vocable de « mapping » selon une terminologie anglo-saxonne) entre l’emplacement ou répertoire « physique » DED1 de la donnée d’entrée ED1 (en l’espèce selon l’exemple illustré par la un répertoire temporaire du système de fichier 45 d’une plateforme 4 d’imagerie médicale ou plus généralement d’un ordinateur de développement ou de test) ledit répertoire DED1 étant accessible par le chemin d’accès DPED1 « /tmp/inputs/ED1 » et le répertoire « virtuel » VDED1 (en l’espèce sur l’exemple illustré par la , le répertoire virtuel « /inputs/ED1 ») défini par le concepteur de l’application A1 dans le module applicatif. Ainsi, lorsque ladite application logicielle A1 est exécutée, cette dernière lit la valeur de la donnée d’entrée ED1 dans le répertoire virtuel VDED1 « /inputs/ED1 » alors que physiquement, c’est-à-dire dans la mémoire 45 de la machine 4 mettant en œuvre ladite application logicielle A1, ledit répertoire virtuel correspond à un répertoire physique DED1 choisi par ledit utilisateur, en l’espèce le répertoire dont le chemin d’accès DPED1 est « /tmp/inputs/ED1 ».
De la même manière, les arguments (arg2), (arg3) et (arg4) définissent, respectivement pour les données EDi, OD1 et ODj, les liens entre les répertoires virtuels VDEDi « /inputs/EDi », VDOD1 « /outputs/OD1 », VDODj « /outputs/ODj » et les répertoires physiques DEDi « /tmp/inputs/EDi », DOD1 « /outputs/OD1 » et DODj « /outputs/ODj ».
Les arguments (arg5) et (arg6) permettent de transmettre à l’application A1 les valeurs VALUE1 et VALUEk respectivement aux variables d’environnement E1 et Ek.
Enfin l’argument (arg7) de la commande désigne l’identifiant AID de l’image de l’application A1, en l’espèce « my_application » de version 1.0.
L’invention ne saurait être limitée à ce seul choix d’implémentation d’une application logicielle sous la forme d’un conteneur ou de la technologie « Docker ». En variante, elle pourrait s’appuyer sur une solution équivalente telle que la solution « podman » développée par Red Hat. Une application logicielle pourrait également consister en un programme exécutable « classique » en lieu et place d’un conteneur. Dans tous les cas, pour être exploitée par un procédé d’intégration et d’exécution d’applications logicielles conforme à l’invention tel que le procédé 100 dont un exemple de mise en œuvre est illustré par la , une application logicielle, telle que l’application A1 décrite par la , est associée à un contenu numérique tiers C1, nommé contrat. Par l’exploitation de ce dernier, par exemple par le module 44 illustré en , l’exécution d’une application logicielle peut être déclenchée en désignant cette dernière de manière non ambigüe, en résolvant les liens entre les emplacements physiques DED1, DEDi des données d’entrées ED1, EDi, les emplacements physiques DOD1, DODj des données de sortie OD2, ODj sur la plateforme d’imagerie 4 et les emplacements virtuels ou « internes » VDED1, VDEDi, VDOD1, VDODj au module applicatif, voire en définissant des valeurs à des variables d’environnement E1 à Ek. C’est l’exploitation conjointe de ce contrat C1 et du système de fichiers 42 qui permet de faciliter l’intégration et l’exécution d’une application logicielle.
Ainsi, en liaison avec la et la , un contrat C1 comporte un ensemble de champs ou d’éléments, distinguables les uns et d’autres par exemple par des balises ou tout autre moyen technique équivalent, afin que préalablement à l’exécution en tant que telle d’une application logicielle éventuellement paramétrée par des variables d’environnement E1, Ek, les valeurs des données d’entrées ED1, EDi soient inscrites dans des emplacements de la mémoire 45 via le système de fichiers 42 et qu’à l’issue de l’exécution de ladite application logicielle A1, les données de sortie OD1 et ODj produites par celle-ci puissent être exploitées par ladite plateforme 4. Le contrat C1, associé à l’application logicielle A1 peut avantageusement comprendre : l’identifiant unique AID de l’application logicielle A1, en l’espèce sur la , l’image du conteneur ; les valeurs EV1 et EVk à assigner respectivement aux variables d’environnement E1 et Ek lors de l’exécution de ladite application logicielle A1; les répertoires virtuels d’entrée VDED1, VDEDi destinés à contenir, les valeurs des données d’entrée ED1, EDi de l’application logicielle A1 ; les répertoires virtuels de sortie VDOD1, VDODj destinés à contenir les valeurs des données de sortie OD1, ODj de l’application logicielle A1.
Plus généralement, un tel contrat C1 comporte par donnée d’entrée ED1, EDi ou de sortie OD1, ODj, les emplacements virtuels VDED1, VDEDi, VDOD1, VDODj pour écrire/lire une valeur de ladite donnée d’entrée ED1, EDi ou de sortie OD1, ODj. La présence d’une valeur EV1, EVk à assigner à une variable d’environnement est optionnelle, certaines applications logicielles ne nécessitant de tels paramètres de fonctionnement comme par exemple pour sélectionner une palette de couleurs parmi une pluralité ou encore un référentiel d’unités. Le format d’un contrat est imposé par la plateforme d’imagerie médicale de sorte que celle-ci puisse avoir la capacité d’exploiter (c’est-à-dire lire et éventuellement mettre à jour) ledit contrat C1. En revanche, le contenu dudit contrat C1 est imposé par l’application logicielle selon les données d’entrée, de sorties/variables d’environnement qu’elle nécessite. Après installation de l’application logicielle et de son contrat en mémoire 45 de la plateforme d’imagerie médicale 4, il revient à l’opérateur de la plateforme ou à la plateforme en tant que telle, de modifier et/ou paramétrer ledit contrat C1 par exemple en inscrivant les chemins d’accès physique DPED1, DPDEi, DPOD1, DPODj aux répertoires DED1, DEDi, DOD1, DODj du système de fichiers 42 régissant la mémoire 45 de ladite plateforme 4 pour stocker les données d’entrée ED1, EDi et de sortie OD1, ODj de ladite application A1 si lesdits répertoires d’entrée DED1, DEDi et de sortie DOD1, DODj sont immuables, ainsi que pour fixer les valeurs de variables d’environnement EV1, EVk si elles existent ou sont requises. De manière préférée, lesdits chemins d’accès DPED1, DPDEi, DPOD1, DPODj ne sont pas inscrits dans le contrat C1 de sorte à laisser la plateforme d’imagerie 4 le soin d’allouer des répertoires temporaires DED1, DEDi, DOD1, DODj préalablement à l’exécution en tant que telle de l’application A1. La résolution des liens entre les répertoires virtuels VDE1, VDEi, VDO1, VDOj et les répertoires physiques DED1, DEDi, DOD1, DODj est réalisée par les arguments de la commande d’exécution comme illustré précédemment en lien avec l’application « my_application ». Nous pouvons parler d’une étape de configuration de l’application logicielle A1 à l’issue de son installation ou chargement en mémoire 45 pour qualifier ladite mise à jour optionnelle du contrat C1.
La permet d’illustrer la mise en œuvre et la description fonctionnelle d’un procédé 100 d’intégration et d’exécution d’une application logicielle conforme à l’invention. Un tel procédé 100 est mis en œuvre par une plateforme d’imagerie médicale telle que la plateforme 4 selon la et la . Le fonctionnement de cette dernière est adapté par l’implantation dans la mémoire 45 d’un programme d’ordinateur dont les instructions de programme provoquent, lors de leur exécution par l’unité de traitement 41 sous le contrôle éventuel d’un module décisionnel 44, la mise en œuvre d’un tel procédé 100. Supposons que la mémoire 45 comporte en outre l’application logicielle A1, par exemple sous la forme d’un conteneur associée à un contrat C1, ce dernier se présentant sous la forme d’un fichier texte structuré, c’est-à-dire agencé au moyen de balises idoines, à l’instar des application logicielle A1 et du contrat C1 d’ores et déjà décrits en lien avec la .
La réception d’une séquence d’images médicales 12 exploitée par l’unité de traitement 41 déclenche la mise en œuvre du procédé 100 pour provoquer l’exécution de l’application logicielle A1 jugée pertinente.
Selon un mode de réalisation de l’invention, le logement de réception est disposé dans une partie avant du réservoir de liquide de nettoyage. En d’autres termes, le logement de réception est situé à l’avant d’un plan transversal médian vertical du réservoir de liquide de nettoyage.
Selon un mode de réalisation de l’invention, un rapport d’une dimension transversale maximale, et par exemple d’une largeur maximale, du logement de réception sur une dimension transversale maximale, et par exemple d’une largeur maximale, d’un tronçon du conduit d’aspiration central logé dans le logement de réception est compris entre 1 et 1,2, et avantageusement entre 1 et 1,1. Une telle configuration du logement de réception permet à ce dernier d’épouser sensiblement la forme du conduit d’aspiration central, et donc d’optimiser encore le volume interne du réservoir de liquide de nettoyage.
Selon un mode de réalisation de l’invention, le réservoir de liquide de nettoyage comporte deux parois de délimitation situées de part et d’autre du conduit d’aspiration central et s’étendant chacune au moins en partie le long du conduit d’aspiration central, les deux parois de délimitation délimitant en partie le logement de réception.
Selon un mode de réalisation de l’invention, chaque paroi de délimitation présente, vue de dessus, un profil externe qui est orienté vers le conduit d’aspiration central et qui correspond sensiblement au profil externe, vue de dessus, d’une portion longitudinale latérale respective du conduit d’aspiration central. Une telle configuration du réservoir de liquide de nettoyage favorise encore l’optimisation du volume interne du réservoir de liquide de nettoyage.
Selon un mode de réalisation de l’invention, chaque paroi de délimitation est espacée du conduit d’aspiration central, une distance de séparation minimale entre chaque paroi de délimitation et le conduit d’aspiration central est inférieure à 10 mm, avantageusement inférieure ou égale à 5 mm, de façon encore avantageuse comprise entre 1 et 4 mm, et par exemple comprise entre 1 et 3 mm. En d’autres termes, le conduit d’aspiration central et chaque paroi de délimitation délimitent un espace longitudinal respectif s’étendant le long du conduit d’aspiration central, chaque espace longitudinal présentant une largeur minimale inférieure à 10 mm, avantageusement inférieure ou égale à 5 mm, de façon encore avantageuse comprise entre 1 et 4 mm, et par exemple comprise entre 1 et 3 mm.
Selon un mode de réalisation de l’invention, le réservoir de liquide de nettoyage et le conduit d’aspiration central sont configurés de telle sorte que la distance de séparation minimale entre chaque paroi de délimitation et le conduit d’aspiration central est sensiblement constante le long du conduit d’aspiration central.
Selon un mode de réalisation de l’invention, chaque paroi de délimitation comporte une portion supérieure s’étendant sensiblement verticalement.