When I set PixelRepresentation to 1, which is also carried out to the written .*dcm files, nothing changes. Everything I set in the C++ code is carried over, except the rescale slope and intercept. Below is an image for comparing the header information:
Also, what I noticed is the following: I have set the PixelType for my DICOM images like this using OutputImagePixelType = float;. This works fine, but the images are ALWAYS interpreted as short or int when read by ITK-SNAP. Are these expected or are we facing a possible error here, where I just set my datatypes wrongly?
An additional indicator for that (I think) is that when I take another data set, where one time set the datatype to unsigned short (gets displayed not correctly), and one time to signed short ( gets displayed correctly) the Pixel Representation tag is only set rightly for the correctly displayed one:
Left: correctly displayed and correctly set Pixel Representation Right: not correctly displayed due to being unsigned with intensities starting at -1024 and not correctly set PixelRepresentation tag
Again, thank you a lot. Feels like we are getting close.
using OutputImagePixelType = float; is the right setting. What you are experiencing is due to the use of ITK-SNAP. I believe it converts the data during reading. If you open the image in Slicer you’ll see the original float values.
Not sure what is causing the writer to ignore your setting of the slope/intercept values, that is very strange. Will require some more debugging on your side (see that the GDCMImageIO actually accesses these values during writing walk through this portion of the code with your debugger).
Okay, then I will switch to Slicer altogether for checking the results. I just found it weird that I can read the nifti file, but the dicom images are wrapped regarding their intensity - interesting.
Thank you again, I will try walking through the GDCMImageIO part during the writing and report back if I find something.
Anything else there is that I did wrong potentially?
I got it working. I am not quite sure what the tipping point was, but my best bet is that the pixel type of the output image must be float, and setting the metadata must be of type std::string. After I changed that back, it was working flawlessly.