Possible error in `dcm_write`

[Dale-Black]

I wrote this out on Zulip but I realized this might actually be a bug in dcm_write the more I am looking into it

Any idea why a tag (0x005e, 0x0040) is being created after creating a DICOM file using dcm_write when the original DICOM file used in dcm_write doesn't contain the previously mentioned tag?

[notZaki]

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.

[Dale-Black]

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?

[notZaki]

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.

[Dale-Black]

That solved it

dcm[tag"Rows"] = size(array, 1)
dcm[tag"Columns"] = size(array, 2)

[Dale-Black]

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