Friday, February 10, 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: 孙磊
New Today New Today: 1
New Yesterday New Yesterday: 27
User Count Overall: 20591

People Online People Online:
Visitors Visitors: 9
Members Members: 1
Total Total: 10

Online Now Online Now:
01: 孙磊

ClearCanvas Community Forums

Responsibility of ImageViewer vs Dicom libraries
Last Post 2009-11-15 03:27 PM by stiank81. 9 Replies.
Printer Friendly
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Resolved
stiank81
Advanced Member
Advanced Member
Posts:33

--
2009-10-30 05:55 AM  

Hi,

I've asked a few questions before, and you've given good answers, but we're confused about the responsibility of the different ClearCanvas libraries.

We're building a Wpf application that will have a Dicom viewer. We're attempting to use the ClearCanvas library to handle the Dicom files and protocol, and have just started the work on this. Note that we want to handle all the View parts ourselves. All we want is a library that loads a Dicom file and provides the attributes to us, including the images - in a useable form.

We're looking at the libraries Dicom and ImageViewer. Our initial thought and understanding is that the Dicom library handles the Dicom file itself, and the ImageViewer contains WinForms objects to embed in WinForms applications for viewing the Dicom files. If this is correct it sounds like we'd want to stick to the Dicom library. However, there has been recommendations that we use the ImageViewer "as a library" - and just don't worry about the view-parts, but I haven't really understood why.

What we've done this far is actually using the class LocalSopDataSource from the ImageViewer library to handle the file:

    var localSopDataSource = new LocalSopDataSource(new DicomFile(dicomFilePath));
    var patientName = localSopDataSource.File.DataSet.GetAttribute(DicomTags.PatientsName);
    var imgData = localSopDataSource.File.DataSet.GetAttribute(DicomTags.PixelData);

           

..But I see that you just as easily can use the DicomFile object directly - and get the exact same data out: 

    var file = new DicomFile(dicomFilePath);
    var patient = file.DataSet.GetAttribute(DicomTags.PatientsName);
    var image = file.DataSet.GetAttribute(DicomTags.PixelData);

 

So; why would I want to use the ImageViewer anyway? My current problem is setting the PixelData to an image, and I assume the answer relates to this?

I'm sorry, but we just don't understand the separation of responsibility between your libraries. Is it reasonable to use the ImageViewer library to handle the files even if we want to make the viewer ourselves? I hope you can enlighten us, and that we can use ClearCanvas in our application :-) 

Cheers,

Stian

 

stewart
Senior Member
Senior Member
Posts:2033

--
2009-11-03 01:43 PM  

Hi Stian, I hope my reply will explain a little more about the value of the viewer.  The viewer, although currently not as well separated out as I'd like, is not just for embedding WinForms objects in an application.  In fact, if you tried to do that, I think you'd find it rather hard to do, although I know there have been some forum members who have succeed with this.

ClearCanvas is an application framework, and is actually not tied in any way to WinForms.  When you look in the plugins folder, you'll see that each plugin (e.g. CC.ImageViewer) has a corresponding plugin with a .View.WinForms extension.  This is the GUI plugin for the corresponding logical model, where all the actual business logic resides.  Please see this post where there was a rather heated but healthy discussion on the CC architecture and converting to WPF.  The idea behind the CC architecture is that the .View.Winforms plugins could be completely swapped out with .View.WPF plugins and we wouldn't have to rewrite all the actual business logic.  Separation of model and view is a very common thing to do, and there are a number of design patterns that describe slightly different ways to do it; CC is based on Presentation Model.

Anyway, CC.ImageViewer.dll is the plugin that contains all the business logic of a typical DICOM viewer application, and it has no ties to WinForms.  You can use the classes defined in it to, say, load a DICOM image and render it to a bitmap, then put that bitmap in a WPF Image control.  This would take about 10 lines of code with the viewer, and considerably more if you were to write it yourself.  Search these forums for "DrawToBitmap" and you should find some examples, although they may be a bit outdated.

The viewer also handles pretty much everything for you in terms of display.  Lookup tables (LUTs), DICOM Overlays, Presentation States, Color Maps, spatial transforms (zoom/pan), overlaid vector graphics, rendering, interpolation - everything!  If you choose to just use the DICOM library, you'll be extremely limited in terms of what you can do without rewriting all the stuff in the viewer.  You can't just take the pixel data straight out of a DICOM file and put it in an Image control - there's really a lot more to it than that.

Anyway, I hope this clears things up a bit.

Best regards,

Stewart

Real-time support available to Clinical Edition and Team Edition customers
stewart
Senior Member
Senior Member
Posts:2033

--
2009-11-03 01:50 PM  
Sorry, you did mention towards the end of your post that you're writing your own viewer. I would say that the ImageViewer code can definitely help you get your own viewer up and running faster, but it's really a matter of choice. If the way the ImageViewer is architected doesn't mesh well with how your viewer is supposed to work, then you can most certainly just use the DICOM library and write all your own viewer code from scratch.
Real-time support available to Clinical Edition and Team Edition customers
stiank81
Advanced Member
Advanced Member
Posts:33

--
2009-11-09 02:39 AM  
Thanks Stewart,
That was clarifying. I'm well aware of the Presentation Model pattern, and it's comforting to hear that you are too. What got me confused was the "Viewer" part of the ImageViewer. I got the impression that this was in fact the WinForms viewer component. Now that I've learned that it isn't - and that viewing the image is more than just fetching the data from the dicom file - I'm starting to get the architecture of the ClearCanvas library. Thanks!

I'm using the ImageViewer library with DrawToBitmap in my Wpf application. This far it's working really well - except for some files that aren't supported. Will there be extended support for e.g. more image types and transfer syntaxes in version 2.0?

Stian
stewart
Senior Member
Senior Member
Posts:2033

--
2009-11-10 11:09 AM  
Hi, there won't be any additional transfer syntax support in 2.0. With the exception of JPEG2000, we've got the most common transfer syntaxes covered, although there are plenty we don't support. The biggest problem is finding reliable codecs that are free and that can be distributed freely with our open source offering.

Best regards,
Stewart
Real-time support available to Clinical Edition and Team Edition customers
smr99
Advanced Member
Advanced Member
Posts:54

--
2009-11-10 01:36 PM  

Stewart,

In the case of JPEG2000, is there a codec that is reliable enough to use?  In the past, I've used Kakadu, but it's been several years since I looked into this question.

Does CC have a commercial offering with JPEG 2k?

Thanks,

-Steve

 

stiank81
Advanced Member
Advanced Member
Posts:33

--
2009-11-10 02:14 PM  

Thanks for the feedback Stewart.

I guess we'll just have to live with the current support for now, and we'll evaluate if this is sufficient after a while. No matter what ClearCanvas has proven excellent for the development of our product. And we'll see if its support is sufficient for production eventually. Is there a complete overview of the support somewhere? I'm guessing you don't support MPEG2? 

Best Regards,

Stian

norman
Senior Member
Senior Member
Posts:811

--
2009-11-11 07:33 PM  
Steve R,

We do in fact have a commercial J2K plugin that uses the Accusoft Pegasus J2K library. Like with a number of our other closed source products, we haven't gotten around to productizing it, which is why we haven't made it widely available yet. But it is on our todo list. :)

N.
stewart
Senior Member
Senior Member
Posts:2033

--
2009-11-12 09:49 AM  
Stian,

the Workstation DICOM conformance statement fully describes what is supported. You can find it from our main website, under Resources/Documentation. We currently don't support MPEG2, although I did briefly look into it recently and I recall finding a few free libraries that might work for implementing MPEG codecs; can't remember what it's called, but it was easily found through a web search.

I don't think we'll be implementing MPEG codecs anytime soon, but if someone from the community felt like writing/contributing it, that would be great :)

Best regards,
Stewart
Real-time support available to Clinical Edition and Team Edition customers
stiank81
Advanced Member
Advanced Member
Posts:33

--
2009-11-15 03:27 PM  
Thanks for the reply Stewart.
If we remain happy with the ClearCanvas library, and ends up only lacking MPEG2 support we might consider looking into it later on. But we won't be looking into this yet..

Cheers,
Stian
You are not authorized to post a reply.

Active Forums 4.1
Copyright 2011 ClearCanvas Inc.