No subject

- gdcm source code is in <source>/ITK/Utilities/GDCM
- itk layer for gdcm is in <source>/ITK/IO/GDCM
- tests for gdcm are in nonunit.

First of, the gdcm source seems to be a full copy of gdcm which would
explain why you see so much GDCM variables popping up even though they
might not be relevant (*We* need to test them!)

Then, I suppose that the GDCM tests don't have their proper and final
test holder yet and that it's still work in progress. With the current
layout, I guess we should expect GDCM test to be part of the IO tests.
Again, just a wild guess.

>
> This is a non-obvious location, in my mind. =A0I would have each module
> be able to build its own tests, and the test driver be part of the
> core (which, as I suggested earlier, should never not be included).
> That way, when I build gdcm, I also build relevant tests. =A0I don't
> have to go ahead and build 'nonunit' (I don't even know what that
> means, especially since these look to be unit tests). =A0It also means
> that 'testing' would mean turning on the tests for each module, rather
> than what happens now, where just having 'testing' enabled 129 tests
> starting with 'itk', including:
>
> ITK-Common =A0 =A0 =3D =A0 6.09 sec
> ITK-IO-BMP =A0 =A0 =3D =A0 0.23 sec
> ITK-IO-Base =A0 =A0=3D =A0 0.13 sec
> ITK-IO-JPEG =A0 =A0=3D =A0 0.17 sec
> ITK-IO-Meta =A0 =A0=3D =A0 0.15 sec
> ITK-IO-PNG =A0 =A0 =3D =A0 0.16 sec
> ITK-IO-TIFF =A0 =A0=3D =A0 0.33 sec
> ITK-IO-VTK =A0 =A0 =3D =A0 0.17 sec
>
> Shouldn't the common tests only get made when Core gets compiled, and
> the IO tests when the IO module gets compiled? =A0Why have tests for
> modules that aren't otherwise made?
>
> In the meantime, I'll go ahead and use nonunit to get the gdcm tests,
> but it does seem like this arrangement should change.
>
> Working on the compilation against system gdcm now....
>
> Mark
>
> On Sat, Mar 12, 2011 at 8:46 PM, Alexandre GOUAILLARD
> <agouaillard at gmail.com> wrote:
>> hi mark,
>>
>> the minimum to make accessible from gdcm to ITK is the work on
>> streaming, RT and the network (pacs support). My understanding is that
>> the ITK layer for streaming is here, but not for the network. The
>> design of the ITK layer for network should be done in collaboration
>> with the mayo clinic team you met during last meeting in Boston.
>>
>> Also the roadmap should be:
>> - develop the feature in gdcm [DONE]
>> - compile ITK against system-gdcm
>> - develop the ITK layer
>> - merge gdcm in ITK
>>
>> I'm not confident the last two points should be done in this order.
>>
>> Maybe the gdcm community care to advice on this point either?
>>
>> alex.
>>
>>
>> On Sun, Mar 13, 2011 at 12:21 PM, Mark Roden <mmroden at gmail.com> wrote:
>>> Well, the fix may be there in the repository, but when I run:
>>>
>>> Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R itkGDCM
>>> Test project /Users/mmroden/Documents/src/itk/itk-build-unix
>>> No tests were found!!!
>>>
>>> Or with just gdcm:
>>> Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R GDCM
>>> Test project /Users/mmroden/Documents/src/itk/itk-build-unix
>>> No tests were found!!!
>>>
>>> This is after turning everything on in CMake syncing 2 days ago. =A0I
>>> then synced 20 minutes ago:
>>>
>>> Mark-Rodens-MacBook-Pro:itk-build-unix mmroden$ ctest -R GDCM
>>> Test project /Users/mmroden/Documents/src/itk/itk-build-unix
>>> =A0 =A0Start 645: itkGDCMImageIOTest1
>>> 1/8 Test #645: itkGDCMImageIOTest1 .................. =A0 Passed =A0 =
=A01.30 sec
>>> =A0 =A0Start 646: itkGDCMImageIOTest2
>>> 2/8 Test #646: itkGDCMImageIOTest2 .................. =A0 Passed =A0 =
=A00.31 sec
>>> =A0 =A0Start 647: itkGDCMImageIOTest3
>>> 3/8 Test #647: itkGDCMImageIOTest3 .................. =A0 Passed =A0 =
=A00.19 sec
>>> =A0 =A0Start 648: itkGDCMImageIOTest4
>>> 4/8 Test #648: itkGDCMImageIOTest4 .................. =A0 Passed =A0 =
=A00.16 sec
>>> =A0 =A0Start 649: itkGDCMImageIOTest5
>>> 5/8 Test #649: itkGDCMImageIOTest5 .................. =A0 Passed =A0 =
=A00.30 sec
>>> =A0 =A0Start 650: itkGDCMSeriesReadImageWrite
>>> 6/8 Test #650: itkGDCMSeriesReadImageWrite .......... =A0 Passed =A0 =
=A00.26 sec
>>> =A0 =A0Start 651: itkGDCMSeriesStreamReadImageWrite1
>>> 7/8 Test #651: itkGDCMSeriesStreamReadImageWrite1 ... =A0 Passed =A0 =
=A00.19 sec
>>> =A0 =A0Start 652: itkGDCMSeriesStreamReadImageWrite2
>>> 8/8 Test #652: itkGDCMSeriesStreamReadImageWrite2 ... =A0 Passed =A0 =
=A00.19 sec
>>>
>>> 100% tests passed, 0 tests failed out of 8
>>>
>>> Label Time Summary:
>>> ITK-IntegratedTest =A0 =A0=3D =A0 2.90 sec
>>>
>>> Total Test time (real) =3D =A0 6.38 sec
>>>
>>> So either I didn't build everything right the first time, or I didn't
>>> have the gdcm tests.
>>>
>>> I think that these tests only cover a subset of gdcm functionality;
>>> the question is, what kind of functionality are we going to need to
>>> add in?
>>>
>>> Mark
>>>
>>>
>>>
>>> On Sat, Mar 12, 2011 at 1:01 PM, Alexandre GOUAILLARD
>>> <agouaillard at gmail.com> wrote:
>>>> mark,
>>>>
>>>> The latest itk v4 pulled form git has the itkGDCM tests (see below).
>>>> You mentioned that those tests were not present since modularization,
>>>> but I find trace of a feb 9th merge of a feb 5th commit that seems to
>>>> indicate the support was taken care of:
>>>>
>>>> Merge topic 'ModularizationFixingGDCMTestDriver'
>>>> 55c0f87 ENH: Use IO test driver for GDCM IO tests.
>>>>
>>>> I also confirmed that the gdcm cmake variables you mentioned (as well
>>>> as direct gdcm wrapping variables) where present before and are still
>>>> present. I did not turn them ON to test (yet).
>>>>
>>>> I agree with you that if they are of no use for ITK, they should not
>>>> be visible when using the itk copy of gdcm.
>>>>
>>>> Perhaps the gdcm community would like to comment on this?
>>>>
>>>> alex.
>>>>
>>>> ld: warning: duplicate dylib ../../../../lib/libITK-Path-4.0.1.dylib
>>>> ld: warning: duplicate dylib ../../../../lib/libITK-Transform-4.0.1.dy=
lib
>>>> ld: warning: duplicate dylib ../../../../lib/libITK-Statistics-4.0.1.d=
ylib
>>>> ld: warning: duplicate dylib ../../../../lib/libITK-Common-4.0.1.dylib
>>>> [100%] Built target ITK-IntegratedTestTestDriver
>>>> NB8086:BUILD-DEBUG-64 gouaillarda$ ctest -R GDCM
>>>> Test project /Users/gouaillarda/DEVEL/GITROOT/ITK/BUILD-DEBUG-64
>>>> =A0 =A0Start 645: itkGDCMImageIOTest1
>>>> 1/8 Test #645: itkGDCMImageIOTest1 .................. =A0 Passed =A0 =
=A02.45 sec
>>>> =A0 =A0Start 646: itkGDCMImageIOTest2
>>>> 2/8 Test #646: itkGDCMImageIOTest2 .................. =A0 Passed =A0 =
=A00.38 sec
>>>> =A0 =A0Start 647: itkGDCMImageIOTest3
>>>> 3/8 Test #647: itkGDCMImageIOTest3 .................. =A0 Passed =A0 =
=A00.28 sec
>>>> =A0 =A0Start 648: itkGDCMImageIOTest4
>>>> 4/8 Test #648: itkGDCMImageIOTest4 .................. =A0 Passed =A0 =
=A00.20 sec
>>>> =A0 =A0Start 649: itkGDCMImageIOTest5
>>>> 5/8 Test #649: itkGDCMImageIOTest5 .................. =A0 Passed =A0 =
=A00.37 sec
>>>> =A0 =A0Start 650: itkGDCMSeriesReadImageWrite
>>>> 6/8 Test #650: itkGDCMSeriesReadImageWrite .......... =A0 Passed =A0 =
=A00.33 sec
>>>> =A0 =A0Start 651: itkGDCMSeriesStreamReadImageWrite1
>>>> 7/8 Test #651: itkGDCMSeriesStreamReadImageWrite1 ... =A0 Passed =A0 =
=A00.28 sec
>>>> =A0 =A0Start 652: itkGDCMSeriesStreamReadImageWrite2
>>>> 8/8 Test #652: itkGDCMSeriesStreamReadImageWrite2 ... =A0 Passed =A0 =
=A00.25 sec
>>>>
>>>> 100% tests passed, 0 tests failed out of 8
>>>>
>>>> Label Time Summary:
>>>> ITK-IntegratedTest =A0 =A0=3D =A0 4.55 sec
>>>>
>>>> Total Test time (real) =3D =A0 6.32 sec
>>>> NB8086:BUILD-DEBUG-64 gouaillarda$
>>>>
>>>>
>>>>
>>>> On Sun, Mar 13, 2011 at 2:13 AM, Mark Roden <mmroden at gmail.com> wrote:
>>>>> I assumed as much, but I wanted to be sure. =A0There could have been =
the
>>>>> intent to push all gdcm tests into gdcm proper. =A0And as I said, the=
re
>>>>> are none of the standard gdcm tests in itk now, nor were they there
>>>>> prior to the merge, so if that was the intent, I just need to know so
>>>>> that I can put them there.
>>>>>
>>>>> Mark
>>>>>
>>>>> On Sat, Mar 12, 2011 at 9:45 AM, Bill Lorensen <bill.lorensen at gmail.c=
om> wrote:
>>>>>> I think the itkGDCM tests should definitely stay. I assume that thei=
r
>>>>>> absence after modularization is not intentional.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>> On Sat, Mar 12, 2011 at 10:29 AM, Alexandre GOUAILLARD
>>>>>> <agouaillard at gmail.com> wrote:
>>>>>>> hi
>>>>>>>
>>>>>>> On Sat, Mar 12, 2011 at 2:55 PM, Mark Roden <mmroden at gmail.com> wro=
te:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Previously, there were itk-gdcm specific tests, that could be run =
by typing
>>>>>>>>
>>>>>>>> ctest -R itkGDCM
>>>>>>>>
>>>>>>>> Those tests are no longer present since modularization. =A0I do no=
t know
>>>>>>>> if they have been removed because they don't match the expectation=
s of
>>>>>>>> the new scheme, or as an oversight, or if the gdcm_build_tests cma=
ke
>>>>>>>> flag was supposed to cover it. =A0I'm putting this discussion on t=
he
>>>>>>>> insight developers list as a result, so that perhaps I can get som=
e
>>>>>>>> feedback on that.
>>>>>>>
>>>>>>> I'm checking that right now.
>>>>>>>
>>>>>>>>
>>>>>>>> Personally, I think that we should just have the itk gdcm tests ba=
ck,
>>>>>>>> and not have the same coverage as the rest of gdcm. =A0ITK devs, a=
t
>>>>>>>> least for the moment, don't need a complete tag editing solution, =
they
>>>>>>>> need to be able to read and write various forms of image data. =A0=
I'm
>>>>>>>> fairly certain that the previous test suite covered those cases.
>>>>>>>>
>>>>>>>
>>>>>>> We have to be positive.
>>>>>>>
>>>>>>>> The testing data size is a few megs, so not a big deal, and it's
>>>>>>>> retrieved through a git submodule init call in the gdcm root
>>>>>>>> directory. =A0That is a bit of a pain for deployment purposes, bec=
ause
>>>>>>>> it means that any user who wants to use gdcm has to get a particul=
ar
>>>>>>>> set of images for testing, and they have to use a series of
>>>>>>>> non-obvious steps to get those images and set up the testing direc=
tory
>>>>>>>> (which is, as I said, currently blank). =A0I suppose that could be=
 done
>>>>>>>> through the setupfordevelopment script, but that seems like overki=
ll,
>>>>>>>> especially if the older itkgdcm tests did the job.
>>>>>>>>
>>>>>>>
>>>>>>> That sounds good, the actual testing/data is also retrieved thourgh=
 a
>>>>>>> git submodule mechanism, so I guess, if we were to decide to take i=
n
>>>>>>> the gdcm tests, there is no show stopper. We need to investigate if
>>>>>>> that s really what we want / need to do. i.e. we need to have a lis=
t
>>>>>>> of gdcm features available in ITK proper.
>>>>>>>
>>>>>>> alex.
>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On Fri, Mar 11, 2011 at 10:35 PM, Alex Gouaillard <agouaillard at gma=
il.com> wrote:
>>>>>>>>> Hi mark.
>>>>>>>>>
>>>>>>>>>> it would be good to know how these tests worked in the
>>>>>>>>>> past.
>>>>>>>>>
>>>>>>>>> Your job to find out.
>>>>>>>>>
>>>>>>>>> Then if those tests were not included, please answer the followin=
g questions first:
>>>>>>>>> - are those testing gdcm features exposed in itk ? If not, no nee=
d in itk proper.
>>>>>>>>> - what is the size of the testing data?
>>>>>>>>> - how do you get the data? (cvs? Svn? Tarball?...)
>>>>>>>>>
>>>>>>>>> Gaetan, can you then advice on using external project Thingy from=
 cmake 2.8 ?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>> 2011/3/11 Ga=EBtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>>>>>>>>>>>
>>>>>>>>>>> Le 12 mars 11 =E0 01:04, Mark Roden a =E9crit :
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> So I notice that under the new (and the old, incidentally) cma=
ke
>>>>>>>>>>>> options for itk, there are the four canonical gdcm options, na=
mely:
>>>>>>>>>>>>
>>>>>>>>>>>> build_applications
>>>>>>>>>>>> build_examples
>>>>>>>>>>>> build_shared_libs
>>>>>>>>>>>> build_testing
>>>>>>>>>>>>
>>>>>>>>>>>> However, since the gdcm stuff is supposed to be rolled in dire=
ctly
>>>>>>>>>>>> with ITK, these options don't make a whole lot of sense to me.
>>>>>>>>>>>> Indeed, choosing build_testing as an option leads to cmake err=
ors
>>>>>>>>>>>> which, when solved, lead to many compilation errors when testi=
ng is
>>>>>>>>>>>> turned on.
>>>>>>>>>>>>
>>>>>>>>>>>> I propose to remove these options from the build process entir=
ely.
>>>>>>>>>>>> The user isn't interested in gdcm per se, but in having dicom =
support
>>>>>>>>>>>> in itk. =A0That means that these options are not useful to the=
 user, and
>>>>>>>>>>>> can only cause building problems.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Mark,
>>>>>>>>>>>
>>>>>>>>>>> I'd keep the tests, and turn them on automatically when ITK's o=
ption
>>>>>>>>>>> BUILD_TESTING is on. I don't think you will reimplement all the=
 gdcm tests
>>>>>>>>>>> in ITK, so it would be nice that gdcm can be tested on the user=
 system with
>>>>>>>>>>> the other ITK tests.
>>>>>>>>>>> This wouldn't be the only case: VXL tests are run with the ITK =
tests for
>>>>>>>>>>> example.
>>>>>>>>>>>
>>>>>>>>>>> Ga=EBtan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ga=EBtan Lehmann
>>>>>>>>>>> Biologie du D=E9veloppement et de la Reproduction
>>>>>>>>>>> INRA de Jouy-en-Josas (France)
>>>>>>>>>>> tel: +33 1 34 65 29 66 =A0 =A0fax: 01 34 65 29 09
>>>>>>>>>>> http://voxel.jouy.inra.fr =A0http://www.itk.org
>>>>>>>>>>> http://www.mandriva.org =A0http://www.bepo.fr
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.html
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>