Description:A SYSTEM AND METHOD FOR CONFIGURABLE DIRECTED ACYCLIC GRAPH (DAG) BASED IMAGE PROCESSING

FIELD OF INVENTION
The present invention relates to the field of medical image processing, and more particularly, to a configurable system and method for constructing, validating, and executing image processing flows in clinical imaging environments. Specifically, the invention enables the use of dynamically generated directed acyclic graphs (DAGs) based pipeline structure to represent and manage the flow of medical image data through a series of modular image processing threads, based on selected imaging modes or user-defined configurations, enhancing adaptability, efficiency, and error prevention in image-guided diagnostic and interventional procedures.

BACKGROUND OF THE INVENTION
Image processing in medical imaging systems, such as those used in catheterization laboratories, has traditionally been implemented using fixed processing threads. In such systems, each image frame is subjected to a predetermined sequence of operations such as denoising, gamma correction, and edge enhancement. These sequences are rigid, with each processing step executed in a fixed order, irrespective of the imaging mode or clinical requirement. While effective for basic applications, this fixed structure limited flexibility and adaptability in real-time clinical environments.

To improve adaptability, subsequent systems introduced mode-specific strings where different sets of processing steps could be activated for different imaging modes. These modes allowed selection of relevant processes such as noise suppression for fast acquisition or enhanced filtering for contrast-sensitive procedures. However, the underlying execution order remained largely constrained, and users had little control over reordering or skipping individual processes, even when certain steps were unnecessary for a particular imaging task.

In these configurable systems, a repository of processes could be defined, but typically all processes were instantiated regardless of their clinical relevance. This often resulted in higher computational load and latency, with redundant processes consuming resources and slowing down image throughput. In some cases, inactive or undefined processes introduced inconsistencies in the flow, leading to execution errors or unpredictable results.
Another limitation arose in the management of process flows. Without robust validation, user-defined or system-generated flows could form cyclic dependencies. Such cycles caused loops in processing, leading to instability and blocking of image data strings. Conventional systems did not provide comprehensive validation mechanisms to prevent such issues, leaving them vulnerable to execution errors.

Parallel image processing also presented challenges. While multi-threaded approaches were adopted, they often relied on shared resources and complex synchronization techniques, which could result in race conditions, deadlocks, or accumulation of frames in thread queues. These problems adversely affected frame rate and real-time performance, which are critical in clinical imaging applications.

Indexing and parameter management further added to the complexity. Conventional systems lacked a structured mapping between processes and their parameters, making it difficult to manage configuration across different imaging modes. In addition, thread parameters such as gamma or enhancement levels were fixed at startup, offering no flexibility in runtime adjustment, thereby limiting adaptability across varied imaging scenarios.

Despite these incremental developments, existing systems continued to face significant limitations, including rigid execution sequences, lack of robust validation for process flows, inefficient handling of inactive processes, risks of cyclic dependencies, and difficulties in managing thread concurrency without performance loss. These shortcomings created persistent challenges in achieving reliable, flexible, and efficient real-time image processing tailored to diverse clinical imaging requirements.

The prior art, such as US2007150877A1, describes a medical image display and processing system that applies a series of enhancement and transformation functions using predefined processing modules. These modules are selected based on clinical tasks or modalities and are applied in a fixed sequence. The system includes a controller that selects appropriate modules depending on the metadata or context of the imaging procedure. The design emphasizes workflow automation but relies on static routing through processing units using configuration files that define fixed execution paths. The system supports flexible module selection but does not introduce any pipeline structure or validation mechanisms for string configuration.

The prior art, such as US20240311195A1, discloses an image processing framework focused on medical imaging, particularly employing multiple sequential processing stages such as contrast enhancement, noise suppression, and structural adjustments. These processing steps are controlled by predefined rules, and the system adapts its execution flow based on image properties or clinical conditions. However, D2 maintains a structured and linear approach, managed by a central control logic, without using pipeline structure of flow or dynamic validation techniques. The control unit governs execution, and the system reacts to input signals or environmental cues but does not depict or validate flows through a pipeline structure.

The prior art, such as CN101710286A, outlines a medical image processing method in which enhancement and correction operations are performed in a strict, linear fashion. The operations are applied based on the imaging type, such as CT or MRI, and are optimized for diagnostic accuracy and image clarity. D3 emphasizes real-time performance and quality consistency but structures its processing as a rigid sequence of predefined operations. There is no mention of dynamic configuration, flow validation, or graphical models of thread sequences.

Hence, medical image processing systems often suffer from rigid and predetermined thread sequences, making it difficult to adapt processing flows to specific imaging modes and clinical requirements. Existing approaches do not provide reliable validation against cyclic dependencies or inactive processes, nor do they optimize execution to bypass unnecessary steps, leading to instability, increased latency, and reduced frame rates in real-time applications.

OBJECTS OF THE INVENTION
The principal objective of the invention is to provide a processing module adapted to generate a directed acyclic graph (DAG) based pipeline structure of the image processing flow with nodes representing processing threads and edges representing directed data flow.

Another objective of the invention is to provide a validation module configured to parse the pipeline structure, perform cycle detection using a graph traversal algorithm such as Depth-First Search (DFS), and block activation if a cycle is detected, thereby ensuring that processing threads are executable only along acyclic paths.

Another objective of the invention is to ensure that the validation module verifies active thread entries and index mapping so that each node in the pipeline structure corresponds to a valid and active thread.

Another objective of the invention is to perform all verification operations, including cycle detection, active thread verification, and index matching, during a configuration phase prior to execution, so that only successfully validated flows are processed in real time.

Said and other objects of the present disclosure will be apparent to a person skilled in the art after consideration of the following summary of subject matter as claimed, detailed description taken into consideration with accompanying drawings in which preferred embodiments of the present disclosure are illustrated.

SUMMARY OF THE INVENTION
It is therefore a general aspect of the embodiments to provide a configurable image processing system tailored for clinical imaging applications. At its core, the system includes a memory unit that stores different imaging mode configurations, with each mode defining a specific set of image processing threads and the order in which they should be applied to the imaging data. These threads are visually represented as nodes in a graph, and the sequence of processing is shown using directed edges that describe how data flows from one thread to another. A processing module is provided to interpret the imaging mode data and to generate DAG based pipeline structure of the image processing flow.
A validation module check that the pipeline structure is safe and functional. This validation includes a cycle detection step, which ensures there are no loops in the processing flow. To do this, the system uses a Depth-First Search (DFS) algorithm—a well-known graph traversal technique that is fast and reliable for finding cycles. This means the system can prevent infinite processing loops and only execute valid, safe processing flows.
The system also verifies that every image processing thread used in the selected imaging mode is available and active. To manage this, the memory includes a database of all threads, including their activation status across different imaging modes. The validation module checks that all threads marked as “active” in a mode’s configuration are also present and usable in the database. This prevents errors caused by trying to use inactive or missing threads.
Each thread is also given a unique index, and the system maintains a thread index map. This allows the validation module to confirm that every node in the graph correctly corresponds to a real, defined thread. This index-matching check ensures consistency between the flow structure and the stored thread data.
All of these checks—cycle detection, thread availability, and index validation—are performed during a configuration phase, before any actual image processing takes place. This ensures the system only operates on verified, stable configurations, reducing the risk of runtime errors.
According to an embodiment, the system includes a user graphical interface that lets users modify the flow in real time by adding, removing, or reordering threads to support user interaction. After each change, the system revalidates the graph before allowing execution. This flexibility supports custom workflows while ensuring safety and consistency. .
Once validated, the system executes the flow such that each image frame passes through a given processing thread only once, preventing repetitive processing and reducing computational load. Additionally, the system is designed to handle multiple image frames in parallel, allowing each frame to progress independently through the system without waiting for others.
To coordinate this concurrent processing, a scheduler ensures that no two image frames use the same thread at the same time, thereby avoiding thread conflicts or data mix-ups. This ensures smooth, accurate, and high-throughput image processing suitable for real-time clinical use.
In an embodiment, a method for configuring and executing an image processing flow for clinical imaging applications. This method begins with storing, in a memory unit, various imaging mode entries. Each imaging mode includes a set of image processing threads—such as enhancement, filtering, or noise suppression modules—and a predefined order in which these threads should process incoming imaging data. These configurations serve as templates for how the system should behave under different clinical scenarios, such as angiography or fluoroscopy.
Next, a processing module reads the selected imaging mode information and creates a visual representation of the processing flow in the form of a directed graph. In this graph, each node represents a processing thread, while the directed edges indicate the flow of data between threads—i.e., the output of one thread becomes the input of another. This DAG based pipeline structure helps define the actual execution string.
Before any image data is processed, a validation module performs checks on this pipeline structure to ensure safety and correctness. First, it parses the pipeline structure. Then, it applies a graph traversal algorithm to detect if the graph contains any cycles. Cycles are loops in the processing flow that could lead to infinite processing or system crashes. If a cycle is found, the system blocks the execution of the flow, thereby avoiding potential failures during real-time operation.
Only if the pipeline structure passes all validation checks is the image processing flow activated. At that point, the system proceeds to receive actual imaging data, which is processed in real time according to the validated flow corresponding to the selected imaging mode. This ensures that the system only runs safe and predefined configurations, improving the reliability and adaptability of clinical imaging workflows.
BRIEF DESCRIPTION OF DRAWINGS
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identify the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and modules.

Figure 1 describes the system architecture in accordance with an embodiment of the invention.

Figure 2 shows DAG-based image processing string.

Figure 3 shows an example of concurrent frame execution along a string.

Figure 4 illustrate method for configuring an image processing flow for clinical imaging.

Figure 5 shows User interface layout for image processing thread configuration.

Figure 6 (a-d) shows User interface layout for adding an image processing thread.

Figure 7 (a-b) shows User interface layout for deleting an image processing thread.

Figure 8 (a-e) shows User interface layout for moving up/down an image processing thread.

The figures depict embodiments of the present subject matter for the purposes of illustration only. A person skilled in the art will easily recognize from the following description that alternative embodiments of the method and composition illustrated herein may be employed without departing from the principles of the disclosure described herein.

DETAILED DESCRIPTION
The best and other modes for carrying out the present invention are presented in terms of the embodiments, herein depicted in drawings provided. The embodiments are described herein for illustrative purposes and are subject to many variations. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient, but are intended to cover the application or implementation without departing from the spirit or scope of the present invention. Further, it is to be understood that the phraseology and terminology employed herein are for the purpose of the description and should not be regarded as limiting. Any heading utilized within this description is for convenience only and has no legal or limiting effect.

The terms “a” and “an” herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced items.

The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other, sub-systems, elements, structures, components, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.

For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as would normally occur to those skilled in the art are to be construed as being within the scope of the present invention.

It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof.

Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this invention belongs.

The system and method provided herein are only illustrative and not intended to be limiting. Embodiments of the present invention will be described below in detail with reference to the accompanying figures.

The present invention provides a configurable image processing system designed to streamline and validate clinical imaging workflows using a Directed acyclic graph (DAG)-based model of execution. At the core of the system is a memory unit that stores imaging mode information, where each imaging mode defines a unique string of image processing threads and a specific pattern for their execution. This data serves as the basis for generating a pipeline structure of the image processing flow. A processing module interprets the selected imaging mode and creates this graph, while a validation module performs critical pre-execution checks. A key aspect of the invention is its flexibility—users can interact through a graphical user interface (GUI) to select predefined modes or define custom thread configurations by adding, removing, or reordering threads in real time.

This architecture facilitates adaptive, real-time clinical imaging workflows, offering scalability, efficiency, and high reliability—critical for diagnostic and interventional procedures.

Fig. 1 shows the architecture of configurable image processing system (10). The configurable image processing system (10) comprises a thoughtfully layered set of components that work in tandem to provide a flexible, reliable, and validated image processing workflow tailored to various clinical imaging modes.

At the heart of the configurable image processing system (10) lies the Memory Unit (11), which stores a set of predefined imaging modes (Imaging Mode 1…n). Each imaging mode is structured around a string (1..n) with a predefined Thread and Pattern, which specifies not only the set of image processing threads to be used but also their execution pattern—showing how threads are connected and the order in which they must operate. This execution pattern is essentially a recipe for constructing a Directed Acyclic Graph (DAG) that governs the flow of image data during clinical imaging modes such as Low-Dose Fluoroscopy, Roadmap Imaging, Coronary Angiography, Contrast-Enhanced Imaging, Valve Placement, Diagnostic Angiography etc. The DAG ensures that the system operates along acyclic paths, thereby preventing deadlocks or repetitive processing loops.

Each thread in this system (10) is a modular software block responsible for a specific transformation or enhancement of the image data. Examples include Noise Reduction, Edge Detection, Frame Averaging, Contrast Enhancement, Registration, and Temporal Filtering. These threads are modular and reusable, meaning they may appear in multiple imaging modes but in different sequences or combinations. For instance, in Low-Dose Fluoroscopy, performance is optimized by disabling non-essential enhancement threads (such as AIPEnhance) to reduce processing latency. Conversely, in Coronary Angiography, threads that enhance contrast may be activated to improve vessel visualization. Thus, each imaging mode functions as a string of interconnected threads, uniquely configured to serve a particular diagnostic purpose.

At the heart of this mechanism is the Processing Module (12), which is responsible for converting imaging mode data into a pipeline structure of the flow. When a user selects an imaging mode via the UI, the processing module (12) fetches the corresponding thread and pattern definition from the memory unit (11). It then parses the configuration string (1…n) into a set of nodes and directed edges, creating an in-memory DAG (shown in Fig. 2). Each node represents a specific thread, identified by its index and attributes, while edges define how the output of one thread connects to the input of another. This representation ensures that threads are not just listed in sequence but structurally connected in a way that captures both linear and branching workflows. For example, while the sample flow is linear, the DAG architecture also supports branches (e.g., one thread feeding two others) and merges (multiple threads feeding a single node), provided that the DAG based pipeline structure remains acyclic.
Fig.2 shows an example of DAG-based image processing string with clear roles for each component. At the start, there is an input node (0) where the image frames first enter the system and ends at a defined output point (20). Between this, the images move into one of several image processing threads indexed from 1 to 16. Each thread corresponds to a distinct processing function—for example, ADR (adaptive dynamic range), Magnification, Geometry correction, Mean Log, Log, Mean Gamma, Live Gamma, ADE, Mean Filter, Sharpen, AIPEnhance, IPM, Display Gamma, Brightness, Contrast, and Invert. These threads are the building blocks of the string.
The Processing Module (12) takes the configuration string (120)—such as the example “0:1, 1:4, 4:5, 5:11, 11:16, 16:20”—and converts it into a Directed Acyclic Graph (DAG) shown in Fig. 2. For example, the string is "0:1, 1:4, 4:5, 5:11, 11:16, 16:20". Here Thread 1 = ADR Process, Thread 4 = Mean Log Process, Thread 5 = Log Process, Thread 11 = AIP Enhance, Thread 16 = Invert Process. Further, Each edge pair (X: Y) represents that the output of thread X serves as the input for thread Y. The processing module (12) obtain the string (120) and builds an in-memory directed graph. Concretely, the module (12) binds thread 1 (ADR) as the first stage, routes its output to thread 4 (Mean Log), then to thread 5 (Log), then to thread 11 (AIP Enhance), then to thread 16 (Invert), and finally to node 20 for output—exactly the linear path depicted in Fig. 2. In other words, the module realizes the stepwise flow “0→1 (ADR) →4 (Mean Log) →5 (Log) →11 (AIP Enhance) →16 (Invert) →20 (Output)” by creating node objects for indices 0, 1, 4, 5, 11, 16, 20 and connecting them with directed edges in that order. This construction obeys the overall architecture shown in Fig. 1. The system (10) exposes a fixed library of threads indexed 1–16 (e.g., ADR, Mag, Geometry, Mean Log, Log, Mean Gamma, Live Gamma, ADE, Mean Filter, Sharpen, AIP Enhance, IPM, Display Gamma, Brightness, Contrast, Invert), and the Processing Module (12) interprets a JSON/config string to wire them into a DAG for the selected mode; the resulting DAB based pipeline structure is then handed to validation module (13) and, if accepted, becomes the executable flow for incoming frames. Thus, as per Fig. 2, the Processing Module translates the edge list into the concrete node-and-edge structure that drives a string at runtime, while still supporting the broader capability to skip or reorder threads as per clinical requirement or imaging modes, so long as the pipeline structure remains acyclic. By converting simple configuration strings into DAGs, the Processing Module enforces correctness, scalability, and adaptability in clinical image processing.
This DAG based pipeline structure is then handed to the Validation Module (13) before execution can begin. The Validation Module (13) is the safety gatekeeper of the configurable image processing system (10). It performs cycle detection checks (130) which is a key function, to ensure that the string (120) representing the image processing flow is safe, executable, and properly aligned with the database (15) before real-time execution begins. In cycle detection (130), the module (13) parses the pipeline structure representation of the flow and applies a traversal algorithm such as depth-first search, to ensure that the flow is acyclic. Finally, the validated flow is executed, with images moving step-by-step through the DAG until reaching the output node (20) (shown in Fig. 2). The system (10) also supports skipping non-essential threads (e.g., disabling AIP Enhance in low-dose fluoroscopy to reduce latency) and reordering the string to suit different imaging modes like coronary angiography or roadmap imaging, provided that the DAG principle (no cycles) is preserved. This means no image frame will ever be trapped in an endless loop between threads. If a cycle is detected, execution is immediately blocked.
In an embodiment, the goal in low-dose fluoroscopy is to minimize latency and keep radiation exposure as low as possible. Enhancement threads, while useful for clarity, add computational overhead. These are skipped to prioritize real-time speed and safety. Roadmap mode focuses on overlaying contrast-enhanced vessels onto live fluoroscopy for guidance. Some smoothing or denoising steps may be bypassed because clinicians need immediacy rather than maximum clarity. Coronary angiography emphasizes contrast and vessel visibility. Some optional transformations (like inversion or averaging) may not be needed if the vessel contrast is already sufficient, so they can be skipped. Contrast-Enhanced Imaging mode uses injected contrast agents, and sometimes additional threads like registration are not essential if alignment is already stable. Valve Placement positioning relies more on anatomical landmarks and overlays than on enhanced edge profiles, so some filters may be bypassed. In diagnostic angiography, clinicians often need to see each frame distinctly; temporal averaging or filtering may be omitted to avoid blurring time-resolved features.
In an embodiment, Depth first search (DFS) is a well-known graph traversal technique. It starts at a selected node and explores as far along one branch (or “depth”) of the graph as possible before backtracking. In directed graphs, DFS can be adapted to detect cycles by keeping track of the traversal state of each node
Further, the validation module (13) interacts closely with the Database (15) present in memory unit (11), which maintains three essential elements: the complete set of available image processing threads (150), the activation status of each thread for every imaging mode (151), and the thread index (152) that uniquely identifies each thread for proper alignment in the execution graph. Image processing threads (150) is the complete library of all possible image processing functions supported by the system. Each thread corresponds to a specific processing task like ADR Process, Log Process, Sharpen Process, AIP Enhance, or Invert. These threads act as building blocks that can be combined into different sequences depending on the clinical imaging mode selected. Activation status (151) defines whether a particular thread is enabled (active) or disabled (inactive) in a given mode, because all threads are not required in every imaging mode. For instance, in Low-Dose Fluoroscopy, latency-sensitive operations like AIP Enhance may be disabled to optimize performance, while in Coronary Angiography the same thread would be active to enhance vessel clarity. This mechanism allows the system (10) to customize string for diverse clinical requirements without permanently removing any thread from the system. Thread index (152) is a crucial structure that assigns a unique index number to every image processing thread. The index ensures precise mapping between the pipeline structure of the flow and the database entries. Each node in the DAG (directed acyclic graph) is identified not just by the thread name but also by its index. This prevents ambiguity when different imaging modes reuse the same threads in different patterns.
The Validation Module (13) further performs two major checks to guarantee correctness and safety. It conducts Thread Availability Verification (131) to confirm that every thread called by the string (120) both exists in the database (15). The module (13) ensures that the thread exists and is marked as active for the selected imaging mode. Inactive threads are never instantiated, so if one is erroneously referenced, the module halts validation and blocks execution.
Additionally, Index Matching (132) verifies that every node in the pipeline structure corresponds to a valid thread index in the database. This ensures that the flow does not point to an invalid or mismatched thread. Only when every index aligns with a valid thread entry does validation succeed.
Suppose the database (15) contains the following threads: Index 1: ADR Process, Index 4: Mean Log Process, Index 5: Log Process, Index 11: AIP Enhance Process and Index 16: Invert Process. Now consider a flow defined by the edges: 0:1, 1:4, 4:5, 5:11, 11:16, 16:20.
The validation module (13) uses the index map to confirm that each referenced index (1, 4, 5, 11, 16) corresponds to a valid thread in the database. It also checks that each of those threads is active in the selected imaging mode. For e.g., AIP Enhance is active in Coronary Angiography but inactive in Low-Dose Fluoroscopy. If any index does not exist in the thread index map, or if it exists but is inactive in the mode, validation fails, and the Error Module (16) issues an alert. If all checks pass, the validated directed acyclic graph (DAG) is stored and used for real-time execution. At that point, imaging data subsequently entering the system (10) is guaranteed to flow only through a verified, acyclic, and mode-consistent string.

In an embodiment, the system (10) supports different validation strictness levels, which gives flexibility depending on clinical or operational requirements. In some embodiments, the system (10) may only require two-element mapping. For example, a lightweight validation could check only that a thread exists and is active (Thread + Activation Status), or that a thread exists and is correctly indexed (Thread + Index). This reduces overhead and speeds up configuration, but carries the risk that a thread may be referenced by index while inactive, or active but mis-indexed. The more robust approach, and the one emphasized in the documents, is all-three mapping (Thread + Activation Status + Index). This comprehensive validation ensures that the thread exists, is active in the chosen mode, and is properly indexed in the database. Although this introduces slight additional processing during configuration, the overhead is minimal compared to the gain in reliability and clinical safety.

In practice, the two-element mapping approach may be suitable in research, testing, or training contexts where performance is prioritized over strict safeguards. In contrast, all-three mapping is the preferred embodiment in clinical use because it maximizes safety, ensures consistency, and prevents misconfiguration that could otherwise compromise imaging results. By combining memory, validation, and error management, the system guarantees that only verified, acyclic, and mode-consistent strings are executed on clinical image data, balancing flexibility with strict reliability.

Lastly, the User Interface (14) is the central command hub of the configurable image processing system (10). It enables clinicians and technicians to control and monitor backend operations such as memory access, graph construction, validation, and error handling in a manner that is both intuitive and clinically safe. Each of the components shown in Fig. 1 highlights the layered importance of the UI (14). Its primary role is to ensure that highly technical workflows are made accessible, reliable, and safe for real-world clinical use.

Through the UI (14), users can initiate the system by selecting predefined imaging modes (140) (e.g., coronary angiography or low-dose fluoroscopy), uploading external images (142) for analysis, or creating entirely custom workflows via input (141). When an imaging mode (140) is selected, the UI (14) automatically communicates with the memory unit to fetch the corresponding thread-pattern string, which defines the image processing sequence. Each modification of thread flow or mode selection automatically triggers validation. The UI (14) manages this seamlessly by sending the updated string to the Validation Module (13), where cycle detection, availability verification, and index matching occur. This greatly reduces setup time, ensuring clinicians can focus on the patient rather than the technology.

Further, uploading external images (142) through the User Interface (14) gives clinicians or technicians the flexibility to work with imaging data that does not originate directly from the system’s (10) own acquisition sources. This feature is particularly valuable when images are imported from external diagnostic equipment, pre-recorded studies, or reference datasets. When an operator chooses this option, the UI (14) provides a dedicated panel or file selection tool to browse and upload the external image files. Once uploaded, the images are handed over to the Processing Module (12), which treats them like live-acquired frames by routing them into the corresponding thread-and-pattern string of the chosen imaging mode. The Validation Module (13) still performs its checks—verifying that the chosen pipeline is acyclic, threads are active, and indices match—ensuring safety and consistency even for external inputs.
The UI (14) is not a simple display panel but a central, interactive component of the configurable image processing system (10) (shown in Fig. 5). Its primary purpose is to give clinicians and technicians the ability to modify the sequence of image processing threads in real time without having to directly interact with the complex backend logic of the system (10). Through the UI (14), a user input (141) perform three key operations on the string: adding new threads, removing non-essential threads, or reordering existing threads (shown in Fig. 6, 7, 8) to changing clinical requirements. These actions are typically performed through intuitive tools such as drag-and-drop lists, checkboxes, or menu selections. For example, if a clinician wants to adapt the string for coronary angiography, they may add a contrast enhancement thread or reorder enhancement operations to appear earlier in the string. Similarly, in low-dose fluoroscopy mode, they might remove heavy processing threads like AIP Enhance to reduce latency. Each modification instantly triggers the validation module (13) to check for cycles, thread availability, and index mismatches, thereby preventing unsafe configurations. Without such an interface, fine-grained, user-driven customization of imaging workflows would be impractical, and clinical adaptability would be severely limited.
In addition, the UI (14) serves as a visualization and feedback platform. It can display DAG-based execution modelof the processing flow, highlight active versus inactive threads, and provide alerts or logs when errors occur. This makes the system transparent, giving operators confidence in its reliability and making validation outcomes immediately visible. By centralizing all configuration, validation, and execution commands, the UI (14) reduces complexity, consolidates control, and prevents operators from having to manually interact with different modules like the memory or validation units.
Users can reset or reinitialize the current processing flow if a different mode or thread sequence is required mid-session. For example, if a procedure transitions from roadmap imaging to angiography, the UI allows quick re-initialization without restarting the entire system. This enhances real-time adaptability.
The UI (14) allows the operator to trigger database-level checks (e.g., confirming whether a thread exists, whether it is active for the selected mode, and whether its index is valid). This transparency empowers users to cross-check backend integrity without relying solely on automated modules, improving confidence in the string.
Finally, the UI (14) contributes directly to efficiency and safety in clinical practice. By offering a single access point for mode selection, external data handling, string reconfiguration, and error management, it ensures workflows are streamlined, accurate, and traceable. This is particularly critical in imaging environments where time-sensitive decisions depend on both image quality and system reliability.
In an embodiment, if there is no user-defined directed acyclic graph (DAG), the string automatically reverts to a basic linear sequence of threads, ensuring that imaging data can still be processed without requiring explicit configuration. The default sequence typically follows a simplified progression: [0, 1, 2, 3, 4, 5], which corresponds to a basic pipeline of Log → Gamma → Contrast → Filter → Sharpen operations. This ensures that at least essential image enhancement steps are performed, producing clinically usable images in the absence of a custom or mode-specific pipeline. This default pipeline acts as a failsafe mode, allowing imaging sessions to proceed while signaling to the user (via the UI and error logs) that a custom or optimized configuration should be defined for best results. This ensures uninterrupted operation while maintaining reliability and patient safety.
In an embodiment, Error Message (16) block in Fig. 1 plays a crucial role in maintaining safety and reliability of the configurable image processing system (10). Whenever a user-defined or mode-specific configuration is submitted to the Validation Module (13), the system (10) checks the flow for acyclicity (130), thread availability (131), and correct index mapping (132). If any of these checks fail, the error-message (16) is immediately triggered. The invalid configuration is a cycle detected in the graph (i.e., a non-acyclic path), an undefined process ID referenced in the flow, or an inactive process/thread erroneously included in the string (120). Then, the system (10) follows a hard-blocking strategy to prevent unpredictable or unsafe execution. The system (10) logs an error message describing the precise nature of the problem, such as the location of the cycle or the identity of the unavailable thread, blocks execution of the string until the issue is corrected, ensuring that no unsafe or undefined flow can proceed or prompts the user via the UI (14) to correct the configuration. This may involve reordering threads, removing an invalid reference, or selecting an alternate mode. This approach ensures that errors are never silently bypassed or auto-corrected, which could otherwise compromise clinical integrity. Instead, the responsibility for correction remains with the operator, while the system (10) provides clear feedback and guidance through the UI. By combining strict blocking with transparent error communication, the system (10) preserves clinical safety, user accountability, and operational reliability.
The Scheduler (133), as part of the Validation Module (13), is responsible for maintaining orderly and conflict-free execution of frames across the string. It enforces the one-thread-per-frame policy, ensuring that no two frames ever occupy the same processing thread simultaneously. This safeguard avoids race conditions, deadlocks, and thread conflicts that could compromise system stability and image integrity. By coordinating how frames move through the validated thread-and-pattern string (120), the Scheduler (133) dynamically decides whether an incoming frame should wait, reroute, or flush an older frame already present in a given thread.

In case of multiple frames, Parallelism is achieved by assigning each process to its own dedicated thread. Frames entering the string can therefore advance in parallel, each occupying different processing stages. For example, while one frame undergoes ADR Process, another can simultaneously be processed in Gamma Correction, and another in Contrast Enhancement. This string approach maximizes throughput and minimizes latency. Before execution, the Validation Module (13) confirms that the string is acyclic (130), all threads are available (131), and thread indices are valid (132). Once validated, the Scheduler (133) takes over during runtime execution, enforcing exclusivity and enabling concurrent frame progression through the graph.

Hence, each frame is processed independently, which prevents interference. Instead of holding frames in waiting, the system (10) flushes older frames if a new one arrives for the same thread. This ensures responsiveness and avoids accumulation of stale data. Also, the scheduler (133) always prioritizes the most recent frame. If two frames compete for the same thread, the older frame is discarded, ensuring real-time clinical relevance.

Figure 3 illustrates how multiple image frames can move through the image processing string at the same time while following a Directed Acyclic Graph (DAG) structure. Each stage of the string corresponds to a distinct image processing thread. Multiple frames (e.g., Frame A, Frame B, Frame C) enter the system sequentially but start moving through the DAG concurrently. Each frame is tagged with metadata (imaging mode, timestamp, etc.) to ensure proper routing. Frame A might occupy Thread 1 (Mag Process). While Frame A is still being processed, Frame B moves ahead into Thread 2 (AIP enhance Process). Simultaneously, Frame C may already be in Thread 3 (ADE boost Process). Because each frame moves independently, this creates a string-like flow, where multiple frames progress in parallel but in different stages. The concurrency model supports modes like low-dose fluoroscopy (optimized for speed) and coronary angiography (optimized for detail) by letting frames flow through the string without bottlenecks. This prevents deadlocks, avoids waiting queues, and maintains real-time responsiveness.

Figure 4 illustrates a flowchart (40) that represents the method for configuring and executing an image processing flow in a clinical imaging system. This method highlights the sequential stages through which imaging mode configurations are defined, validated, and applied to real-time clinical data.
The process begins with storing (41) imaging mode information in a memory unit. Each imaging mode contains a set of image processing threads and a defined execution pattern, often referred to as a "string." These strings specify the order and connection between threads that process incoming imaging data. For example, in low-dose fluoroscopy mode, certain enhancement threads may be omitted to improve speed, while coronary angiography may include additional contrast enhancement threads for vessel clarity. At this stage, the memory acts as a repository of all possible imaging modes, each pre-configured for different clinical needs. Next, the processing module retrieves (42) the imaging mode string and translates it into a pipeline structure of the image processing flow. This representation takes the form of a Directed Acyclic Graph (DAG), where Nodes represent individual image processing threads and Edges represent the directional data flow between threads, indicating that the output of one thread serves as input to the next. This DAG-based execution model provides a visual and logical map of how image data will flow through the system, enabling both configurability and clarity.
Before execution, the DAG based pipeline structure must be validated (43) by the validation module. This is a critical safety stage and involves multiple checks parsing the graph to ensure its structural correctness, Cycle Detection using graph traversal algorithms like Depth-First Search (DFS). This ensures that the flow is acyclic and that no image processing loop exists and Blocking Execution if any cycle is found. This ensures that only safe, non-cyclic flows can be executed. In addition, validation often involves verifying thread availability, activation status for the chosen mode, and index matching with the database. If any issue arises (e.g., a missing thread, an inactive process being referenced, or invalid indexing), the system raises an error and halts execution. Finally, once validation succeeds, the system proceeds to real-time processing (44) of incoming imaging data. The validated flow is executed exactly as configured, ensuring that the image frames pass through the designated sequence of threads safely and efficiently. This ensures reliable clinical imaging tailored to the selected mode, whether it be fluoroscopy, angiography, or other modalities.
The User Interface (UI) (14) is the operator’s main access point for configuring and managing the image processing string. It provides a grid-style window listing all available threads, their indices, associated modes, and process names. The user interface (UI) layout shown in the figure 5 provides a clear and structured way to configure processing thread parameters within the configurable image processing system. The table is divided into three key columns: Index, Mode, and Process, each playing a critical role in defining and organizing the available image processing threads. Here index is a unique numerical identifier assigned to each processing thread. For example, ADR Process is indexed as 1, Log Process as 5, and Invert Process as 16. This index ensures that each thread can be uniquely referenced within the system and used in validation checks such as index matching. In the example, all threads are listed under the mode "CINE." This indicates that the table reflects processing functions associated with the cine mode of imaging. However, in practice, other imaging modes such as Low-Dose Fluoroscopy, Roadmap Imaging, or Coronary Angiography could have their own set of threads, with some overlapping and others unique, depending on clinical requirements. The mode column makes it explicit which imaging context the thread belongs to, ensuring proper mapping when modes are selected. Further process column lists the actual processing function or task performed by each thread. These are the image processing operations such as ADR Process (adaptive dynamic range adjustment), Mean Log Process, AIP Enhance Process, Sharpen Process, Contrast, and Invert. Each represents a discrete transformation applied to image frames, and their sequence determines the overall processing string’s outcome. Further, the UI also have a drop down menu labelled "Process Parameters," along with ADD and Save Changes buttons. This feature allows users to insert a new processing function into the list by selecting it from available options. Once added, the updated configuration can be stored with "Save Changes," ensuring persistence across sessions. For example, a technician could add a Noise Reduction Process at runtime and save the updated configuration for future use. This ADD and Save Changes functions allow real-time reconfiguration and persistence, enabling workflows to adapt dynamically to clinical needs while still being safe and validated. Hence, the layout provides clinicians or technicians with direct control over string customization and making it easy for non-technical users to interact with the system.

The User Interface (UI) of the configurable image processing system is designed to give clinicians and technicians intuitive control over how processing threads are managed, without requiring them to directly interact with the system’s backend logic. Figures 6, 7, and 8 together illustrate how the UI enables adding, deleting, reordering, and saving of threads in a clear and stepwise manner.
In Figure 6 (a–d), the UI supports the addition of new image processing threads. The operator can use a dropdown menu (Fig. 6a) to select a specific process, such as Gamma Correction or Contrast Adjustment. By clicking the Add button and assigning the process to the desired imaging mode (as shown in Figs. 6b and 6c), the selected thread becomes part of the mode-specific configuration string. Once all desired parameters are added, the operator finalizes the update by clicking the Save Changes button (Fig. 6d). At this point, the new process is incorporated into the configuration table but does not become active until the operator saves the configuration and re-authenticates, ensuring deliberate and traceable modifications.
In Figure 7 (a–b), the UI allows for deletion of processes. The operator highlights the row corresponding to the process and selects a Delete option (Fig. 7a), which is followed by a confirmation dialog (Fig. 7b). This confirmation prevents accidental deletions and ensures deliberate operator control. For instance, a non-essential process like AIP Enhance may be disabled in low-dose fluoroscopy mode to reduce latency, resulting in a leaner string.
In Figure 8 (a–d), the UI provides Move Up and Move Down controls to reorder threads within the configuration. This is critical because clinical outcomes may depend on the sequence of image enhancement—for example, applying Gamma Correction before Contrast Adjustment produces different visual results than the reverse order. After reordering, the operator commits the changes by pressing the Save Changes button (Fig. 8e). To ensure reliability, all modifications require user re-authentication and system re-initialization before activation. This prevents accidental or unauthorized changes from taking effect during live imaging.
The overall design of the UI ensures that users can add, remove, and reorder threads in real time, with each modification automatically triggering the validation module to check DAG acyclicity, thread availability, and index mapping. By centralizing all configuration controls into a single interactive table with simple tools, the UI empowers clinicians to adapt workflows quickly and safely to evolving clinical requirements, while guaranteeing backend validation and consistency.
Hence, the system by integrating memory-driven imaging modes, processing and validation modules, user interaction via the UI, and strict error handling, the architecture guarantees that only validated, acyclic flows are executed. This allows clinicians to benefit from flexible, customizable pipelines without compromising system integrity or patient safety.
, Claims:I/We Claim:
1. A configurable image processing system (10) comprising:
• a memory unit (11) comprising one or more imaging mode string (1…n), wherein each imaging mode string comprising a plurality of image processing threads used in the specific imaging mode and a pattern in which those image processing threads are to be executed on an imaging data;
• a processing module (12) adapted to process imaging mode data and adapted to generate a pipeline structure (120) of an image processing flow the imaging data has to go through on execution of the specific imaging mode, the pipeline structure comprising:
a plurality of nodes each representing an image processing thread; and
one or more edges representing directed a data flow between said processing threads; and
• a validation module (13) configured to, prior to activation of the processing flow:
-parse said pipeline structure;
-perform a cycle detection (130) operation on said image processing flow using a graph traversal algorithm; and
-block activation of the image processing flow if a cycle is detected, thereby ensuring that processing threads are executable only along acyclic paths;
wherein, upon successful validation, the imaging mode string subsequently received by the system (10) is processed according the validated processing flow of the imaging mode.

2. The system (10) as claimed in claim 1, wherein the graph traversal algorithm is a Depth-First Search (DFS) traversal algorithm.

3. The system (10) as claimed in claim 1, wherein the memory unit (11) comprises a database (15) storing a plurality of image processing threads (150) along with their activation status (151), present across one or more imaging modes, and wherein the validation module (13) is configured to verify (131) that each Image processing thread designated in the selected imaging mode have a corresponding valid and active thread entry stored in the database (15).

4. The system (10) as claimed in claim 3, wherein each image processing thread (150) is associated with a unique index stored in a thread index (152) in the memory unit (11), and the validation module (13) is further configured to index match (132), that each node referenced in the pipeline structure of the image processing flow corresponds to a valid index listed in the thread index (152).

5. The system (10) as claimed in claim 1, wherein the validation module (13) is configured to perform all verification operations, including cycle detection (131), active thread verification (132), and index matching (133), during a configuration phase prior to execution, such that only successfully validated flows are permitted for real-time processing.

6. The system (10) as claimed in claim 1, further comprising a user interface (14) configured to allow a user input (141) to modify the sequence of image processing threads by adding, removing, or reordering threads in real time, wherein each modification triggers a validation process prior to enabling execution.

7. The system (10) as claimed in claim 1, further comprising a scheduler (133) configured to manage the execution of image processing threads such that, during processing, each image frame passes through any given image processing thread no more than once, in accordance with the validated pipeline structure.

8. The system (10) as claimed in claim 7, wherein the scheduler (133) is further configured to coordinate concurrent processing of multiple image frames across different image processing threads, such that each frame progresses independently through the validated flow associated with its imaging mode.
9. The system (10) as claimed in claim 8, wherein the scheduler (133) ensures exclusive occupancy of each image processing thread, such that no two image frames are processed by the same thread at the same time.
10. A method (40) for configuring an image processing flow for clinical imaging, the method comprising:
• Storing (41), in a memory unit, one or more imaging mode string entries, each comprising a plurality of image processing threads and a defined pattern in which the threads are to be executed on imaging data;
• Processing (42), by a processing module, the imaging mode string to generate a pipeline structure of an image processing flow, wherein the pipeline structure comprises:
o a plurality of nodes each representing an image processing thread; and
o one or more directed edges representing data flow between the threads, indicating that the output of a source thread is passed to a destination thread;
• validating (43), by a validation module and prior to activation of the processing flow:
o parsing the pipeline structure of the image processing flow;
o performing a cycle detection operation using a graph traversal algorithm; and
o blocking activation of the image processing flow if a cycle is detected, thereby ensuring the image processing threads are organized in an acyclic execution path; and
• processing (44), upon successful validation, the imaging data according to the validated image processing flow associated of the imaging mode.