I took a look at the dicom file. It is not properly structured:
Missing tag: SAMPLES_PER_PX (0028:0002)
It is bad to not indicate how many channels a pixel has.
Missing tag: PHOTOMETRIC (0028:0004)
It is bad to not indicate how the pixels are structured.
Also missing tag: PIXEL_SPACING (0028:0030), should indicate size of a pixel.
Further, Bits Stored = 14
The IPP Dicom decoder does not use two very important tags: BITS_STORED (0028:0101) and HIGH_BIT (0028:0102). The decoder assumes the image is 16 bit, and thus with 14 bits, the whitest pixel has value 2^14-1, which in 16 bit space is 1/4 of white, or, dark gray.
If you want to fix this problem, you must modify the IPP Dicom decoder to return tags Bits Stored and High Bit.
Using that, you can add code to Left_Shift all bits 16-HighBit (16-14 = 2 -> 14 bit becomes 16 bit).
Actually, although your Dicom file is 14 bit, only 11 bits are used, thus even when upscaling the specified 14 bit to the full 16 bit, that result will display as a very dark gray image. To fix that, you need to disregard the specified 14 bit and "detect" the actual number of bits (11), and then do the upscaling.
Intel could consider adding code to the Dicom decoder sample, to upscale the image from <16 bit (9..15 bit) to full 16 bit, when returning a 16 bit image. Motivation: The Dicom file specifies 14 bit, so 2^14-1 = white. Therefore in the context of the Dicom decoder, the 14 bits *must* be considered full range, and then, since it returns a 16 bit image, it must remap 14 bit white to 16 bit white.
I found reason of this problem. In case of Lossless mode for J2K image saving variableparam.quality always equal to 0. This bring to encoding image to zero size. To fix this issue you need to change one row in filesavedlg.cpp. In functionvoid FileSaveDialog::updateJpeg2000Buttons(void) change: