RenderImage produces black image in WPF

[Anton Eagle]

I am trying to render images created from a linear accelerator (DICOM RT Images).  When using the instruction on the Wiki... I end up with a WriteableBitmap with all zeros... a black image.  The code I am using is...

            ImageManager.SetImplementation(WPFImageManager.Instance);

            WriteableBitmap wBM = theDI.RenderImage().As<WriteableBitmap>();

The DICOM image has some unusual window and leveling values, because the linac uses units called "CU" for this image, which are approx. 0.21 and 0.11 respectively.  Are these values being less than 1 causing this problem?  When I specifically set the WindowWidth and WindowCenter values to something more reasonable in the code, it does not change the image... still all black.  Any ideas?

Attached is the DICOM image in question.  And note, I can display this image in all sorts of other programs (ImageJ for example) and it displays just fine using PyDICOM as well, so there is nothing inherently wrong with the image.

[Reinhard Gruber]

fo-dicom internally works with integers to represent pixel data. The raw pixel data are word-values with possible values from 0 to 64000. then there is a RescaleSlope of 5.6e-06, so after multiplying the values with this rescaleslope, the possible values are in range from 0 to 0.35 (actually 0.11 and 0.21 as you told previously). Internally this is stored as integer and therefore rounded to 0 for all pixel values. Even if then the windowing of windowcenter 0.1 and windowwith 0.2 is applied, all the values are mapped to black.

So fo-dicom is not ready at the moment to process this kind of RT Image, but as I see in code the change would not be too much to make it work. 

Would you create an issue on github/fo-dicom/fo-dicom?

[Anton Eagle]

I ended up just writing my own code to create a 32-bit byte array... with each byte (corresponding to each color channel) being 255 * (pixel_value / 65536), where pixel_value is the 2-byte word corresponding to the actual DICOM pixel values.  I ignored RescaleSlope, as I don't need it, or want it, for rendering in this case.  For this image type, RenderSlope is just used to the get absolute values of the pixels in the correct range to be equivalent to "measured dose".  I don't care about dose, and just want the image.  Doing this got me a nice grey-scale image.  

So, I guess I just ended up rending this for myself.  Thanks though, for verifying that I wasn't going crazy... and that it was in fact the weird pixel values that were causing me the problem.

Question though... is it really supposed to be a fraction of 64000 instead of 65536?   I assumed that a 16 bit image had 2^16 possible values.  So, why 64000?

Also, I will submit a feature request... using the username "centuraphysics".

Thanks again for your prompt reply.