Roadmap and development ideas

[marksgraham]

Documenting the roadmap here, feel free to pick up any issues or suggest more:

Easy first issues

• Add type hints throughout. This reader has an example. Types should also be removed from all the docstrings.
• Move construct definitions out of reader classes and into their own subfolder (I think @Dbrown411 is already working on this)
• The fda reader has a lot more functionality implemented than the fds reader, such as support for more metadata and for reading contours. These should be added to the fds reader, too.

Harder

• Improve the .e2e reader. Have had recent reports of users unable to read .e2e, (e.g. see here and here). I think the reader could be improved by learning from this C++ based reader, LibOCT.
• Improve .e2e reading of acquisition date/birthday acquisition. The code for acquisition date just uses a heuristic at the moment, and the birthdate is plain wrong, but we now have example code for how they should be properly extracted here.
• Add testing. I've wanted to do this a while, but I'm a bit stumped. While we could unit test some of the codebase with synthetic data, a lot of the functionality would ideally be tested on real data (i.e. checking a change to a reader does not change the output). However, most data I have is private, so we need a way of running tests on data whilst ensuring that data cannot be accessed by anyone but me. Alternatively, we need public data from more manufactuers - currently we only have for .fda and .fds. Any ideas welcome!
• Add proper documentation. The codebase is simple but I think we have enough non-technical users that would appreciate some proper documentation hosted on read the docs or similar.
• Dicom export for OCT and fundus
• Add a Factory for creating file readers.

[Oli4]

What do you think about joining forces with similar projects? I thought about making OCT-Converter a dependency of eyepy to add support for more file types outside the Heidelberg universe. The E2E Reader of eyepy is going to be functional within the next few days.

[marksgraham]

What do you envision this looking like? Very happy for use to use OCT-converter as a dependency and I can look into using eyepy as I imagine it has some more fleshed out support for heidelberg than I currently have. Or are you proposing a merging into a single project?

[Oli4]

Having a "standard" package when working with OCT data in python by merging existing projects would be great and was what I once envisioned with eyepy. Increasing the number of people being involved will also increase the chance for ongoing maintenance compared to the many stale projects you find when searching the internet/github for OCT-related code. For eyepy I am the only maintainer what about OCT-Converter?

[marksgraham]

We have a few contributors, but I'm the only maintainer. Agree it would be good to have a single go-to package. Might require some more thought and discussion on exactly what this might look like. Do you want to have a call to discuss?

[drombas]

Having a standard Python package for OCT sounds fantastic.
I aimed for something similar in MATLAB here. I also have quite some Python code for OCT feature extraction that I would be happy to contribute with if there was a package with a broader scope.

[Oli4]

@drombas Very impressive Matlab Package. I would be happy to integrate more feature extraction functionality in eyepy. I also thought about integrating my current work on drusen segmentation and quantification when published.
@marksgraham Yes it needs more thought and discussion and I think it's a great idea to have a call on the topic. I'll write you an Email.

[drombas]

@Oli4 happy to discuss that integration! I will look into eyepy to get an idea of how it is structured.

[Oli4]

@drombas happy to hear that. Let me know if you have any questions. I did a lot of refactoring and documentation lately that is not yet in the main branch. I aim at merging it this week. It probably makes sense to wait for this latest version.

[Oli4]

@drombas The new version of eyepy is out and it does have a documentation now :)

[naterichman]

Hi @marksgraham would you have interest in being able to save as dicom? I am willing to put in some work to add dicom export for Fundus and OCT if that would be of interest to you

[marksgraham]

Hi @naterichman

I'd be very interested in having dicom export! I think it's been requested in the past and i've not had the time to work on it. I'll add it to the roadmap, let me know if I can do anything to support you :)

Feel free to open an issue for the topic if you want to discuss more

[YaseminTurkan]

There are OCTA images in topcon and Optovue. Will there be any feature to read these images from .fda files and/or .OCT files

[big97kai]

I finised the acquisition time problem. After double checking that's right, I'll push my code... hope that's will help.
Still, I'm looking forward to finish size_y problem.

[marksgraham]

I finised the acquisition time problem. After double checking that's right, I'll push my code... hope that's will help. Still, I'm looking forward to finish size_y problem.

That would be great, look forward to the PR!