[Insight-users] Loading DICOM RTStructs

[Luis Ibanez]

Hi Mark,

Thanks for filing the feature request in the MANTIS bug tracker.

We will give it a shot for the release of ITK 3.18.


     Thanks


           Luis


----------------------------------------------------------------------------------
On Wed, Oct 21, 2009 at 8:47 PM, Mark Roden <mmroden at gmail.com> wrote:
> Hi Luis,
>
> On Wed, Oct 21, 2009 at 2:59 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>> Hi Mark,
>>
>>
>> 1) Please log a bug ("Feature Request") In the MANTIS bug tracker:
>>
>>          http://public.kitware.com/Bug/my_view_page.php
>>
>>    To requesting the modification of the ITK installation procedure to
>>    use a single flat directory instead of the current set of subdirectories.
>>
>>     I agree with you in that, this will make easier to use ITK from
>>     external project, even in the cases where they use CMake
>>     for configuration.
>>
>>     We don't have headers with duplicate names (as far as I know)
>>     so name collisions shouldn't be an issue.
>
> Thanks, I'll head over there now.
>
>>
>>
>> 2) You may find useful to read the tutorial:
>>
>>               http://www.itk.org/ITK/help/tutorials.html
>>
>>     in particular:
>>
>>     http://www.itk.org/CourseWare/Training/GettingStarted-I.pdf
>>
>>     It will show you how to create a HelloWorld example from
>>     scratch.
>>
>>     The same procedure is explained in the initial chapters of
>>      the ITK Software Guide
>>
>>             http://www.itk.org/ItkSoftwareGuide.pdf
>>
>
> I was using the 'getting started' from the manual, and the HelloWorld
> code from that.  Both examples are still CMake-based, which is OK, but
> not what I want.
>
>>
>>
>> 3)  I don't see why you would need to include "itkConfigure.h"
>>     in any program that uses ITK.
>>
>>     If you have found that to be needed, you may be dealing
>>     with a larger configuration issue.
>>
>>     Normally, including headers such as "itkImage.h" should
>>     do the trick.
>>
>>     You may find useful to look at the many examples in the
>>      directory:
>>
>>                             Insight/Examples/
>>
>
> When I:
> 1) build the install directory (CMake, shared libraries on and nothing else)
> 2) Create a new sln (vs2008, new project, C++, win32 console app)
> 3) point to the itk/headers/common directory (additional include directories)
> 4) #include "itkimage.h"
> 5) build
> I get an error stating that itkconfigure.h could not be found.  If I
> then include that directory, I get another error that vnl_math.h could
> not be found.  If I'm doing something wrong, I'll happily correct my
> procedure, but that's how I thought things should be done.  Once the
> directory structure gets flattened, that would seem like the way to do
> things.
>
>>
>>
>> 4)  You may understand better the advantages of using CMake
>>     when you are confronted with the following scenarios:
>>
>>        A)    Moving your project from one computer to another,
>>               (even when they have identical operating systems
>>                 and build environments).
>
> I solve this problem by requiring that my projects always be buildable
> from source code.  If the project cannot be checked out, built, and
> then run entirely from a command line script, then it is broken.
> CMake is one way to solve this problem, MSBuild is another.  I'm used
> to MSBuild.
>
>>
>>        B)    Building your project in two (or more) different
>>                platforms.
>
> True.  I've done this as well, and have found that for the most part,
> when using native libraries, there needs to be some native code
> calling on the UI side.  Something like Qt may solve this issue, but
> when I first tried Qt it didn't have the UI widgets I needed and I
> haven't returned.  So, with that experience in hand, the team I was on
> had a large portion of the code was uniform across platforms, and some
> was Windows and some was Mac.  The unfortunate reality was that that
> did cause development to be lopsided in some features to one platform
> over another, but at the time, it was the best solution we had because
> the UI coding was so different and there wasn't a solution like Qt.
> Now, with Qt, I'd still just have the code in one place and buildable,
> and something like CMake may help, but I'm not in that environment at
> the moment.
>
>>
>>         C)   Building projects that have dependencies on
>>                many third party libraries.
>>
>
> When I do this, I check the libraries into the source repository, and
> just have cascading builds.  If I have the source for those libraries,
> great, then I can build them when a new version comes out, but for the
> most part, the libraries are unchanged over the time I change my code,
> so that the possibility of the interaction failing is minimized. So,
> with the libraries checked into source, and the source required to
> build from the command line at any given time not to be broken, this
> requirement is also fulfilled.
>
> It's just a different way to skin the cat.  I understand why itk does
> use CMake, because I don't support more than a single platform at a
> time, and I could see how modern UI widgets available across all UIs
> could make it possible to have a single unified codebase.
>
>>
>>      Of course, you are not forced to use CMake in order to
>>      take advantage of ITK.
>>
>
> And that is exciting to me, as I'm sure you can tell :)
>
> Thanks,
> Mark
>
>>
>>
>>   Regards,
>>
>>
>>          Luis
>>
>>
>> -------------------------------------------------------------------------
>> On Wed, Oct 21, 2009 at 1:29 PM, Mark Roden <mmroden at gmail.com> wrote:
>>> Hi Luis,
>>>
>>> Thanks for the help, but I'm still having problems.  Namely, the
>>> headers continue to be scattered throughout a directory tree rather
>>> than in one big folder.  I'll just do that by hand, I suppose.  But
>>> the include directory should be flat.  If there are headers that are
>>> named the same thing, then they should have different names just to
>>> avoid collisions in general.
>>>
>>> Here's the thing.  You compare ITK to STL, and it's STL that I'm
>>> thinking of.  There, when I #include <vector>, I don't also have to
>>> #include <algorithm> until I need an algorithm.  If I #include
>>> <itkimage.h> then I also need to include itkConfigure.h and then that
>>> needs vnl_math.h and then... and so forth, and they're all in
>>> different directories.  I want to be able to include the headers I
>>> need, but just point to one place to use that header, rather than
>>> pointing to a nested directory structure.  The structure can remain
>>> nested on the development side; that's entirely irrelevant to me.  But
>>> for the sake of ease of use, if it's all in one flat directory, then I
>>> don't need to learn Yet Another Build Tool (CMake), and can just
>>> include that directory and be done.
>>>
>>> I want to start from a blank slate project, where HelloWorld.cpp and
>>> HellowWorld.h are just there, and nothing else.  Instead, HelloWorld
>>> is surrounded by a bunch of other projects, and it's not at all clear
>>> how to make a new project that's entirely empty.  I don't even see a
>>> HelloWorld.h, and that weirds me out.  Within this separate project, I
>>> am now free to Do My Own Thing and impose whatever stylistic
>>> guidelines I want, anything from source control, unit tests, class
>>> organization, etc.  I don't like being tied to CMake as a tool because
>>> I don't see how it's necessary to get the job done, I just see it as a
>>> convenience for making the library.  Once the library is made, the
>>> tools to make it should get out of the way and let me do my thing.
>>>
>>> Thanks,
>>> Mark
>>>
>>
>