OCT-Converter icon indicating copy to clipboard operation
OCT-Converter copied to clipboard

Roadmap and development ideas

Open marksgraham opened this issue 1 year ago • 14 comments

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

Easy first issues

  • [x] Add type hints throughout. This reader has an example. Types should also be removed from all the docstrings.
  • [x] Move construct definitions out of reader classes and into their own subfolder (I think @Dbrown411 is already working on this)
  • [x] 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.
  • [x] Dicom export for OCT and fundus
  • [ ] Add a Factory for creating file readers.

marksgraham avatar Jan 31 '23 01:01 marksgraham