Open Dale-Black opened 2 years ago
It could be a bug.
What were the types for array
and file
? The dcm_write
function doesn't currently do any sanity checks, so a possible reason could be that the replaced values don't have the same type as the old PixelData and InstanceNumber values.
It looks like it does have something to do with the dcm[tag"Pixel Data"] = array
operation. When I comment out that line, the code runs fine and I can indeed write
that to a new DICOM file and then load it using dcm_parse
. I don't think it's the array type that is causing problems though since they have the same types. Could it be a problem with replacing the original Pixel Data
with a different size array for the new Pixel Data
?
Yup, the Rows
and Columns
fields will have to be updated if the size is different. I can never remember which of these should be 440 and which should be 640. Maybe see which combination gives a proper looking image.
That solved it
dcm[tag"Rows"] = size(array, 1)
dcm[tag"Columns"] = size(array, 2)
I am guessing there is a way to check for something like this when using dcm_write
so if I ever get enough time I will try to create a PR to do just that
I wrote this out on Zulip but I realized this might actually be a bug in
dcm_write
the more I am looking into itAny idea why a tag
(0x005e, 0x0040)
is being created after creating a DICOM file usingdcm_write
when the original DICOM file used indcm_write
doesn't contain the previously mentioned tag?