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.