I've been working a bit more on E2E to DICOM and have a few updates...
DICOM-specific
Added ProtocolName and SeriesDescription tags to hold enface modality and scan pattern
Moved Fundus PixelSpacing to first-level tag
Added red/green/blue to ImageType depending on enface type
Exposed scalex and slice_thickness as args that can be passed. (I'm still trying to figure these out, especially scalex, but... This at least allows the user to set these values correctly if known.)
Additional E2E updates
Adjusted laterality logic (Had a test file where the previous logic didn't work for the first slice of the second eye scan)
Adjusted "laterality" from Int8un to ascii, because it's really just stored as R or L in the E2E.
Fleshed out more metadata chunks, tried to comment in a way that points out some great potential spots for more investigation
Chunk 7: Eye Data (thanks to libE2E). The test files I had only have corneal curve(c_curve_mm) and 0s for the other fields, unfortunately
Chunk 9001: Device Name (in my test files, always ["Heidelberg Retina Angiograph", "HRA", ""])
Chunk 9005: Examined Structure (in my test files, always "Retina")
Chunk 9006: Scan Pattern (found values of "OCT Art Volume", "Images", "OCT B-Scan", "3D Volume", "OCT Star Scan")
Chunk 10025: Localizer (thanks to eyepy). I'm really hoping to figure out this chunk further...
Chunk 3: I've listed this as pre_data because it typically seems to start each series of chunks. It definitely has laterality, and there's an "ART" a little ways in, but I haven't been able to decode further.
Chunk 39: Time... The first thing that jumped out at me were timezones (Like "Eastern Standard Time"). I think there's likely more here. Timestamps would make the most sense, along with regional information.
Chunk 52, 54, 1000, 1001 (and maybe more, it seems like there's some variation that I haven't figured out) are UIDs
Chunk 1007 seems to be a padded string with a brand name, potentially the supplier of the device, but I'm not certain.
I'd still really like to find how to calculate scalex (wouldn't we all!), and am still slowly working on that, mostly running into a lot of places where there isn't useful information for that particular puzzle piece. Let me know if there are any changes you'd like made!
Hi Mark!
I've been working a bit more on E2E to DICOM and have a few updates...
DICOM-specific
Additional E2E updates
Int8un
toascii
, because it's really just stored as R or L in the E2E.c_curve_mm
) and 0s for the other fields, unfortunatelypre_data
because it typically seems to start each series of chunks. It definitely has laterality, and there's an "ART" a little ways in, but I haven't been able to decode further.I'd still really like to find how to calculate scalex (wouldn't we all!), and am still slowly working on that, mostly running into a lot of places where there isn't useful information for that particular puzzle piece. Let me know if there are any changes you'd like made!