OCT-Converter
OCT-Converter copied to clipboard
Roadmap and development ideas
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.