Thursday, February 09, 2012
Google Custom Search

ClearCanvas Highlights

Download our Open Source software
Watch some Videos
Get the Source
Check out our Licensing
Join our  Forums
Some Research: OICR IPP-Trials

Our Community

Membership Membership:
Latest New User Latest: tchlee
New Today New Today: 16
New Yesterday New Yesterday: 26
User Count Overall: 20579

People Online People Online:
Visitors Visitors: 13
Members Members: 4
Total Total: 17

Online Now Online Now:
01: okdicom
02: ShaffstallK706
03: rlake
04: tchlee

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.
Printer Friendly
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
WaltRiceJr
New Member
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
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
Senior Member
Posts:521
Avatar

--
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
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
Copyright 2011 ClearCanvas Inc.