slice position information

hello, I want to transfer the dicom files into 4d nifity files, but mrconvert give following errors:
mrconvert: [ERROR] slice position information missing from DICOM header!
mrconvert: [ERROR] error reading series 15 of DICOM image "041075-28 (041075-28) [MR] epi_dti_xd_iso1.4_DIR64_SaveBySlc"
mrconvert: [ERROR] error opening image "epi_dti_xd_iso1.4_DIR64_SaveBySl_20191215_124008"
And I know the positon of slices are left to right and up to done from the dcm files. So how can I solve this problem.

I’ve had a quick look at the data you sent me. It seems to contain images acquired on a United Imaging system – this is the first time I’ve come across data from that manufacturer. It looks like each file contains all slices for a given volume, stored as multi-frame dataset (even though your file naming suggests you expect the data to be stored slice-wise). It’ll take me a bit of time to figure out how to handle data of this nature correctly, but hopefully I’ll find time to look into this over the next few days.

OK, I’ve dug around a bit more with the data you sent. As far as I can tell, these are not stored according to the DICOM standard. The data stream is DICOM (I can parse it all without errors), but the information required to actually interpret the images is inconsistent. I’ve used dcminfo -all 000002.dcm (any of your source DICOM images will do) to inspect the data attributes. These are the relevant lines in the output, with my comments before some of the entries (the lines starting with a #):

TYPE  GRP  ELEM VR     SIZE   OFFSET   NAME                                   CONTENTS
----- ---- ---- --  -------  -------   -------------------------------------  ---------------------------------------
# These are the number of samples acquired along the ROW and COL axes of the image,
# but the images are often reconstructed to different sizes using e.g. zero-filling. 
# so it's useful to know, but not usable on its own to read the data:
# instead we need to rely on the ROWS & COLUMS entries below
[DCM] 0018 1310 US        8     1658   AcquisitionMatrix                      72 0 0 68
# these are the standard entries for the image size, but this is far too big,
# the images appear to be 72×72 ...?
[DCM] 0028 0010 US        2     2208   Rows                                   576
[DCM] 0028 0011 US        2     2218   Columns                                576
# That's an unexpected number of slices... as far as I can tell, there should be 62 slices?
# But it matches the total number of acquired slices: 62 slices × 68 volumes
[DCM] 0054 0081 US        2     2448   NumberOfSlices                         4216
# this matches the acquisition matrix entry, but the images appear to have been reconstructed as 72×72?
[DCM] 0065 1004 SH        6     2634   unknown                                68*72        
# I expect that's the number of slices, but it's not a standard DICOM tag 
# (odd group IDs are private entries, which vendors are allowed to use -- 
# but they're not part of the standard)
[DCM] 0065 1050 DS        2    25798   unknown                                62
# At this point, there's a sequence container that seems to contain slice-specific information, 
# but again, this is within a private, non-standard tag -- so can't be standards-compliant:
[DCM] 0065 1051 SQ        0    25808 > unknown
[DCM] FFFE E000 UN        0    25820   - Item
[DCM] 0008 0022 DA        8    25828     AcquisitionDate                      2019/12/15
[DCM] 0008 002A DT       22    25844     AcquisitionDateTime                  20191215124705.145000
[DCM] 0008 0032 TM       14    25874     AcquisitionTime                      12:47:05.145
[DCM] 0018 9073 FD        8    25896     AcquisitionDuration                  26
[DCM] 0020 0032 DS       36    25912     ImagePositionPatient                 -47.2232819 -80.0572052 -45.8242874
[DCM] 0020 1041 DS       12    25956     SliceLocation                        -18.2261829
[DCM] 0065 100F SH        6    25976     unknown                              F18.2
[DCM] 0065 1015 DS       22    25990     unknown                              -1.418 -33.411 -30.383
[DCM] 0065 1029 SH        4    26020     unknown                              0.03
[DCM] FFFE E00D UN        0    26032     ItemDelimitationItem                 unknown data type
[DCM] FFFE E000 UN        0    26040   - Item
[DCM] 0008 0022 DA        8    26048     AcquisitionDate                      2019/12/15
[DCM] 0008 002A DT       22    26064     AcquisitionDateTime                  20191215124708.435000
# repeated for 62 entries...
# this is the part that contains the actual raw data, but this only makes sense 
# if it contains a 576×576 16-bit image (which actually matches the ROWS & COLS entries). 
# Alternatively, this matches 64 images at 72×72 - but there are 62 slices as far as I can tell? 
[DCM] 7FE0 0010 OW   663552    39260   PixelData                              unknown data type

So the only way I can interpret what’s going on is that the images are stored as an 8×8 mosaic of images of size 72×72 – I can’t see why else there would be space for 64 slices in the data portion. There’s a precedent for that with the Siemens mosaic format, but that again is very non-standards compliant and requires very custom handling to get right, and these images are encoded quite differently from what I see in your data.

In terms of standards compliance, the fact that a lot of the critical information is stored within private tags is a Bad Idea. For one thing, it means that most of this information wouldn’t survive anonymisation, since most anonymisation software packages would strip out any private tags (since they’re unknown, there’s no way for a software program to guarantee that their contents don’t contain identifiable information). This is actually also a problem for data stored using the Siemens mosaic format (it can be near-unusable after anonymisation).

So basically, I don’t think I can sort this out quickly – and I’m not inclined to invest much time in this given how non-standard these images appear to be. If you have access to the system, you might be able to modify the settings used by the system to produce the DICOM data, and hopefully end up with data you can actually convert correctly…? You might also investigate other DICOM converters – and if you find one that actually works, let me know! I might be able to replicate their handling if it’s sufficiently simple.

It’s also worth contacting the manufacturer about this: I expect any DICOM software package will struggle with these data, and that’s bound to cause issues for interoperability with all kinds of 3rd party systems, including radiological workstations, neurosurgical navigation workstations, etc…