We are performing site maintenance. Some features may not not be available at this time.

Paul,
The ADIR_nii2dicom software we include+use in 0.3.x is writing new DICOM from the de-faced .nii, then copying only what it confidently knows won't mismatch with the newly created DICOM. So, InstanceNumber 1 may be entirely a different part of the image and could even be sliced with a totally different orietnation, vs. the original InstanceNumber 1. It's not trying to replace only PixelData or necessarily figure out/match the original ordering in the orignial DICOM. Bits, creation time, SOPInstanceUID, LargestImagePixelValue are all modified to be correct for the new data. 

For the CSA, that comes back to "only what it confidently knows won't mismatch with the newly created DICOM." It only copies the tags that are completely consistent within each volume (not necessarily in the whole series but at least in each volume). For the CSA, since it's a binary, we don't have a way to remove only certain parts. If anything in the CSA includes some info that varies for each slice (e.g. slice timing, max intensities, things like that), the whole thing is gone. The whole thing is not a perfect system but it preserves quite a bit more than any of the other nii->DICOM converters/replacers I was able to find at the time.

These challenges and others are why we've been rewriting the whole thing ground-up with an alternate approach "ADIR_DicomPixelReplacer" that probably works more like you're expecting. It also supports enhanced DICOM natively, which we needed for our Philips MEGRE support. With the new function, we'll be able to keep more tags more consistently, since it will decidedly preserve the original slice orderings. So for this, I acknowledge that we can do better, and we'll have that soon! On the other hand, it wasn't a big priority because AFAIK there's nothing too important in the CSA for the image types that we de-face. If we de-faced diffusion it would be different, but fortunately we don't have to. The need for the rewrite was mainly driven by Philips MEGRE not getting valid dcm2niix outputs after dcuncat. 

As for copying tags back post-hoc, there's probably at least one line of the CSA that won't be accurate anymore when you do that. How problematic that is vs. removing it entirely is up to you to assess. Certainly you shouldn't copy back the "modified" set of tags as those are changed for a good reason.

Chris