How does one set the PatientPosition and other spatial attributes when writing a dicom CT volume?

I am trying to write DICOMs of a CT volume in both single- and multi-file form. To check that the result is readable, I try reading the file(s) back in with dicomreadVolume(). Below is one such attempt.

            info.StudyDescription = 'Description';
            info.SOPClassUID = '1.2.840.10008.5.1.4.1.1.2';
     
            info.PixelSpacing = [1,1]; % x & y voxel size
            info.SliceThickness =1; % optional
            info.SpacingBetweenSlices = 1; 
            
            info.ImageOrientationPatient = [1,0,0,0,-1,0]; 

            info.PatientPosition='HFS';
            

         status=dicomwrite(ones(250,250,1,250),'out.DCM', info,'CreateMode','copy','ObjectType',...
                                              'CT Image Storage','MultiframeSingleFile',1);

Warning: The 'SOPClassUID' and 'ObjectType' parameters are ignored when 'CreateMode' is 'copy'.

         info=dicominfo('out.DCM');

Clearly, the write operation produced a DICOM file containing a PatientPosition attribute because,

         info.PatientPosition

ans = 'HFS'

Why then, does dicomreadVolume complain?

         
         V=dicomreadVolume('out.DCM');

Error using images.internal.dicom.getSeriesDetails>throwMissingPatientPosition (line 140)
File "out.DCM" must contain the attribute 'PatientPosition'.

Error in images.internal.dicom.getSeriesDetails (line 29)
throwMissingPatientPosition(filename)

Error in dicomreadVolume (line 101)
[seriesFilenames, spatialInfo, sliceDim] = images.internal.dicom.getSeriesDetails(filenames);

[Simon Chan]

Did you encounter similar issue for both single and multi-file form?

I think it should be easier for multi-file form since you do not need to re-create a 3D volumn via dicomwrite.

[Rik]

This is really strange. The error message doesn't actually match what is going on.

Best I can tell, the getSpatialDetailsForMultiframe function fails to extract 'PerFrameFunctionalGroupsSequence' and 'SharedFunctionalGroupsSequence'. It then returns an empty object, because it doesn't even attempt to access the PatientPosition attribute.

My guess would be that the two attributes are required by dicomreadVolume, but are not written by dicomwrite.

This mess is one of the reasons I only use DICOM as an interchange format and only use slices.

[Matt J]

@Simon Chan the syntax dicomreadVolume(folder) also fails with the same error. I can read single file format with dicomread() and I can read multi-file format if I use dicomread() in a loop over the different files. But the benefit of dicomreadVolume(), I thought, was to handle all that in a unified way..

@Rik Which two attributes do you mean? What's the other attribute?

It's clear to me that some attribute is missing that allows dicomreadVolume to populate its second output argument (spatial), but it's obscure to me both what that attribute is (maybe ImagePositionPatient?), and what format it should take for dicomwrite() to handle it properly in both the single and multi-file cases.

[Rik]

I just followed the execution to a few lines before the error is thrown. The code tries to determine these two values. I haven't googled them to see if they are actual DICOM attributes, or just internal Matlab ones. At any rate, those two are empty, leading to the error you see. The strange thing is that the object in the workspace of that function actually does contain the PatientPosition. So the error message is incorrect. I can't tell if this is a bug or not.