1.一个dicom 文件里的SOPInstanceUID与MediaStorageSOPInstanceUID是相等的.类似的SOPClassUID与MediaStorageSOPClassUID也是相等的.
As to the reason why these items are duplicated, I can only speculate, but the File Meta Information Header only exists in dicom files (it is not transmitted by an SCP/SCU). When an SCP writes a file from the DICOM data it receives, it has to get the SOP class and instance UIDs from the dataset, so that is the mechanical reason they are the same. As to why these tags and not some others, I am sure there are many reasons, but note that the File Meta Information Header is always readable by any dicom entity as it is always "Little Endian Explicit" even if the following dataset is some weird transfer syntax. So these two fields are always guaranteed to be readable and usable in any valid dicom file (even if the group 8 versions are in an unreadable transfer syntax).
至于为什么这些项目是重复的原因，我只能推测，但文件元信息标题只存在于dicom文件中（它不由SCP / SCU传输）。 当SCP从它接收的DICOM数据中写入文件时，它必须从数据集中获取SOP类和实例UID，因此这是它们相同的机械原因。 至于为什么这些标签而不是其他标签，我确信有很多原因，但请注意，任何dicom实体都可以读取文件元信息标题，因为它始终是“Little Endian Explicit”，即使以下数据集有些奇怪 转移语法。 因此，这两个字段始终保证在任何有效的dicom文件中都是可读和可用的（即使第8组版本采用不可读的传输语法）。
2.下面用dicom表示读取的一个dicom文件.其中值得注意的是直接用dicom.pixel_array,获取的数据矩阵不可靠,很有可能是经过调整的hu值. 这时,我们要运用dicom.RescaleIntercept以及dicom.RescaleSlope获得这两个参数,并利用这两个参数获取原始的设备获得的hu值.公式如下
dicom.pixel_array*dicom.RescaleSlope+dicom.RescaleIntercept
这点我之前的博客https://blog.csdn.net/qq_36401512/article/details/85620706的代码中也有体现只是没有细说,这里顺便记录下.
3.由于一个文件夹下所有dicom的列表获取.但获取顺序是随机的(固定),要从小到大排序,可用dicom的SOPInstanceUID,ImagePositionPatient[2]或InstanceNumber三个属性来排序.但是SOPInstanceUID情况多样字符串排序比较麻烦(如出现.1,.10,.100,.2,.20,.200...之类的排序,很难办.),ImagePositionPatient[2]世界坐标的z轴会存在小数的情况.故而推荐使用InstanceNumber来排序简单(1,2,3,....).
4.讲讲sort以及np.argsort函数的使用对照第3点:
ll.sort(key=lambda x:x[1])#ll列表,key=lambda x:x[1]表示用第二个元素升序(默认)排列
pbb = np.copy(result_pbb)#result_pbb矩阵 a = np.argsort(-result_pbb[:, 0]) # 获取按第1列降序(升序去掉-)排列的索引. result_pbb = result_pbb[a]#重新排列后的矩阵