Explore Projects

MedEye3D.jl aims to enhance medical imaging visualization within the Julia language ecosystem. The current proposal addresses the need for improved functionality in windowing, support for the display of super voxels, faster load times, and robust viewing of multiple images. By leveraging Rocket.jl and ModernGL.jl, the proposal plans to implement features like enhanced windowing for MRI and PET data, support for the display of super voxels, and high-level functions for improved user experience. The project aims to streamline visualization processes and provide essential tools for 3D medical imaging workflows. The main deliverables include: Supporting simultaneous visualization of multiple registered medical images, with linked scrolling, cursor highlighting, and connecting lines between annotated points across images. Implementing automatic windowing and colormaps for common MRI and PET imaging modalities to provide consistent visualizations mimicking other medical imaging software. Adding support for visualizing supervoxel segmentations with boundary detection using techniques like the Sobel filter. Improving startup time by precompiling critical components of the package. Implementing high-level functions to simplify basic usage by abstracting away low-level details of image loading, rendering, and visualization. By enhancing MedEye3D.jl with these features, the project aims to provide a more comprehensive and user-friendly tool for 3D medical image visualization and analysis within the Julia ecosystem. The improvements will facilitate better integration into medical imaging workflows and enable more efficient exploration and interpretation of data across different modalities.

Ensembl VEP's web interface offers dozens of configuration options for variant annotation, overwhelming new users and generating recurring helpdesk queries. Ask VEPai is a locally-hosted, open-source AI assistant that translates natural-language descriptions into recommended VEP configurations with justifications. The system uses Retrieval-Augmented Generation (RAG) grounded in a curated knowledge base, with a deterministic constraint checker that catches species violations and option conflicts the model misses. Beyond the project brief's scope of option labelling, training data, and a prototype model, this proposal adds four components: (1) the constraint checker, empirically validated across three model sizes, (2) a quantitative evaluation framework with leave-one-out methodology and multi-run statistical replication, (3) a structured JSON schema mapping recommendations directly to VEP web form sections for "click to apply" integration, and (4) an interpretability layer where every recommendation includes a source citation traceable to the knowledge base. A working demo validated across Qwen 2.5 3B/7B/14B shows +19–30% Enable F1 from the knowledge base, with all code and results published. Core deliverables: expanded KB (~55 options), 15–20 gold-standard examples, RAG pipeline, constraint checker, JSON schema, evaluation report, and documentation. My availability (~400 hours) supports extending to a 350-hour Large project, adding QLoRA fine-tuning, attribution testing, FastAPI wrapper, and VEP output explainer.

OpenTRIM is a C++/Qt Monte Carlo ion transport simulator for radiation damage research. Every parameter study today requires four manual steps: edit config.json, invoke the CLI, load HDF5 output, and plot by hand. No Python interface exists. No live view inside the target. This project delivers both. Feature A - Python Bindings: A pybind11 module wrapping libopentrim so researchers drive simulations directly from Python: result = opentrim.run(config_dict). Tally data is exposed as zero-copy NumPy arrays via ArrayNDd buffer protocol. result.to_xarray() returns a labeled Dataset with element names and nm coordinates for publication-ready depth profiles in one line. result.core exposes mccore internals - ion counts, per-tally SEM, and run merging. GSoC 2025 user_tally binning is bridged to Python. Seven benchmark configurations verify physics parity with the CLI. Feature B - Real-Time 3D Visualization: A QOpenGLWidget tab rendering live ion tracks as GL_LINES during simulation. A two-buffer pipeline handles 30M events/second without stalling. Cascade genealogy is color-coded from ion.recoil_id(): beam ions blue, PKAs orange, sub-cascade recoils red. A SEM convergence overlay tells researchers when to stop. Camera state serializes to JSON; --render produces headless PNG with no display server. Both features are isolated - bindings/ and source/gui/trackview.* - delivered across 14 pull requests in 350 hours.

BRL-CAD is a battle-tested Constructive Solid Geometry (CSG) engine, but it currently lacks a native, bidirectional interface for headless command execution, creating a massive barrier for modern web integrations and AI agents. This project proposes building BRL-CAD’s first native, extension-agnostic C++ Local IPC (Inter-Process Communication) API. By securely binding a stdio-based pipe listener to the main event loop and leveraging native libbu utilities for memory-safe string parsing, this infrastructure will allow users to safely pipe commands directly into the libged database engine. Designed with a "generic passthrough" architecture, it avoids hardcoding 400+ command schemas and ensures frictionless portability to BRL-CAD’s upcoming MOOSE/Qt interface. Alongside this foundational API, the project delivers a robust Model Context Protocol (MCP) server to establish BRL-CAD's first native Agentic AI integration. Operating externally as decoupled Python-based FastMCP middleware, this daemon bridges the legacy C-engine with modern Large Language Models. Rather than embedding a bulky AI chatbot inside MGED, the user interacts through their preferred external MCP client (like Cursor IDE or Claude Desktop), which routes commands directly into BRL-CAD's new background IPC pipeline. This empowers users to seamlessly query native documentation, automate batch database tasks, and debug spatial relationships using conversational commands, drastically lowering BRL-CAD's onboarding friction.

The goal for this project is to develop a NeRF model training pipeline within the OpenCV library. The end result will be a fully functioning data processing pipeline that is well integrated with the NeRF model training procedure, as well as online documentation that detail how to use the pipelines properly. There are 3 key deliverables for this project. First, implement data loaders that can process user-taken images of real-world scenes. This will involve using the COLMAP and OpenCV data processing pipelines in order to extract the camera poses and epipolar geometry of the scene; these are requirements for the model's ability to learn a meaningful representation of the given scene. Second, build, train, and test the actual NeRF model. This will involve using PyTorch's built-in CUDA support and extensive usage of the PyTorch library as a whole in order to incorporate critical components of the NeRF architecture such as positional encoding, ray sampling, and regularization into our model design. This step will also include rendering procedures that will allow users to extract images/videos, depth maps, and other logging information such as the training loss curve from the fully trained model. Third, create simple and intuitive documentation on how to use both the data loaders and the NeRF code base. This will involve creating a page on OpenCV's documentation (via Doxygen) that will list out specific terminal commands that the user should use to train the model. It will also include a summary of required packages, recommended environment configurations, and links to other helpful resources such as YouTube video demonstrations, which will all be geared towards increasing the usability and accessibility of the pipeline.

Uyuni is a powerful systems management platform, but today it lacks a native way to automate actions based on events in real time. As a result, administrators often have to write custom scripts to react to things like patch updates or system changes, which adds unnecessary complexity and effort. This project aims to change that by introducing a simple, scalable event-driven architecture that turns Uyuni into an automation-friendly platform. The idea is to make it easy for administrators to connect Uyuni with other tools and build workflows without writing a lot of custom code. The solution has two main parts. First, an MQTT-based event publisher that hooks into Uyuni’s existing event pipeline and emits real-time events such as patch updates, system registrations, and Salt state results. Second, a custom Node-RED integration that allows administrators to visually design automation workflows using a drag-and-drop interface. The publisher is designed to be lightweight and non-intrusive, running as a passive listener so it does not interfere with Uyuni’s current behavior. It sends structured JSON messages, supports topic-based filtering, and includes reliability features like retries, batching, and rate limiting to handle larger deployments. On top of this, the Node-RED layer provides reusable nodes for consuming events, triggering actions, and interacting with Uyuni APIs. Overall, this project makes automation in Uyuni much more accessible, reduces the need for manual scripting, and enables easy integration with external tools like Slack or Jira. It also lays a solid foundation for building more advanced automation features in the future.

The existing Neural-lam probabilistic forecasting model, GraphEFM, currently exists in an isolated branch (prob_model_lam) with a monolithic ARModel class encapsulating both the training, rollout, and single-step prediction functionality in a single file. Meanwhile, PR #208 refactors the deterministic models into a clean three-layer hierarchy: ForecasterModule (Lightning training harness), Forecaster (rollout strategy), and StepPredictor (single-step prediction). The GraphEFM model cannot be merged into main until it is ported to this new hierarchy. This project ports the GraphEFM model into the new hierarchy by refactoring it into three new classes that mirror the existing separation of concerns: GraphEFMPredictor (extends StepPredictor : owns the encoder, prior, decoder, latent variable logic), EnsembleForecaster (extends Forecaster : owns the AR rollout with separate prior and encoder paths), and EnsembleForecasterModule (extends ForecasterModule : owns the ELBO training, ensemble metrics, and visualization). Key design decisions include using explicit forward() and forward_encoder_path() instead of gating on self.training (handled automatically by PyTorch Lightning), making the predictor self-contained with its own per_var_std buffer, and replacing all hardcoded constants with the datastore API introduced in PR #208. Deliverables: - All components of the encoder/decoder moved, GraphEFM predictor that fulfills the contract of StepPredictor, EnsembleForecaster with both paths tested, and end-to-end graph efM training of --model graph_efm on MEPS, along with ensemble metrics. - KL/CRPS warmup schedules, ensemble parameters defined via configuration, Zarr-based ensemble prediction saving, additional ensemble visualizations, spread maps, and spaghetti plot, checkpoint backward compatibility, and architecture documentation.

DICOMHawk is an open-source honeypot that emulates a vulnerable DICOM medical imaging server to attract and log unauthorized access attempts. The current v3.0 rewrite is functional at the core protocol level but presents a single fixed identity, lacks a web interface, has incomplete DIMSE handler coverage, and performs no analysis on attacker-submitted payloads. This project transforms DICOMHawk into a profile-driven deception platform. A profile system allows the honeypot to impersonate different medical imaging systems through YAML-backed configuration, controlling the DICOM identity, web-facing surface, and honeytrap behavior per deployment. An attacker-facing web extension built with Flask exposes realistic viewer interfaces and honeytrap endpoints, while browser and environment fingerprinting collects telemetry about attacker infrastructure. On the protocol side, the project completes missing DIMSE handlers (associate, release, abort) and adds DICOMweb (QIDO-RS, WADO-RS, STOW-RS) endpoints. A structured logging pipeline with session correlation ties DICOM, web, and fingerprint events together. A static-analysis sandbox quarantines and analyzes uploaded payloads without execution, shipping with starter YARA rules. Finally, Docker deployment is hardened for safer operation. Deliverables: Profile-based architecture with two starter profiles, attacker-facing web extension with per-profile templates, operator Web API, browser fingerprinting with correlation database, completed DIMSE and DICOMweb handlers, unified JSON event logging with session correlation, static-analysis sandbox with YARA support, and hardened Docker deployment.

Apache ShardingSphere is positioned as a Database Plus, and aims at building a standard layer and ecosystem above heterogeneous databases. It focuses on how to reuse existing databases and their respective upper layer, rather than creating a new database. The goal is to minimize or eliminate the challenges caused by underlying database fragmentation. ShardingSphere parser engine is the core of ShardingSphere, It helps users parse a SQL to get the AST (Abstract Syntax Tree) and visit this tree to get SQLStatement (Java Object). At present, this parser engine can handle SQLs for MySQL, PostgreSQL, SQLServer, openGauss and Oracle. However, there are still many statements that are not supported yet. Therefore this project proposes to Solve unsupported Postgres sql about alter statements for ShardingSphere parser and also proofread and optimize the grammar wherever needed. This project would require to proofread through DDLStatement.g4 to analyze existing grammars and optimize them (essential), write grammar for unsupported alter statements referring to the official PostgreSQL documentation (essential), implement visit methods for the statements (essential), add new corresponding SQL cases and expected parsed results (essential), Run SQLParserParameterizedTest and UnsupportedSQLParserParameterizedTest to make sure there are no exceptions (essential). Successful Implementation of the project will add proper support for PostgreSQL Alter Statements ensuring there are no exceptions for the following statements, ALTER OPERATOR, ALTER POLICY, ALTER PUBLICATION, ALTER ROUTINE, ALTER RULE, ALTER SCHEMA, ALTER SEQUENCE, ALTER SERVER, ALTER STATISTICS, ALTER SUBSCRIPTION, ALTER TABLE, ALTER TEXT SEARCH,ALTER TRIGGER, ALTER TYPE, ALTER VIEW. This project will significantly improve the ShardingSphere parser engine.

Loan agreements are supposed to protect borrowers. In practice, most people sign them without understanding what they say, not because they're careless, but because these documents are written in language that takes training to parse. For the rural borrowers and small business owners that Mifos X was built to serve, this gap is not a minor inconvenience. It is a direct risk to their financial wellbeing. This project builds an LLM-powered summarization layer that integrates directly into Mifos X. A loan officer pastes a contract or pulls a loan product from Mifos X via the Fineract REST API, and the system extracts every key financial term like loan amount, interest rate, repayment schedule, every fee. It runs a mathematical consistency check on the numbers, and returns a plain-language summary written so anyone can understand it before they sign. Every extracted value is verified against the source text before reaching the screen, so the tool never silently surfaces wrong information. For MFIs with strict data privacy requirements, the system supports fully local inference via Ollama, no borrower data ever leaves their server. Before writing this proposal I built a working POC, deployed at https://loan-analyzer.streamlit.app/ , to prove the core pipeline actually works on real contracts. That POC is the foundation. The GSoC project takes it from a proof of concept into a properly integrated Mifos tool, with three deliverables: a working application connected to Mifos X with summaries generated in under ten seconds; a documented LLM evaluation comparing four providers on accuracy, readability, speed, and cost submitted to the Mifos wiki; and a clean codebase any contributor can clone and run in under fifteen minutes.

The 3D PDF Export for FreeCAD project aims to develop a native capability for exporting interactive 3D models directly to PDF format, enhancing FreeCAD's documentation and collaboration capabilities. Currently, FreeCAD users must rely on complex multi-step workflows involving external tools like MeshLab, LaTeX, or even commercial CAD software to create 3D PDFs, often resulting in loss of model fidelity, colors, and structure. This project proposes implementing a seamless 3D PDF export feature integrated directly into FreeCAD's TechDraw workbench. Users will be able to create standard technical drawings with traditional orthographic views and dimensions, plus an interactive 3D view that appears as a regular isometric view in print but becomes fully interactive when viewed digitally. Key components of the implementation include: 1. Document Structure Access: Utilizing FreeCAD's Python API to traverse the document object hierarchy or need to rely on Qt for accessing certain structural information. 2. 3D Format Conversion: Implementing exporters for both U3D format and PRC format to support NURBS surfaces for higher fidelity representation. 3. PDF Generation: Creating a PDF container that properly embeds the 3D content with interactive viewing capabilities. 4. TechDraw Integration: Extending the TechDraw workbench to include a new "3D View" type alongside traditional orthographic views. The completed feature will significantly enhance FreeCAD's usability for professional documentation, enabling users to share interactive 3D models with clients and collaborators who don't have CAD software, addressing a long-requested feature within the FreeCAD community.

Keploy - OSS Code Indexer for Efficient Retrieval. (Project-2) Problem solved - Current AI models struggle to generate high-quality Unit Tests for large codebases without a deep, structured understanding of the source code. Solution Plan- 1. I implemented code parsing using tree-sitter to create semantic chunks, preserving essential context. 2. Then generating embeddings for these chunks with Gemini, openAI, huggigface and store them in a Milvus vector database. 3. I'm utilizing HNSW indexing within Milvus for efficient semantic similarity search. 4. Then I have extracted code relationships (function calls, class inheritance etc.) and store them as a knowledge graph in Neo4j. 5. Embeddings are generated with Gemini :- https://huggingface.co/spaces/mteb/leaderboard 6. I have developed a dynamic indexing mechanism (using file watching/Git hooks, potentially enhanced by Difftastic) to keep both Milvus and Neo4j synchronized with code changes. 7. Then I build a hybrid retrieval system querying both Milvus (for semantic relevance) and Neo4j (for structural context). 8. Then I integrated this combined context into Keploy's existing Unit Test Generation (UTG) workflow, feeding it to the Gemini API for test creation. 9. Then I need further suggestion to implement an LLM-as-a-judge component to evaluate the generated tests. Deliverables:- A robust GraphRAG system integrated into Keploy. This includes codebase indexing (vector embeddings in Milvus, structural graph in Neo4j), dynamic index updates, hybrid context retrieval, and integration with the Gemini, leading to substantially improved Unit Test Generation quality and relevance for users with large or complex codebases. Thanks. Regards Sparsh.

Teleradiology in underserved regions such as rural Alaska depends on reliable, low-latency transfer of large DICOM medical imaging files between remote clinics and reading centers. Today, these transfers are governed by static configurations - a fixed IP address, port, and Application Entity (AE) Title standardized decades ago. This breaks silently when SCP nodes restart, IPs change, or storage queues fill. This proposal introduces Dynamic DICOM Endpoints, an intelligent orchestration layer integrated with the open-source Orthanc PACS server and Docker containers on the Cloud. A FastAPI Orchestrator backed by a real-time Redis registry continuously monitors the health, latency, queue depth, and storage capacity of every Orthanc node in a multi-region deployment, selecting the optimal routing destination in milliseconds and replacing fragile static pipes with a self-healing, load-aware mesh. Deliverables include a four-region Docker Compose simulation environment; a Python telemetry daemon; a pluggable scoring algorithm; a thin Edge Agent bridging legacy scanners (GE, Siemens); a comprehensive test and benchmarking suite validating routing correctness, failover behavior, and transfer performance; and a documentation suite. All code will be contributed as open-source to the Diomede repository, directly improving imaging infrastructure for remote and resource-constrained healthcare settings. As part of my pre-proposal engagement with the host organization, I submitted Issues #59, #79, and #85, along with the corresponding PRs #60, #80, and #86, to the Diomede repository. This contribution demonstrates my familiarity with the project's codebase and development workflow, and establishes a collaborative relationship with the maintainers ahead of the GSoC coding period.

I want to implement a feature for pocket that enables users to merge their existing projects, because it's not possible in the current version. Implementing a project merging feature will greatly improve the experience for pocket code users when it comes to building even more powerful applications and games. I've divided the problem into the following 5 milestones, with their subtasks to achieve: 1. Merging Projects Components with existing, simple conflicting variables protocol: 1.1 Merging Multiple Sprites 1.2 Merging Scenes 2. Implementing a Manual Conflict-Handler Interface: 2.1 User Interface for Merging Dialog: (choosing which conflict to merge, option to abort merge etc.) 2.2 Handling Local & Global Variable Conflicts 2.3 Handling Script Conflicts: View of Conflicting Scripts, Choose One 2.4 Handling Looks & Sounds Conflicts: Duplication User chooses 2.5 Handling Equal Sprites 2.6 Handling Equal Scenes 3. Merging options for UI 3.1 Abort Merge 3.2 Automatic Merge Without Conflict Search ( may not import everything) 3.3 Manual Merge ( Powerful Merge every conflict needs to be resolved) 4. Device specific configurations 4.1 Handling Screen Size & Resolution sensitive variables 4.2 Handling Screen Size & Resolution sensitive bricks 5. Merging Remix Graph 5.1 Implementing project merge history Each feature will be implemented using Kotlin or Java depending on source code files affected by changes, and each feature should be well tested.

The Ziff–Gulari–Barshad (ZGB) model describes how CO and O₂ molecules adsorb and react on a metal surface represented as a square lattice. CO occupies a single site, while O₂ dissociates into two oxygen atoms placed on adjacent sites. When a CO and an O atom meet, they form CO₂, which leaves the surface and frees up space. As the CO partial pressure (yCO) changes, the surface transitions from oxygen-poisoned (no CO₂ production) to reactive (CO₂ formation) and eventually to CO-poisoned. Apothesis is a kinetic Monte Carlo simulator that models these surface reactions with high precision. Building on the ZGB model and the Apothesis simulator, PyApothesis provides a clean, Python-first workflow for running, analyzing, and sharing Kinetic Monte Carlo experiments. From a single script you can change simulation parameters (temperature, pressure, lattice size, seed), define custom adsorption/reaction/desorption processes, and run reproducible simulations — then immediately visualize results with publication-ready plots. PyApothesis includes time-series coverage plots, stacked-area composition views, process-rate and event-count analyses, spatial coverage maps and profiles, and real-time playback of the lattice (color-coded by species) to inspect microscopic behavior as it unfolds. It automatically produces a comprehensive analysis report (plots, logs, and statistical summaries) so users don’t have to dig through raw files, and it exposes hooks to incorporate lightweight ML models for surrogate predictions, parameter scans, or pattern detection directly from Python. Altogether, PyApothesis turns complex surface-kinetics simulations into an interactive, interpretable, and reproducible toolkit ideal for both researchers and students.

This project enhanced Stingray.jl, the Julia-based implementation of the Stingray library for X-ray timing analysis in high-energy astrophysics. Starting from my childhood passion for astronomy, GSoC allowed me to contribute to real astronomical research tools that analyze signals from stars and X-ray telescopes. Technical Journey & Contributions: Beginning with learning Julia from scratch and understanding astronomical data formats through NASA HEASARC documentation, I implemented core functionality across multiple areas: Event Data Processing: Developed comprehensive read events functionality supporting .evt and .fits files from telescopes like NICER, including GTI (Good Time Intervals) handling, energy filtering (filter_energy), and metadata extraction. This enables astronomers to process millions of X-ray events efficiently. Light Curve Analysis: Built complete lightcurve workflows from raw telescope data to scientific plots, including creation, error handling, rebinning, and intuitive plotting recipes allowing simple plot(lc) commands. Spectral Analysis: Implemented Power Spectrum and Averaged Power Spectrum analysis for both binned and unbinned data, with multiple normalization options (Leahy, fractional, absolute) and comprehensive visualization capabilities. Cross-Spectrum Analysis: Tackled the most challenging component - Cross-Spectrum and Averaged Cross-Spectrum implementation for studying phase lags and time delays between different energy bands. This contribution includes advanced plotting for amplitude, coherence, time lag, and phase lag analysis. The project transformed my understanding from basic stargazing to sophisticated astronomical data analysis, creating tools that real astronomers will use to unlock the mysteries of the universe.

I am Ryan, a college student finishing their last semester for a bachelors in computer science. My contribution to the multi-agent traffic optimization project would be to take the lessons I’ve learned from my previous bevy projects, and use them to update and improve rmf_site’s infrastructure over the course of several stages, and to use those improvements to add procedural generation for the tests sites that will then be used for multi-agent optimization testing. The stages for this would be as follows: 1. bevy 0.12 -> latest version of bevy + library updates.. 2. Compile time improvements 3. Debug tool improvements 4. test scenario automation through procedural generation. Update everything: The first thing to do would be to update rmf_site bevy and all other dependencies to their latest versions. I’ve done this for all my projects since bevy 0.11, and I can do it for rmf_site too. Improve Compile TImes: The next step would be improving compile times. When I tested this project on my local machine. Iterative compile times took around 50 seconds. With the appropriate restructuring of crates, slimmer crate imports, more granular feature flags, and the introduction of the mold linker, these recompile times could be cut down to around 2-7 seconds. Improve debug tools: After that, then comes adding more debug tools. We can add bevy_inspector_egui for bevy entity/component inspection, bevy_tracing for performance optimization via Tracy. Automate test scenarios: Lastly, would be adding procedural generation for test sites. First, would be adding initial tests with randomized prefab placement, then moving to procedural room layouts from tiles, then assigning different layout kinds to each of these, (storage room, office room, etc..), and then finally connecting these different layouts together into a single site.

<p>The Microcks CLI (microcks-cli, written in Go) is a key part of Microcks' CI/CD story - it lets developers trigger contract tests and import artifacts from the command line and in GitHub Actions. This project goes into the developer experience layer. Today, developers must navigate to the Microcks web UI in a browser to see test results, check mock status, and diagnose import errors. There is no IDE integration, no offline validation mode, and no way to get mock results inline with the code being tested. This project builds three focused improvements that bring Microcks into the editor and the local dev loop: a VS Code extension, a local dry-run mode powered by Testcontainers, and an updated GitHub Actions output format that annotates PRs with per-operation pass/fail results.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- A VS Code extension (microcks-vscode) published to the VS Code Marketplace that connects to a running Microcks instance and shows: loaded services, mock operation status, recent test run results, and importer job logs - all inline in the editor sidebar (Like postman, thunder client)</p><p>&nbsp;- A microcks test --dry-run flag in the CLI that uses Testcontainers (the Microcks uber image) to spin up an ephemeral local Microcks instance, import the specified artifact, run the contract test, report results, and tear down - with no external Microcks server required</p><p>&nbsp;- A demo video and documentation page on microcks.io showing the full local-to-CI workflow</p><p><br></p>

This project focuses on solving a real gap in the current research workflow that is the disconnect between running experiments and turning those results into clean, publication-ready outputs. Right now, tools like Visdom are great for live experiment visualization, but the moment a researcher wants to use those results in a paper, everything becomes manual. Plots are exported as screenshots or loosely formatted images, experiment configurations are tracked separately (often in notes or notebooks), and comparisons across differnent runs are done by hand. This makes the process slow, error-prone, and difficult to reproduce. The proposed solution is to extend Visdom into a complete “experiment-to-publication” pipeline. Instead of stopping at visualization, the system will allow researchers to directly generate structured, reproducible, and publication-quality outputs from Visdom itself. The project introduces four tightly connected components: A publication-quality export engine that allows plots to be exported in formats like SVG, PNG, and PDF with proper resolution and formatting suitable for academic journals. An experiment metadata tracker that automatically records configurations, parameters, environment details, and results for every run, ensuring full reproducibility. A LaTeX generation system that converts plots into ready-to-use LaTeX figure blocks, eliminating the need for manual formatting in Overleaf or similar tools. A multi-experiment comparison suite that enables researchers to compare different runs with statistical summaries and generate both plots and tables for inclusion in papers. By building this system, Visdom evolves from a visualization tool into a full research workflow assistant. The end result is simple: what currently takes days of manual effort can be reduced to minutes, while also improving the reproducibility and consistency across various experiments.

<p>The main aim of this project is to come up with distributed and resilient version of Amber, which can help it in achieving the real vision of 404/broken-link free internet. The project can be divided into two different parts which involves IPFS integration, and distributed Amber design and implementation.</p> <h4>IPFS Integration</h4> <p>IPFS is the new P2P hypermedia protocol made to achieve “The permanent web” by Protocol Labs. It can be seen as a single BitTorrent swarm, exchanging objects within one Git repository. It will be added into Amber’s backend options using official <a href="https://github.com/cloutier/php-ipfs-api" target="_blank">PHP IPFS API</a> implementation.</p> <h4>Distributed Amber</h4> <p>This section of project deals with distributed version of Amber which enable Amber nodes to communicate and share cached contents with each other (P2P cache sharing). The proposed design can be briefly divided as:</p> <ul> <li><p><strong>Central Server</strong> based on <a href="https://github.com/mementoweb/timegate" target="_blank">memento timegate</a>, which will allow users to query peers and facilitate P2P cache sharing.</p> </li> <li><p><strong>Amber nodes</strong> with added APIs for cache sharing.</p> </li> <li><p><strong>Security Measurements</strong> to prevent misuse of the system by using <strong>Public-key cryptography</strong> and <strong>Reputation based cache resolving</strong>.</p> </li> </ul> <p>Technologies: Python, PHP, Networking concepts, Basic cryptography</p>

At the CMS detector, jet images are stored at reduced resolution, discarding ~75% of total deposited energy. Standard super-resolution fails here because it optimises for visual similarity, not physical validity — a model without energy constraints converges to a response of 0.52, recovering only half the missing energy. As part of the ML4Sci/CMS test task, I developed a complete physics-aware conditional GAN pipeline (github.com/rajveer43/cms-superres-reconstruction) that maps 3×64×64 LR jet images to 3×125×125 HR reconstructions using a residual CNN generator, PatchGAN discriminator with spectral normalisation, and a three-component hybrid loss (LSGAN + L1 + energy response). The best configuration achieves raw-space L1 of 0.00698 vs 0.00846 for bicubic (17.5% improvement), PSNR 14.32 vs 14.13 dB, and energy response 1.0098 — within 1% of simulation ground truth. This GSoC project extends that validated baseline by implementing and benchmarking SwinIR-style transformer SR adapted for η-φ calorimeter coordinates, and a conditional DDPM/flow-matching diffusion variant as a stretch goal. Every architecture is evaluated on the same physics-constrained suite: energy response must remain within [0.99, 1.01] or the model is rejected regardless of pixel quality. Deliverables: reproducible GAN baseline with full metric suite, trained transformer SR model with benchmark comparison table, mid-project GAN vs transformer report, final benchmark across all architectures, technical report, and organized codebase for CMS collaboration use.

Print Dialogs are one of the most used features for many people, and it is important that they stay up to date with the current print technologies (like CUPS) and be able to quickly adopt any new such upcoming technology (XYZ Cloud Printing Service). The print technology developers should also be able to fix any bugs as soon as they are found. However, since most Print Dialogs are provided natively by the GUI toolkits (and in some cases applications like LibreOffice and Chrome), this is often not the case. This is because the GUI toolkits themselves are large projects with long release cycles, and they have a lot of other similarly important things to work on. As of current, most GUI toolkits like GTK and QT connect their Print Dialogs directly with the print technologies like CUPS which creates problems for both. Any changes made by the print technologies, be it a bug fix or a new feature release often takes a long time to show up in the print dialogs upstream due to the reason mentioned before. Similarly, the print technologies need to constantly maintain backwards compatibility since they can’t release breaking changes if the Print Dialogs have not yet implemented them. Besides this, there is also a disconnect between the two sides due to the slow-release cycles. The Common Print Dialog Backends (CPDB) introduced in 2017 by Till Kamppeter aims to de-couple the GUI from the print technologies. Instead of directly connecting to each print technologies separately, the GUI projects only must adopt CPDB support once, and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPD Backend for the print technologies to be up to date with any changes. This way print technologies can react quickly and not be bound by the big GUI toolkits’ inertia. This project will attempt to get CPDB into print dialogs upstream for GTK, Qt and Chrome.

Problem Statement In interactive tabletop environments, Game Masters (GMs) face significant cognitive load when managing audio assets during live narration. Manually searching for and triggering specific dramatic recordings often disrupts the immersive flow of the session. There is a need for an automated system that can understand narrative intent and retrieve assets without interrupting the storytelling process.Proposed Solution I plan to bridge the gap between raw audio data and narrative utility by developing an automated pipeline for the TableTalk ecosystem. Leveraging my background in Computer Science and Economics and experience in agentic AI frameworks, I will implement:Narrative Tone Classification: Using a machine learning framework to categorize voice recordings into distinct narrative states (e.g., Urgent, Calm, Fearful).Hybrid Semantic Retrieval: Creating a retrieval engine that combines structured filtering with semantic ranking to allow GMs to use natural-language queries.Real-Time Trigger Logic: Implementing stream-based keyword spotting to map a storyteller's live performance to environmental atmospheric effects like lighting and soundscapes.DeliverablesQuantized Inference Engine: A lightweight model optimized for on-device mobile execution to ensure low-latency narrative classification.Search & Retrieval Module: A high-fidelity interface for natural-language audio discovery.Atmospheric Bridge: A software component that translates identified narrative tones or keywords into external hardware triggers.Technical Documentation: A complete guide and implementation roadmap for integrating these modules into the TableTalk mobile application.This project combines technical machine learning rigor with a deep appreciation for narrative immersion, informed by my previous work in multi-genre game development and algorithmic optimization