Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to Find .image File After Exporting Data from RTVue XR (Version 2017.1.9.151) #74

Open
HYenTung opened this issue Nov 21, 2024 · 5 comments

Comments

@HYenTung
Copy link

I am using RTVue XR version 2017.1.9.151 to export data, but I am unable to locate any .image files in the exported results (/DiagnosisData/). I have analyzed the exported files and found components like an XML file describing metadata (e.g., image dimensions, pixel size, and offsets) and a Zlib-compressed data block. I have read this GitHub issue, but it does not mention the issue of missing .image files. Could this be related to the version I am using, or is there an additional step or tool required to extract the image data? Any guidance on how to locate or reconstruct the .image file would be greatly appreciated. Thank you!

@camlloyd
Copy link
Owner

Hi @HYenTung. Thank you for your report. That is interesting. It could be due to your version/licenses (see #39).

If you have the Zlib-compressed data block, this should be all you need. You can try converting this file directly.
It should not be necessary to reconstruct the .images file, only to deconstruct it again.

Are you able to share your exported files please?

@HYenTung
Copy link
Author

Hi @camlloyd, Thank you for your response!
I’ve provided a sample of these exported files for your reference here: https://drive.google.com/drive/folders/1edyagHt-lev6hjzhjzLaH9SBbssZy3ij?usp=sharing

The exported folder structure from my RTVue device looks like this:

OCTA
├── DiagnosisData
│   ├── 00
│   │   └── 005a094f64e943498608bd3e4c821f56
│   ├── 0b
│   │   └── 0b3f82a14029a04d99d1e9b9d07d93ca
│   ├── 11
│   │   └── 11d641e1de734642832f9d4c8242f3eb
│   ├── 47
│   │   └── 474af1767e0a5946a6e2b3ec7b03f6b2
│   ├── 4b
│   │   └── 4bee3e235d5d24499bbdc5167326a1a3
│   └── 4c
│       └── 4c29165191b2a1449776fc0b2dc819a4
└── RawData
    ├── 00
    │   └── 005a094f64e943498608bd3e4c821f56
    ├── 0b
    │   └── 0b3f82a14029a04d99d1e9b9d07d93ca
    ├── 11
    │   └── 11d641e1de734642832f9d4c8242f3eb
    ├── 47
    │   └── 474af1767e0a5946a6e2b3ec7b03f6b2
    ├── 4b
    │   └── 4bee3e235d5d24499bbdc5167326a1a3
    └── 4c
        └── 4c29165191b2a1449776fc0b2dc819a4

14 directories, 12 files

Here’s my current situation:
I have successfully identified the Zlib-compressed data block as detected at offset in my file using binwalk.
However, I am uncertain about the exact process to directly convert or deconstruct this block into usable image data.
I ran the following command on DiagnosisData/0b/0b3f82a14029a04d99d1e9b9d07d93ca:
binwalk -e DiagnosisData/0b/0b3f82a14029a04d99d1e9b9d07d93ca
and it showed

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
73016         0x11D38         Zlib compressed data, default compression
554359        0x87577         XML document, version: "1.0"

The extraction created files like this:

_0b3f82a14029a04d99d1e9b9d07d93ca.extracted
│   │       ├── 11D38
│   │       └── 11D38.zlib

I also tried extracting the XML data block using this command:
dd if=0b3f82a14029a04d99d1e9b9d07d93ca of=extracted.xml bs=1 skip=554359
The extracted content included:

<?xml version="1.0" encoding="utf-8"?>
<FileContents>
       <EnFaceImg>
               <Img totalBytes="92416" fileType="PixBuffer" width="304" height="304" depth="1" comp="1" dataType="OvData8u" compress="None" cat="Derived" pixSizeX="0.009868" pixSizeY="0.009868" pixSizeZ="1.000000" mmOffsetX="2.750000" mmOffsetY="1.500000" mmOffsetZ="0.000000" Time="0.000000" pixType="PixStandard" />
               <EnFace TrkmmOffsetX="0.000000" TrkmmOffsetY="0.000000" MapType="OvEnFace" Which="OvBestSSADAOct" StartLayer="0" StartOffsetum="0" EndLayer="9" EndOffsetum="10" />
       </EnFaceImg>
</FileContents>

After the XML content, there was a lot of unreadable binary data
Now, I am stuck on how to directly convert or deconstruct the Zlib-compressed data block into usable image data and not sure about the XML content. Could you kindly guide me on the next steps?
Thank you again for your time and support! I look forward to your suggestions.

@camlloyd
Copy link
Owner

Hi @HYenTung, great detective work!

  1. What scan data are you trying to find in these exported files?

I’ve provided a sample of these exported files for your reference here

  1. Are there more directories? The directories you have provided look too small to contain angio scan data.

  2. Have you tried running grep with the name of the scan data you are looking for e.g. for "Angio Retina":

    grep -lr 'ScanPatternName="Angio Retina"' ./DiagnosisData/

@HYenTung
Copy link
Author

Thank you for your response!

  1. I’m looking for standard OCT scan data, ideally in a format suitable for 3D reconstruction or volumetric analysis. Additionally, if available, I’d like to locate OCTA 3D volume data for angio-specific analysis.

  2. The directories I provided were raw data exported using "File > Data Transfer > Output Data." Based on this, I believe these contain the six scans for one patient. If there are additional directories or a different export process to retrieve the angio scan data, please let me know.

  3. I did try running the grep command for ScanPatternName="Angio Retina" as you suggested, but unfortunately, it didn’t return any results. If there are other keywords or identifiers I should search for, I’m happy to refine the approach.

Thank you again for your guidance, and let me know if there’s anything else I should try!

@camlloyd
Copy link
Owner

@HYenTung standard OCT scan data should be stored in .OCT files. Did you try File > Export > Current Visit?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants