[Insight-users] Padding in synthetic DICOM

[Federico Milano]

Hi Mathieu,

Thanks for your suggestions. I've changed from Secondary Capture to CT Image
and the problem is still there.

I've also set these fields to "imitate" an original CT DICOM file:

tagkey = "0028|1052"; // Rescale Intercept
value = "-1024";
itk::EncapsulateMetaData<std::string>(dict, tagkey, value);
tagkey = "0028|1053"; // Rescale Slope
value = "1";
itk::EncapsulateMetaData<std::string>(dict, tagkey, value );
tagkey = "0028|1054"; // Rescale Type
value = "HU";

but the generated DICOM shows "US" as "Rescale Type", and it doesn't solve
the problem.

I've tried to change the "SyntaxTransfer" field to "Implicit VR Little
Endian", but I don't know if that makes sense.

Today I've tried with 3DSlicer and it opens o the generated DICOM. I'm still
wondering why VolView fails when trying to open it (and also why the Stryker
navigator renders it with a grey box around).

Thanks,

Federico

On Thu, Apr 7, 2011 at 8:53 AM, Mathieu Malaterre <
mathieu.malaterre at gmail.com> wrote:

> Federico,
>
>  Pixel Padding is in the General Equipement so it should be ok to
> have this attribute in Secondary Capture Image Storage. Anyway maybe
> there is an issue with support of those SOP Class Instance. What i
> would do it simply try to convert the Seconday Capture to CT Image
> Storage just in case...
>
> 2cts
>
> On Thu, Apr 7, 2011 at 2:21 AM, Federico Milano <fmilano at gmail.com> wrote:
> > Hi, I'm generating a synthetic DICOM image with the Insight Toolkit
> (using
> > itk::GDCMImageIO) and I've found two problems:
> >
> > VolView fails loading my DICOM (with the message: Sorry, the file cannot
> be
> > read). ITK-Snap opens and shows it OK.
> > I'm trying to use this image in a Stryker surgical navigator. The problem
> is
> > that the image is loaded ok, but then the padding pixels are shown in a
> > certain gray level, showing a box (actually the bounding box) of the
> image.
> > If I load non synthetic DICOMs this doesn't happen.
> >
> > This is what gdcminfo is showing:
> >
> > MediaStorage is 1.2.840.10008.5.1.4.1.1.7 [Secondary Capture Image
> Storage]
> > TransferSyntax is 1.2.840.10008.1.2.1 [Explicit VR Little Endian]
> > NumberOfDimensions: 2
> > Dimensions: (33,159,1)
> > Origin: (0,0,0)
> >
> >
> > Spacing: (1,1,1)
> > DirectionCosines: (1,0,0,0,1,0)
> > Rescale Intercept/Slope: (0,1)
> > SamplesPerPixel    :1
> > BitsAllocated      :16
> > BitsStored         :16
> > HighBit            :15
> > PixelRepresentation:0
> > ScalarType found   :UINT16
> >
> >
> > PhotometricInterpretation: MONOCHROME2
> > PlanarConfiguration: 0
> > TransferSyntax: 1.2.840.10008.1.2.1
> > Orientation Label: AXIAL
> >
> > I'm using unsigned short as pixel type in itk::Image object and I'm
> setting
> > all the padding pixels to 0 (zero), as is suggested by the DICOM standard
> > for unsigned scalar images. gdcminfo does not show it, but I'm also
> setting
> > the Pixel Padding (0028,0120) field to zero.
> >
> > I would really appreciate any hint about this problem.
> >
> > Thanks in advance,
> >
> > Federico
> >
> > _____________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://www.kitware.com/products/protraining.html
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.itk.org/mailman/listinfo/insight-users
> >
> >
>
>
>
> --
> Mathieu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20110408/20d684c5/attachment.htm>