No subject
Wed May 9 12:08:04 EDT 2012
(git submodule or ExternalProject), if would be great if we could configure
ITKv4 passing our own version of DCMTK by specifying DCMTK_DIR.
Within CTK, since end of April, a more recent version of DCMTK is used
(Snapshot 2012-02-22). See [1] And looking at the associated DCMTK change
log, some CLang issues have been fixed. [2]
Thanks
Jc
[1] https://github.com/commontk/CTK/commit/70c0a8d
[2]
http://git.dcmtk.org/web?p=dcmtk.git;a=blob;f=CHANGES.361;h=d281e817cbd647479dacb5e972f2d76d75602c25;hb=ae3b946f6e6231
On Fri, May 25, 2012 at 5:47 PM, Williams, Norman K <
norman-k-williams at uiowa.edu> wrote:
> Hans has asked me to work on finishing Alexandre Gouaillard's work on the
> DCMTK ImageIO.
>
> Today I've been trying to move his work from his own github repository
> into a gerrit topic on the current branch. There are a number of issues
> that this raises.
>
> 1. Hans suggested using a CMake ExternalProject to build DCMTK instead of
> what Alex did, which is to introduce the DCMTK included in the CTK project
> as a git module. For one thing, that version of DCMTK won't compile with
> Clang.
>
> I don't see a clean way to grab and build DCMTK within the current ITK
> framework at all. What's done everywhere else is that there's a
> SuperBuild or MetaBuild, which builds all of a project's prerequisites as
> ExternalProjects, and then builds the project itself as an
> ExternalProject, configuring it with ITK_DIR, VTK_DIR etc so that it finds
> the prerequisites.
>
> Could that be something that will be part of the ITK build process? Or are
> we going to incorporate some sort of snapshot of DCMTK in
> Modules/ThirdParty?
>
> 2. DCMTK can read a DICOM directory directly, meaning that it wouldn't be
> necessary to use an ImageSeriesReader to read dicom datasets. Should I
> stick with creating a DCMTKSeriesFileNames?
>
> That feels rather clumsy, but it raises the issue of trying to choose
> which image in a multi-series DicomDirectory to load.
>
> --
> Kent Williams norman-k-williams at uiowa.edu
>
>
>
>
>
>
> ________________________________
> 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.
> ________________________________
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
--
+1 919 869 8849
--047d7b2ee6451a2f9e04c0e37f94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Kent,=A0<div><br></div><div><div>From Slicer perspective, independently =
of the method used to retrieve DCMTK (git submodule or ExternalProject), if=
would be great if we could configure ITKv4 passing our own version of DCMT=
K by specifying DCMTK_DIR.</div>
<div><br></div><div>Within CTK, since end of April, a more recent version o=
f DCMTK is used (Snapshot 2012-02-22). See [1] And looking at the associate=
d DCMTK change log, some CLang issues have been fixed. [2]</div><div><br>
</div><div>Thanks</div><div>Jc</div><div><br></div><div>[1]=A0<a href=3D"ht=
tps://github.com/commontk/CTK/commit/70c0a8d">https://github.com/commontk/C=
TK/commit/70c0a8d</a></div><div>[2]=A0<a href=3D"http://git.dcmtk.org/web?p=
=3Ddcmtk.git;a=3Dblob;f=3DCHANGES.361;h=3Dd281e817cbd647479dacb5e972f2d76d7=
5602c25;hb=3Dae3b946f6e6231">http://git.dcmtk.org/web?p=3Ddcmtk.git;a=3Dblo=
b;f=3DCHANGES.361;h=3Dd281e817cbd647479dacb5e972f2d76d75602c25;hb=3Dae3b946=
f6e6231</a></div>
<div><br><div class=3D"gmail_quote">On Fri, May 25, 2012 at 5:47 PM, Willia=
ms, Norman K <span dir=3D"ltr"><<a href=3D"mailto:norman-k-williams at uiow=
a.edu" target=3D"_blank">norman-k-williams at uiowa.edu</a>></span> wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hans has asked me to work on finishing Alexandre Gouaillard's work on t=
he<br>
DCMTK ImageIO.<br>
<br>
Today I've been trying to move his work from his own github repository<=
br>
into a gerrit topic on the current branch. =A0There are a number of issues<=
br>
that this raises.<br>
<br>
1. Hans suggested using a CMake ExternalProject to build DCMTK instead of<b=
r>
what Alex did, which is to introduce the DCMTK included in the CTK project<=
br>
as a git module. =A0For one thing, that version of DCMTK won't compile =
with<br>
Clang.<br>
<br>
I don't see a clean way to grab and build DCMTK within the current ITK<=
br>
framework at all. =A0What's done everywhere else is that there's a<=
br>
SuperBuild or MetaBuild, which builds all of a project's prerequisites =
as<br>
ExternalProjects, and then builds the project itself as an<br>
ExternalProject, configuring it with ITK_DIR, VTK_DIR etc so that it finds<=
br>
the prerequisites.<br>
<br>
Could that be something that will be part of the ITK build process? Or are<=
br>
we going to incorporate some sort of snapshot of DCMTK in<br>
Modules/ThirdParty?<br>
<br>
2. DCMTK can read a DICOM directory directly, meaning that it wouldn't =
be<br>
necessary to use an ImageSeriesReader to read dicom datasets. =A0Should I<b=
r>
stick with creating a DCMTKSeriesFileNames?<br>
<br>
That feels rather clumsy, but it raises the issue of trying to choose<br>
which image in a multi-series DicomDirectory to load.<br>
<br>
--<br>
Kent Williams <a href=3D"mailto:norman-k-williams at uiowa.edu">norman-k-willi=
ams at uiowa.edu</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
________________________________<br>
Notice: This UI Health Care e-mail (including attachments) is covered by th=
e Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidenti=
al and may be legally privileged. =A0If you are not the intended recipient,=
you are hereby notified that any retention, dissemination, distribution, o=
r copying of this communication is strictly prohibited. =A0Please reply to =
the sender that you have received the message in error, then delete it. =A0=
Thank you.<br>
________________________________<br>
_______________________________________________<br>
Powered by <a href=3D"http://www.kitware.com" target=3D"_blank">www.kitware=
.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href=3D"http://www.kitware.com/opensource/opensource.html" target=3D"_bl=
ank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href=3D"http://kitware.com/products/protraining.php" target=3D"_blank">h=
ttp://kitware.com/products/protraining.php</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href=3D"http://www.itk.org/Wiki/ITK_FAQ" target=3D"_blank">http://www.it=
k.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href=3D"http://www.itk.org/mailman/listinfo/insight-developers" target=
=3D"_blank">http://www.itk.org/mailman/listinfo/insight-developers</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>+1 919 869 8=
849<br><br>
</div></div>
--047d7b2ee6451a2f9e04c0e37f94--
More information about the Insight-developers
mailing list