I chose not to compress the icon image, because it is not required by the DICOM standard (PS 3.5-2004, page 63: "Pixel Data within an Icon Image Sequence may or may not be compressed"). Further, I think an icon image is especially useful if it is easily accessible.
When debugging the software I found the following code in the file dcpixel.cxx:
Code: Select all
if (xferSyn.isEncapsulated() && (! isIconImage))
{
if (fTransferState == ERW_init)
{
DcmRepresentationListIterator found;
errorFlag = findConformingEncapsulatedRepresentation(xferSyn, NULL, found);
.
.
.
isIconImage is false because it is not set when reading the original image. In stead of checking for an Icon Image Sequence, the decision is based on the presence of unencapsulated pixel data in a file with encapsulated transfer syntax:
Code: Select all
if (Length == DCM_UndefinedLength)
{
....
}
else
{
/* the pixel data is captured in native (uncompressed) format */
/* if the transfer state is ERW_init, we need to prepare */
/* the reading of the pixel data from the stream. */
if (fTransferState == ERW_init)
{
current = original = repListEnd;
unencapsulatedVR = Tag.getEVR();
recalcVR();
existUnencapsulated = OFTrue;
if (ixferSyn.isEncapsulated())
{
/* Special case: we have encountered an uncompressed image
* although we're decoding an encapsulated transfer syntax.
* This is probably an icon image.
*/
isIconImage = OFTrue;
}
}
My question is:
Is my analysis correct, or did I forget something? And if you think I am right, do you think it could be an item on the 'to do list' for the next version?