ordering of extracted OCT volumes

[natwille1]

I really like this tool, and I'm using it a lot. One thing I'm confused about is the order of the extracted OCT volumes. If we know that the volumes were acquired in a particular order, does the tool extract those volumes in the same acquired order? Also, is there any metadata we can extract about eye laterality of the volume? Ideally, I'd like to be able to know which volume corresponds to which eye. Thanks.

[marksgraham]

Hi,

Glad to hear it's useful! I'm guessing that, given you're extracting multiple volumes from a file, you're extracting .e2e data? If that is the case then I'm afraid there is no clear order in which the volumes are extracted. Extraction happens in the order the 'chunks' are found in the file, and it isn't clear to me what order that it - it is possible that it is in acquisition order, but possible it is not! It might be possible to discern this from the filename which is [patientid][studyid][series_id]

• perhaps study_id or series_id relate to this order?

It should however be possible to get the laterality from the files and store that in the OCTVolume metadata - I will take a look.

On Fri, 24 Jul 2020 at 06:58, Nathalie Willems notifications@github.com wrote:

I really like this tool, and I'm using it a lot. One thing I'm confused about is the order of the extracted OCT volumes. If we know that the volumes were acquired in a particular order, does the tool extract those volumes in the same acquired order? Also, is there any metadata we can extract about eye laterality of the volume? Ideally, I'd like to be able to know which volume corresponds to which eye. Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/marksgraham/OCT-Converter/issues/5, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4UIM5FSGF6VDVTGR3NOHTR5EPJJANCNFSM4PGMZFEA .

[natwille1]

Okay that would be great, the Eye laterality annotation is actually the crucial bit that I need (otherwise I was going to deduce laterality based on acquisition order; but annotation would be better!). Any idea where you would start looking for that metadata? Is it encoded in the header information of the E2E file at all? Thanks!

[marksgraham]

The laterality is stored in one of the chunks, as described here: https://bitbucket.org/uocte/uocte/wiki/Heidelberg%20File%20Format It should be possible to figure out how to extract the laterality in a similar manner to how the imaging data is extracted in the .e2e reader https://github.com/marksgraham/OCT-Converter/blob/master/oct_converter/readers/e2e.py If you are able to have a go and make a pull request then go for it, but otherwise I should be able to take a look at it sometime in the coming week.

[natwille1]

Great thanks Mark, I'm looking into it now - I guess I have to identify the laterality data within the chunk based on the "type" attribute (// type == 0x0000000B - laterality), just like how you identify the "image_data" from the chunk (line 133 in e2e.py). How did you determine that "if chunk.type == 1073741824:" corresponds to the image_data? Thanks for all your help on this!

[marksgraham]

The type given by the uocte wiki are hexademical so: 0x40000000 == 1073741824 in decimal, and for laterality 0x0000000B == 11. I think you could check either type == 0x0000000B or type == 11, they would both work.

[natwille1]

So I've made some updates to support extraction of fundus autofluorescence images, which is working. With your recommendations, I'm now also able to extract the laterality information for the FAF images, but weirdly the same structure specs do not seem to work for OCT volumes.. I'm getting the following error "'ascii' codec can't decode byte 0xbf in position 0: ordinal not in range(128)". Just thought I'd update you :)

[marksgraham]

Would be great to add in support for FAF data! If you share your laterality code I could take a look at it on my end, too

[natwille1]

I forked the repo and added the changes here: https://github.com/natwille1/OCT-Converter/blob/master/oct_converter/readers/e2e.py At the moment, it expects the user to specify if the image type is "Fundus Autofluorescence" and then does some checks based on that (could make this more generic/less hard-coded). It has trouble matching all the images based on the "volume_string" that gets generated so some images are missed/skipped when it tries to create the OCTVolume object.. my lazy solution was just to pass back a list of the raw FAF images as well to make sure nothing is missed. It now also automatically extracts any regular fundus images in the E2E file that are stored with the OCT volume data. If you have time to check out how to extract the laterality info for the OCT data, that would be amazing!

[marksgraham]

Do you have any FAF and OCT data in .e2e format that you are able to share with me for testing? I currently don't have access to any Heidelberg data!

[natwille1]

Ah okay, sorry I don't think I can share anything.. would there be any examples online or in some repos somewhere? I'll see if I can address the issue in any case, and let you know.

[natwille1]

One question, how did you determine the number of characters to f.read() to for the various data chunks?

[marksgraham]

No problem, would be surprised if you were able to share data! I'll see if I can find any online to play with but likely won't get round to it this week.

The number of characters to read is determined by the number of bytes in the header. So, for example, the image chunk header is:

// type == 0x40000000 - image data
u32                   size
u32                   type ("0x02010201" for fundus, "0x02200201" for tomogram)
u32                   ?
u32                   width
u32                   height

Each unsigned 32-bit float takes up four bytes, and there are five of them, so we need to read 20 bytes. It isn't clear for the laterality how many we should be reading because there are an unknown number of 8-bit ints (due to the u8[?] entry), but we know we need to read at least 15 and the laterality is stored in the 15th.

[natwille1]

Hi again, as previously mentioned I've run into a few issues with extracting FAF images from E2E files due to the way the volume_string is constructed (resulting in missing images when the OCTVolume object is constructed). I thought I fixed this by extracting the volume string from the individual data chunks instead - this definitely allowed more images to be extracted, but it appears not all. If it's of interest, I'm happy to have a chat about it and take you through it - might be useful for generalising the code a bit. No worries if not though :)

[marksgraham]

Hi, That would be certaintly be useful. I'll direct message you and we can set up a call?