Hi @drombas

thank you very much for your contribution!

The most important metadata is the scaling information and in case we add the color fundus as localizer, also the start and end position of each B-scan on this localizer. So yes it would be possible to add the color fundus as EyeEnface to the EyeVolume. If we have all the required metadata then we can map annotations from the OCT Volume to the fundus.

• Do you know whether all this information is available in FDA?
• Do you have any specific questions about the metadata handling in eyepy?

Hi @Oli4, thanks for the feedback.

On your points:

• I made changes to OCT-Converter to parse scaling data. My next step is to add that to this PR.
• The position of B-scans on fundus images should be readable but I would need to investigate it a bit.

Apart from scaling info is there anything else I should add to this?

PD: I had some funny time getting familiar with poetry, pre-commit. Hopefully it is all good but double-check it please.

Hi @drombas

thank you for your effort, I'll have a look. Sorry for leaving you alone on how to set up the development environment for eyepy. I plan to add a respective section in the documentation so future contributors can focus on their contribution more than on setting up the environment. Sorry again.

Scaling info would be nice, I'll soon add the possibility to plot a scalebar on the images which would use the scale information.
B-scan positions would be nice as well but can also be added later.

Best regards
Olivier

Quick question @Oli4. What does each dimension in bscan start position tuple mean ? (maybe row/column from top-left fundus image corner?)

Quick question @Oli4. What does each dimension in bscan start position tuple mean ? (maybe row/column from top-left fundus image corner?)

eyepy/src/eyepy/core/eyemeta.py

Line 99 in f37f20f

start_pos: B-scan start on the enface (in enface space)

The tuple is (x, y) - Coordinate of the B-Scan's start point in mm in Localizer/Fundus coordinates. So the top left of the localizer/fundus is (0,0).

Good catch, this should definitely be documented better. Storing the position this way originates from the Spectralis XML and VOL formats where the B-scan positions are stored like this.

Thanks @Oli4 . I think I managed to adapt it to that convention. Now both scaling and bscan positions are used.

Is there any method that uses bscan position that we can use for testing?

eye_volume.plot(bscan_positions=True) for plotting the fundus with lines indicating the individual Bscans. Instead of True you can also specify indices of Bscans to plot the line for.

I had a look at your recent changes and it looks good, but showing the B-scan positions might not work yet, because the Fundus/Localizer image the positions refer to isn't provided to the EyeVolume. In this case a pseudo localizer is created by projecting the OCT volume. but here the B-scan positions then do not fit.

Creating and adding the localizer should work with code similar to the following:

# Modality and laterality are not necessary but nice to have.
localizer_meta = EyeEnfaceMeta(scale_x=scalex, scale_y=scaley, scale_unit="mm", modality="CFP/NIR", laterality="OD/OS")
localizer = EyeEnface(localizer_image, localizer_meta)
eye_volume = Eyevolume(..., localizer=localizer, transformation=_compute_localizer_oct_transform(
                volume_meta, localizer.meta, oct_volume.shape))

The transformation is used to map from a 2D projection of the OCT volume to the localizer and is computed using the B-scan positions. This could probably be done internally, but for now, you need to specify it when setting up the volume.

Thank you for your effort!

Thanks @Oli4. I tried adding what you mentioned.
I feel the entire solution is a bit ugly and could be more efficient but it looks like it works.

Hi @drombas
looks good to me. What do you think could be improved? How the EyeVolume is initialized or how data is read from the FDA file? If you are having any changes in mind for eyepy, let me know, so we can discuss them.
I am happy that we can read this additional format with eyepy and would accept your pull request if it's okay for you.
Best Olivier

Hey @Oli4. Many thanks for following up this so closely.

I feel like there is a bit of overhead having to define so many objects but we can discuss that in the future.

I guess we can merge this and improve it once we add more features.