|
ClearCanvas Community Forums
|
Measurement graphics (both built-in and custom) not saving correctly in key images
Last Post 2010-03-25 02:17 PM by WaltRiceJr. 3 Replies.
|
Sort:
|
|
Prev Next |
You are not authorized to post a reply. |
|
| Author |
Messages |
 |
WaltRiceJr
 New Member Posts:6
 |
| 2010-03-22 11:00 AM |
|
Hello,
I'm building a custom plugin with a measurement template, and have based much of it on the included protractor tool. Everything seems to work great, including saving the image via the "clipboard" feature, but saving as a key image is eluding me.
The callout gets saved, but there is no image of my measurement graphic. I think the problem is also demonstrated in the protractor graphic, where when you save it on a key image, the main lines of the polyline graphic are displayed, but the arc for the angle is missing.
How can I resolve this and save all of the related graphics to the key image? (If you fix the protractor tool, I think that will guide an approach to my tool as well -- but I'm stuck!)
Thanks,
Walt Rice
WaltRiceJr@gmail.com |
|
|
|
|
WaltRiceJr
 New Member Posts:6
 |
| 2010-03-23 10:28 PM |
|
An update:
I was previously unaware of the DICOM annotation serialization framework, and since there were no serializers defined for my objects, they didn't save to the key image. I have some semblance of this saving working now, using the following code for my graphics object, which extends CompositeGraphic:
[DicomSerializableGraphicAnnotation(typeof(HipTemplateGraphicDicomSerializer))]
public class HipTemplateGraphic : CompositeGraphic, IPointsGraphic
{
// ... the whole class here ...
private class HipTemplateGraphicDicomSerializer : GraphicAnnotationSerializer<HipTemplateGraphic>
{
protected override void Serialize(HipTemplateGraphic graphic, GraphicAnnotationSequenceItem serializationState)
{
foreach (IGraphic subgraphic in graphic.Graphics)
SerializeGraphic(subgraphic, serializationState);
}
}
}
I'm building against 1.5 SP1, so I can't immediately verify if these issues are resolved, but there are a few things that possibly need fixing in the main ImageViewer code base:
- CompositeGraphic objects have no serialization code or logic defined. They should, by default, just iterate through and serialize each subgraphic.
- LinePrimitive objects have no serialization defined. The DICOM stuff obviously can handle this, and I shouldn't have to extend LinePrimitive to make it work with key images (EllipsePrimitive, for instance, works just fine).
Other questions:
- Is it possible to set the color of the DICOM annotation graphics before saving? (Does DICOM support this?)
- Same question, but with regard to LineStyle?
- Callouts with modified fonts do not save with such; is this a DICOM limitation, or just not a feature in ClearCanvas?
Thanks in advance for your help!
Walt Rice |
|
|
|
|
jasper.yeh
 Senior Member Posts:521

 |
| 2010-03-24 05:15 PM |
|
Hi Walt,
Yes, I also thought we need some default serialization logic to be defined for primitives and composites. We've already entered ticket #5942 to implement this, but it might be some time before we actually get a chance to do it. At any rate, you don't have to perform serialization at all levels - you could implement the serialization for everything at the composite level. At the primitive level, a line is a line, but at the composite level, you know that line 'A' denotes anatomy and should be solid, while line 'B' associates some text with the anatomy and should be presented differently, perhaps dashed, or something like that.
Unfortunately, the specification for DICOM presentation states is quite basic as of DICOM 2008, and many of the presentation options are left up to the implementation at the receiving end. Text font is one of these; line style is another. Colour may be specified, but it is applied for an entire layer of presentation state graphics, and is specified as an ICC colour (something we lack support for, and thus we always render in the same default colour). There does exist a Supplement 120 which specifies extended presentation states, but it is currently still in the draft stages. When this supplement is finally released, we will probably take a look at bringing our presentation state implementation up to date with it.
(Note about line style: we have some code as a workaround for dashed lines if you're interested. The source code is in a changeset that hasn't been merged into the trunk yet, but I'll attach the relevant code snippet.)
Hope this helps! |
Attachment: dashedLinePresentationStateSnippet.txt
|
| // Jasper |
|
|
WaltRiceJr
 New Member Posts:6
 |
| 2010-03-25 02:17 PM |
|
Jasper,
Thanks for the response.
Given that my template is made of up circles and lines, with the one callout that is already correctly serialized, I think the easiest approach is just to write the serializer for the line and tell the CompositeGraphic to serialize all the subgraphics. I subclassed LinePrimitive and wrote my own serializer (attached, if you want it), and everything seems to work fine.
It's actually a circle where I would want to use the dashed or dotted line style, so while your workaround is rather creative, I don't think it will work for me. I'll have to wait for colors (my preferred choice) sometime in the future.
Peace,
Walt |
Attachment: LinePrimitiveDicomSerializer.txt
|
|
|
|
| You are not authorized to post a reply. |
|
Active Forums 4.1
|
|
|
|
|