[Insight-developers] DCMTK Questions

[Williams, Norman K]

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.
________________________________