NanoPyx: super-fast bioimage analysis powered by adaptive machine learning

To overcome the challenges posed by large and complex microscopy datasets, we have developed NanoPyx, an adaptive bioimage analysis framework designed for high-speed processing. At the core of NanoPyx is the Liquid Engine, an agent-based machine-learning system that predicts acceleration strategies for image analysis tasks. Unlike traditional single-algorithm methods, the Liquid Engine generates multiple CPU and GPU code variations using a meta-programming system, creating a competitive environment where different algorithms are benchmarked against each other to achieve optimal performance under the user”s computational environment. In initial experiments focusing on super-resolution analysis methods, the Liquid Engine demonstrated an over 10-fold computational speed improvement by accurately predicting the ideal scenarios to switch between algorithmic implementations. NanoPyx is accessible to users through a Python library, code-free Jupyter notebooks, and a napari plugin, making it suitable for individuals regardless of their coding proficiency. Furthermore, the optimisation principles embodied by the Liquid Engine have broader implications, extending their applicability to various high-performance computing fields.


Introduction
Super-resolution microscopy has revolutionised cell biology by enabling fluorescence imaging at an unprecedented resolution (4-7).However, the data collected from superresolution experiments requires specific analytical procedures, such as drift correction, channel alignment, resolution enhancement, and quantifying data quality and resolution.Many of these procedures use open-source image analysis software, particularly ImageJ (8) or Fiji (9); and associated plugins such as ThunderSTORM (10), Picasso (11), FairSIM (12), Fourier Ring Correlations (FRC) (13), and Decorrelation Analysis (14).The computational performance of these methodologies bears significant implications for processing time and becomes especially salient given the increasing need for high-performance computing in bioimage analysis.Computational performance has emerged as a significant bottleneck with the expanding adoption of super-resolution mi- croscopy and the consequent upscaling of datasets (number, size, and complexity).This has highlighted the need for a shift towards a more performance-centric approach in managing increasingly extensive datasets and addressing the limitations currently experienced in (super-resolution) microscopy methodologies.
Here, we introduce NanoPyx, a high-performance and adaptive bioimage analysis framework.NanoPyx is not only a Python library but also provides code-free Jupyter notebooks (15) and a napari (16) plugin.At the core of NanoPyx is the Liquid Engine, an agent-based machine-learning system that predicts acceleration strategies for image analysis tasks.
To enhance its image analysis capabilities, the Liquid Engine uses multiple variations (here referred to as implementations) of the same algorithm to perform a specific task.Although these implementations provide numerically identical output for the same input, their computational performance differs by exploiting different computational strategies.OpenMP is used for parallelising the code at the CPU level, while OpenCL ( 17) is used at the GPU level.The Liquid Engine then employs a specially created machine-learning system to predict the optimal combination of implementations based on the user's specific computational environment.This creates a competitive setting wherein various algorithm implementations are benchmarked against each other, to achieve the highest performance.
One of the strengths of NanoPyx is its modular design, which enables users to easily include NanoPyx as part of new methods and algorithms.In its initial iteration, NanoPyx enhances and expands the super-resolution analysis methods previously included in the NanoJ library while introducing a new Python implementation of the Decorrelation Analysis method (14).NanoJ is an extensive suite of ImageJ plugins custom-built for the domain of super-resolution microscopy.(2) and eSRRF (18), error map calculation as per NanoJ-SQUIRREL (3), Fourier Ring Correlation (FRC) (13), and Image Decorrelation Analysis (14) (1).To make NanoPyx accessible to users with different levels of coding expertise, we offer it through three separate avenues -as a Python library for developers with the skills to create their workflow scripts, as Jupyter Notebooks (15) that can be executed either on a local machine or on a cloud-based service like Google Colaboratory, and as a plugin for napari (16), a Python based image viewer, for users without programming experience.By distributing NanoPyx in this manner, we can cater to the needs of a wider audience, ensuring users of varying coding expertise have easy access and can effectively utilise NanoPyx for their bioimage analysis needs.

NanoPyx's Liquid Engine
Pure Python code often runs on a single CPU core, impacting the performance and speed of Python frameworks.Alternative solutions, such as Cython (20), PyOpenCL (21) and Numba (22), permit parallelisation of the CPU and GPU, while enabling a considerable computational accel- eration (Supplementary Note 1).However, identifying the swiftest implementation depends substantially on the input data and available hardware.For instance, Figure 2 presents a case where for smaller inputs, employing threaded CPU processing completes an interpolation task over 10x faster than a GPU.However, the situation reverses with increasing input size, where GPU-based processing reveals itself as the more efficient alternative.In Supplementary Figure S1, a comprehensive analysis is conducted to contrast the execution times of OpenCL with alternative implemented run time methodologies using diverse hardware configurations, including Google Colaboratory.The obtained results not only reaffirm the identified correlation between the faster implementation and input data size, but also elucidate the hardware-dependent breakpoints at which a given implementation surpasses the performance of its alternatives.Supplementary Figures S2, S3 and S4 further elucidate these observations by illustrating run times for various implementations across distinct input datasets and parameters on two contrasting hardware setups.The benchmark used features a 2D convolution with varying kernel sizes.While the professional workstation results align with expectations -OpenCL implementation was markedly faster as input image size and kernel size increased.However, this was not mirrored on a lap-top device (Supplementary Figure S2).Laptop performance showed that while larger kernel sizes boosted OpenCL's relative efficiency against CPU threading, expanding image size beyond a certain threshold made the parallelised CPU approach faster again.Notably, this outcome likely ties to the test laptop (MacBook Air M1) lacking a dedicated GPU, demonstrating how closely run times are tied to specific user hardware.This apparent disparity in results underlines how reliance on one implementation can prove restrictive; for instance, choosing OpenCL implementation for lower-sized images could escalate the run time by up to 300 times compared to CPU processing.Similarly, threaded CPU processing for larger-sized images performed up to 10x slower than GPU processing on professional workstations.Collectively these findings stress the importance of having an adaptable system that selects the optimum implementation based not just on data inputs but also considering unique user hardware configurations.
To address this, we have developed the Liquid Engine.This machine learning-based system manages multiple tasks by exploiting various device components and selecting the most efficient implementation based on input data (Supplementary Note 2).The Liquid Engine can significantly enhance computational speed for tasks involving input data of varying sizes.It achieves this by predicting when to switch between algorithmic implementations, as depicted in Supplementary Figures S1 and S2, showing the capacity for a 10x acceleration.The black dotted line in Figure S2 indicates when the switch between implementations occurs.The Liquid Engine features three main components: meta-programming tools for multi-hardware implementation (called tag2tag and c2cl, see Supplementary Note 3); an automatic benchmarking system for different implementations; and a supervisor machine learning-based agent that determines the ideal combination of implementations to maximise performance (Figure 3).
The tag2tag tool enables developers to generate multiple implementations of the same algorithm written as C or Python code snippets.Effectively, tag2tag transcribes these snippets into single-threaded and multi-threaded versions of the code, generally then called by Cython (20).In addition, the c2cl tool auto-generates GPU-based implementations based on C code snippets, using OpenCL (17), called via Py-OpenCL (21).The Liquid Engine also supports Numba (22) as an alternative performance-boosting option for Python code snippets.The implementation of the Liquid engine in NanoPyx adapts to the user's hardware, selecting the fastest implementation available to each user and ensuring optimal computational speeds.In the cases where a user does not have access to one of the implementations, it will ignore that implementation and pick the fastest from the remaining ones, guaranteeing that users will always be able to process their images.

Liquid Engine's adaptive optimisation
NanoPyx's Liquid Engine independently identifies ideal implementation combinations for specific workflows keeping in view device-dependent performance variations ( The image analysis workflows of NanoPyx are built on top of the Liquid Engine, which automatically benchmarks implementations of all tasks in the specific workflow.The Liquid Engine keeps a historical record of the run times of each task and the shape of the used input, allowing a machinelearning-based agent to select the fastest combination of implementations.In the case of an unexpected delay, the agent dynamically adjusts the preferred implementations to ensure optimal performance. and Supplementary Figure S1 and S2).Through automatic benchmarking of each implementation, the Liquid Engine keeps an historic record of runtimes for each implementation.Whenever a workflow is scheduled to be run, the supervisor agent is responsible to select the optimal implementation based on the previous recorded run times.The agent can adapt to unexpected delays in any implementation (Supplementary Figure S5).In case a severe delay is detected, reaching a level where it could potentially lead to a different implementation becoming faster, the agent predicts if the optimal implementation has changed.For that, the agent predicts the likelihood of the delay being repeated in the future and then assigns a probability for each implementation that depends on an estimation of the expected run time that each one might take.For instance, if the fastest implementation for a method uses OpenCL (17) and the GPU is under heavy load, resulting in an abnormally prolonged run time that is longer than the second fastest, the agent activates its delay management (Supplementary Figure S6).All available implementations are now assigned a probability that is a function of their expected run time, as given by the average values measured in the past.The expected run time for the delayed implementation is adjusted based upon the probability that the delay is maintained and the magnitude of the measured delay itself.Therefore, in this example, the probability the agent chooses to run using OpenCL is low, especially if the delay is continuously maintained.However, the delayed implementation should always have a bigger than zero probability to be chosen.Due to this probabilistic approach, the agent will still select and use the delayed implementation from time to time.This ensures that it can detect when the delay is over.Once it detects that the delay is over, the agent goes back to selecting implementations based only on the fastest average run time.In the example of Supplementary Figure S6, the Liquid Engine was able to detect an artificial delay that slowed down the OpenCL implementation.During the delay, the OpenCL implementation was used less times, but stochasticity allowed the Engine to detect the end of the delay.In this example, over the course of several sequential runs of the same method, we show that delay management improved the average run time by a factor of 1.8 for a 2D convolution and 1.5 for an eSRRF analysis (Supplementary Figure S6).Users can also manually initiate benchmarking, prompting the Liquid Engine to profile the execution of each implementation, using either multiple automatically generated data loads or using their own input, and identify the fastest one.This benchmarking is performed per task, allowing the Liquid Engine to adapt to the user's hardware configuration and progressively optimise the chosen combination of implementations to reduce the total run time.The system analyses similar benchmarked examples from the user's past data, using fuzzy logic (23) (see Supplementary Note 4) to identify the benchmarked example with the most similar input properties, utilising it as a baseline for the expected execution time.This system enables NanoPyx to immediately make adaptive decisions based on an initially limited set of benchmarked examples, progressively learning, and improving its performance as more data is processed.

The NanoPyx Framework
NanoPyx is a comprehensive and extensible bioimage analysis framework providing wide-ranging methods which can cover an entire bioimage analysis microscopy workflows.
In Figure 4 Decorrelation Analysis (14) to determine image resolution.These various assessment methods enable a comprehensive quantitative evaluation of the resolution improvements achieved by the super-resolved reconstruction.NanoPyx also allows users to perform channel registration on the acquired or super-resolved images.

Distribution to end users
NanoPyx was developed with the primary objective of ensuring accessibility and ease of use for end users.To achieve this goal, we have made available three distinct interfaces through which users can interact with and utilise NanoPyx.Firstly, NanoPyx is accessible as a Python library (Figure 4), which can be conveniently accessed and installed via PyPI (Python Package Index) for stable releases or through our GitHub repository for the latest development versions.The Python library primarily targets developers seeking to incorporate NanoPyx's methodologies into their workflows.Alongside the Python library we provide template files to help developers implement their own methods using the Liquid Engine.Secondly, we have provided Jupyter notebooks (15) through our GitHub repository (Figure 4 and Supplementary Figure S7).Each notebook offers separate implementations of each individual method.Users of these notebooks are not required to interact with any code directly: by sequentially executing cells, a graphical user interface (GUI) is generated (24,25), enabling users to fine-tune the parameters for each step easily.
Consequently, these notebooks are specifically designed for users with limited coding expertise.Lastly, for users desiring a more interactive approach, we are concurrently developing a plugin for napari (16), a Python image viewer, granting access to all currently implemented NanoPyx methods (Figure 4 and Supplementary Figure S7).By offering these three diverse user interfaces, we ensure that NanoPyx can be readily utilised by users irrespective of their coding proficiency level.NanoPyx also offers a wide range of example datasets for the users to test and explore its capabilities (see Supplementary Note 5).

Discussion and Future Perspectives
NanoPyx introduces a novel approach to optimise performance for bioimage analysis through its machine learningpowered Liquid Engine.This enables dynamic switching between implementations to maximise speed based on data and hardware.In initial experiments, NanoPyx achieves over 10x faster processing by selecting the optimal implementation.This has significant implications given the rapidly expanding scale of microscopy image datasets.The Liquid Engine's optimisation strategy diverges from traditional approaches of relying on single algorithms or implementations.Alternative Python tools like Transonic (26) and Dask (27)  Sample preparation for microscopy.A549 cells were seeded on a glass bottom µ-slide 8 well (ibidi) at a 0.05 -0.1 x 106 cells/cm2 density.After 24 h incubation at 37 °C in a 5% CO2 incubator, cells were washed once using phosphatebuffer saline (PBS) and fixed for 20 min at 23 °C using 4 % paraformaldehyde (PFA, in PBS).After fixation, cells were washed three times using PBS (5 min each time), quenched for 10 min using a solution of 300 mM Glycine (in PBS), and permeabilised using a solution of 0.2% Triton-X (in PBS) for 20 min at 23 °C.After three washes (5 min each) in washing buffer (0.05% Tween 20 in PBS), cells were blocked for 30 min in blocking buffer (5% BSA, 0.05% Tween-20 in PBS).Samples were then incubated with a mix of anti-α-tubulin (1 µg/mL of clone DM1A, Sigma; 2 µg/mL of clone 10D8, Biolegend; 2 µg/mL of clone AA10, Biolegend) and anti-septin 7 (1 µg/mL of #18991, IBL) antibodies for 16 h at 4 °C in blocking buffer.After three washes (5 min each) using the washing buffer, cells were incubated with an Alexa Fluor™ 647 conjugated goat anti-mouse IgG and an Alexa Fluor™ 555 conjugated goat anti-rabbit IgG (6 µg/mL in blocking buffer) for 1 h at 23 °C.Cells were then washed thrice (5 min each) in washing buffer and once in 1X PBS for 10 min.Finally, cells were mounted with a GLOX-MEA buffer (50 mM Tris, 10 mM NaCl, pH 8.0, supplemented with 50 mM MEA, 10% [w/v] glucose, 0.5 mg/ml glucose oxidase, and 40 µg/ml catalase).
For channel 0, a dichroic filter with the bands of 498-551 nm and 576-620 nm was used; for channel 1, a 665-705 nm dichroic filter was used.The sequential multicolor acquisition was performed for AlexaFluor647, AlexaFluor555 and Hoechst-33342.Using an EPI-fluorescence illumination, a pulse of high laser power (90%) of the 640-nm laser was used, and 10 000 frames were immediately acquired.Then, the sample was excited with the 488-nm laser (13.7% laser power), whereas 500 frames were acquired, followed by the 405-nm laser excitation (40% laser power), with an acquisition of another 500 frames.For all acquisitions, an exposure time of 10 ms was used.
Liquid Engine's agent.Run times of methods implemented in NanoPyx through the Liquid Engine are locally stored on users' computers and are associated with the used hardware.For OpenCL implementations, the agent also stores an identification of the device and is capable of detecting hardware changes.Whenever a method is run through the Liquid Engine, the overseeing agent splits the 50 most recent recorded runtimes into 2 halves: one with the 25 fastest run times (fast average) and one with the 25 lowest (slow average).Then it calculates the average of the 25 fastest run times for each implementation and selects the implementation with the lowest average runtime.Once the method finishes running, the agent checks whether there was a delay, which is defined by the last runtime being higher than the previously recorded average runtime of the fastest runs plus four times the standard deviation of the fastest runs (Equation 1).If a delay is detected (Supplementary Figure S5), the agent will also calculate the delay factor (DF, Equation 2) and will activate a probabilistic approach that stochastically selects which method to run.This is performed by using a Logistic Regression model to calculate the probability of the delay being present on the next run and adjusting the expected runtime of the delayed implementation according to Equation 3, while still using the fast average for all non-delayed implementations.Then, the agent picks which implementation to use based on probabilities assigned to each implementation using 1 over the squared normalized expected runtime (Equation 4).This stochastic approach ensures that the agent will still run the delayed implementation from time to time to check whether that delay is still present.The agent decides that the delay is over once the last runtime becomes smaller than the slow average minus the standard deviation of the slowest runs or higher than the fast average plus the standard deviation of the fastest runs (Equation 5).Once the delay is over, the agent will go back to selecting which implementation to use based only on the fast average of each implementation (Supplementary Figure S6).
NanoPyx comparison with NanoJ.Run times of eSRRF image processing were measured using a MacBook Air M1 with 16Gb of RAM and a 512Gb SSD.The parameters used for the analysis where the same for both NanoPyx and NanoJ: magnification -5; radius -1.5; sensitivity -2; number of frames for SRRF -1.The input image was a stack with 283 by 283 pixels and 10 000 frames.For the final image output an average reconstruction was performed.
Junior Leader Fellowship (LCF/BQ/PI20/11760012) financed by "la Caixa" Foundation (ID 100010434) and by European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 847648, and a from a Maratona da Saúde award.This study was supported by the Academy of Finland (338537 to G.J.), the Sigrid Juselius Foundation (to G.J.), the Cancer Society of Finland (Syöpäjärjestöt; to G.J.), and the Solutions for Health strategic funding to Åbo Akademi University (to G.J.).This research was supported by InFLAMES Flagship Programme of the Academy of Finland (decision number: 337531).

EXTENDED AUTHOR INFORMATION
• Bruno M. Saraiva: 0000-0002-9151-5477; Bruno_MSaraiva • Inês Martins Cunha: 0000-0002-1327-9018; inesmcunha • António D. Brito: 0009-0001-1769-2627; Antonio_DBrito • Gautier Follain: 0000-0003-0495-9529; Follain_Ga • Raquel Portela: 0000-0002-5559-9554; RaquelP02997757 • Robert Haase: 0000-0001-5949-2327; haesleinhuepf • Pedro Matos Pereira: 0000-0002-1426-9540; MicrobeMatos • Guillaume Jacquemet: 0000-0002-9286-920X; guijacquemet • Ricardo Henriques: 0000-0002-2043-5234; HenriquesLab Python (.py), Cython (.pyx), and OpenCL (.cl) files.In practice, for most tasks implemented in the Liquid Engine, we used a single-threaded version of the code as the original tag, and created multi-threaded versions of the code by replacing the range in the for loops with prange.Additionally, we added implementations with different schedulers for the parallelisation.This allows the developer to easily create as many code variations as they find necessary.This approach streamlines the process of maintaining consistency across various code implementations, as altering the code in one version ensures that the modification is seamlessly and consistently applied to all other relevant versions.As a result, developers can effectively manage code updates and improvements, as these are propagated into the other implementations effortlessly, reducing redundancy and enhancing code maintainability.Another meta-programming tool used in the Liquid Engine is the c2cl tool.c2cl is analogous to the tag2tag tool, but specifically designed to extract C functions and propagate them into .clfiles, so the C functions can be used in OpenCL kernels.Manual conversion of these adaptations would be time-consuming and prone to errors, which is where c2cl comes in.The tool automates the process of porting C code to OpenCL by extracting reusable code blocks from the C functions, converting the C code into valid OpenCL kernels, and inserting the modified kernels back into the OpenCL file.The Liquid Engine also supports Numba as an alternative performance-boosting option for Python code snippets.With all these implementations, NanoPyx can be run and used by users with diverse hardware configurations.Overall, the Liquid Engine extensively uses meta-programming techniques to avoid manual coding.Code generation and transformations are used to automatically create specialised implementations, resulting in a simple and flexible architecture.

Fig. 1 .
Fig. 1.Schematic representation of the NanoPyx framework.NanoPyx is a Python framework for super-resolution microscopy images.It uses the Liquid Engine for self-tuning high performance.Currently, NanoPyx offers methods for Image Registration (1), Radial Fluctuations (2), and Quality Control (3) categories.
Notable methods exploiting NanoJ (1) include NanoJ-SRRF(2)  and NanoJ-eSRRF(18) which generate super-resolution reconstructions from diffraction-limited image sequences; and NanoJ-SQUIRREL (3) which provides image quality and resolution analysis.Bringing the adaptability of the Liquid Engine into these methods allows NanoPyx to overcome many limitations of NanoJ and other modern bioimage analysis packages.By providing a flexible framework we can assure accessibility of both new and old image analysis pipelines regardless of the user hardware, with further performance enhancement.Furthermore, we can leverage this flexibility and use it in conjunction with other Python libraries and tools.This is particularly valuable as many methods increasingly rely on Python-based deep learning techniques, making the use of current analysis frameworks (such as NanoJ (1)) prohibitive in specific scenarios.As part of NanoPyx, users can access critical features, including drift correction (1), channel registration (1), SRRF

Fig. 3 .
Fig.3.NanoPyx achieves optimal performance by exploiting the Liquid Engine self-optimisation capabilities.The image analysis workflows of NanoPyx are built on top of the Liquid Engine, which automatically benchmarks implementations of all tasks in the specific workflow.The Liquid Engine keeps a historical record of the run times of each task and the shape of the used input, allowing a machinelearning-based agent to select the fastest combination of implementations.In the case of an unexpected delay, the agent dynamically adjusts the preferred implementations to ensure optimal performance.

Fig. 4 .
Fig. 4. Microscopy image processing workflow using NanoPyx methods.NanoPyx implements several methods of super-resolution image generation and processing.Through NanoPyx, users can correct drift that occurred during image acquisition, generate a super-resolved image using enhanced radiality fluctuations (eSRRF)(2), assess the quality of the generated image using Fourier Ring Correlation (FRC)(13) or Image Decorrelation Analysis (14), perform artifact detection using the error map and then perform channel registration in multi-channel images.NanoPyx methods are made available as a Python library, a napari plugin, and Jupyter Notebooks that can be ran locally or through Google Colaboratory.Scale bars: 10 µm.
Fig. S2.Ratio between the run times of a 2D convolution.Run times were measured across multiple input data sizes and kernel sizes using either a MacBook Air M1 (A) or a Professional Workstation (B).Areas within dashed lines correspond to kernel and image sizes where OpenCL is faster than threaded CPU.

Fig. S3 .
Fig. S3.Run time of each implementation is highly dependent on the shape of input data.A 2D convolution was performed on images with increasing size using either a MacBook Air M1 (A) or a professional workstation (B).A 21 by 21 kernel was used in all operations.When using the MacBook laptop, interestingly the PyOpenCL implementation is the fastest until 125MB after which the Cython threaded implementations become significantly faster.In the professional workstation, while unthreaded is virtually always the slowest implementation, the threaded implementations are only the fastest until the size increases to 20MB, after which PyOpenCL becomes the fastest.

Fig. S4 .
Fig. S4.Kernel size impacts which implementation is the fastest.A 2D convolution was performed on images with varying kernel sizes, ranging from 1 to 21 (every 4) using either a MacBook Air M1 (A) or a professional workstation (B).A 21 by 21 kernel was used in all operations While unthreaded is virtually always the slowest implementation, the threaded implementations are only the fastest until the size increases to 20MB, after which PyOpenCL becomes the fastest.Bottom panels correspond to zoomed in windows of top panels, indicated by dotted boxes.

Fig. S6 .
Fig. S6.Example of delay management by the Liquid engine.Multiple two-dimensional convolutions (A) and eSRRF analysis (B) were run sequentially in a professional workstation.Starting from two initial benchmarks, the agent is responsible to inform the Liquid Engine is what is the best probable implementation.An artificial delay was induced by overloading the GPU with superfluous calculations in a separate Python interpreter.

Fig. S7 .
Fig. S7.NanoPyx is available to users independently or their coding expertise.Besides the using NanoPyx as a Python library, users also have access to Jupyter notebooks (10) (A) that can either be run locally or through Google Collaboratory and a napari (11) plugin (B).

0.60 ms Benchmark Laptop Professional Workstation 7.8 ms 0.068 s 0.58 s 5.2 s 30 s CPU Analysed Input Data (10, 10, 10) (10, 300, 300) (500, 300, 300)
Fig. 2. Comparative run times of multiple implementations of an algorithm, ran on either a consumer-grade laptop or a professional workstation.The fastest (rabbit) and slowest (snail) implementations depend on the shape of the real-time during acquisition, NanoPyx's accelerated performance becomes critical.We plan to leverage the Liquid Engine's auto-tuning capabilities to optimise pipelines on heterogeneous hardware.This could enable real-time AI to guide data collection, processing, and analytics.Additionally, we aim to incorporate more diverse reconstruction approaches beyond current methods like SRRF and eSRRF.
that accelerate workflows through just-intime compilation or parallelism do not adapt implementations based on context.In contrast, the Liquid Engine continually benchmarks and collects runtime metrics to train its diverse hardware will maximize performance from laptops to cloud platforms.Enhancing usability through graphical interfaces will improve accessibility.Fostering an open-source community will help drive continual innovation.Looking ahead, a priority for NanoPyx is expanding support for emerging techniques like AI-assisted imaging and smart microscopes.As these methods involve processing data in