Welcome to DWiM Discussions!

[pradeeban]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[XxSURYANSHxX]

Hi @pradeeban,

My name is Suryansh Maurya, and I'm really excited about the DWiM project. The goal of building a MATLAB-native alternative to Niffler is a fantastic idea, especially with its potential for GSoC 2026. I saw the repository is brand new, and I'd love to jump in and be the first contributor.

My programming background is in C++, Python and Java, so I'm very comfortable with data structures, OOP concepts, and building modular systems. I'm keen to apply those principles to help build this framework in MATLAB.

After reading the project description, I've outlined a potential phased plan that I think could work well. I'd love to get your thoughts on it.

My idea is to build this in a modular way, so each part (retrieval, processing, analysis) can be built and tested separately.

Phase 1: Environment Setup & Core Retrieval
This is about getting the basic "Hello, World!" for DICOM connectivity.

1. Environment: Get MATLAB R2025a, the Medical Imaging Toolbox, and Image Processing Toolbox up and running.
2. PACS Sim: Set up a local Orthanc server, as suggested.
3. Test Data: Populate Orthanc with some sample anonymized images from TCIA.
4. Connectivity: Write the first core script. Use MATLAB's webread or webwrite functions to talk to the Orthanc REST API and successfully fetch a test study or its metadata. This would be the foundation of the "retrieval" module.

Phase 2: Building the Core Processing Pipeline (Niffler Feature Parity)
This phase would be focused on replicating the core utilities Niffler provides. We could build a function or class that takes a DICOM object and...

1. Extracts Metadata: Uses dicominfo to read the header and organize the data into a MATLAB table for easy export to CSV with writetable.
2. Anonymizes: Uses dicominfo to get the tags, modifies/nulls the sensitive ones (like PatientName), and saves a new, clean file using dicomwrite.
3. Converts Format: Uses dicomread to get the pixel data and imwrite to save it as a PNG or JPEG.

Phase 3: Integration & The "Scientific Contribution"
This is where it gets really powerful and we can show the "merit" the project description mentions.

1. Integration: Tie Phases 1 and 2 into a simple, high-level function (e.g., dwim.get_and_process_study('StudyID', 'output_format', 'png')).
2. Sample Workflow: We could replicate a Niffler workflow, like "scanner usage computation," by using our Phase 2 metadata extractor to pull data from all studies and analyze it.
3. The "Merit": The real win for using MATLAB is the seamless retrieval-to-analysis pipeline. We could aim to create a function that automatically:
   • Retrieves a DICOM series (Phase 1).
   • Pre-processes it into a 3D matrix (Phase 2).
   • Feeds it directly into a pre-trained model using MATLAB's Deep Learning Toolbox.

That single-environment, end-to-end workflow would be a huge contribution.

To get the ball rolling, I'd be happy to tackle the first part of Phase 1. I can:

1. Set up the local Orthanc + TCIA data.
2. Document the setup process in the README.md for future contributors.
3. Submit a PR with a single .m script that proves it can connect to the Orthanc API and retrieve the metadata for one test image.

Let me know what you think of this approach! I'm really looking forward to hearing your feedback and am ready to get started.

Best,
Suryansh

[pradeeban]

@XxSURYANSHxX Awesome.

A comment for @XxSURYANSHxX and anyone else who is submitting multiple proposals to Alaska (same goes for any organization actually. If you apply to multiple project ideas in any organization, this observation holds true mostly:)
Make sure to indicate your preference order in your proposal when/if you submit proposals for multiple project ideas within Alaska. While we do not mostly respect the applicant's preferences (because we are ranking the proposals rather than the candidates, and the stronger proposal ranks higher), if your both proposals are equally good, your preference order comes in handy.

[XxSURYANSHxX]

Sure @pradeeban, i will rank all of my 3 proposals that I am submitting in Alaska. I have finished my revision for DWiM proposal and will mail you shortly.

[XxSURYANSHxX]

@pradeeban, I have mailed you my Updated proposal with all the changes. Please review it and let me know your feedback. :)

[pradeeban]

Replied!

[XxSURYANSHxX]

Thankyou so much @pradeeban for your valuable time. I will polish my proposal more from my side. And since you said there is no changes required for the DWiM proposal. I'll get onto my other two proposals and will mail you shortly once i finish. Till then I hope my DWiM proposal perfectly aligns with the project goals and there are no changes needed ? If you want me to change anything in future just let me know, I'll be glad to improve it.

[XxSURYANSHxX]

Heyy @pradeeban , As I finalize my GSoC proposal for DWiM. However, I wanted to discuss the alternative plans for three specific architectural risks to make sure we are ready for everything. Here is what I currently have planned in the proposal, and the alternative approaches I'd love your feedback on:

1. The Real-Time SCP Listener Bottleneck

What is currently in my proposal: I plan to build the background listener using MATLAB's native dicomConnection capabilities to minimize external dependencies and if stress testing shows that MATLAB's single threaded nature drops packets under heavy clinical load, my alternative is to use system() commands to hook directly into compiled DCMTK C++ binaries (like storescp or dcmrecv).

What I need your feedback on (Not in the proposal) Before I make this my alternative approach, I want to ask about the ecosystem impact. Are there specific security or cross-platform deployment concerns with shipping compiled DCMTK binaries alongside the .mltbx package if we are forced to go that route?

2. Standardizing Spatial Math (NIfTI to DICOM)

What is currently in my proposal: For the convertNiftiToDicom module, the primary logic involves extracting the 3D affine transformation matrices from the NIfTI header and translating them mathematically into strict DICOM ImagePositionPatient and ImageOrientationPatient vectors.

What I need your feedback on (Not in the proposal): Because NIfTI qform/sform matrices can contradict with the DICOM's strict patient centric coordinate systems (LPS/RAS), direct matrix inversion might lead to flipped or mirrored masks. My alternative idea is to utilize MATLAB's imref3d and affine3d objects as an intermediate harmonization layer to force spatial alignment. What do you think about this approach ?

3. Preventing RAM Exhaustion during Metadata Harmonization

What is currently in my proposal: Currently, the pipeline flattens complex nested DICOM sequences in memory for extremely fast writing to tables/CSVs. If this causes RAM exhaustion on petabyte scale datasets, my alternative is to move to MATLAB's out of core data handling (matlab.io.datastore) or stream it to an external SQL database like SQLite.

What I need your feedback on (Not in the proposal): From your preceptive , do you prefer keeping DWiM strictly reliant on in memory operations for architectural simplicity, or does moving toward SQLite/out of core datastores for the batch exporter align better with the project's long-term vision?

I wanted to add these in my proposal but i wanted to have your view on this first. Plus my proposal is already 37 pages long and it might get more than 40 pages if add these alternatives. will that be okay ?

[pradeeban]

What I need your feedback on (Not in the proposal) Before I make this my alternative approach, I want to ask about the ecosystem impact. Are there specific security or cross-platform deployment concerns with shipping compiled DCMTK binaries alongside the .mltbx package if we are forced to go that route?

We need to think through this. How do we ship and are we going to bloat the GitHub for instance. Ok to go with the sub-optimal option. We do not need to have a production-ready MATLAB alternative for Niffler by end of the summer. This is just the beginning. We could leave things for future. Say, GSoC 2027...

On NifTi/DICOM: What do you think about this approach ?

Sounds good. We could also fail to produce results with an error message for the edge cases. See above.

If this causes RAM exhaustion on petabyte scale dataset
We won't have that much of datasets. But I like that you are thinking for scalability. You can continue with your current in-memory approach. Perhaps, feel free to add a "if-time permits" on this. I know we already have a lot of "if time permits" items. That is ok.

No worries about page count. No page limits on the proposal.

Good work.

[XxSURYANSHxX]

Perfect @pradeeban, we can definitely discuss it during the community bonding period. My plan is to make this project as much as it's possible and in the most efficient way possible during GSoC'26. So that whoever is taking up next on this project in upcoming years can improve it even further with new features as required. Ultimately communication is everything in a project like this :)

[KrishanYadav333]

Just adding a small thought here — earlier @pradeeban mentioned that Niffler itself was the result of several years of work and contributions from multiple developers, so it’s completely reasonable that this project focuses on building a solid foundation first instead of trying to reproduce everything within a single GSoC period.

Even though development is faster now with modern tools and MATLAB Live’s native AI integration, he also suggested keeping the 350‑hour GSoC scope realistic and clearly separating definite goals from “if time permits / optional” items. That might help keep expectations clear and make it easier for future contributors to continue extending the project.

Your work here is excellent and the way you're thinking about the long‑term direction of the project is really valuable.

[pradeeban]

Yes, for example, modules such as Suvpar and ivc-filter detection in Niffler can be completely ignored. They were just use cases. We do not need a MATLAB-mirror of everything Niffler.

[XxSURYANSHxX]

Yess @pradeeban, Thankyou for your clarification on the scope :)

[KrishanYadav333]

That completely makes sense to me now. Thanks....

[XxSURYANSHxX]

Thanks a lot for your input @KrishanYadav333. To clarify, most of the groundwork for this project has already been completed through my previous PRs, and @pradeeban is already aware of the overall direction and has approved the approach.

And regarding the 350-hour scope, I actually raised a similar concern earlier in this discussion: #7 (comment), where I suggested your approach might not fit in the 350 hour timeline. :)

From the very beginning, I’ve been careful to respect the 350-hour GSoC constraint as my entire progress from day 1 is planned according to that only.

At the same time, since the major foundational work is already in place, I planned to dedicate more effort to the later phases, which I believe are the most critical parts of the project. And according to me if we already limit our developer mindset without giving in extra efforts in the provided time than it's not a good habit. By keeping the quality of our efforts on top and doing our best we can achieve great results during the provided timeframe. That was all that I meant in my previous post.

Ultimately, I completely agree that clear communication and well defined scope are important for a project of this scale. Again since this is a completely new project, so non of the approaches are right or wrong as stated by @pradeeban. And I respect and appreciate your efforts to this repository. Please keep it up!

[KrishanYadav333]

Thanks for explaining your perspective, Suryansh. I understand your point about planning the work within the 350‑hour GSoC timeline, and I appreciate the effort you've put into organizing the infrastructure side of the project.

In the earlier PR discussion #7, you mentioned:

“While topics like 'isotropic voxel spacing' and 'volume preprocessing' are interesting for downstream ML research, I think we need to be careful about scope creep here.”

At that time my intention was simply to explore how the processing and ML pipeline layers might eventually fit into the overall architecture. After Pradeeban’s guidance, I continued that work in the experimental branch, where I focused on building the advanced processing engine and preprocessing pipeline during the pre‑GSoC phase while leaving the Niffler‑parity core components for the official coding period.

In the current discussion we are again exploring broader architectural directions for the project. In that sense, both of us are naturally thinking about how the system can evolve beyond the immediate scope, which is understandable for a new project like this.

From my perspective, your work on the retrieval and infrastructure layers and my work on the processing and ML‑ready pipeline layer complement each other and together help establish the overall groundwork for DWiM. I appreciate the effort you've put into this and look forward to continuing the work.

[XxSURYANSHxX]

@pradeeban I have submitted my proposal in the portal and will be updating it with fine refinements and updates before the deadline. Please have a look and if you feel anything that can be improved, I'd be glad to implement that. My other two proposals are in the work and will share that with you in 1 or 2 days for the review. Again Thankyou for everything :D

[pradeeban]

yay, @XxSURYANSHxX. I saw your proposal in the portal.

[XxSURYANSHxX]

Heyy @pradeeban, I hope you’re doing great. I wanted to share something that has been quite meaningful to me personally. Over the past few months, I had the chance to work on a research paper titled “TabFlowM: Lightweight Flow Matching for Mixed-Type Tabular Data Synthesis in Latent Space”, which is currently under review at TMLR (OpenReview). This is during my intern at NTU Singapore, IIT BHU and the University of Warwick, and honestly, the experience pushed me to learn a lot and i have grown beyond what I initially thought I could handle.

Here’s the link: https://openreview.net/forum?id=t5kygrpSIz&referrer=%5BAuthor%20Console%5D(%2Fgroup%3Fid%3DTMLR%2FAuthors%23your-submissions)

I’m sharing this not just to showcase my work, but because I genuinely value your guidance and perspective. If you get some time to read through this, even briefly, your feedback would mean a lot to me. And I know you are really busy so if you don't get the time it's completely fine :)

Thank you so much for your time, it really means a lot.

[pradeeban]

Thanks @KrishanYadav333 for all your contributions to this project. We asked for 16 slots and got only 8 from Google and couldn't get a candidate for this project idea. You were our top-candidate for this project (i.e., you were among the 16).

At some point, I should merge @XxSURYANSHxX and your contributions to the main branch. There are also other branches. I am unsure how easy that would be.

Please feel free to reach out to me if you need anything. Your contributions are highly valued.

[XxSURYANSHxX]

It was great experience to work with you and pradeeban.
I was not able to join alaska this year, but may be next year i could.

Definitely @KrishanYadav333, it was such a great experience to be working with you and make sure to take Matlab project forward next year and I hope it comes next time. You were excellent :D

[KrishanYadav333]

I was genuinely sad when I received the rejection from Alaska—it felt more than just an opportunity to me, it felt like a connection I had built with the organization.

That said, I’ve come to accept it with a positive mindset. I believe there’s always a reason behind such outcomes, even if it’s not immediately clear.

DWiM was very close to my heart, and I truly valued the chance to be part of it. I’m grateful for the experience and everything I learned through the process.

[KrishanYadav333]

Thanks @KrishanYadav333 for all your contributions to this project. We asked for 16 slots and got only 8 from Google and couldn't get a candidate for this project idea. You were our top-candidate for this project (i.e., you were among the 16).

At some point, I should merge @XxSURYANSHxX and your contributions to the main branch. There are also other branches. I am unsure how easy that would be.

Please feel free to reach out to me if you need anything. Your contributions are highly valued.

Thank you so much for the kind words—it truly means a lot to me.

I understand the constraints, and I’m grateful to have been considered among the top candidates. If DWiM comes again next year, I’ll definitely be applying again.

[pradeeban]

My advice would be for you to apply to 3 projects, but two for one organization and one for another (or maybe three to all three different organizations--one each). That will expand your chances, especially as the competition gets tougher, like 4%.