Bioptigen .OCT file extension and other points

[Dbrown411]

Mark,

I've previously coded up a reader for the Bioptigen .OCT file extension, and have already partially shoehorned it into your general project structure (see below for outputted video of a mouse retina using your package).

In the process of creating this, I tackled a few data-organization/management problems a bit differently. I have no experience with other OCT file types (just beginning to use a Heidelberg system and look at .E2E files, which is what lead me to your repo), so i'm not sure if some of these points are specific to the Bioptigen or not. I'm happy to contribute just the barebones construct-based binary readers - however, I would need to make a few changes. Before making these changes, I'm wondering if you've considered the following points for the other readers/your general OCTVolume class:

1) "volumes" vs "framestacks"
In the Bioptigen ecosystem, there are B-scans and frames. Bscans are typically different positions, whereas frames are repeats of the same position. The Bioptigen .OCT file structure arranges these in what I've been calling a "framestack", with the general organization of scan(i)frame(j), e.g., s(0)f(0),s(0)f(1),s(0)f(n),s(1)f(0),s(1)f(1),s(1)f(n)...s(n)f(n).

This "framestack" organization seems to me to be the way the other OCT readers are organizing the data as well. However, in the Bioptigen .OCT file, the resulting 3D framestack is not a true spatial "volume" in that the 3 dimensions are not purely physical - the third dimension in this .OCT framestack is a mixture of z+time.

Do other filetypes mix spatial-temporal in the 3rd dimension or is this a Bioptigen-specific problem? This could be addressed by returning a list of volumes; however, I found it more natural to organize in a 4D volume with the dimensions (t,z,x,y).

2) keeping files in memory vs using H5Py
Some Bioptigen .OCT files that I deal with are multiple Gbs in size. I've found the use of H5Py to be a real asset, allowing you to read/operate on the OCT volumes from disk without having to keep them in memory. This has allowed people in my lab to mark our OCTs even on very low end computers. Adding this functionality to the other readers would be quite straightforward as well. Have you thought about this?

Looking forward to contributing!

Dillon

[marksgraham]

Hi Dillon,

Thanks for contributing, the mouse video looks great! To your points:

1. In my experience .fds/.fda (Topcon) and .img (Zeiss) just have a single volume per file. I have found .e2e files can have multiple volumes per file, but I don't think these are necessarily multiple repeats of the same volume, or even if they are they don't necessarily have the samen number of b-scans per volume, so the volumes can't be nicely aligned into a (t,z,x,y) structure where the (z,y,x) elements correspond to the same point for all values of t.

So this problem seems bioptigen specific. So I guess the options would be to return a list of volumes (as we currently do for .e2e), or create a new 4D tct class that stored it's volumes as (t,z,x,y)?

2. Interesting - .e2e files can also be pretty large so this could be pretty useful. So are you proposing having the facility to read/write extracted volumes as .hdf5? Would love to see some code but in principle I think it would be useful to have this option for all the readers.

Mark