Dose metric disagreement as compared with CERR

[sama2689]

I have noticed that some metrics (e.g. 0.5cc) differ from the value calculated by CERR by as much to 10Gy for certain organs in a particular rtdose+rtss file pair when I use dvh calc. It is possible for binning to be the culprit for such a large deviation in these features? Is it possible to adjust the binning within the code to control this if so?

[bastula]

Small volume metrics with large (relatively speaking 0.3 cm x 0.3 cm or larger) dose grids will show inaccurate values due to dose volume averaging. Enabling interpolation in the dvh calculation parameters should help mitigate that issue. Another option is to export the RT Dose grid at 0.1 cm x 0.1 cm grid size, which tends to be more consistent with other systems.

[sama2689]

Thank you, unfortunately I don't have control over the export dose grid, I only have the dose grids I have been given, so I cannot export them with different grid size. Could you describe what you mean by dose volume averaging?

I tried enabling interpolation and to see if that improves the calculation. If i understand correctly in order to do this when calling get_dvh I set interpolation_resolution to a float in mm and interpolation_segments_between_planes to at least 1, so I tried

dvhcalc.get_dvh(rtss_dir,rtdose_dir,19,interpolation_resolution=1.0,interpolation_segments_between_planes=1)

but I get an attribute error when calculate_dvh is called, 'AttributeError: New pixel spacing must be a factor of 1.50375/(2^n), where n is an integer. Value provided was 1.'

What are the implications of this and where does that pixel spacing factor come from?

EDIT: It looks like the bulk of the disagreements are happening at the edge of the structure when compared to CERR, e.g. 0.1cc can sometimes differ by as much as 10Gy. This makes me think that there must be some fundamental differences in how dicompyler-core and CERR are computing the DVH. I have plotted histograms from CERR with a histogram from dicompyler-core for comparison. However I was not able to quite work out by looking at the source code just how dicompyler-core is computing the DVH. My “guess” is that dicompyler is choosing which voxels are within the mask differently. Could it be something as simple as where the “centre” of the voxel is defined as with respect to the structure geometry? i.e. bottom corner vs. centre of the voxel?

below are the DVHs as computed by CERR (mr and tw, which are identical) and the DVH as computer by dicompyler-core (ps). They are mostly similar but you can see that there is some discrepancy in the higher dose regions.

EDIT 2: As suggested, I have enabled interpolation, which I have done as shown here, setting n=2 and determining interpolation as follows:

rtdose = dicomparser.DicomParser(dose_path)
pixel_spacing=rtdose.GetDoseData()['pixelspacing']
if pixel_spacing[0]==pixel_spacing[1]:
            interpolation_resolution=pixel_spacing[0]/2**n
        else:
            interpolation_resolution=(pixel_spacing[0]/2**n,pixel_spacing[1]/2**n)

This seems to produce a DVH much more similar to CERR, but the computation time is now more than double.

This seems to solve my problem, but I am still not quite sure why or how. What does this interpolation resolution do that was not being done earlier?

[bastula]

The interpolation is just interpolating the dose grid resolution (in your case) from 1.50375 x 1.50375 to 0.751875 x 0.751875. Thus the voxel size would be 1/4 the size of the original dose grid. Then in the case of high dose gradients, the change in dose over a small distance can be more appreciably sampled in each voxel. This leads to close agreement with the other systems. The factor needs to be 2^n since it needs to be a n factor smaller.

I hope that helps.

[sama2689]

So does that mean that the dvh is more accurate at higher n? Or is this just something that enables agreement with other systems? When it interpolates the dose grid, is it performing linear interpolation based on the doses in the closest planes?

[bastula]

Sorry for the delayed response. It's really a matter of debate. Finer dose grid resolution will enable better agreement with other systems. However, as you mentioned, it will take longer to calculate.

During interpolation using the argument interpolation_resolution performs linear interpolation on the same dose plane (z).

When using the argument interpolation_segments_between_planes it does not actually interpolate, but copy slices between actual planes (z) to mimic interpolation. This problem is a little harder to solve.

[sama2689]

Thanks, that's a very important clarification. Now is there any reason that finer dose grid resolution would be less accurate (or at least not an improvement on accuracy)? Ignoring the effect on computation time is there any reason that in principle a smaller n would produce more accurate result? I am a bit confused as to why there is indeed a debate.

I can understand why interpolation_segments_between_planes might not be more accurate, but unless I'm missing something it seems like higher n should always be the more accurate dvh?

[sama2689]

I'm closing this issue as larger n solves it.

[bastula]

What I meant to say is there are diminishing returns on increasing n relative to calculation time. It depends on your use case. I published a poster for AAPM 2018: SU-I-GPD-T-99 that detailed that. In my clinical projects, I found the sweet spot for resolution n was PixelSpacing / 16. Hope that helps.