Feedback on Dicom files

[Jackiecs3]

Hi Mark，

About outputting dicom file label information.
1、I can obtain all the fundus data now, but can the number of files output in dicom format be consistent with images?

2、About outputting dicom file label information.
oct-converter output dicom file tag

Regarding the label pixel spacing, it should appear in the level 1 directory, currently at level 3

Correct example

How is the content of this field generated?? At present, if measurements are made based on this parameter, the data is clearly incorrect! 300mm should be bigger than one eye

This is my own data, and the dicom tags comply with the specifications and the values are normal. The following figure shows the measurement results

3、 About dicom tag
Correct example
Condition：
(0002,0003) Media Storage SOP Instance UID == (0008,0018) SOP Instance UID

current results

[marksgraham]

Will fix 1 soon, should be straightforward.

I'll look into the others when I have a chance. Flagging for @sustrev in case you've any thoughts, too!

[Jackiecs3]

Will fix 1 soon, should be straightforward.

I'll look into the others when I have a chance. Flagging for @sustrev in case you've any thoughts, too!

Among these issues.
Fixing issue number 1 can allow us to obtain complete data.
Fixing issue number 3 can make dicom files more perfect and more standardized for review.
Question 2 should be the most important because this parameter determines the accuracy of the measurement. One is the location where the (0028,0030) Pixel Spacing label appears, and the other is how to obtain relevant parameters from the e2e file.

I can try to find some examples of converting e2e files to dicom files for your reference.

[sustrev]

Thank you so much for your feedback and testing, @Jackiecs3! Question 2 shouldn't be too difficult to address, moving the label and adjusting pixel spacing. Please correct me if I'm wrong, but I believe e2e utilizes a default fundus pixel spacing, so setting PixelSpacing to 0.011493\0.011493 (instead of 1.0\1.0 here) should fix the measurement accuracy.

For tag placement, currently opt_shared_functional_groups here is re-used from oct volume to DICOM for fundus to DICOM; my thought would be to create a slightly different function to be called when writing the fundus dicom here...

[Jackiecs3]

Thank you so much for your feedback and testing, @Jackiecs3! Question 2 shouldn't be too difficult to address, moving the label and adjusting pixel spacing. Please correct me if I'm wrong, but I believe e2e utilizes a default fundus pixel spacing, so setting PixelSpacing to 0.011493\0.011493 (instead of 1.0\1.0 here) should fix the measurement accuracy.

For tag placement, currently opt_shared_functional_groups here is re-used from oct volume to DICOM for fundus to DICOM; my thought would be to create a slightly different function to be called when writing the fundus dicom here...

I will find a formal data to verify the accuracy of pixel spacing. AS a reference for @sustrev and @marksgraham , please provide me with your email address. I will send you the specific data via email.

[sustrev]

That would be excellent, thank you! My email is [email protected].

[Jackiecs3]

Thank you so much for your feedback and testing, @Jackiecs3! Question 2 shouldn't be too difficult to address, moving the label and adjusting pixel spacing. Please correct me if I'm wrong, but I believe e2e utilizes a default fundus pixel spacing, so setting PixelSpacing to 0.011493\0.011493 (instead of 1.0\1.0 here) should fix the measurement accuracy.

For tag placement, currently opt_shared_functional_groups here is re-used from oct volume to DICOM for fundus to DICOM; my thought would be to create a slightly different function to be called when writing the fundus dicom here...

e2e utilizes a default fundus pixel spacing （0.011493\0.011493），Is this value applicable to most e2e files? Is it just e2e files generated for certain device models?

Because besides this parameter（0.011493\0.011493）, I have also seen another parameter (0.011465\0.011465)

[sustrev]

I'm not sure; I haven't been able to find the pixel spacing data in the binary, which makes me wonder if e2e has a set default related to other specifications (model, scan type, etc) that their software identifies instead of having it stored in the file.

[Jackiecs3]

I'm not sure; I haven't been able to find the pixel spacing data in the binary, which makes me wonder if e2e has a set default related to other specifications (model, scan type, etc) that their software identifies instead of having it stored in the file.

How did you obtain this value（0.011493\0.011493）?

[sustrev]

That's simply copied over from the images you shared with correct values, nothing derived from my own test files.

[Jackiecs3]

That's simply copied over from the images you shared with correct values, nothing derived from my own test files.

How to obtain this value and whether it is accurate. I can provide some relevant e2e file data and provide the correct values for this batch of data as a reference for use. I hope it can provide you with some ideas.

Because I feel great using this project, I hope it can become more perfect.

We can do the following statistics
1、The manufacturer and model of these data
2、Are there significant differences or only slight changes in these values before.
For example: 0.011493 and 0.011465

Collecting and organizing this data can be time-consuming,

Of course, during this period, if you have corrected any issues on the 1st, 2nd, or 3rd, you can notify us to conduct testing and based on feedback.

[sustrev]

That would be excellent, thank you so much for your willingness to assist in improving the accuracy of this!

[Jackiecs3]

Hi Mark,

what are your thoughts on obtaining pixel spacing from e2e files? Have you successfully obtained this parameter from the file in the past?

[marksgraham]

There has been some discussion on this subject in the past, see here. We think it is likely calculated from some other variables (scan width/ eye distance to scanner). Tagging @ilannotal who has shown some interest in this topic in the past.

[Oli4]

I just had a look at the relationship between the scan focus and the scale given in VOL meta data (also from Heidelberg Engineering). I computed the length between the lens and retina for the scale and angle given in the file.

$$\text{length} = \frac{\cos(\text{angle})} {\sin(\text{angle})} \cdot \frac{\text{size\_x} \cdot \text{scale\_x}}{2}$$

This length correlates with the scan focus. But there seems to be an additional factor.

Next steps would be:

1. Identify the scan focus in the E2E file (It might be what LibE2E calls quality)
2. Search for a value in E2E that correlates with the residuals from the length / scan focus line.

I plotted the results for 100 volumes. The fitted linear regression has intercept 16.480 and slope -0.255

[Jackiecs3]

Hi Mark,

May I ask if there is any latest progress in resolving issue 1? When can I obtain the same number of dicom files as the jpg format?

I need to collect some data to ensure accuracy for Question 2, and it will take a few more days. After collection, it will be sent to you and @sustrev as soon as possible.

Can Question 3 be released together with Question 1 to form a new version?

[ilannotal]

HI, I just want to be sure - are we dealing here about dcm or about e2e of Heidelberg.
Regarding dcm, I'm trying to convert Zeiss(cirrus) output to avi (or mat) for analyzing it - Where are we with this challenge?

[marksgraham]

Hi Mark,

May I ask if there is any latest progress in resolving issue 1? When can I obtain the same number of dicom files as the jpg format?

I need to collect some data to ensure accuracy for Question 2, and it will take a few more days. After collection, it will be sent to you and @sustrev as soon as possible.

Can Question 3 be released together with Question 1 to form a new version?

I've pushed a fix for the the first issue, let me know if it works

[marksgraham]

HI, I just want to be sure - are we dealing here about dcm or about e2e of Heidelberg. Regarding dcm, I'm trying to convert Zeiss(cirrus) output to avi (or mat) for analyzing it - Where are we with this challenge?

We're talking about .e2e images - there is some new functionality to write these images to .dcm which is why that is being mentioned.

Re zeiss cirrus - the only reader we have is the simple .img reader here.

[Jackiecs3]

Hi Mark，
I pulled the latest code and after running it, I found that I could obtain the same number of dicom files as the images, which is really great.

At the same time, I have identified some new areas for improvement.
Question 4: The naming method of dicom files is consistent with that of image files, and the naming method of images is clearly more clear and readable.

Question 5: Multiple dicom files generated from one e2e file should use a unified series ID, now each file will have a separate Series Instance UID, which should be used.

After merging into a sequence, a new problem arises, which is the sorting problem. When a dicom file generates a name, there will be a count field that can be used for sorting. Write the content of this field into the (0020,0013) Instance Number label. This can solve the problem.
dicom： filename = f"{Path(input_file).stem}fundus{str(count)}.dcm"

Question 6
Add content in the Laterality field to the existing sequence description and use commas to separate it from other content.

Question 7:
It is recommended to temporarily change the pixel spacing value in the existing dicom file to 0.011493\0.011493. After reviewing about 300 files, I found that the value of 0.011493 is very close to other similar data values, except for a slight change in the last three digits, but the change is not significant. Now it's 1.0 1.0. This is obviously not suitable. It is recommended to temporarily change the pixel spacing value to 0.011493\0.011493
This adjustment will make the generated dicom files more standardized

[marksgraham]

Thanks for all this feedback! I'll try to look at some of this when I can but things are busy at the moment so might be a while.

[marksgraham]

It's going to be a while longer before I can put any significant dev time into this myself, but PRs for these issues are still welcome.

[Jackiecs3]

It's going to be a while longer before I can put any significant dev time into this myself, but PRs for these issues are still welcome.

If there are any details of any issues that need to be discussed, feel free to communicate with me at any time. I have been using our program recently, and I will summarize a batch of new improvement suggestions.

[Jackiecs3]

It's going to be a while longer before I can put any significant dev time into this myself, but PRs for these issues are still welcome.
Hi mark
Has there been any progress in resolving the issues in the recent feedback?
I have always felt troubled by these issues in my recent use, and I hope they can be resolved. If possible, can we start with simple problems. thanks