[Insight-developers] DCMTK Questions

[Jean-Christophe Fillion-Robin]

Excellent. It all makes sens.
Thanks for clarifying
Jc

On Tue, May 29, 2012 at 2:37 PM, Williams, Norman K <
norman-k-williams at uiowa.edu> wrote:

> The usual method of doing things would be
>
> IF(ITK_USE_SYSTEM_DCMTK)
> find_package(DCMTK REQUIRED)
> # yadda yadda.
> ENDIF()
>
> This would fail if DCMTK_DIR is not defined -- assuming of course DCMTK
> isn't installed in the standard paths.
> --
> Kent Williams norman-k-williams at uiowa.edu
>
>
>
>
>
>
> On 5/29/12 1:34 PM, "Jean-Christophe Fillion-Robin"
> <jchris.fillionr at kitware.com> wrote:
>
> >
> >On Tue, May 29, 2012 at 11:55 AM, Williams, Norman K
> ><norman-k-williams at uiowa.edu> wrote:
> >
> >
> >Jean-Christophe, it seems like what you're saying is that you wish
> >DCMTK_DIR, if defined, to in essence, force ITK_USE_SYSTEM_DCMTK.  That's
> >fine, and looking how other external packages are dealt with -- FFTW being
> >the prime example -- that's how it would work.
> >
> >
> >
> >If passing both -DITK_USE_SYSTEM_DCMTK:BOOL=ON and
> >-DDCMTK_DIR:PATH=/path/to/my/dcmtk when configuring ITK works as
> >expected, I guess that should be enough from Slicer perspective.
> >
> >Thanks
> >Jc
> >
> >
> >
> >
> >Bill, I think that the goal, as indicated by Terry Yu, is that GDCM will
> >be deprecated, so the DCMTK reader will be the one true way to deal with
> >DICOM.  This could be a problem for programs that have used GDCMImageIO
> >explicitly -- or used GDCM calls directly, but I think most people were
> >cured of that tendency when ITK went from GDCM1 to GDCM2, which broke
> >anything that used GDCM in a non-trivial fashion.
> >
> >I think I see my way clear to make DCMTK work as well -- or probably
> >better -- than GDCM as a DICOM reader.  I need to focus on that and
> >produce a Gerrit patch.  There are a ton of peripheral issues around
> >DICOM reading that will take longer to iron out.
> >
> >The fact of the matter is that DICOM is squirrelly enough to make it
> >impossible to use transparently with the existing ImageIO framework.  For
> >one thing, the ImageFileReader/Writer really don't want to deal with
> >directories as image paths, so any program who wants to use ITK for Image
> >IO has to have infrastructure around ImageIO to sniff for the DICOM case
> >and do it differently than every other file format.
> >
> >Plus DICOM is potentially quite a lot more than just files in a file
> >system, and ITK has never dealt with the rest of DICOM at all.  Slicer4
> >has some support for network DICOM stuff, but they're using DCMTK directly
> >to handle that case.
> >
> >On 5/29/12 10:28 AM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
> >
> >>If you treat dcmtk as we treat vtk then you will not need a
> >>ITK_USE_SYSTEM_DCMTK.
> >
> >
> >
> >
> >________________________________
> >Notice: This UI Health Care e-mail (including attachments) is covered by
> >the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
> >confidential and may be legally privileged.  If you are not the intended
> >recipient, you are hereby notified that any retention, dissemination,
> >distribution, or copying of this communication is strictly prohibited.
> >Please reply to the sender that you have received the message in error,
> >then delete it.  Thank you.
> >
> >
> >________________________________
> >
> >
> >
> >
> >
> >
> >
> >
> >--
> >+1 919 869 8849
> >
>
>
>
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by
> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
> confidential and may be legally privileged.  If you are not the intended
> recipient, you are hereby notified that any retention, dissemination,
> distribution, or copying of this communication is strictly prohibited.
>  Please reply to the sender that you have received the message in error,
> then delete it.  Thank you.
> ________________________________
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120529/636cf40f/attachment.htm>