From yj76@columbia.edu Wed, 28 Feb 2001 16:07:42 -0500 Date: Wed, 28 Feb 2001 16:07:42 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] compliering error This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0A1A0.94609210 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable It looks that ITK.dsw generated by CMake was changed, I got the below = message after a update: Is it relating to my MSVC++ setting or it is something due to CMake? It = only happened today, used to be fine all the time. --------------------Configuration: VXLNumerics - Win32 = Debug-------------------- Compiling... ...... \insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib=20 LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. VXLNumerics.lib - 1 error(s), 358 warning(s) --------------------Configuration: ITKCommon - Win32 = Debug-------------------- Compiling... ...... \insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib=20 LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib" Error executing link.exe. ITKCommon.lib - 1 error(s), 1 warning(s) --------------------Configuration: ITKBasicFilters - Win32 = Debug-------------------- Compiling... itkWriter.cxx Creating library... Microsoft (R) Library Manager Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. ITKBasicFilters.lib - 1 error(s), 0 warning(s) ------=_NextPart_000_001B_01C0A1A0.94609210 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
It looks that ITK.dsw generated by = CMake was=20 changed, I got the below message after a update:
Is it relating to my MSVC++ setting or = it is=20 something due to CMake? It only happened today, used to be fine all the=20 time.
 
 
--------------------Configuration: = VXLNumerics -=20 Win32 Debug--------------------
Compiling...
 
......
 
\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib =
LINK : fatal=20 error LNK1181: cannot open input file=20 "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib"
Error = executing=20 link.exe.
 
VXLNumerics.lib - 1 error(s), 358=20 warning(s)
--------------------Configuration: ITKCommon - Win32=20 Debug--------------------
Compiling...
 
......
 
\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib=
LINK=20 : fatal error LNK1181: cannot open input file=20 "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib"
Err= or=20 executing link.exe.
 
ITKCommon.lib - 1 error(s), 1=20 warning(s)
--------------------Configuration: ITKBasicFilters - Win32 = Debug--------------------
Compiling...
itkWriter.cxx
Creating = library...
Microsoft=20 (R) Library Manager Version 6.00.8447
Copyright (C) Microsoft Corp = 1992-1998.=20 All rights reserved.
LINK : fatal error LNK1181: cannot open input = file=20 "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib"
Error = executing=20 link.exe.
 
ITKBasicFilters.lib - 1 error(s), 0=20 warning(s)
 
------=_NextPart_000_001B_01C0A1A0.94609210-- From bill.hoffman@kitware.com Wed, 28 Feb 2001 16:32:40 -0500 Date: Wed, 28 Feb 2001 16:32:40 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] compliering error --=====================_1220739290==_.ALT Content-Type: text/plain; charset="us-ascii" It is working for me here. There have been some cmake changes recently. Did you rebuild CMake itself and run the CMakeSetup program again? -Bill At 04:07 PM 2/28/2001 -0500, you wrote: >It looks that ITK.dsw generated by CMake was changed, I got the below message after a update: >Is it relating to my MSVC++ setting or it is something due to CMake? It only happened today, used to be fine all the time. > > >--------------------Configuration: VXLNumerics - Win32 Debug-------------------- >Compiling... > >...... > >\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib >LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" >Error executing link.exe. > >VXLNumerics.lib - 1 error(s), 358 warning(s) >--------------------Configuration: ITKCommon - Win32 Debug-------------------- >Compiling... > >...... > >\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib >LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib" >Error executing link.exe. > >ITKCommon.lib - 1 error(s), 1 warning(s) >--------------------Configuration: ITKBasicFilters - Win32 Debug-------------------- >Compiling... >itkWriter.cxx >Creating library... >Microsoft (R) Library Manager Version 6.00.8447 >Copyright (C) Microsoft Corp 1992-1998. All rights reserved. >LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" >Error executing link.exe. > >ITKBasicFilters.lib - 1 error(s), 0 warning(s) > --=====================_1220739290==_.ALT Content-Type: text/html; charset="us-ascii" It is working for me here.

There have been some cmake changes recently. 
Did you rebuild CMake itself and run the CMakeSetup program again?

-Bill

At 04:07 PM 2/28/2001 -0500, you wrote:
It looks that ITK.dsw generated by CMake was changed, I got the below message after a update:
Is it relating to my MSVC++ setting or it is something due to CMake? It only happened today, used to be fine all the time.
 
 
--------------------Configuration: VXLNumerics - Win32 Debug--------------------
Compiling...

 
......
 
\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib
LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib"
Error executing link.exe.

 
VXLNumerics.lib - 1 error(s), 358 warning(s)
--------------------Configuration: ITKCommon - Win32 Debug--------------------
Compiling...

 
......
 
\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib
LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib"
Error executing link.exe.

 
ITKCommon.lib - 1 error(s), 1 warning(s)
--------------------Configuration: ITKBasicFilters - Win32 Debug--------------------
Compiling...

itkWriter.cxx
Creating library...
Microsoft (R) Library Manager Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib"
Error executing link.exe.

 
ITKBasicFilters.lib - 1 error(s), 0 warning(s)
 
--=====================_1220739290==_.ALT-- From yj76@columbia.edu Wed, 28 Feb 2001 16:54:48 -0500 Date: Wed, 28 Feb 2001 16:54:48 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] compliering error This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C0A1A7.28B90B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I did, but it still happened. ----- Original Message -----=20 From: Bill Hoffman=20 To: Yinpeng Jin=20 Cc: insight-Developers=20 Sent: Wednesday, February 28, 2001 4:32 PM Subject: Re: [Insight-developers] compliering error It is working for me here. There have been some cmake changes recently. =20 Did you rebuild CMake itself and run the CMakeSetup program again? -Bill At 04:07 PM 2/28/2001 -0500, you wrote: It looks that ITK.dsw generated by CMake was changed, I got the = below message after a update: Is it relating to my MSVC++ setting or it is something due to CMake? = It only happened today, used to be fine all the time. =20 =20 --------------------Configuration: VXLNumerics - Win32 = Debug-------------------- Compiling... =20 ...... =20 \insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib=20 LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. =20 VXLNumerics.lib - 1 error(s), 358 warning(s) --------------------Configuration: ITKCommon - Win32 = Debug-------------------- Compiling... =20 ...... =20 \insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib=20 LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib" Error executing link.exe. =20 ITKCommon.lib - 1 error(s), 1 warning(s) --------------------Configuration: ITKBasicFilters - Win32 = Debug-------------------- Compiling... itkWriter.cxx Creating library... Microsoft (R) Library Manager Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. =20 ITKBasicFilters.lib - 1 error(s), 0 warning(s) =20 ------=_NextPart_000_0033_01C0A1A7.28B90B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I did, but it still = happened.
----- Original Message -----
From:=20 Bill=20 Hoffman
To: Yinpeng Jin
Cc: insight-Developers<= /A>=20
Sent: Wednesday, February 28, = 2001 4:32=20 PM
Subject: Re: = [Insight-developers]=20 compliering error

It is working for me here.

There have been some = cmake=20 changes recently. 
Did you rebuild CMake itself and run the=20 CMakeSetup program again?

-Bill

At 04:07 PM 2/28/2001 = -0500, you=20 wrote:
It looks=20 that ITK.dsw generated by CMake was changed, I got the below message = after a=20 update:
Is it relating to my = MSVC++=20 setting or it is something due to CMake? It only happened today, = used to be=20 fine all the time.
 
 
--------------------Configuration: VXLNumerics - Win32=20 Debug--------------------
Compiling...

 
......
 
\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib =
LINK :=20 fatal error LNK1181: cannot open input file=20 "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib"
Error=20 executing link.exe.

 
VXLNumerics.lib - 1 error(s), 358=20 warning(s)
--------------------Configuration: ITKCommon - Win32=20 Debug--------------------
Compiling...

 
......
 
\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib= =20
LINK : fatal error LNK1181: cannot open input file=20 = "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib"
Err= or=20 executing link.exe.

 
ITKCommon.lib - 1 error(s), 1=20 warning(s)
--------------------Configuration: ITKBasicFilters - = Win32=20 Debug--------------------
Compiling...

itkWriter.cxx
Creating library...
Microsoft (R) = Library Manager=20 Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All = rights=20 reserved.
LINK : fatal error LNK1181: cannot open input file=20 "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib"
Error=20 executing link.exe.

 
ITKBasicFilters.lib - 1 error(s), 0=20 warning(s)
 
------=_NextPart_000_0033_01C0A1A7.28B90B80-- From lng@insightful.com Wed, 28 Feb 2001 14:34:27 -0800 Date: Wed, 28 Feb 2001 14:34:27 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] compliering error I am having the same problem. I have also done a clean build of CMake. Lydia ----- Original Message ----- From: Yinpeng Jin To: insight-developers@public.kitware.com Sent: Wednesday, February 28, 2001 1:54 PM Subject: Re: [Insight-developers] compliering error I did, but it still happened. ----- Original Message ----- From: Bill Hoffman To: Yinpeng Jin Cc: insight-Developers Sent: Wednesday, February 28, 2001 4:32 PM Subject: Re: [Insight-developers] compliering error It is working for me here. There have been some cmake changes recently. Did you rebuild CMake itself and run the CMakeSetup program again? -Bill At 04:07 PM 2/28/2001 -0500, you wrote: It looks that ITK.dsw generated by CMake was changed, I got the below message after a update: Is it relating to my MSVC++ setting or it is something due to CMake? It only happened today, used to be fine all the time. --------------------Configuration: VXLNumerics - Win32 Debug-------------------- Compiling... ...... \insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. VXLNumerics.lib - 1 error(s), 358 warning(s) --------------------Configuration: ITKCommon - Win32 Debug-------------------- Compiling... ...... \insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib" Error executing link.exe. ITKCommon.lib - 1 error(s), 1 warning(s) --------------------Configuration: ITKBasicFilters - Win32 Debug-------------------- Compiling... itkWriter.cxx Creating library... Microsoft (R) Library Manager Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. LINK : fatal error LNK1181: cannot open input file "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. ITKBasicFilters.lib - 1 error(s), 0 warning(s) From yj76@columbia.edu Wed, 28 Feb 2001 17:40:57 -0500 Date: Wed, 28 Feb 2001 17:40:57 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] compliering error This is what I did: I found that itkcommon is depending on vxl_numerics, and vxl_numerics also depends on itkcommon. so I tried to remove the dependency of itkcommon on vxl_numerics, and complier itkCommon now I got some itkCommon.lib, and then I can complier all other libs. I hope it works fine, I need to test. ----- Original Message ----- From: "Lydia Ng" To: "Yinpeng Jin" ; Sent: Wednesday, February 28, 2001 5:34 PM Subject: Re: [Insight-developers] compliering error > I am having the same problem. > I have also done a clean build of CMake. > > Lydia > > ----- Original Message ----- > From: Yinpeng Jin > To: insight-developers@public.kitware.com > Sent: Wednesday, February 28, 2001 1:54 PM > Subject: Re: [Insight-developers] compliering error > > > I did, but it still happened. > ----- Original Message ----- > From: Bill Hoffman > To: Yinpeng Jin > Cc: insight-Developers > Sent: Wednesday, February 28, 2001 4:32 PM > Subject: Re: [Insight-developers] compliering error > > > It is working for me here. > > There have been some cmake changes recently. > Did you rebuild CMake itself and run the CMakeSetup program again? > > -Bill > > At 04:07 PM 2/28/2001 -0500, you wrote: > > It looks that ITK.dsw generated by CMake was changed, I got the below > message after a update: > Is it relating to my MSVC++ setting or it is something due to CMake? It only > happened today, used to be fine all the time. > > > --------------------Configuration: VXLNumerics - Win32 > Debug-------------------- > Compiling... > > ...... > > \insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib > LINK : fatal error LNK1181: cannot open input file > "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" > Error executing link.exe. > > VXLNumerics.lib - 1 error(s), 358 warning(s) > --------------------Configuration: ITKCommon - Win32 > Debug-------------------- > Compiling... > > ...... > > \insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib > LINK : fatal error LNK1181: cannot open input file > "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib" > Error executing link.exe. > > ITKCommon.lib - 1 error(s), 1 warning(s) > --------------------Configuration: ITKBasicFilters - Win32 > Debug-------------------- > Compiling... > itkWriter.cxx > Creating library... > Microsoft (R) Library Manager Version 6.00.8447 > Copyright (C) Microsoft Corp 1992-1998. All rights reserved. > LINK : fatal error LNK1181: cannot open input file > "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" > Error executing link.exe. > > ITKBasicFilters.lib - 1 error(s), 0 warning(s) > > From bill.hoffman@kitware.com Wed, 28 Feb 2001 17:37:28 -0500 Date: Wed, 28 Feb 2001 17:37:28 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] compliering error I have found the problem and am working on a fix. I will post to the list once I fix it. -Bill At 02:34 PM 2/28/2001 -0800, Lydia Ng wrote: >I am having the same problem. >I have also done a clean build of CMake. > >Lydia From bill.hoffman@kitware.com Wed, 28 Feb 2001 17:45:20 -0500 Date: Wed, 28 Feb 2001 17:45:20 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] compliering error I have just checked in a fix. You will have to rebuild CMake, and update Insight. I had to change several CMakeLists.txt files. Also, there was a problem in CMake that had static libraries depending on each other. -Bill From ibanez@cs.unc.edu Wed, 28 Feb 2001 20:41:12 -0500 (EST) Date: Wed, 28 Feb 2001 20:41:12 -0500 (EST) From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] mesh data structure problem. Hi Ting, my mistake, I should have said: point.Value() = p; for the iterator, intead of : point.Value( p ) In any case, that will only help you with the speed of access. I think that the real problem in you code could be the allocation. Did you add a line like: GetPoints()->Reserve( 1000 ); before starting to get access to the points ? This line will allocate a number of points (1000 in this case ) for you. Hope that helps, Luis ---------------------------------------- On Wed, 28 Feb 2001, Ting Chen wrote: > but point.value take no parameter and just return the value stored at the > location, any other suggestion? > > > > >PointsContainerPointer myPoints = GetPoints(); > >PointsContainer::Iterator point = myPoints->Begin(); > >PointType p; > >p = 0,0,0; > >while( point != myPoints->End() ) > >{ > > point.Value( p ); > > ++point; > >} > > > > > > > >Luis > > > > > >----------------------------------------------------------------------- > > > >Ting Chen wrote: > > > >> I write the following code in my itkDeformableMesh class: > >> > >> .... > >> float ds[3], d[3]={0, 0, 0}; > >> SetPoint(1, (PointType)d); > >> GetPoint(1, (PointType*)ds); > >> .... > >> > >> but I found out that ds={-1.074e+008, 0, 0} after the operation. > >> > >> if I do > >> .... > >> float ds[3], d[3]={0, 0, 0}; > >> SetPoint(0, (PointType)d); > >> GetPoint(0, (PointType*)ds); > >> .... > >> > >> ds = {-1.074e+008, -1.074e+008, -1.074e+008} > >> > >> it seems the first element in the container has problems here. what is > the > >> problem here? > >> thanks > >> ting > >> > >> _______________________________________________ > >> Insight-developers mailing list > >> Insight-developers@public.kitware.com > >> http://public.kitware.com/mailman/listinfo/insight-developers > > > >-- > >______________________________________________________________________ > > > >Luis Ibanez > >Research Assistant Professor - Division of Neurosurgery > >University of North Carolina at Chapel Hill > >CB# 7060, Chapel Hill, NC 27599 > >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez > >phone : (919)-843-9961 fax : (919)-966-6627 > >______________________________________________________________________ > > -- ----------------------------------------------------------- Luis Ibanez Research Assistant Professor - Division of NeuroSurgery University of North Carolina at Chapel Hill Chapel Hill, NC, 27599 http://www.cs.unc.edu/~ibanez ------------------------------------------------------------ From ibanez@cs.unc.edu Thu, 01 Mar 2001 10:36:19 -0500 Date: Thu, 01 Mar 2001 10:36:19 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkMesh GetClassName() and windows.h Hi, I've found the following problem on WinNT: Using itkMesh in a larger application mixed with other non-itk classes. It happens that if you include : #include #include in this order, and declare a variable of type itkMesh, the calls to GetPoints() generate the following error concerning GetClassName() : ------------------- error message ----------------------------- :\usr\ibanez\src\insightalpha\insight\code\common\itkmesh.txx(78) : error C2039: 'GetClassName' : is not a member of 'Mesh >' h:\microsoft visual studio\vc98\include\xstring(583) : while compiling class-template member function 'class itk::SmartPointer > > __thiscall itk::Mesh >::GetPoints(void)' h:\usr\ibanez\src\insightalpha\insight\code\common\itkmesh.txx(78) : error C2039: 'GetClassName' : is not a member of 'Mesh >' h:\microsoft visual studio\vc98\include\xstring(583) : while compiling class-template member function 'class itk::SmartPointer > > __thiscall itk::Mesh >::GetPoints(void)' Error executing cl.exe. ------------------ end error message ------------------------------- But, if the order of includes are revesed, like: #include #include The code compiles fine. Looks like some definitions on windows.h obscures the Macro declaration of itkTypeMacro. I cannont avoid the inclusion of "windows.h" because it is buried nested in includes from other package (FLTK) from which I'm deriving classes. Is there something we can do about it ? Thanks Luis -- ______________________________________________________________________ Luis Ibanez Research Assistant Professor - Division of Neurosurgery University of North Carolina at Chapel Hill CB# 7060, Chapel Hill, NC 27599 email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez phone : (919)-843-9961 fax : (919)-966-6627 ______________________________________________________________________ From bill.hoffman@kitware.com Thu, 01 Mar 2001 10:32:24 -0500 Date: Thu, 01 Mar 2001 10:32:24 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] itkMesh GetClassName() and windows.h You should not include windows.h and mesh. I have created a new file called itkWindows.h, if you include that instead of windows.h it will get rid of the problem. At 10:36 AM 3/1/2001 -0500, Luis Ibanez wrote: >Hi, > >I've found the following problem on WinNT: > >Using itkMesh in a larger application mixed >with other non-itk classes. > >It happens that if you include : > > #include > #include > >in this order, > >and declare a variable of type itkMesh, >the calls to GetPoints() generate the following error >concerning GetClassName() : > >------------------- error message ----------------------------- >:\usr\ibanez\src\insightalpha\insight\code\common\itkmesh.txx(78) : >error C2039: 'GetClassName' : is not a member of 'Meshitk::DefaultStaticMeshType >' > h:\microsoft visual studio\vc98\include\xstring(583) : while >compiling class-template member function 'class itk::SmartPointeritk::VectorContainer > > >__thiscall itk::MeshultStaticMeshType >::GetPoints(void)' >h:\usr\ibanez\src\insightalpha\insight\code\common\itkmesh.txx(78) : >error C2039: 'GetClassName' : is not a member of 'Meshitk::DefaultStaticMeshType >' > h:\microsoft visual studio\vc98\include\xstring(583) : while >compiling class-template member function 'class itk::SmartPointeritk::VectorContainer > > >__thiscall itk::MeshultStaticMeshType >::GetPoints(void)' >Error executing cl.exe. > >------------------ end error message ------------------------------- > >But, if the order of includes are revesed, like: > >#include >#include > >The code compiles fine. > >Looks like some definitions on windows.h >obscures the Macro declaration of itkTypeMacro. > >I cannont avoid the inclusion of "windows.h" because >it is buried nested in includes from other package (FLTK) >from which I'm deriving classes. > > > >Is there something we can do about it ? > > > >Thanks > > >Luis > > > > > > > >-- >______________________________________________________________________ > >Luis Ibanez >Research Assistant Professor - Division of Neurosurgery >University of North Carolina at Chapel Hill >CB# 7060, Chapel Hill, NC 27599 >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez >phone : (919)-843-9961 fax : (919)-966-6627 >______________________________________________________________________ > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From ibanez@cs.unc.edu Thu, 01 Mar 2001 10:58:36 -0500 Date: Thu, 01 Mar 2001 10:58:36 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkMesh GetClassName() and windows.h It works fine, Thanks ! I can even keep the indirect include to "windows.h" (for which I have no choice because it is included from fltk headers) as long as itkWindows.h is included before itkMesh.h, like: #include #include #include Is that because of the #undef GetClassName in itkWindows.h ? Thanks, Luis Bill Hoffman wrote: > You should not include windows.h and mesh. I > have created a new file called itkWindows.h, if you include > that instead of windows.h it will get rid of the problem. From bill.hoffman@kitware.com Thu, 01 Mar 2001 11:59:13 -0500 Date: Thu, 01 Mar 2001 11:59:13 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] itkMesh GetClassName() and windows.h Yes, Brad has just added that undef to itkWin32Header.h, so if you do an update, you may be able to get rid of the include of itkWindows.h altogether. -Bill At 10:58 AM 3/1/2001 -0500, Luis Ibanez wrote: >Is that because of the #undef GetClassName in itkWindows.h ? > >Thanks, > >Luis From blezek@crd.ge.com Thu, 1 Mar 2001 14:58:01 -0500 (EST) Date: Thu, 1 Mar 2001 14:58:01 -0500 (EST) From: Daniel J. Blezek, Ph.D. blezek@crd.ge.com Subject: [Insight-developers] Template parameters Hi all, I'm digging into the Insight code, and noticed some inconsistancies is how template paramaters are being used. In one case: template class ITK_EXPORT NeighborhoodOperatorImageFilter : public ImageToImageFilter< Image, Image > In another: template class ITK_EXPORT ShrinkImageFilter: public ImageToImageFilter In another: template class ITK_EXPORT ThresholdImageFilter:public ImageToImageFilter Case: 1. Specified the pixel type and dimension 2. Specified both input and output image types, not really necessary, shrink should not change the pixel type of the data 3. Use only one image type for both input and output I think this raises a fundamental question about how to specify a filter. Do we specify by pixel type and dimension, or by input/output type, or just one type? Ideas? -dan -- Daniel Blezek, Ph.D. blezek@crd.ge.com Visualization and Computer Vision Program Electronic Systems Lab GE Corporate Research & Development From chenting@graphics.cis.upenn.edu Thu, 1 Mar 2001 16:01:36 -0600 Date: Thu, 1 Mar 2001 16:01:36 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] mesh data structure problem. Hi! I have tried to add the memory allocation code before I do anything to the pointcontainer, but I still cannot get the correct answer, and by the way, did you try to add that piece of code into itkMeshTest and run it? ting -----Original Message----- From: Luis Ibanez To: Ting Chen Cc: Insight toolkit Date: Thursday, March 01, 2001 8:17 AM Subject: Re: [Insight-developers] mesh data structure problem. >Hi Ting, > >my mistake, I should have said: > > point.Value() = p; > >for the iterator, >intead of : > > point.Value( p ) > >In any case, that will only help you >with the speed of access. > >I think that the real problem in you >code could be the allocation. >Did you add a line like: > > GetPoints()->Reserve( 1000 ); > >before starting to get access to the >points ? > >This line will allocate a number of >points (1000 in this case ) for you. > > >Hope that helps, > >Luis > > >---------------------------------------- > >On Wed, 28 Feb 2001, Ting Chen wrote: > >> but point.value take no parameter and just return the value stored at the >> location, any other suggestion? >> >> > >> >PointsContainerPointer myPoints = GetPoints(); >> >PointsContainer::Iterator point = myPoints->Begin(); >> >PointType p; >> >p = 0,0,0; >> >while( point != myPoints->End() ) >> >{ >> > point.Value( p ); >> > ++point; >> >} >> > >> > >> > >> >Luis >> > >> > >> >----------------------------------------------------------------------- >> > >> >Ting Chen wrote: >> > >> >> I write the following code in my itkDeformableMesh class: >> >> >> >> .... >> >> float ds[3], d[3]={0, 0, 0}; >> >> SetPoint(1, (PointType)d); >> >> GetPoint(1, (PointType*)ds); >> >> .... >> >> >> >> but I found out that ds={-1.074e+008, 0, 0} after the operation. >> >> >> >> if I do >> >> .... >> >> float ds[3], d[3]={0, 0, 0}; >> >> SetPoint(0, (PointType)d); >> >> GetPoint(0, (PointType*)ds); >> >> .... >> >> >> >> ds = {-1.074e+008, -1.074e+008, -1.074e+008} >> >> >> >> it seems the first element in the container has problems here. what is >> the >> >> problem here? >> >> thanks >> >> ting >> >> >> >> _______________________________________________ >> >> Insight-developers mailing list >> >> Insight-developers@public.kitware.com >> >> http://public.kitware.com/mailman/listinfo/insight-developers >> > >> >-- >> >______________________________________________________________________ >> > >> >Luis Ibanez >> >Research Assistant Professor - Division of Neurosurgery >> >University of North Carolina at Chapel Hill >> >CB# 7060, Chapel Hill, NC 27599 >> >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez >> >phone : (919)-843-9961 fax : (919)-966-6627 >> >______________________________________________________________________ >> >> > >-- >----------------------------------------------------------- >Luis Ibanez >Research Assistant Professor - Division of NeuroSurgery >University of North Carolina at Chapel Hill >Chapel Hill, NC, 27599 http://www.cs.unc.edu/~ibanez >------------------------------------------------------------ > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From brad.king@kitware.com Thu, 1 Mar 2001 17:36:52 -0500 (EST) Date: Thu, 1 Mar 2001 17:36:52 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Template parameters Here is my view: > template > class ITK_EXPORT NeighborhoodOperatorImageFilter : > public ImageToImageFilter< Image, > Image > This version should never be used because it locks down the filter to operating on the Image class directly. This prevents someone from using an image adaptor or writing their own image class that conforms to our image's interface. > template > class ITK_EXPORT ShrinkImageFilter: > public ImageToImageFilter This version should always be used. Any type can be passed to each parameter, so image adaptors and other image classes can be substituted for our image. Even when the image types must be the same for both input and output, someone could still use an image adaptor on one end, and thus we need two different template parameters. > template > class ITK_EXPORT ThresholdImageFilter: > public ImageToImageFilter This version should never be used due to the above argument about image adaptors. If you want to make sure the data and dimensions are the same for the two images, there are other ways to do it at compile time. I'll try to come up with an example of this if someone needs to do it. -Brad From cates@cayenne.cs.utah.edu Thu, 1 Mar 2001 18:19:05 -0700 (MST) Date: Thu, 1 Mar 2001 18:19:05 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] Template parameters Seems like there was some discussion on this awhile back and people agreed(?) that for most filters the was the way to go. From a "black-box" component view of constructing a pipeline, specifying input type and output type as the template parameters makes good sense. Downside is that it requires a lot of fancy typenaming of typedef'd typedefs to get at the actual parameters you need. Might be wise to establish some conventions for how to do this that are acceptable to all the supported compilers. (ie. enum'ing the image dimension, getting the pixel type, etc.) Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates On Thu, 1 Mar 2001, Daniel J. Blezek, Ph.D. wrote: > Hi all, > > I'm digging into the Insight code, and noticed some inconsistancies is > how template paramaters are being used. In one case: > > template > class ITK_EXPORT NeighborhoodOperatorImageFilter : > public ImageToImageFilter< Image, > Image > > > > In another: > > template > class ITK_EXPORT ShrinkImageFilter: > public ImageToImageFilter > > > In another: > > template > class ITK_EXPORT ThresholdImageFilter:public ImageToImageFilter > > > Case: > 1. Specified the pixel type and dimension > 2. Specified both input and output image types, not really necessary, > shrink should not change the pixel type of the data > 3. Use only one image type for both input and output > > I think this raises a fundamental question about how to specify a filter. > Do we specify by pixel type and dimension, or by input/output type, or > just one type? > > Ideas? > -dan > > -- > Daniel Blezek, Ph.D. > blezek@crd.ge.com > Visualization and Computer Vision Program > Electronic Systems Lab > GE Corporate Research & Development > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From lng@insightful.com Fri, 2 Mar 2001 00:09:06 -0800 Date: Fri, 2 Mar 2001 00:09:06 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] mesh data structure problem. Hi, The problem seems to be with VectorContainer::GetElementIfIndexExists() it thinks id = 0 is invalid and fails ( see code below ). Hence the bogus result when you call mesh->GetPoint( 0, &point ) Can someone from GE/Kitware look into this? Cheers, Lydia --------------- from itkVectorContainer.txx ------------------------- template bool VectorContainer< TElementIdentifier , TElement > ::GetElementIfIndexExists(ElementIdentifier id, Element* element) const { if((id > 0) && (id < this->VectorType::size())) { if(element) { *element = this->VectorType::operator[](id); } return true; } return false; } ----- Original Message ----- From: "Ting Chen" To: "Luis Ibanez" Cc: "Insight toolkit" Sent: Thursday, March 01, 2001 2:01 PM Subject: Re: [Insight-developers] mesh data structure problem. > Hi! I have tried to add the memory allocation code before I do anything to > the pointcontainer, but I still cannot get the correct answer, > and by the way, did you try to add that piece of code into itkMeshTest and > run it? > ting > -----Original Message----- > From: Luis Ibanez > To: Ting Chen > Cc: Insight toolkit > Date: Thursday, March 01, 2001 8:17 AM > Subject: Re: [Insight-developers] mesh data structure problem. > > > >Hi Ting, > > > >my mistake, I should have said: > > > > point.Value() = p; > > > >for the iterator, > >intead of : > > > > point.Value( p ) > > > >In any case, that will only help you > >with the speed of access. > > > >I think that the real problem in you > >code could be the allocation. > >Did you add a line like: > > > > GetPoints()->Reserve( 1000 ); > > > >before starting to get access to the > >points ? > > > >This line will allocate a number of > >points (1000 in this case ) for you. > > > > > >Hope that helps, > > > >Luis > > > > > >---------------------------------------- > > > >On Wed, 28 Feb 2001, Ting Chen wrote: > > > >> but point.value take no parameter and just return the value stored at the > >> location, any other suggestion? > >> > >> > > >> >PointsContainerPointer myPoints = GetPoints(); > >> >PointsContainer::Iterator point = myPoints->Begin(); > >> >PointType p; > >> >p = 0,0,0; > >> >while( point != myPoints->End() ) > >> >{ > >> > point.Value( p ); > >> > ++point; > >> >} > >> > > >> > > >> > > >> >Luis > >> > > >> > > >> >----------------------------------------------------------------------- > >> > > >> >Ting Chen wrote: > >> > > >> >> I write the following code in my itkDeformableMesh class: > >> >> > >> >> .... > >> >> float ds[3], d[3]={0, 0, 0}; > >> >> SetPoint(1, (PointType)d); > >> >> GetPoint(1, (PointType*)ds); > >> >> .... > >> >> > >> >> but I found out that ds={-1.074e+008, 0, 0} after the operation. > >> >> > >> >> if I do > >> >> .... > >> >> float ds[3], d[3]={0, 0, 0}; > >> >> SetPoint(0, (PointType)d); > >> >> GetPoint(0, (PointType*)ds); > >> >> .... > >> >> > >> >> ds = {-1.074e+008, -1.074e+008, -1.074e+008} > >> >> > >> >> it seems the first element in the container has problems here. what is > >> the > >> >> problem here? > >> >> thanks > >> >> ting > >> >> > >> >> _______________________________________________ > >> >> Insight-developers mailing list > >> >> Insight-developers@public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/insight-developers > >> > > >> >-- > >> >______________________________________________________________________ > >> > > >> >Luis Ibanez > >> >Research Assistant Professor - Division of Neurosurgery > >> >University of North Carolina at Chapel Hill > >> >CB# 7060, Chapel Hill, NC 27599 > >> >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez > >> >phone : (919)-843-9961 fax : (919)-966-6627 > >> >______________________________________________________________________ > >> > >> > > > >-- > >----------------------------------------------------------- > >Luis Ibanez > >Research Assistant Professor - Division of NeuroSurgery > >University of North Carolina at Chapel Hill > >Chapel Hill, NC, 27599 http://www.cs.unc.edu/~ibanez > >------------------------------------------------------------ > > > > > > > >_______________________________________________ > >Insight-developers mailing list > >Insight-developers@public.kitware.com > >http://public.kitware.com/mailman/listinfo/insight-developers > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From lng@insightful.com Fri, 2 Mar 2001 00:31:20 -0800 Date: Fri, 2 Mar 2001 00:31:20 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] Visual C++ project tutorial Hi Damion, I found I also needed to set "Use Run-time Library" to "Debug Multithreaded DLL" (debug mode ) and "Multithreaded DLL" (release mode) else it won't compile. In my system, these weren't the defaults for a console app. Are you able compile using a different run-time library setting? Cheers, Lydia I found that I also need to make ----- Original Message ----- From: "Damion Shelton" To: "Insight-Developers" Sent: Friday, February 23, 2001 1:21 PM Subject: [Insight-developers] Visual C++ project tutorial > Hi all... > > At Steve's request, I checked in a new tutorial file under > Insight/Documentation called VC_Custom_Projects. It describes the project > settings necessary to build a Visual C++ 6.0 project outside of the Insight > source tree. Please run through it if you have a chance and give me feedback > (particularly if there are errors!), as this sort of tutorial will be useful > to the participants in the alpha test. Thx. > > -Damion- > > /-----------------------------------------------\ > Damion Shelton > University of Pittsburgh > Department of Bioengineering > dmsst59@pitt.edu > 412-624-9931 > \-----------------------------------------------/ > > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From lorensen@crd.ge.com Fri, 2 Mar 2001 07:08:59 -0500 Date: Fri, 2 Mar 2001 07:08:59 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] mesh data structure problem. I believe I introduced that problem when purging some signed/unsigned mis matches. I checked in the fix. Bill -----Original Message----- From: Lydia Ng [mailto:lng@insightful.com] Sent: Friday, March 02, 2001 3:09 AM To: Luis Ibanez Cc: insight-developers@public.kitware.com Subject: Re: [Insight-developers] mesh data structure problem. Hi, The problem seems to be with VectorContainer::GetElementIfIndexExists() it thinks id = 0 is invalid and fails ( see code below ). Hence the bogus result when you call mesh->GetPoint( 0, &point ) Can someone from GE/Kitware look into this? Cheers, Lydia --------------- from itkVectorContainer.txx ------------------------- template bool VectorContainer< TElementIdentifier , TElement > ::GetElementIfIndexExists(ElementIdentifier id, Element* element) const { if((id > 0) && (id < this->VectorType::size())) { if(element) { *element = this->VectorType::operator[](id); } return true; } return false; } ----- Original Message ----- From: "Ting Chen" To: "Luis Ibanez" Cc: "Insight toolkit" Sent: Thursday, March 01, 2001 2:01 PM Subject: Re: [Insight-developers] mesh data structure problem. > Hi! I have tried to add the memory allocation code before I do anything to > the pointcontainer, but I still cannot get the correct answer, > and by the way, did you try to add that piece of code into itkMeshTest and > run it? > ting > -----Original Message----- > From: Luis Ibanez > To: Ting Chen > Cc: Insight toolkit > Date: Thursday, March 01, 2001 8:17 AM > Subject: Re: [Insight-developers] mesh data structure problem. > > > >Hi Ting, > > > >my mistake, I should have said: > > > > point.Value() = p; > > > >for the iterator, > >intead of : > > > > point.Value( p ) > > > >In any case, that will only help you > >with the speed of access. > > > >I think that the real problem in you > >code could be the allocation. > >Did you add a line like: > > > > GetPoints()->Reserve( 1000 ); > > > >before starting to get access to the > >points ? > > > >This line will allocate a number of > >points (1000 in this case ) for you. > > > > > >Hope that helps, > > > >Luis > > > > > >---------------------------------------- > > > >On Wed, 28 Feb 2001, Ting Chen wrote: > > > >> but point.value take no parameter and just return the value stored at the > >> location, any other suggestion? > >> > >> > > >> >PointsContainerPointer myPoints = GetPoints(); > >> >PointsContainer::Iterator point = myPoints->Begin(); > >> >PointType p; > >> >p = 0,0,0; > >> >while( point != myPoints->End() ) > >> >{ > >> > point.Value( p ); > >> > ++point; > >> >} > >> > > >> > > >> > > >> >Luis > >> > > >> > > >> >----------------------------------------------------------------------- > >> > > >> >Ting Chen wrote: > >> > > >> >> I write the following code in my itkDeformableMesh class: > >> >> > >> >> .... > >> >> float ds[3], d[3]={0, 0, 0}; > >> >> SetPoint(1, (PointType)d); > >> >> GetPoint(1, (PointType*)ds); > >> >> .... > >> >> > >> >> but I found out that ds={-1.074e+008, 0, 0} after the operation. > >> >> > >> >> if I do > >> >> .... > >> >> float ds[3], d[3]={0, 0, 0}; > >> >> SetPoint(0, (PointType)d); > >> >> GetPoint(0, (PointType*)ds); > >> >> .... > >> >> > >> >> ds = {-1.074e+008, -1.074e+008, -1.074e+008} > >> >> > >> >> it seems the first element in the container has problems here. what is > >> the > >> >> problem here? > >> >> thanks > >> >> ting > >> >> > >> >> _______________________________________________ > >> >> Insight-developers mailing list > >> >> Insight-developers@public.kitware.com > >> >> http://public.kitware.com/mailman/listinfo/insight-developers > >> > > >> >-- > >> >______________________________________________________________________ > >> > > >> >Luis Ibanez > >> >Research Assistant Professor - Division of Neurosurgery > >> >University of North Carolina at Chapel Hill > >> >CB# 7060, Chapel Hill, NC 27599 > >> >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez > >> >phone : (919)-843-9961 fax : (919)-966-6627 > >> >______________________________________________________________________ > >> > >> > > > >-- > >----------------------------------------------------------- > >Luis Ibanez > >Research Assistant Professor - Division of NeuroSurgery > >University of North Carolina at Chapel Hill > >Chapel Hill, NC, 27599 http://www.cs.unc.edu/~ibanez > >------------------------------------------------------------ > > > > > > > >_______________________________________________ > >Insight-developers mailing list > >Insight-developers@public.kitware.com > >http://public.kitware.com/mailman/listinfo/insight-developers > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From dmsst59@pitt.edu Fri, 2 Mar 2001 08:54:35 -0500 Date: Fri, 2 Mar 2001 08:54:35 -0500 From: Damion Shelton dmsst59@pitt.edu Subject: [Insight-developers] visual c++ tutorial status To Lydia and others.... It turns out there were two omissions in the tutorial (found by Stephen and Bill) which prevent it from compiling if you follow it exactly. These are: 1) You need to use the multi-thread libraries, with /MDd for debug builds or /MD for release builds 2) You need to enable RTTI, found on the "C++ language" pulldown under the C/C++ tab in the project options window Another suggestion provided by Stephen is adding the include and library paths to Visual C++ in general, via Tools->Options->Directories, rather than using the /I flags in the compiler settings for each project. In most circumstances this is probably a good idea, because it saves you from having to retype everything (probably not a good idea if you're going to be distributing stand-alone example workspaces though). Hopefully those two flags are all I overlooked. I'll be updating the tutorial very soon, hopefully later today after I'm clear of my last midterm. If anyone else has suggestions for additional things they'd like to see, or any other errors/omissions, please let me know. Thanks for the help. -Damion- From cates@cayenne.cs.utah.edu Fri, 2 Mar 2001 15:22:06 -0700 (MST) Date: Fri, 2 Mar 2001 15:22:06 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] hash_map Hi all, >From todays TCON it seems clear that we will need hash tables in Insight and cannot use the non-standard STL hashed container extensions because they are not supported by microsoft. Our "itkHashTable" can either be completely STL-compatible, or stand-alone, or somewhere in between. I think the latter is a good compromise, ie. make a reasonable effort to implement the stl associative container concept (ideally by modifying some public domain implementation), but not try to tackle the full SGI hashed associative container concept. Other folks thoughts on this? If we agree that this is a reasonable way to go, I'll start putting something together. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates From chenting@graphics.cis.upenn.edu Fri, 2 Mar 2001 19:29:53 -0600 Date: Fri, 2 Mar 2001 19:29:53 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] mesh data structure problem. Hi! Thanks for check in the fix, however, the problem has not been solved yet. when I use: itk::Mesh Mesh; Mesh::PointType x; getpoint(i, x); the value in x is still not right. please look into that.(though much better now, all the data is there, but the order is not correct) Thx ting I cannot get the proper value in the mesh -----Original Message----- From: Lorensen, William E (CRD) To: 'Lydia Ng' ; Luis Ibanez Cc: insight-developers@public.kitware.com Date: Friday, March 02, 2001 6:09 AM Subject: RE: [Insight-developers] mesh data structure problem. >I believe I introduced that problem when purging some signed/unsigned mis matches. > >I checked in the fix. > >Bill > > >-----Original Message----- >From: Lydia Ng [mailto:lng@insightful.com] >Sent: Friday, March 02, 2001 3:09 AM >To: Luis Ibanez >Cc: insight-developers@public.kitware.com >Subject: Re: [Insight-developers] mesh data structure problem. > > >Hi, > >The problem seems to be with VectorContainer::GetElementIfIndexExists() >it thinks id = 0 is invalid and fails ( see code below ). > >Hence the bogus result when you call > mesh->GetPoint( 0, &point ) > >Can someone from GE/Kitware look into this? > >Cheers, >Lydia > >--------------- from itkVectorContainer.txx ------------------------- >template >bool >VectorContainer< TElementIdentifier , TElement > >::GetElementIfIndexExists(ElementIdentifier id, Element* element) const >{ > if((id > 0) && (id < this->VectorType::size())) > { > if(element) > { > *element = this->VectorType::operator[](id); > } > return true; > } > return false; >} > > > >----- Original Message ----- >From: "Ting Chen" >To: "Luis Ibanez" >Cc: "Insight toolkit" >Sent: Thursday, March 01, 2001 2:01 PM >Subject: Re: [Insight-developers] mesh data structure problem. > > >> Hi! I have tried to add the memory allocation code before I do anything to >> the pointcontainer, but I still cannot get the correct answer, >> and by the way, did you try to add that piece of code into itkMeshTest and >> run it? >> ting >> -----Original Message----- >> From: Luis Ibanez >> To: Ting Chen >> Cc: Insight toolkit >> Date: Thursday, March 01, 2001 8:17 AM >> Subject: Re: [Insight-developers] mesh data structure problem. >> >> >> >Hi Ting, >> > >> >my mistake, I should have said: >> > >> > point.Value() = p; >> > >> >for the iterator, >> >intead of : >> > >> > point.Value( p ) >> > >> >In any case, that will only help you >> >with the speed of access. >> > >> >I think that the real problem in you >> >code could be the allocation. >> >Did you add a line like: >> > >> > GetPoints()->Reserve( 1000 ); >> > >> >before starting to get access to the >> >points ? >> > >> >This line will allocate a number of >> >points (1000 in this case ) for you. >> > >> > >> >Hope that helps, >> > >> >Luis >> > >> > >> >---------------------------------------- >> > >> >On Wed, 28 Feb 2001, Ting Chen wrote: >> > >> >> but point.value take no parameter and just return the value stored at >the >> >> location, any other suggestion? >> >> >> >> > >> >> >PointsContainerPointer myPoints = GetPoints(); >> >> >PointsContainer::Iterator point = myPoints->Begin(); >> >> >PointType p; >> >> >p = 0,0,0; >> >> >while( point != myPoints->End() ) >> >> >{ >> >> > point.Value( p ); >> >> > ++point; >> >> >} >> >> > >> >> > >> >> > >> >> >Luis >> >> > >> >> > >> >> >>----------------------------------------------------------------------- >> >> > >> >> >Ting Chen wrote: >> >> > >> >> >> I write the following code in my itkDeformableMesh class: >> >> >> >> >> >> .... >> >> >> float ds[3], d[3]={0, 0, 0}; >> >> >> SetPoint(1, (PointType)d); >> >> >> GetPoint(1, (PointType*)ds); >> >> >> .... >> >> >> >> >> >> but I found out that ds={-1.074e+008, 0, 0} after the operation. >> >> >> >> >> >> if I do >> >> >> .... >> >> >> float ds[3], d[3]={0, 0, 0}; >> >> >> SetPoint(0, (PointType)d); >> >> >> GetPoint(0, (PointType*)ds); >> >> >> .... >> >> >> >> >> >> ds = {-1.074e+008, -1.074e+008, -1.074e+008} >> >> >> >> >> >> it seems the first element in the container has problems here. what >is >> >> the >> >> >> problem here? >> >> >> thanks >> >> >> ting >> >> >> >> >> >> _______________________________________________ >> >> >> Insight-developers mailing list >> >> >> Insight-developers@public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/insight-developers >> >> > >> >> >-- >> >> >______________________________________________________________________ >> >> > >> >> >Luis Ibanez >> >> >Research Assistant Professor - Division of Neurosurgery >> >> >University of North Carolina at Chapel Hill >> >> >CB# 7060, Chapel Hill, NC 27599 >> >> >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez >> >> >phone : (919)-843-9961 fax : (919)-966-6627 >> >> >______________________________________________________________________ >> >> >> >> >> > >> >-- >> >----------------------------------------------------------- >> >Luis Ibanez >> >Research Assistant Professor - Division of NeuroSurgery >> >University of North Carolina at Chapel Hill >> >Chapel Hill, NC, 27599 http://www.cs.unc.edu/~ibanez >> >------------------------------------------------------------ >> > >> > >> > >> >_______________________________________________ >> >Insight-developers mailing list >> >Insight-developers@public.kitware.com >> >http://public.kitware.com/mailman/listinfo/insight-developers >> >> >> _______________________________________________ >> Insight-developers mailing list >> Insight-developers@public.kitware.com >> http://public.kitware.com/mailman/listinfo/insight-developers >> > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From chenting@graphics.cis.upenn.edu Fri, 2 Mar 2001 19:53:03 -0600 Date: Fri, 2 Mar 2001 19:53:03 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] mesh data structure problem. ok, I found out the problem is in type cast. now the getpoint method is ok! Thanks Bill. -----Original Message----- From: Lorensen, William E (CRD) To: 'Lydia Ng' ; Luis Ibanez Cc: insight-developers@public.kitware.com Date: Friday, March 02, 2001 6:09 AM Subject: RE: [Insight-developers] mesh data structure problem. >I believe I introduced that problem when purging some signed/unsigned mis matches. > >I checked in the fix. > >Bill > > >-----Original Message----- >From: Lydia Ng [mailto:lng@insightful.com] >Sent: Friday, March 02, 2001 3:09 AM >To: Luis Ibanez >Cc: insight-developers@public.kitware.com >Subject: Re: [Insight-developers] mesh data structure problem. > > >Hi, > >The problem seems to be with VectorContainer::GetElementIfIndexExists() >it thinks id = 0 is invalid and fails ( see code below ). > >Hence the bogus result when you call > mesh->GetPoint( 0, &point ) > >Can someone from GE/Kitware look into this? > >Cheers, >Lydia > >--------------- from itkVectorContainer.txx ------------------------- >template >bool >VectorContainer< TElementIdentifier , TElement > >::GetElementIfIndexExists(ElementIdentifier id, Element* element) const >{ > if((id > 0) && (id < this->VectorType::size())) > { > if(element) > { > *element = this->VectorType::operator[](id); > } > return true; > } > return false; >} > > > >----- Original Message ----- >From: "Ting Chen" >To: "Luis Ibanez" >Cc: "Insight toolkit" >Sent: Thursday, March 01, 2001 2:01 PM >Subject: Re: [Insight-developers] mesh data structure problem. > > >> Hi! I have tried to add the memory allocation code before I do anything to >> the pointcontainer, but I still cannot get the correct answer, >> and by the way, did you try to add that piece of code into itkMeshTest and >> run it? >> ting >> -----Original Message----- >> From: Luis Ibanez >> To: Ting Chen >> Cc: Insight toolkit >> Date: Thursday, March 01, 2001 8:17 AM >> Subject: Re: [Insight-developers] mesh data structure problem. >> >> >> >Hi Ting, >> > >> >my mistake, I should have said: >> > >> > point.Value() = p; >> > >> >for the iterator, >> >intead of : >> > >> > point.Value( p ) >> > >> >In any case, that will only help you >> >with the speed of access. >> > >> >I think that the real problem in you >> >code could be the allocation. >> >Did you add a line like: >> > >> > GetPoints()->Reserve( 1000 ); >> > >> >before starting to get access to the >> >points ? >> > >> >This line will allocate a number of >> >points (1000 in this case ) for you. >> > >> > >> >Hope that helps, >> > >> >Luis >> > >> > >> >---------------------------------------- >> > >> >On Wed, 28 Feb 2001, Ting Chen wrote: >> > >> >> but point.value take no parameter and just return the value stored at >the >> >> location, any other suggestion? >> >> >> >> > >> >> >PointsContainerPointer myPoints = GetPoints(); >> >> >PointsContainer::Iterator point = myPoints->Begin(); >> >> >PointType p; >> >> >p = 0,0,0; >> >> >while( point != myPoints->End() ) >> >> >{ >> >> > point.Value( p ); >> >> > ++point; >> >> >} >> >> > >> >> > >> >> > >> >> >Luis >> >> > >> >> > >> >> >>----------------------------------------------------------------------- >> >> > >> >> >Ting Chen wrote: >> >> > >> >> >> I write the following code in my itkDeformableMesh class: >> >> >> >> >> >> .... >> >> >> float ds[3], d[3]={0, 0, 0}; >> >> >> SetPoint(1, (PointType)d); >> >> >> GetPoint(1, (PointType*)ds); >> >> >> .... >> >> >> >> >> >> but I found out that ds={-1.074e+008, 0, 0} after the operation. >> >> >> >> >> >> if I do >> >> >> .... >> >> >> float ds[3], d[3]={0, 0, 0}; >> >> >> SetPoint(0, (PointType)d); >> >> >> GetPoint(0, (PointType*)ds); >> >> >> .... >> >> >> >> >> >> ds = {-1.074e+008, -1.074e+008, -1.074e+008} >> >> >> >> >> >> it seems the first element in the container has problems here. what >is >> >> the >> >> >> problem here? >> >> >> thanks >> >> >> ting >> >> >> >> >> >> _______________________________________________ >> >> >> Insight-developers mailing list >> >> >> Insight-developers@public.kitware.com >> >> >> http://public.kitware.com/mailman/listinfo/insight-developers >> >> > >> >> >-- >> >> >______________________________________________________________________ >> >> > >> >> >Luis Ibanez >> >> >Research Assistant Professor - Division of Neurosurgery >> >> >University of North Carolina at Chapel Hill >> >> >CB# 7060, Chapel Hill, NC 27599 >> >> >email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez >> >> >phone : (919)-843-9961 fax : (919)-966-6627 >> >> >______________________________________________________________________ >> >> >> >> >> > >> >-- >> >----------------------------------------------------------- >> >Luis Ibanez >> >Research Assistant Professor - Division of NeuroSurgery >> >University of North Carolina at Chapel Hill >> >Chapel Hill, NC, 27599 http://www.cs.unc.edu/~ibanez >> >------------------------------------------------------------ >> > >> > >> > >> >_______________________________________________ >> >Insight-developers mailing list >> >Insight-developers@public.kitware.com >> >http://public.kitware.com/mailman/listinfo/insight-developers >> >> >> _______________________________________________ >> Insight-developers mailing list >> Insight-developers@public.kitware.com >> http://public.kitware.com/mailman/listinfo/insight-developers >> > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From wlorens1@nycap.rr.com Sun, 04 Mar 2001 08:21:15 -0500 Date: Sun, 04 Mar 2001 08:21:15 -0500 From: Bill Lorensen wlorens1@nycap.rr.com Subject: [Insight-developers] Your new filter Julien, Good to see your new filter that computes a Danielsson distance map. I'm assuming that you built and tested it on Windows. The other platforms are a bit more strict in some C++ usage. Most of the compile errors on the SGI and gnu compilers will go away if you use the typename hint. For example: TOutputImage::PixelType replaced with typename TOutputImage::PixelType Also, the sgi is confused with your usage of sqrt. The arguments are of type short. Is this really what you meant? The squaring of the short's could cause overflow. Also, neither your .h nor .txx files ended with a new line. Lastly, I believe the filter should be called: itkDanielssonImageFilter or perhaps itkDanielssonDistanceImageFilter according to the new naming conventions we discussed in Salt Lake. Thanks, Bill From bahrahm@yahoo.com Mon, 5 Mar 2001 08:47:45 -0800 (PST) Date: Mon, 5 Mar 2001 08:47:45 -0800 (PST) From: Jisung Kim bahrahm@yahoo.com Subject: [Insight-developers] New PhysicalImage[Adaptor] class Hello. I'm Jisung Kim and working at CADD Lab at UNC-CH. I just made some changes to introduce the new PhysicalImage class and PhysicalImageAdaptor class. SUMMARY 1. moved all space and origin related functions, member variables, and typedefs from ImageBase, Image, & ImageAdaptor classes to PhysicalImage & PhysicalImageAdaptor classes. 2. added PhysicalImage & PhysicalImageAdaptor class files to Insight/Code/Common directory. 3. changed some test programs (see CHANGES DETAIL): 4. deleted all space and origin related functions from itkImportImageFilter (in Insight/Code/BasicFilters/) class, and created itkImportPhysicalImageFilter with the space and origin related functions. (I just read through the original class and deleted those functions. So you might get some run-time error. IF YOU KNOW POSSIBLE RUNTIME ERRORS WITH THIS MODIFICATIONS, please let me know.) 5. changed the internal image type definition in the ImageMomentsCalculator class from Image to PhysicalImage. (It seems that the origin and spacing are integral parts of the class. So, it would be nice to change the name of the class to PhysicalImageMomentsCalculator. I will ask the person who is in charge of maintaing CVS repository to rename the class and make appropriate changes.) POSSIBLE PROBLEMS & SUGGESTIONS 1. Compile error in your own code (error messages complain about [Set|Get][Origin|Spacing] functions) -> It might be caused by using [Set|Get][Origin|Spacing]() functions of Image class. Use PhysicalImage class instead of Image class. same for ImageAdaptor class. 2. Compile time error in Insight toolkit (error messages complain about [Set|Get][Origin|Spacing] functions) ->It might be caused by using ImportImageFilter with Origin or Spacing stuff. Use ImportPhysicalImageFilter or class with PhysicalImage class. 3. Runtime error with ImportImageFilter class ->As I mentioned in SUMMARY #4, it might be causes by the modification in both classes. please email me. CHANGES DETAIL * replaced Image class with PhysicalImage class o Insight/Testing/Code/Common/itkAffineTransform.cxx o Insight/Testing/Code/Common/itkImageIteratorTest.cxx o Insight/Testing/Code/Common/itkIteratorTests.cxx o Insight/Testing/Code/Common/itkPixelAcessTest.cxx o Insight/Testing/Code/Common/itkBasicArchitectureTest.cxx o Insight/Testing/Code/BasicFilters/itkCyclicReference.cxx o Insight/Testing/Code/BasicFilters/itkShrinkImageTest.cxx o Insight/Testing/Code/BasicFilters/itkThresholdImageFilterTest.cxx o Insight/Testing/Code/Algorithms/itkCurvatureFlowTest.cxx o Insight/Testing/Code/Algorithms/itkInterpolateTest.cxx o Insight/Testing/Code/Algorithms/itkPrincipalAxesResampler.cxx o Insight/Testing/Code/Algorithms/itkImageMomentsTest.cxx * also replaced ImageAdaptor class with PhysicalImageAdaptor class o Insight/Testing/Code/BasicFilters/itkImageAdaptorPipelineTest.cxx * special cases (see summary #4) o Insight/Testing/Code/BasicFilters/itkImportImageTest.cxx - replaced Image class with PhysicalImage and ImportImageFilter Thank you, ===== Jisung Kim bahrahm@yahoo.com 106 Mason Farm Rd. 129 Radiology Research Lab., CB# 7515 Univ. of North Carolina at Chapel Hill Chapel Hill, NC 27599-7515 __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From cates@cayenne.cs.utah.edu Tue, 6 Mar 2001 13:07:49 -0700 (MST) Date: Tue, 6 Mar 2001 13:07:49 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] changes to neighborhood base classes Hello, In the spirit of itk::Image, I've templated the itk::Neighborhood class over allocator type. Didn't use stl allocators but rather modeled a default allocator after vnl_vector. This means you can plug vnl_vectors into neighborhood objects (iterators, neighborhoods, neighborhood operators). Also neighborhoods now define const iterators through their data. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates From lorensen@crd.ge.com Wed, 7 Mar 2001 11:21:01 -0500 Date: Wed, 7 Mar 2001 11:21:01 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] changes to neighborhood base classes Josh, I checked in a few changes for SGI compatibility. Also, the test itkGradientAnisoptropicDiffusionTest is in BasicFilters, yet the class is in Algorithms. I removed the test from the CMakeLists.txt file for now until it is resolved. Should the class be moved to BasicFilters? Bill > -----Original Message----- > From: Joshua Cates [SMTP:cates@cayenne.cs.utah.edu] > Sent: Tuesday, March 06, 2001 3:08 PM > To: Insight-Developers > Subject: [Insight-developers] changes to neighborhood base classes > > Hello, > > In the spirit of itk::Image, I've templated the itk::Neighborhood class > over allocator type. Didn't use stl allocators but rather modeled a > default allocator after vnl_vector. This means you can plug vnl_vectors > into neighborhood objects (iterators, neighborhoods, neighborhood > operators). Also neighborhoods now define const iterators through their > data. > > > Josh. > > ______________________________ > Josh Cates > School of Computer Science > University of Utah > Email: cates@cs.utah.edu > Phone: (801) 587-7697 > URL: www.cs.utk.edu/~cates > > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers From cates@cayenne.cs.utah.edu Wed, 7 Mar 2001 10:46:39 -0700 (MST) Date: Wed, 7 Mar 2001 10:46:39 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] changes to neighborhood base classes Hi Bill, Thanks. I'm working on cleaning up some of the new warnings now. Yes, the itkGradientAnisotropicDiffusionImageFilter.h/.txx should be in BasicFilters. I'll go ahead and move it. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates On Wed, 7 Mar 2001, Lorensen, William E (CRD) wrote: > Josh, > I checked in a few changes for SGI compatibility. > > Also, the test itkGradientAnisoptropicDiffusionTest is in BasicFilters, yet the class is in > Algorithms. > I removed the test from the CMakeLists.txt file for now until it is resolved. Should the class be > moved to BasicFilters? > > Bill > > > > -----Original Message----- > > From: Joshua Cates [SMTP:cates@cayenne.cs.utah.edu] > > Sent: Tuesday, March 06, 2001 3:08 PM > > To: Insight-Developers > > Subject: [Insight-developers] changes to neighborhood base classes > > > > Hello, > > > > In the spirit of itk::Image, I've templated the itk::Neighborhood class > > over allocator type. Didn't use stl allocators but rather modeled a > > default allocator after vnl_vector. This means you can plug vnl_vectors > > into neighborhood objects (iterators, neighborhoods, neighborhood > > operators). Also neighborhoods now define const iterators through their > > data. > > > > > > Josh. > > > > ______________________________ > > Josh Cates > > School of Computer Science > > University of Utah > > Email: cates@cs.utah.edu > > Phone: (801) 587-7697 > > URL: www.cs.utk.edu/~cates > > > > > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From brad.king@kitware.com Wed, 7 Mar 2001 14:37:42 -0500 (EST) Date: Wed, 7 Mar 2001 14:37:42 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] itkTypeMacro Hello all, I have noticed warnings about classes with virtual functions but no virtual destructor. The problem comes from the use of itkTypeMacro in these classes. The macro is designed for use only in classes that are part of the itk::LightObject hierarchy. Classes like itk::Vector should not use the macro because they are not subclasses of the light object. If anyone has written any classes with this problem, please remove the macro from them. This will clear up several warnings from the dashboard. Thanks, -Brad From dmsst59@pitt.edu Wed, 7 Mar 2001 17:00:02 -0500 Date: Wed, 7 Mar 2001 17:00:02 -0500 From: Damion Shelton dmsst59@pitt.edu Subject: [Insight-developers] VC++ tutorial update The VC++ tutorial has been updated to reflect last week's revelations regarding multithreaded DLLs and RTTI. Let me know if any additional info needs to be added. -Damion- From ibanez@cs.unc.edu Wed, 07 Mar 2001 20:58:42 -0500 Date: Wed, 07 Mar 2001 20:58:42 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkTypeMacro Hi The itkTypeMacro was removed also from itkCovariantVector Thanks Luis -------------------------- Brad King wrote: > Hello all, > > I have noticed warnings about classes with virtual functions but no > virtual destructor. The problem comes from the use of itkTypeMacro in > these classes. The macro is designed for use only in classes that are > part of the itk::LightObject hierarchy. Classes like itk::Vector should > not use the macro because they are not subclasses of the light object. > If anyone has written any classes with this problem, please remove the > macro from them. This will clear up several warnings from the dashboard. > > Thanks, > -Brad > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers From ibanez@cs.unc.edu Wed, 07 Mar 2001 22:34:28 -0500 Date: Wed, 07 Mar 2001 22:34:28 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkIndex signed -> unsigned Hi, Recently itkIndex changed from using signed to unsigned values. That has the advantage to eliminate a lot of warnings when it is compared against image size (in most iterator loops), but has the disadvantage that negative positions can't be specified. we found that for the Danielsson distance map filter a signed index was quite useful. Should we create another class to express vector distances between indices ? (the equivalent of what the vector class is for the point class). Thanks Luis From millerjv@crd.ge.com Thu, 8 Mar 2001 08:30:47 -0500 Date: Thu, 8 Mar 2001 08:30:47 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] itkIndex signed -> unsigned I think we had discussed having a class "itkOffset" that could represent the difference between two itkIndex's. Anyone else have a suggestion for a name? -----Original Message----- From: Luis Ibanez [mailto:ibanez@cs.unc.edu] Sent: Wednesday, March 07, 2001 10:34 PM To: insight-developers@public.kitware.com Subject: [Insight-developers] itkIndex signed -> unsigned Hi, Recently itkIndex changed from using signed to unsigned values. That has the advantage to eliminate a lot of warnings when it is compared against image size (in most iterator loops), but has the disadvantage that negative positions can't be specified. we found that for the Danielsson distance map filter a signed index was quite useful. Should we create another class to express vector distances between indices ? (the equivalent of what the vector class is for the point class). Thanks Luis _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From aylward@unc.edu Thu, 08 Mar 2001 12:12:26 -0500 Date: Thu, 08 Mar 2001 12:12:26 -0500 From: Stephen R. Aylward aylward@unc.edu Subject: [Insight-developers] itkIndex signed -> unsigned Hi, I thought we had decided it would be best to keep itkIndex signed so that we could check for <0 for termination of certain methods and so that we can check offsets via subtraction and <0. Stephen Luis Ibanez wrote: > > Hi, > > Recently itkIndex changed from using signed to unsigned values. > That has the advantage to eliminate a lot of warnings when it is > compared against image size (in most iterator loops), > but has the disadvantage that negative positions can't be specified. > we found that for the Danielsson distance map filter a signed index > was quite useful. > > Should we create another class to express vector distances > between indices ? > (the equivalent of what the vector class is for the point class). > > Thanks > > Luis > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From cates@cayenne.cs.utah.edu Thu, 8 Mar 2001 11:48:07 -0700 (MST) Date: Thu, 8 Mar 2001 11:48:07 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] slice.h Hello, Where does slice.h reside on windows machines with VC++? I need a cross-platform way to #include "std/slice.h" (see todays dashboard under Win-NT-4.0-VC++) Thanks, Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates From cates@cayenne.cs.utah.edu Thu, 8 Mar 2001 12:04:43 -0700 (MST) Date: Thu, 8 Mar 2001 12:04:43 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] itkIndex signed -> unsigned Hi, I agree that we should keep itkIndex signed, for the reasons Stephen has mentioned. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates On Thu, 8 Mar 2001, Stephen R. Aylward wrote: > Hi, > > I thought we had decided it would be best to keep itkIndex signed so > that we could check for <0 for termination of certain methods and so > that we can check offsets via subtraction and <0. > > Stephen > > Luis Ibanez wrote: > > > > Hi, > > > > Recently itkIndex changed from using signed to unsigned values. > > That has the advantage to eliminate a lot of warnings when it is > > compared against image size (in most iterator loops), > > but has the disadvantage that negative positions can't be specified. > > we found that for the Danielsson distance map filter a signed index > > was quite useful. > > > > Should we create another class to express vector distances > > between indices ? > > (the equivalent of what the vector class is for the point class). > > > > Thanks > > > > Luis > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > -- > =============================================== > Stephen R. Aylward > Assistant Professor of Radiology > Adjunct Assistant Professor of Computer Science > http://www.cs.unc.edu/~aylward > aylward@unc.edu > (919) 966-9695 > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From bill.hoffman@kitware.com Thu, 08 Mar 2001 13:29:54 -0500 Date: Thu, 08 Mar 2001 13:29:54 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] slice.h What is slice.h??? At 11:48 AM 3/8/2001 -0700, Joshua Cates wrote: >Hello, > >Where does slice.h reside on windows machines with VC++? I need a >cross-platform way to #include "std/slice.h" (see todays dashboard under >Win-NT-4.0-VC++) > >Thanks, > >Josh. > >______________________________ > Josh Cates > School of Computer Science > University of Utah > Email: cates@cs.utah.edu > Phone: (801) 587-7697 > URL: www.cs.utk.edu/~cates > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From brad.king@kitware.com Thu, 8 Mar 2001 13:47:27 -0500 (EST) Date: Thu, 8 Mar 2001 13:47:27 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] slice.h According to the C++ standard, the "slice" class is defined by #include I don't know for sure if this works on all platforms, though. -Brad At 11:48 AM 3/8/2001 -0700, Joshua Cates wrote: >Hello, > >Where does slice.h reside on windows machines with VC++? I need a >cross-platform way to #include "std/slice.h" (see todays dashboard under >Win-NT-4.0-VC++) > >Thanks, > >Josh. From cates@cayenne.cs.utah.edu Thu, 8 Mar 2001 13:30:54 -0700 (MST) Date: Thu, 8 Mar 2001 13:30:54 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] slice.h Hi, Sounds like I should just #include then to conform to the standard. This has worked to define std::slice on VC++ in the past. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates On Thu, 8 Mar 2001, Brad King wrote: > According to the C++ standard, the "slice" class is defined by > #include > > I don't know for sure if this works on all platforms, though. > -Brad > > At 11:48 AM 3/8/2001 -0700, Joshua Cates wrote: > >Hello, > > > >Where does slice.h reside on windows machines with VC++? I need a > >cross-platform way to #include "std/slice.h" (see todays dashboard under > >Win-NT-4.0-VC++) > > > >Thanks, > > > >Josh. > > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From wlorens1@nycap.rr.com Thu, 08 Mar 2001 17:21:03 -0500 Date: Thu, 08 Mar 2001 17:21:03 -0500 From: Bill Lorensen wlorens1@nycap.rr.com Subject: [Insight-developers] slice.h I had already checked in that change. We had an update problem last evening on VC++. Bill At 01:30 PM 3/8/01 -0700, Joshua Cates wrote: >Hi, > >Sounds like I should just #include then to conform to the >standard. This has worked to define std::slice on VC++ in the past. > >Josh. >______________________________ > Josh Cates > School of Computer Science > University of Utah > Email: cates@cs.utah.edu > Phone: (801) 587-7697 > URL: www.cs.utk.edu/~cates > > >On Thu, 8 Mar 2001, Brad King wrote: > > > According to the C++ standard, the "slice" class is defined by > > #include > > > > I don't know for sure if this works on all platforms, though. > > -Brad > > > > At 11:48 AM 3/8/2001 -0700, Joshua Cates wrote: > > >Hello, > > > > > >Where does slice.h reside on windows machines with VC++? I need a > > >cross-platform way to #include "std/slice.h" (see todays dashboard under > > >Win-NT-4.0-VC++) > > > > > >Thanks, > > > > > >Josh. > > > > > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From lorensen@crd.ge.com Fri, 9 Mar 2001 09:00:08 -0500 Date: Fri, 9 Mar 2001 09:00:08 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] Registration Patterns Folks, Marc Levoy has published a paper that analyzes the ICP registration algorithm. He has borken it down nicely and examined variations of each step in the process. This may be of interest to us as to the approach he has taken. His analysis can map nicely into an OO framework. Somwething similar may be appropriate for Insight's registration framework. Bill http://graphics.stanford.edu/papers/fasticp/ From ibanez@cs.unc.edu Fri, 09 Mar 2001 10:34:15 -0500 Date: Fri, 09 Mar 2001 10:34:15 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Registration Patterns It is certainly a good breakdown of the ICP algorithm, seems that we should be able implement it as a specialized version of the registration framework in Insight. Thanks, Luis "Lorensen, William E (CRD)" wrote: > Folks, > > Marc Levoy has published a paper that analyzes the ICP registration algorithm. He has borken it down > nicely and examined variations of each step in the process. > > This may be of interest to us as to the approach he has taken. His analysis can map nicely into an OO > framework. Somwething similar may be appropriate for Insight's registration framework. > > Bill > > http://graphics.stanford.edu/papers/fasticp/ > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- ______________________________________________________________________ Luis Ibanez Research Assistant Professor - Division of Neurosurgery University of North Carolina at Chapel Hill CB# 7060, Chapel Hill, NC 27599 email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez phone : (919)-843-9961 fax : (919)-966-6627 ______________________________________________________________________ From gee@GRASP.cis.upenn.edu Fri, 9 Mar 2001 10:55:37 -0500 Date: Fri, 9 Mar 2001 10:55:37 -0500 From: James Gee gee@GRASP.cis.upenn.edu Subject: [Insight-developers] Registration Patterns i agree with luis. it's very nice but specialized enough that i don't see it replacing the general framework that the group has already put together. > > It is certainly a good breakdown of the ICP algorithm, > seems that we should be able implement it as a specialized > version of the registration framework in Insight. > > Thanks, > > Luis > > > > "Lorensen, William E (CRD)" wrote: > > > Folks, > > > > Marc Levoy has published a paper that analyzes the ICP registration algorithm. He has borken it down > > nicely and examined variations of each step in the process. > > > > This may be of interest to us as to the approach he has taken. His analysis can map nicely into an OO > > framework. Somwething similar may be appropriate for Insight's registration framework. > > > > Bill > > > > http://graphics.stanford.edu/papers/fasticp/ > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > -- > ______________________________________________________________________ > > Luis Ibanez > Research Assistant Professor - Division of Neurosurgery > University of North Carolina at Chapel Hill > CB# 7060, Chapel Hill, NC 27599 > email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez > phone : (919)-843-9961 fax : (919)-966-6627 > ______________________________________________________________________ > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From vikram@insightful.com Fri, 9 Mar 2001 15:08:58 -0500 Date: Fri, 9 Mar 2001 15:08:58 -0500 From: vikram@insightful.com vikram@insightful.com Subject: [Insight-developers] Re: Testing/2 Synopsis: Need a hook from the dashboard to the bug tracker Responsible-Changed-From-To: bill->lorensen Responsible-Changed-By: vikram Responsible-Changed-When: Fri Mar 9 15:08:53 2001 Responsible-Changed-Why: Bill is responsible for this now. http://public.kitware.com/cgi-bin/gnatsweb.pl?cmd=view&pr=2&database=insight From millerjv@crd.ge.com Fri, 9 Mar 2001 16:17:43 -0500 Date: Fri, 9 Mar 2001 16:17:43 -0500 From: millerjv@crd.ge.com millerjv@crd.ge.com Subject: [Insight-developers] Re: Testing/2 Synopsis: Need a hook from the dashboard to the bug tracker Responsible-Changed-From-To: lorensen->blezek Responsible-Changed-By: millerjv Responsible-Changed-When: Fri Mar 9 16:17:42 2001 Responsible-Changed-Why: Dan writes all the dashboard XSLT. http://public.kitware.com/cgi-bin/gnatsweb.pl?cmd=view&pr=2&database=insight From vikram@insightful.com Fri, 9 Mar 2001 14:39:58 -0800 (PST) Date: Fri, 9 Mar 2001 14:39:58 -0800 (PST) From: Vikram Chalana x314 vikram@insightful.com Subject: [Insight-developers] gnats ready to go GNATS has been setup and is now ready to be used for filing ITK bugs. All the people listed in UserList.txt have access to the gnats database at: http://public.kitware.com/cgi-bin/gnatsweb.pl Use your email address (as listed in UserList.txt) as your password. Four categories of bugs are currently defined (new categories can be easily added as we move forward): Build Documentation Source Testing Everyone on this email list is set to get a notification whenever a bug is added or its status is changed. Again the notification list can be changed as needed. As the BUG-CZAR, I will be monitoring and cleaning the bug list periodically. Thanks, Vikram From ibanez@cs.unc.edu Sat, 10 Mar 2001 11:22:27 -0500 Date: Sat, 10 Mar 2001 11:22:27 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Problems with CMake Hi, I just updated from the repository and when I run CMake it is reporting errors. a small window pops up with the message CMake error: and the OK button. It appears several times. Any ideas ? Thanks Luis From wlorens1@nycap.rr.com Sat, 10 Mar 2001 11:27:37 -0500 Date: Sat, 10 Mar 2001 11:27:37 -0500 From: Bill Lorensen wlorens1@nycap.rr.com Subject: [Insight-developers] Problems with CMake Luis, You may need to run CMakeSetup At 11:22 AM 3/10/01 -0500, Luis Ibanez wrote: >Hi, > >I just updated from the repository >and when I run CMake it is reporting errors. >a small window pops up with the message > >CMake >error: > >and the OK button. > >It appears several times. > >Any ideas ? > >Thanks > >Luis > > > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From ibanez@cs.unc.edu Sat, 10 Mar 2001 11:52:36 -0500 Date: Sat, 10 Mar 2001 11:52:36 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Problems with CMake Sorry, I forgot to tell that this is happening on WinNT, I run the executable in the CMakeSetup project, but it still doing the same. It is unfortunate that the message is not very informative... Parsing the repository I saw that CMakeList.txt files should have an ending new line, could that be related ? Should I make a clean checkout ? Thanks Luis ------- Bill Lorensen wrote: > Luis, > You may need to run CMakeSetup > > At 11:22 AM 3/10/01 -0500, Luis Ibanez wrote: > >Hi, > > > >I just updated from the repository > >and when I run CMake it is reporting errors. > >a small window pops up with the message > > > >CMake > >error: > > > >and the OK button. > > > >It appears several times. > > > >Any ideas ? > > > >Thanks > > > >Luis > > > > > > > > > > > >_______________________________________________ > >Insight-developers mailing list > >Insight-developers@public.kitware.com > >http://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- ______________________________________________________________________ Luis Ibanez Research Assistant Professor - Division of Neurosurgery University of North Carolina at Chapel Hill CB# 7060, Chapel Hill, NC 27599 email : ibanez@cs.unc.edu home : http://www.cs.unc.edu/~ibanez phone : (919)-843-9961 fax : (919)-966-6627 ______________________________________________________________________ From ibanez@cs.unc.edu Sat, 10 Mar 2001 11:58:38 -0500 Date: Sat, 10 Mar 2001 11:58:38 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkIndex initialization Hi, I just noticed that itkIndex has a static variable initialized to zero. So, Instead of writting itk::Index<3> start; start[0] = 0; start[1] = 0; start[2] = 0; itk::Region<3> region; region.SetIndex( start ); we can write: itk::Region<3> region; region.SetIndex( itk::Index<3>::ZeroIndex ); That reduces a little the protocol for initializing images. Luis From bill.hoffman@kitware.com Sat, 10 Mar 2001 12:20:10 -0500 Date: Sat, 10 Mar 2001 12:20:10 -0500 From: William A. Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] Problems with CMake That is a useful error isn't it? The problem is caused because you need to do a cvs update -d, Brad has added several new directories, and for some reason the new CMake commands write out some empty error messages. -Bill At 11:22 AM 3/10/01 -0500, Luis Ibanez wrote: >Hi, > >I just updated from the repository >and when I run CMake it is reporting errors. >a small window pops up with the message > >CMake >error: > >and the OK button. > >It appears several times. > >Any ideas ? > >Thanks > >Luis > > > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From chenting@graphics.cis.upenn.edu Sat, 10 Mar 2001 17:00:43 -0600 Date: Sat, 10 Mar 2001 17:00:43 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] about testing Hi! I checked in 2 test program, itkDeformableTest and itkGibbsTest. Both of them are running ok on my system (NT4.0 VC++6.0), my pal at Columbia also checked out from the CVS server and the program runs well there, too. however, on the dashboard, the status of my program is still not run, can guys from kitware or GE check out what is run there for me? ( for itkGibbsTest, the problem is that I used a local file, but there is no reason for itkDeformableTest ) Thanks a lot! ting From bill.hoffman@kitware.com Sat, 10 Mar 2001 17:56:50 -0500 Date: Sat, 10 Mar 2001 17:56:50 -0500 From: William A. Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] about testing Your programs have a getchar() call in them. While this is fine for interactive testing, there is no there to press a key at night! At 05:00 PM 3/10/01 -0600, Ting Chen wrote: >Hi! I checked in 2 test program, itkDeformableTest and itkGibbsTest. Both of >them are running ok on my system (NT4.0 VC++6.0), my pal at Columbia also >checked out from the CVS server and the program runs well there, too. >however, on the dashboard, the status of my program is still not run, can >guys from kitware or GE check out what is run there for me? ( for >itkGibbsTest, the problem is that I used a local file, but there is no >reason for itkDeformableTest ) >Thanks a lot! >ting > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From brad.king@kitware.com Mon, 12 Mar 2001 09:41:55 -0500 (EST) Date: Mon, 12 Mar 2001 09:41:55 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Problems with CMake Luis, The problem is not immediately obvious from my new commands. I have added code to cmCommand that should produce a more descriptive error message in the case of an empty message from a GetError() call. If you can still duplicate the problem, do a cvs update and try it again. Thanks, -Brad On Sat, 10 Mar 2001, William A. Hoffman wrote: > That is a useful error isn't it? The problem is caused because you need > to do a cvs update -d, Brad has added several new directories, and for some > reason the new CMake commands write out some empty error messages. > > -Bill > > > At 11:22 AM 3/10/01 -0500, Luis Ibanez wrote: > >Hi, > > > >I just updated from the repository > >and when I run CMake it is reporting errors. > >a small window pops up with the message > > > >CMake > >error: > > > >and the OK button. > > > >It appears several times. > > > >Any ideas ? > > > >Thanks > > > >Luis From ibanez@cs.unc.edu Mon, 12 Mar 2001 12:08:05 -0500 (EST) Date: Mon, 12 Mar 2001 12:08:05 -0500 (EST) From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Problems with CMake Hi, I did an update with -d option as Bill suggested, and it is working fine right now. Now, I put that on the .cvsrc file, as default options: "update -d -P" Thanks, Luis --------------------- On Mon, 12 Mar 2001, Brad King wrote: > Luis, > > The problem is not immediately obvious from my new commands. I have added > code to cmCommand that should produce a more descriptive error message in > the case of an empty message from a GetError() call. If you can still > duplicate the problem, do a cvs update and try it again. > > Thanks, > -Brad > > On Sat, 10 Mar 2001, William A. Hoffman wrote: > > > That is a useful error isn't it? The problem is caused because you need > > to do a cvs update -d, Brad has added several new directories, and for some > > reason the new CMake commands write out some empty error messages. > > > > -Bill > > > > > > At 11:22 AM 3/10/01 -0500, Luis Ibanez wrote: > > >Hi, > > > > > >I just updated from the repository > > >and when I run CMake it is reporting errors. > > >a small window pops up with the message > > > > > >CMake > > >error: > > > > > >and the OK button. > > > > > >It appears several times. > > > > > >Any ideas ? > > > > > >Thanks > > > > > >Luis > > From vikram@insightful.com Mon, 12 Mar 2001 19:04:34 -0500 Date: Mon, 12 Mar 2001 19:04:34 -0500 From: vikram@insightful.com vikram@insightful.com Subject: [Insight-developers] Re: Documentation/8 Synopsis: style guide needs to become a real document State-Changed-From-To: open->closed State-Changed-By: vikram State-Changed-When: Mon Mar 12 19:04:34 2001 State-Changed-Why: duplicated. http://public.kitware.com/cgi-bin/gnatsweb.pl?cmd=view&pr=8&database=insight From millerjv@crd.ge.com Tue, 13 Mar 2001 09:16:29 -0500 Date: Tue, 13 Mar 2001 09:16:29 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Preparation for internal alpha In preparation for the internal alpha of insight, I propose that we compose a list of capabilities that will be ready for inclusion in the toolkit by March 31, 2001. There is a lot of collaboration work between various contractors, but some people are waiting for some of the higher level frameworks (registration, level sets, region growing) to be completed prior to converting some of their existing (insight) implementations to the new frameworks. What I'd like to see is a list of dates for when people think these various frameworks may be available. Since this first alpha is an "internal" alpha, it is really meant to timestamp the repository and bring independent development paths back together. I think it is reasonable to strive to have the APIs for these frameworks in place for the internal alpha but not have converted everything over to the new API. Development will continue furiously through the June public alpha (at which time most of the existing techniques should be converted to the new frameworks). I have added an html file to the cvs repository to collect these schedules (HTMLPrivate/InternalAlphaSchedule.html), please edit it and place in your timelines. You can add a row to the table for each capability/algorithm you'll be providing. (I just put in one item to start with). There is a link from the main Insight page to the schedule at http://public.kitware.com/Insight/HTMLPrivate/InternalAlphaSchedule.html I believe that we decided in Utah not to use GNATS for project management, but rather limit GNATS use to actual bugs. However, maintaining this HTML file for schedules and todo items is going to get rather cumbersome. Does anyone know of any "free" web based todo list managers? SourceForge.net would be nice but I don't think we are ready to publicize our project yet. Of course, we also need to drive down all the compiler errors and warnings prior to the internal alpha release! Jim Miller _____________________________________ Computer Graphics & Systems Program GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 <> begin 600 James Miller (E-mail).vcf M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..DUI;&QE7-T96US(%!R;V=R86T[0DQ$1R!+5RP@4DT@0S(Q.$(] M,$0],$%03R!";W@@.#M38VAE;F5C/0T*=&%D>3M.63LQ,C,P,3M5;FET960@ M4W1A=&5S(&]F($%M97)I8V$-"DQ!0D5,.U=/4DL[14Y#3T1)3D<]455/5$5$ M+5!224Y404),13I#;VUP=71E2P@3ED@,3(S,#$],$0],$%5;FET960@4W1A=&5S(&]F M($%M97)I8V$-"D5-04E,.U!2148[24Y415).150Z;6EL;&5R:G9`8W)D+F=E G+F-O;0T*4D56.C(P,#`P,3(X5#$V,C8U-EH-"D5.1#I60T%21`T* ` end From hughett@mercur.uphs.upenn.edu Tue, 13 Mar 2001 10:48:11 -0500 Date: Tue, 13 Mar 2001 10:48:11 -0500 From: Paul Hughett hughett@mercur.uphs.upenn.edu Subject: [Insight-developers] Build broken on Linux 6.2 I just updated to the latest ITK version from the repository, and did "configure", "make clean", and "make". I got the following fatal error message almost immediately: make[3]: Leaving directory `/home/hughett/work/Insight/Utilities/Cable' cd Cable; make -w all make[3]: Entering directory `/home/hughett/work/Insight/Utilities/Cable' make[3]: *** No rule to make target `sourceParser.o', needed by `generateWrappers'. Stop. Paul Hughett From brad.king@kitware.com Tue, 13 Mar 2001 13:48:10 -0500 (EST) Date: Tue, 13 Mar 2001 13:48:10 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Build broken on Linux 6.2 > I just updated to the latest ITK version from the repository, and did > "configure", "make clean", and "make". I got the following fatal error > message almost immediately: > > make[3]: Leaving directory `/home/hughett/work/Insight/Utilities/Cable' > cd Cable; make -w all > make[3]: Entering directory `/home/hughett/work/Insight/Utilities/Cable' > make[3]: *** No rule to make target `sourceParser.o', needed by `generateWrappers'. Stop. Did you do a "cvs update -d"? -Brad From hughett@mercur.uphs.upenn.edu Tue, 13 Mar 2001 13:50:26 -0500 Date: Tue, 13 Mar 2001 13:50:26 -0500 From: Paul Hughett hughett@mercur.uphs.upenn.edu Subject: [Insight-developers] Build broken on Linux 6.2 > Did you do a "cvs update -d"? Yes. And I just did it once again just to make sure that I wan't misremembering it. Same problem. Paul Hugehtt From brad.king@kitware.com Tue, 13 Mar 2001 14:14:51 -0500 (EST) Date: Tue, 13 Mar 2001 14:14:51 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Build broken on Linux 6.2 > I just updated to the latest ITK version from the repository, and did > "configure", "make clean", and "make". I got the following fatal error > message almost immediately: > > make[3]: Leaving directory `/home/hughett/work/Insight/Utilities/Cable' > cd Cable; make -w all > make[3]: Entering directory `/home/hughett/work/Insight/Utilities/Cable' > make[3]: *** No rule to make target `sourceParser.o', needed by `generateWrappers'. Stop. The problem should be fixed now. There was a stray makefile left in the repository from my original development version of Cable before it was integrated in to the Insight/Utilities directory and built with CMake. It was confusing the in-place build process. -Brad From hughett@mercur.uphs.upenn.edu Tue, 13 Mar 2001 14:16:32 -0500 Date: Tue, 13 Mar 2001 14:16:32 -0500 From: Paul Hughett hughett@mercur.uphs.upenn.edu Subject: [Insight-developers] Build broken on Linux 6.2 > The problem should be fixed now. There was a stray makefile left in the > repository from my original development version of Cable before it was > integrated in to the Insight/Utilities directory and built with CMake. > It was confusing the in-place build process. Yup, that fixed it. Thanks. Paul Hughett From brad.king@kitware.com Tue, 13 Mar 2001 14:25:57 -0500 (EST) Date: Tue, 13 Mar 2001 14:25:57 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] itk::Mesh and Cell template parameters Hello, all: Those of you working on development related to the Mesh class and its Cells should note that I have renamed some template parameters. The second template parameter of the Mesh and Cell classes were called "MeshType" and "CellType", but the classes that are passed to them are simply full of typedefs and enums. They play the role of "trait" classes, so I have renamed the template parameters to "MeshTraits" and "CellTraits". The default trait classes "itk::DefaultStaticMeshType" and "itk::DefaultDynamicMeshType" have been renamed accordingly. If anyone has any code that used the old names (that isn't checked in), you will have to update it to work with the new names. Also, anyone who has created additional trait classes should rename them accordingly as well (MyMeshType -> MyMeshTraits). -Brad From ibanez@cs.unc.edu Tue, 13 Mar 2001 14:52:28 -0500 Date: Tue, 13 Mar 2001 14:52:28 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] gdb with Cygwin Hi, I recently downloaded Cygwin, and there are a lot of improvements in the current version. The set of tools is now extended at the point that you really feel like in Linux. One of the nicest things, is the version of gdb, it has a graphic interface and a very intuitive access to breakpoints, stack, registers, mix of source and assembler code, and view of data. Luis From brad.king@kitware.com Tue, 13 Mar 2001 15:30:10 -0500 (EST) Date: Tue, 13 Mar 2001 15:30:10 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Coding style, MSVC INTERNAL COMPILER ERRORs, and enums Hello, all: I just tracked down another ICE by MSVC related to the bug in it that I previously reported to the list. The fix has been checked in, but we can avoid the issue altogether with a little care in the style of our code. Here is a typical example that causes the problem: template class MyClass { void MyMethod(typename TInputImage::PixelType pixel); }; //...and through some chain of includes when MyClass is used... template < unsigned int VDimension > // MSVC fails here with an ICE class SomeOtherClass { /*...*/ }; The only explanation for this problem is a bug in MSVC's compiler. The solution is simple, and should be used anyway just for readability. Any type that is qualified inside another type, namespace, or is a typename type should not be directly used as a method argument. Instead, typedef the type and use the new name as the argument. Here is the example above with this change: template class MyClass { typedef typename TInputImage::PixelType InputPixelType; void MyMethod(InputPixelType pixel); }; // MSVC will no longer ICE on a "template " block. It would be good if everyone could use this style, both for the ICE problem, and for readability. The same thing should be done with enum values as well (like ImageDimension). In fact, it is necessary to do this with enums since the compiler does not get the "typename" hint for an enum value. Earlier today I spent an hour tracking down such an enum problem in itk::DanielssonDistanceMapImageFilter. Here is a simplified example of the problem: template struct X {}; template struct A { void Method(X); }; template void A::Method(X) {} GCC gives the following errors while parsing this code: prototype for `void A::Method(X)' does not match any in class `A' candidate is: void A::Method(X) In method `void A::Method(X)': template definition of non-template `void A::Method(X)' Note that the candidate it gives consists of the EXACT SAME text as the prototype that the candidate does not match! The solution to this problem is to make sure the compiler knows that the value is an enum. template struct X {}; template struct A { enum { EnumValue = T::EnumValue }; void Method(X); }; template void A::Method(X) {} This is actually a C++ issue not related to GCC or any other compiler (I don't have a quote from the C++ standard this time, though). Again, it can be fixed with good style in our code. -Brad From brad.king@kitware.com Tue, 13 Mar 2001 16:58:44 -0500 (EST) Date: Tue, 13 Mar 2001 16:58:44 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] typename platform conflict Hello, all: Well, at long last we have encountered a situation in which the intersection of the capabilities of all our compilers is the empty set. We will have to use a macro to resolve this one. The problem occurs when a typename type is used in a default template argument: typename class X {}; SGI's MIPSpro will not accept this code without the typename keyword. MSVC will not accept this code unless the typename keyword is missing. I have added a macro definition to itkWin32Header.h: #define TYPENAME typename in the case of MSVC, the macro will be defined as #define TYPENAME The new code for the above example is typename class X {}; This macro should ONLY be used for default template arguments. It should NEVER be used in place of plain old "typename" in other situations. If anyone has another problem for which you think you need the TYPENAME macro, post it to this list first for discussion. Also, now would be a good time to discuss the name of this macro. TYPENAME is minimally disruptive to reading the code, but may mislead people into using it when it should not be used (not to mention name conflicts with other libraries). We might want to consider ITK_DEFAULT_ARGUMENT_TYPENAME instead. Anyone have thoughts on this? -Brad From millerjv@crd.ge.com Tue, 13 Mar 2001 17:53:24 -0500 Date: Tue, 13 Mar 2001 17:53:24 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] typename platform conflict Can we solve this by inserting a dummy class, so the code would look like template class DummyTrait { typedef T::SomeType SomeType; } typename::SomeType> class X{} instead of using a macro. (Can you tell I hate macros....) -----Original Message----- From: Brad King [mailto:brad.king@kitware.com] Sent: Tuesday, March 13, 2001 4:59 PM To: Insight Developers Subject: [Insight-developers] typename platform conflict Hello, all: Well, at long last we have encountered a situation in which the intersection of the capabilities of all our compilers is the empty set. We will have to use a macro to resolve this one. The problem occurs when a typename type is used in a default template argument: typename class X {}; SGI's MIPSpro will not accept this code without the typename keyword. MSVC will not accept this code unless the typename keyword is missing. I have added a macro definition to itkWin32Header.h: #define TYPENAME typename in the case of MSVC, the macro will be defined as #define TYPENAME The new code for the above example is typename class X {}; This macro should ONLY be used for default template arguments. It should NEVER be used in place of plain old "typename" in other situations. If anyone has another problem for which you think you need the TYPENAME macro, post it to this list first for discussion. Also, now would be a good time to discuss the name of this macro. TYPENAME is minimally disruptive to reading the code, but may mislead people into using it when it should not be used (not to mention name conflicts with other libraries). We might want to consider ITK_DEFAULT_ARGUMENT_TYPENAME instead. Anyone have thoughts on this? -Brad _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From brad.king@kitware.com Tue, 13 Mar 2001 18:10:26 -0500 (EST) Date: Tue, 13 Mar 2001 18:10:26 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] typename platform conflict Jim, > Can we solve this by inserting a dummy class, so the code would look like > > template > class DummyTrait > { > typedef T::SomeType SomeType; > } > > typename::SomeType> > class X{} > > instead of using a macro. (Can you tell I hate macros....) Sorry, but no. This goes back to the reason the typename keyword exists in the first place: template struct DummyTrait { typedef T::SomeType SomeType; }; template ::SomeType> class X {}; // ..... template <> struct DummyTrait { enum { SomeType = 1 }; }; // ..... template class X; // uh-oh! Obviously we wouldn't ever write the specialization of DummyTrait, but the compiler doesn't know if we might do this or not when it parses DummyTrait::SomeType. The typename keyword exists to enforce that SomeType will be a type. I'm quite confident that the macro is the only solution, but at least it is a somewhat clean macro. If you want to see nasty macro usage, look at BOOST classes. They have code that looks something like: template class X {}; so that they can remove the use of default arguments on compilers that don't support them as well as adjust the use of the typename keyword. -Brad From chenting@graphics.cis.upenn.edu Tue, 13 Mar 2001 18:15:02 -0600 Date: Tue, 13 Mar 2001 18:15:02 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] itk::Mesh and Cell template parameters Hi! Brad, although you must have plenty of reasons to make this kind of modification, I still doubt is it ok to change the structure name this often, especially when the modifications make not too much sense. ting -----Original Message----- From: Brad King To: Insight Developers Date: Tuesday, March 13, 2001 1:23 PM Subject: [Insight-developers] itk::Mesh and Cell template parameters >Hello, all: > >Those of you working on development related to the Mesh class and its >Cells should note that I have renamed some template parameters. The >second template parameter of the Mesh and Cell classes were called >"MeshType" and "CellType", but the classes that are passed to them are >simply full of typedefs and enums. They play the role of "trait" classes, >so I have renamed the template parameters to "MeshTraits" and >"CellTraits". The default trait classes "itk::DefaultStaticMeshType" and >"itk::DefaultDynamicMeshType" have been renamed accordingly. > >If anyone has any code that used the old names (that isn't checked in), >you will have to update it to work with the new names. Also, anyone who >has created additional trait classes should rename them accordingly as >well (MyMeshType -> MyMeshTraits). > >-Brad > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From brad.king@kitware.com Wed, 14 Mar 2001 10:27:53 -0500 (EST) Date: Wed, 14 Mar 2001 10:27:53 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] itk::Mesh and Cell template parameters Ting, > Hi! Brad, although you must have plenty of reasons to make this kind > of modification, I still doubt is it ok to change the structure name > this often, especially when the modifications make not too much sense. I probably should have proposed the change to the list before making it. In the early development last summer, this wouldn't have mattered, but such changes affect many more people now. Sorry about that. Anyway, what doesn't make sense to you about the new name? The old one was a misnomer from the beginning. A template parameter whose only purpose is to encapsulate typedefs and other things that could be template parameters themselves is generally considered a set of "traits". -Brad From yj76@columbia.edu Wed, 14 Mar 2001 14:40:52 -0500 Date: Wed, 14 Mar 2001 14:40:52 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] Depth of nested templates As Brad told me, I have this too deep nested template problem in my code: typedef itk::Point EdgeInfo; std::vector< std::deque > rawEdges; I don't know how far I can go. the first line should be fine since it is just an instantiation of itkPoint. can we go std::vector or std::deque? any suggestion on this? the problem is I have a list of polygon (size of the list is unkown), for each polygon there will be a list of EdgeInfo (again the size of those lists are unknow). what if I know the size of the polygon list as an nonconstant varible. are we allow to do this: typedef std::deque EdgeInfoQ EdgeInfoQ *rawEdges = new EdgeInfoQ[knowSize]; I remember somebody addressed this standard C++ "new" operation issue before, forgot the details. Yinpeng From brad.king@kitware.com Wed, 14 Mar 2001 15:23:55 -0500 (EST) Date: Wed, 14 Mar 2001 15:23:55 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Depth of nested templates > As Brad told me, I have this too deep nested template problem in my code: > [.....] Just so that everyone is clear on what I mean by nested template depth, here is an example: // Recursive type definition. template struct MyStruct { typedef typename MyStruct::Type Type; }; // End the recursion at zero. template <> struct MyStruct<0> { typedef int Type; }; Now, to determine the type of "MyStruct<10>::Type", the compiler has to instantiate "MyStruct<10>", "MyStruct<9>", ..., "MyStruct<1>" in order to get to "MyStruct<0>::Type". This is a depth of 10 template instantiations. Compilers like GCC have a limit to the depth they will allow. By default it is 17 for GCC. The reason a limit is necessary is so that the compiler doesn't get into an infinity loop of instantiations by, say, trying to find the type "MyStruct<-1>::Type". On GCC, the limit can be increased with the "-f-template-depth-N" flag, where N is the depth limit. MSVC doesn't seem to have a limit, and just crashes. If you want, cut and paste the code at the bottom of this message into a new file in Visual Studio's editor, and watch what happens. Make sure everything is saved first :) What Yinpeng has encountered is code that naturally reaches the 17 instantiation limit. It gives an error on GCC unless you specify something like -f-template-depth-50 (I didn't actually find the exact number needed). We could consider requiring this flag to build Insight, but if there are other, just as clean implementations, then they should be used instead. Deep template instantiation depths are slow to build anyway. Thoughts, anyone? -Brad -------------------------- template struct MyStruct { typedef typename MyStruct::Type Type; }; MyStruct<10>::Type x; From will.schroeder@kitware.com Wed, 14 Mar 2001 15:42:18 -0500 Date: Wed, 14 Mar 2001 15:42:18 -0500 From: Will Schroeder will.schroeder@kitware.com Subject: [Insight-developers] Depth of nested templates Hi Folks- Looking at the Voronoi class, I can't help but wonder why this is not a filter? It's a subclass of Mesh?? If it is to exist in the data processing pipeline, the algorithm should be separated from its input and output...algorithm should be an eventual subclass of ProcessObject and the input and output should be subclasses of DataObject. (I'm not picking on Yinpeng, there are other classes that could be filters that are not.) I think that we are not thinking in pipeline fashion. I think that it is essential that the use and interface to classes is as uniform as possible. Will At 02:40 PM 3/14/2001 -0500, Yinpeng Jin wrote: >As Brad told me, I have this too deep nested template problem in my code: > >typedef itk::Point EdgeInfo; >std::vector< std::deque > rawEdges; > >I don't know how far I can go. the first line should be fine since it is >just an instantiation of itkPoint. >can we go std::vector or std::deque? >any suggestion on this? >the problem is I have a list of polygon (size of the list is unkown), for >each polygon there will be a list of EdgeInfo (again the size of those lists >are unknow). > >what if I know the size of the polygon list as an nonconstant varible. >are we allow to do this: > >typedef std::deque EdgeInfoQ >EdgeInfoQ *rawEdges = new EdgeInfoQ[knowSize]; > >I remember somebody addressed this standard C++ "new" operation issue >before, forgot the details. > >Yinpeng > > > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From yj76@columbia.edu Wed, 14 Mar 2001 15:57:40 -0500 Date: Wed, 14 Mar 2001 15:57:40 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] Depth of nested templates yes, I agree, it should be a MeshToMeshFilter, which take input as mesh of vertexCell and output as mesh of polygon. but this is just a part of my segmentation class, i just want to keep it as simple as possible. There is no point for me (for this particular algorithm) to save the vertex into a mesh because I will be using them intensively, and I feel it is more straighforward to just save the vertices into a vector than into a mesh of vertexCell. otherwise, in order to generate the Voronoi Diagram, I need to first generate a Mesh of vertex. Sorry that I didn't take too much into accout of the whole architecture orgnization, and quite frankly, I think our whole segmenation groups cannot take care of this issue too much, since we didn't take part into the development of the basic architecture and we are not really familar with this issue. So maybe in our future development, at least for our segmentation group, we need to write down a brief proposal about what we are going to do, and the architecture people can guide us with proper framework. thanks, Yinpeng ----- Original Message ----- From: "Will Schroeder" To: "Yinpeng Jin" ; "Insight Developers" Sent: Wednesday, March 14, 2001 3:42 PM Subject: Re: [Insight-developers] Depth of nested templates > Hi Folks- > > Looking at the Voronoi class, I can't help but wonder why this is not a filter? It's a subclass of Mesh?? If it is to exist in the data processing pipeline, the algorithm should be separated from its input and output...algorithm should be an eventual subclass of ProcessObject and the input and output should be subclasses of DataObject. (I'm not picking on Yinpeng, there are other classes that could be filters that are not.) > > I think that we are not thinking in pipeline fashion. I think that it is essential that the use and interface to classes is as uniform as possible. > > Will > > > > At 02:40 PM 3/14/2001 -0500, Yinpeng Jin wrote: > >As Brad told me, I have this too deep nested template problem in my code: > > > >typedef itk::Point EdgeInfo; > >std::vector< std::deque > rawEdges; > > > >I don't know how far I can go. the first line should be fine since it is > >just an instantiation of itkPoint. > >can we go std::vector or std::deque? > >any suggestion on this? > >the problem is I have a list of polygon (size of the list is unkown), for > >each polygon there will be a list of EdgeInfo (again the size of those lists > >are unknow). > > > >what if I know the size of the polygon list as an nonconstant varible. > >are we allow to do this: > > > >typedef std::deque EdgeInfoQ > >EdgeInfoQ *rawEdges = new EdgeInfoQ[knowSize]; > > > >I remember somebody addressed this standard C++ "new" operation issue > >before, forgot the details. > > > >Yinpeng > > > > > > > > > > > >_______________________________________________ > >Insight-developers mailing list > >Insight-developers@public.kitware.com > >http://public.kitware.com/mailman/listinfo/insight-developers > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers From will.schroeder@kitware.com Thu, 15 Mar 2001 11:36:04 -0500 Date: Thu, 15 Mar 2001 11:36:04 -0500 From: Will Schroeder will.schroeder@kitware.com Subject: [Insight-developers] (no subject) Hi Folks- In my wanderings through the dashboard and into the source code it appears that DeformableMesh needs some serious work. It was checked in about two weeks ago and the errors it is generating have yet to be addressed. The problems include: * Style - not using m_ as in m_Resolution - indentation is whacked out * Documentation - completely wrong, copied from FilterMeshToMesh (an old name anyway) * Template parameters are bad...it's only using one of the to defined in itkMesh, which of course limits the classes flexibility and usefulness * The use of pow() is causing compile errors because the types are ambiguous (i.e., an argument to the pow() may be integer...it needs to be cast to either float or double depending on the type of the first argument. Please clean it up. Thanks. Will From ibanez@cs.unc.edu Thu, 15 Mar 2001 12:37:28 -0500 Date: Thu, 15 Mar 2001 12:37:28 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Image/ImageAdaptor/DataAccessor modification Hi, Relations between ImageAdaptor, Image and DataAccessor have slightly changed. Before a DataAccessor was only a type with static methods defined in Image and ImageAdaptor. Iterators used it to convert types during pixel access. Now a member variable of DataAccessor type is declared in Image and ImageAdaptor. In this way, the Accessor can have some state information. This is used to make possible a N-th element adaptor. itkNthElementImageAdaptor itkNthElementDataAccessor Given and image whose pixels are of type container: itkVector, itkPoint, std::vector... and in general, any type that provides a operator[](unsigned int) method. The image can be adapted to make it look like a scalar image whose pixels are the n-th elements of the adapted image. The selection of the element number can be done at run time using the SelectNthElement() method in NthElementImageAdaptor. +--------------+ | | Here it looks +----+ N-th | like a scalar +---------------------------+ | element | image. Each pixel | Image, 3> |->| Image | is the n-th element +---------------------------+ | Adaptor | of the corresponding +----+ | pixel in the adapted | m_ElementNum | +--------------+ --- Pixel access is supposed to be inlined. That seems to be the case in VC++ and gcc, ...but if you notice any big change in performance on pixel access, I'll double check the iterator's Get/Set method. Thanks, Luis From yj76@columbia.edu Thu, 15 Mar 2001 13:32:34 -0500 Date: Thu, 15 Mar 2001 13:32:34 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] TCON on friday what should I do if I want to attend the tcon? just dial in that number and code? should I sign-up for something in advance? BTW, please confirm that there is one tomorrow, since some of my group may sign in and discuss our current project with the Architecture persons. thanks, yinpeng From cates@cayenne.cs.utah.edu Thu, 15 Mar 2001 16:18:15 -0700 (MST) Date: Thu, 15 Mar 2001 16:18:15 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] Image/ImageAdaptor/DataAccessor modification Hi all, Luis, I have run into a problem this week that we have been unable to resolve in supporting the image adaptors for non-scalar data types. The problem is a seemingly unavoidable penalty in working with non-scalar data. The penalty results because manipulation of non-scalar data cannot be optimized down to access by reference in many cases. In trivial cases of scalar Get and Set, the compiler should optimize Get() and Set() back down to an operator* call on the actual data pointer, resulting in data access by reference and no loss in performance. But in order to modify fields within more complex data types, you have to work with the copy of the data that Get() returns and then copy back into the memory location with Set(). (see the examples below) I wrote a simple test program (shown below) which gave the following typical results: (1) gcc version 2.95.1 -O2 (Linux) Speed of adaptor supporting interator (for reference) 80000 Speed of interator that does not support adaptors (for reference) 30000 a. Modifying scalar image using adaptor api... 110000 compensated = 30000 b. Modifying scalar image bypassing adaptor api... 50000 compensated = 20000 c. Modifying vector image using adaptor api... 1350000 compensated = 1270000 d. Modifying vector image bypassing adaptor api... 130000 compensated = 100000 (2) MIPSpro Compilers: Version 7.3.1.1m -O2 (IRIX) Speed of adaptor supporting interator (for reference) 70000 Speed of interator that does not support adaptors (for reference) 20000 a. Modifying scalar image using adaptor api... 110000 compensated = 40000 b. Modifying scalar image bypassing adaptor api... 60000 compensated = 40000 c. Modifying vector image using adaptor api... 2090000 compensated = 2020000 d.Modifying vector image bypassing adaptor api... 170000 compensated = 150000 I have attempted to compensate for the difference in speed of the different iterators. The correlation between iterator speed and adaptor support is accidental and does not imply causality. The compensated values for a and b show no significant difference as we would expect. But compensated differences between c and d are significant in both case 1 and 2. The problem I've described imposes a serious penalty for certain cases and merits more testing. Is there a solution within the adaptor framework that I have not though of? or do we need an API to bypass adaptors in cases where the trade-off between adaptor benefits and penalties is not acceptable? Let's spend some time discussing adaptor issues in the TCON tomorrow. Particularly I'd like to hear other developers' experiences with supporting data accessors in their algorithms--other issues they have encountered or resolved--and hear how folks are using image adaptors. Josh. -------------------- itkAdaptorComparisonTest.cxx #include #include #include "itkImage.h" #include "itkSimpleImageRegionIterator.h" #include "itkImageRegionIterator.h" #include "itkVector.h" void AdaptorSupportedIteratorSpeed(itk::Image *img) { itk::SimpleImageRegionIterator > it (img, img->GetRequestedRegion()); it.Begin(); while( ! it.IsAtEnd() ) { ++it; } } void NoAdaptorSupportIteratorSpeed(itk::Image *img) { itk::ImageRegionIterator it (img, img->GetRequestedRegion()); it.Begin(); while( ! it.IsAtEnd() ) { ++it; } } void AdaptorSupportedModifyScalars(itk::Image *img) { itk::SimpleImageRegionIterator > it (img, img->GetRequestedRegion()); it.Begin(); while( ! it.IsAtEnd() ) { // *it += 3.435f; it.Set(it.Get() + 3.435f); ++it; } } void NoAdaptorSupportModifyScalars(itk::Image *img) { itk::ImageRegionIterator it (img, img->GetRequestedRegion()); it.Begin(); while( ! it.IsAtEnd() ) { *it += 3.435f; ++it; } } void AdaptorSupportedModifyVectors(itk::Image, 3> *img) { typedef itk::Vector VectorType; const unsigned int N = 3; unsigned int i; VectorType temp_vector; itk::SimpleImageRegionIterator > it (img, img->GetRequestedRegion()); it.Begin(); while( ! it.IsAtEnd() ) { temp_vector = it.Get(); for (i = 0; i, 3> *img) { typedef itk::Vector VectorType; const unsigned int N = 3; unsigned int i; itk::ImageRegionIterator it (img, img->GetRequestedRegion()); it.Begin(); while( ! it.IsAtEnd() ) { for (i = 0; i ScalarImageType; typedef itk::Image, 3> VectorImageType; clock_t start, stop, no_adaptor_comp, adaptor_comp; // Set up some images itk::ImageRegion<3> region; itk::Size<3> size; size[0] = 100; size[1] = 100; size[2] = 100; itk::Index<3> index; index[0] = 0; index[1] = 0; index[2] = 0; region.SetSize(size); region.SetIndex(index); ScalarImageType::Pointer scalar_image = ScalarImageType::New(); VectorImageType::Pointer vector_image = VectorImageType::New(); scalar_image->SetLargestPossibleRegion(region); scalar_image->SetBufferedRegion(region); scalar_image->SetRequestedRegion(region); scalar_image->Allocate(); vector_image->SetLargestPossibleRegion(region); vector_image->SetBufferedRegion(region); vector_image->SetRequestedRegion(region); vector_image->Allocate(); // Time trials std::cout << "Speed of adaptor supporting interator (for reference) \t"; start = clock(); AdaptorSupportedIteratorSpeed(scalar_image); stop = clock(); adaptor_comp = stop - start; std::cout << adaptor_comp << std::endl; std::cout << "Speed of interator that does not support adaptors (for reference) \t"; start = clock(); NoAdaptorSupportIteratorSpeed(scalar_image); stop = clock(); no_adaptor_comp = stop - start; std::cout << no_adaptor_comp << std::endl; std::cout << "Modifying scalar image using adaptor api...\t"; start = clock(); AdaptorSupportedModifyScalars(scalar_image); stop = clock(); std::cout << (stop - start) << "\t compensated = " << (stop-start) - adaptor_comp << std::endl; std::cout << "Modifying scalar image bypassing adaptor api...\t"; start = clock(); NoAdaptorSupportModifyScalars(scalar_image); stop = clock(); std::cout << (stop - start) << "\t compensated = " << (stop-start) - no_adaptor_comp << std::endl; std::cout << "Modifying vector image using adaptor api...\t"; start = clock(); AdaptorSupportedModifyVectors(vector_image); stop = clock(); std::cout << (stop - start) << "\t compensated = " << (stop-start) - adaptor_comp << std::endl; std::cout << "Modifying vector image bypassing adaptor api...\t"; start = clock(); NoAdaptorSupportModifyVectors(vector_image); stop = clock(); std::cout << (stop - start) << "\t compensated = " << (stop-start) - no_adaptor_comp <what should I do if I want to attend the tcon? just dial in that number and >code? should I sign-up for something in advance? >BTW, please confirm that there is one tomorrow, since some of my group may >sign in and discuss our current project with the Architecture persons. >thanks, >yinpeng > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From yj76@columbia.edu Fri, 16 Mar 2001 10:46:47 -0500 Date: Fri, 16 Mar 2001 10:46:47 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] Depth of nested templates Hi, brad: I just checked in another classes: itkVoronoiSegmentationImageFilter please try a compiler on you machine and told me if there is any too-deep-templates problem. my compiler won't give any warning on this.(MSVC) thanks, yinpeng From ibanez@cs.unc.edu Fri, 16 Mar 2001 11:13:21 -0500 Date: Fri, 16 Mar 2001 11:13:21 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Image/ImageAdaptor/DataAccessor modification Hi, The questions raised by Josh's tests are quite relevant. Let's consider them in order: 1) The difference in execution time between: a- ImageIterator (the one not supporting adaptors) and b- ImageIteratorWithIndex (the one supporting adaptors) when no data is accessed, are due to the computation of the index. (a) is faster because it doesn't keep an updated value of the index, that's good because it doesn't penalize the user for something he is not using. Should the user require to access the index, then (b) will be faster because the index is updated progressively. So far, this differences are not related to the fact of supporting adaptors or not, as Josh correctly noted. The time corrections that Josh did are a perfect compensation for this difference in nature between the two iterators. So, the time comparisions after compensation are fair. 2) The differences found in gcc in Linux for access to scalars are surprisingly high. As far as I can see, they seem to be caused by the fact that the Get() method in the default DataAccessor class is returning by value (copy) instead of by reference: TExternalType Get( const TInternalType & value ) const { return (TExternalType) value; } So, I just modified to return by const reference like: const TExternalType & Get( const TInternalType & value ) const { return (TExternalType) value; } This is posible only in the default DataAccessor because the InternalType and the ExternalType are the same. In any other real DataAccessor, those types will be different, and a temporary copy of the data will be required, in those cases the return has to be done by copy; but that's fair because the user will be paying for the 'cast' which is somethig he is really using. Curiously SGI do better, and seems to optimize the inlined copy... 3) The vector case is the real difficult point. In fact what make them special is not that they are vectors, but that they are big objects and the algorithm needs to modify them 'in place'. For this case, the Get()/Set() approach is not efficient because it forces the user to make two additional copies of the object data. It seems that the best solution for this case is exactly what Josh proprosed: "Bypass the data accessor". It is hard to argue otherwise given that this is in the heart of access to image data, and will affect the overall performance of the toolkit. The option is then, to provide an additional method for accessing pixel data. The use of this method will be justified when data should be modified in place, like the += vector operation in Josh's example. In any other cases, when data is only read or only writen, there is not real penalty in using the Get()/Set() methods. The additional access method could be the * operator, like was originaly, of something like the Value() method in the VectorContainer iterators. *it += vectorInc; or it.Value() += vectorInc; The * operator seems to be a more natural choice, which could be bad, because programmers will have more tendency to use it even if the can use Set()/Get() and support adaptors. The Value() method has the advantage of giving a uniform aspect to all the interators on the toolkit, and that it will force programmers to think if they really need Value() or can go with Set()/Get(). What are your preferences ? Note that supporting Adaptors is specially important in the input and output of filters, but any other computation performed on images declared internally can count on the real nature of the images (unless the type of the input or output has been used to declare them, a case which also needs further discussion...). Thanks, Luis PS. Unfortunately I'll not be able to make the TCon today. I'll appreciate if somebody can summarize the feedback from other people and the discussion on this topic today, and post it to the list. Sorry about that. From brad.king@kitware.com Fri, 16 Mar 2001 11:35:56 -0500 (EST) Date: Fri, 16 Mar 2001 11:35:56 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Depth of nested templates Yipeng, > I just checked in another classes: itkVoronoiSegmentationImageFilter > please try a compiler on you machine and told me if there is any > too-deep-templates problem. my compiler won't give any warning on > this.(MSVC) After a couple minor repairs, it works fine on GCC (see the log entry when you update). There are still some signed/unsigned warnings for you to hammer out, though. If something builds correctly on your development environment, and you are confident it is correct C++ code, go ahead and check it in. One of the dashboard's purposes is to let you see how your changes affected other platforms. You can (should) check it the next day to see if you broke anything. -Brad From yj76@columbia.edu Fri, 16 Mar 2001 12:58:23 -0500 Date: Fri, 16 Mar 2001 12:58:23 -0500 From: Yinpeng Jin yj76@columbia.edu Subject: [Insight-developers] TCON Hi, all: Since we(Upenn & Columbia Segmentation group) had checked in some classes, and we would like to have some feedbacks from the architecture point of view. So if you have any question/suggestion on our codes, please join us at 2:00pm today for the TCON. Thanks. Yinpeng From hughett@mercur.uphs.upenn.edu Fri, 16 Mar 2001 14:57:25 -0500 Date: Fri, 16 Mar 2001 14:57:25 -0500 From: Paul Hughett hughett@mercur.uphs.upenn.edu Subject: [Insight-developers] itkImageMomentsTest on LinuxIA64 and on WinNT/VC++ The dashboard reports that itkImageMomentsTest fails to run on the Linux IA64 platform, which--as I understand it--means that the test program failed to compile. Alas, I have no IA64 platform to compile on. Could someone who does compile itkImageMomentsTest for me and send me the compiler messages? Similarly, the same program compiles on WinNT/VC++ but has very large errors, while running fine on the platform I have to test it on here. Could someone compile it on that platform and send me the compiler messages? Perhaps one of the warnings will shed some light as to why it breaks so badly on that one platform. Many thanks. Paul Hughett PS That's in the Testing/Code/Algorithms directory. pH From wlorens1@nycap.rr.com Fri, 16 Mar 2001 20:06:41 -0500 Date: Fri, 16 Mar 2001 20:06:41 -0500 From: Bill Lorensen wlorens1@nycap.rr.com Subject: [Insight-developers] itkImageMomentsTest on LinuxIA64 and on WinNT/VC++ We just added that platform. It is still not building correctly. Not your problem. Yet... At 02:57 PM 3/16/01 -0500, Paul Hughett wrote: >The dashboard reports that itkImageMomentsTest fails to run on the >Linux IA64 platform, which--as I understand it--means that the test >program failed to compile. Alas, I have no IA64 platform to compile >on. Could someone who does compile itkImageMomentsTest for me and >send me the compiler messages? > >Similarly, the same program compiles on WinNT/VC++ but has very large >errors, while running fine on the platform I have to test it on here. >Could someone compile it on that platform and send me the compiler >messages? Perhaps one of the warnings will shed some light as to >why it breaks so badly on that one platform. > >Many thanks. > > >Paul Hughett > >PS That's in the Testing/Code/Algorithms directory. pH > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From ibanez@cs.unc.edu Sun, 18 Mar 2001 13:36:03 -0500 Date: Sun, 18 Mar 2001 13:36:03 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkMatrix and the binary operator * Hi, There is an error in itkMatrix, that I'm trying to fix. It is related with the operator* with another matrix. itkMatrix derives from vnl_matrix_fixed, which derives from vnl_matrix. The operator* is defined for vnl_matrix, but it doesn't seems to recognize itkMatrix as a valid argument. The strange thing is that it seems to work only when itkMatrix is declared of type double. >From the dashboard, it seems that it only happens in VC++. I've seen that the definition of the * operator in vnl_matrix is done differently in vnl depending on the platform. (using ifdefs) Any ideas ? Thanks Luis From brad.king@kitware.com Tue, 20 Mar 2001 16:26:53 -0500 (EST) Date: Tue, 20 Mar 2001 16:26:53 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] CMake/Cable (EVERYONE PLEASE READ) Hello, all: One of the problems we have all been having with testing our code is that not all the code in a template class is necessarily compiled by our test programs. Consider the following example: -------------------------------------------------- template class MyVector { public: typedef TElement ElementType; void MyMethod0() {} void MyMethod1() { callingNonexistentFunction(); } }; int main() { MyVector mv; // Implicit instantiation of MyVector mv.MyMethod0(); // Only the methods that are called will // be compiled. return 0; } -------------------------------------------------- This program will compile without error because MyMethod1() is never instantiated, and therefore its code is not compiled. However, if someone else uses MyVector, and tries to call MyMethod1(), they will get a compiler error even though their own code is perfectly valid. If, however, there were an explicit instantiation of MyVector, then MyMethod1() would be compiled, even if it is not called. An explicit instantiation would look like "template class MyVector;" and would produce a compiler error immediately on MyMethod1(). Eventually, we would also like to be able to build explicit instantiations of ITK classes into the libraries to reduce code bloat. Writing out dozens of combinations of template arguments to create these instantiations is time consuming and hard to maintain. The new tool "CABLE" I have added to Insight solves this problem, and an extension to CMake makes it easy to use as part of the build process. Near the end of last week I checked in changes to Code/CMakeLists.txt, Code/Common/CMakeLists.txt, and Code/BasicFilters/CMakeLists.txt that introduce automatic generation of explicit instantiations of template classes into the Common and BasicFilters libraries. Now that I have confirmed that the builds with the instantiations are working on all of the dashboard's platforms, it is time to announce this so that everyone can use the new CMake / CABLE features. -------------------------------------------------- Here is a short tutorial of how to use the CMake-Cable-Command features. First off, all control is done in the CMakeLists.txt files through CMake commands. All Cable commands in CMake begin with "CABLE_" to distinguish them from the rest of CMake's commands. The idea here is to define sets of types that can be used as template arguments and then use these sets to automatically instantiate various combinations of template classes. A set is defined with the CABLE_DEFINE_SET command. For example CABLE_DEFINE_SET (BasicType int float long "unsigned short") defines a set called "BasicType" with members "int", "float", "long", and "unsigned short". This set can be referenced in certain other CMake CABLE_ commands by its name with a '$' in front. Now we define a set of specializations of the above "MyVector" class with each of these basic types. CABLE_DEFINE_SET (MyVectorType "MyVector<$BasicType>") This defines a set called "MyVectorType" with the following members: MyVector MyVector MyVector MyVector Now, say we want to actually tell CMake to put explicit instantiations of MyVector into the library being built. Assume that we have fixed the code in MyMethod1() so that it will compile. Here, I assume that we defined "MyVector" in the files myVector.h and myVector.txx CMake will automatically find the file extensions when the source is specified below. Now, we add this code to CMakeLists.txt: # Define the name of the package in which we wish to put the # instantiations. This controls the file name with the generated # code, and must come before any CABLE_INSTANTIATE_CLASS commands. CABLE_PACKAGE(MyVectors) # We must tell CMake where to find the source to our template class, # since it cannot be listed in the regular SOURCE_FILES command. CABLE_SOURCE_FILES(myVector) # Create explicit instantiations of the class. CABLE_INSTANTIATE_CLASS($MyVectorType "MyVector") This will create a package called "MyVectors" with the following explicit instantiations: MyVector MyVector MyVector MyVector MyVector This package will automatcially be compiled and linked into the library specified in this CMakeLists file. The above tutorial is just a quick overview of some of the most basic features in Cable and the CMake extension controlling it. Code already checked in to the Code/CMakeLists.txt, Code/Common/CMakeLists.txt, and Code/BasicFilters/CMakeLists.txt demonstrates much more of the functionality. To help you read it, here is a quick description of some of the features it uses: In a CABLE_DEFINE_SET command, the keyword "SOURCE_FILES" can be used after the list of set elements. Any argument after this keyword will be interpreted as a source file specification. Any place that references the set will automatically include the sources specified. When referencing a set with a '$', the set name is terminated when a character other than A-Z, a-z, 0-9, '_', or ':' is encountered. This prevents one from using the members of a set to construct an identifier. Alternatively, $(setname) will use all the characters between the parentheses as the set name. This allows one to write something like: CABLE_DEFINE_SET(digits 0 1 2 3 4 5 6 7 8 9) CABLE_DEFINE_SET(zeroTo99 "$(digits)$digits") The set "zeroTo99" will contain "00" "01" "02" ... "97" "98" "99". -------------------------------------------------- I would like everyone to read the example code already provided in the CMakeLists files like Code/Common/CMakeLists.txt and add code to create one instantiation of each of your own template classes. Feel free to email the list with questions, and I will answer them. The commands are very flexible and may take some "getting-used-to" to use them. We would like to get an explicit instantiation of every template class in all of Insight so that we are sure all code is compiled for the dashboard. These instantiations will be linked into the libraries where they are defined, and can be used in any test program. For now, however, we would like to stick to instantiations using the ScalarType, PixelType, Dimension, PointType, VectorType, ImageType, and MeshType sets already defined in Code/CMakeLists.txt. This means that filters should only be instantiated as "MyFilter<$ImageType,$ImageType>" (assuming that MyFilter is templated over TInputImage, TOutputImage). However, feel free to define other sets to shorten your code (look at the "iaFunc" example already present). Good luck, and thank you for taking the time to read this, -Brad P.S. In case anyone is wondering what "CABLE" means, it is a recursive acronym: CABLE Automates Bindings for Language Extension Eventually this will become the Tcl/Python/etc wrapping tool. From zhuge@mipg.upenn.edu Tue, 20 Mar 2001 17:45:57 -0600 Date: Tue, 20 Mar 2001 17:45:57 -0600 From: Ying Zhuge zhuge@mipg.upenn.edu Subject: [Insight-developers] compile error I just update the Insight. Something wrong with the ITKCommon.lib and ITKBasicFilters.lib when compiling fatal error C1083: Cannot open source file: 'C:\Users\Insight-VC++\Code\BasicFilters\Cxx\BasicFilters_cxx.cxx': No such file or directory fatal error C1083: Cannot open source file: 'C:\Users\Insight-VC++\Code\Common\Cxx\Common_cxx.cxx': No such file or directory Please check. Thanks a lot Ying From brad.king@kitware.com Tue, 20 Mar 2001 18:16:14 -0500 (EST) Date: Tue, 20 Mar 2001 18:16:14 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] txx policy Hello, all: Since we are beginning to use explicit instantiations, the ITK_MANUAL_INSTANTIATION flag may not always be left undefined now. This means that .txx files must be #included when instantiations are to be created. To prevent multiple inclusion, we must begin a new policy for .txx files similar to that of .h files. All txx files must be surrounded by the following code: #ifndef _NameOfFileWithoutExtension_txx #define _NameOfFileWithoutExtension_txx // rest of code in .txx source. #endif I used an emacs script to put this code around every txx currently checked in (other than those in vxl) and commited the changes. However, anyone writing a new .txx source must add this code, just as when writing a .h. -Brad From brad.king@kitware.com Tue, 20 Mar 2001 18:22:12 -0500 (EST) Date: Tue, 20 Mar 2001 18:22:12 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] compile error > I just update the Insight. Something wrong with the ITKCommon.lib and > ITKBasicFilters.lib when compiling > > fatal error C1083: Cannot open source file: > 'C:\Users\Insight-VC++\Code\BasicFilters\Cxx\BasicFilters_cxx.cxx': No > such file or directory > > fatal error C1083: Cannot open source file: > 'C:\Users\Insight-VC++\Code\Common\Cxx\Common_cxx.cxx': No such file or > directory Did you re-run CMakeSetup? -Brad From george@stetten.com Tue, 20 Mar 2001 19:40:59 -0500 Date: Tue, 20 Mar 2001 19:40:59 -0500 From: George Stetten george@stetten.com Subject: [Insight-developers] what to compile I assume we all don't really need to be compiling all the test programs. What's an easy way to avoid compiling them that can be easily explained to any newcomer? George Stetten From brad.king@kitware.com Wed, 21 Mar 2001 08:59:57 -0500 (EST) Date: Wed, 21 Mar 2001 08:59:57 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] what to compile George, > I assume we all don't really need to be compiling all the test > programs. What's an easy way to avoid compiling them that can be > easily explained to any newcomer? You should be able to just remove the "Testing" and "Examples" subdirectories from the "SUBDIRS" command at the top level CMakeLists.txt file. If you are doing development, though, you should be compiling the tests to make sure you didn't break anything with your changes before you check them in. Also, until we get this explicit-instantiation stuff in the libraries in full use, the test cause most of the build to occur, and almost nothing will build without them. A better way might be to remove indiviudal tests by commenting them out. You can go to the "TESTS" command in the CMakeLists.txt of Testing/Code/* directories and put a "#" before any test, and it will be ignored. -Brad From chandra@cs.unc.edu Thu, 22 Mar 2001 01:16:43 -0500 Date: Thu, 22 Mar 2001 01:16:43 -0500 From: Parag Chandra chandra@cs.unc.edu Subject: [Insight-developers] Changes to ImageIO This is a multi-part message in MIME format. ------=_NextPart_000_06CE_01C0B26D.C16F9A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, If any of you have written file readers that derive from ImageIO, please = make note of the following change. In order to accomodate filetypes that = use multiple extensions (for example, jpeg sometimes uses .jpeg in = addition to .jpg), I modified ImageIO::GetSupportedFileExtensions() = from: virtual std::string GetSupportedFileExtensions() const =3D 0; to: typedef std::deque FileExtensionsListType; virtual FileExtensionsListType GetSupportedFileExtensions() const =3D 0; So now, instead of returning a single string, it returns a list of = strings. The changes that need to be made to any readers are shown in = Unsupported/MetaImage/FileIOMetaImage.cxx and .h. Besides the one for = MetaImage, I'm not aware of any other readers, but if there are, please = let me know and I will help you make the necessary changes. Thanks, -Parag ------=_NextPart_000_06CE_01C0B26D.C16F9A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
If any of you have written file readers = that derive=20 from ImageIO, please make note of the following change. In order to = accomodate=20 filetypes that use multiple extensions (for example, jpeg sometimes uses = .jpeg=20 in addition to .jpg), I modified ImageIO::GetSupportedFileExtensions()=20 from:
 
virtual std::string = GetSupportedFileExtensions()=20 const =3D 0;
 
to:
 
typedef std::deque<std::string>=20 FileExtensionsListType;
virtual FileExtensionsListType=20 GetSupportedFileExtensions() const =3D 0;
So now, instead of returning a single = string, it=20 returns a list of strings. The changes that need to be made to any = readers are=20 shown in Unsupported/MetaImage/FileIOMetaImage.cxx and .h. Besides the = one for=20 MetaImage, I'm not aware of any other readers, but if there are, please = let me=20 know and I will help you make the necessary changes.
 
Thanks,
-Parag
------=_NextPart_000_06CE_01C0B26D.C16F9A70-- From ibanez@cs.unc.edu Thu, 22 Mar 2001 10:11:38 -0500 Date: Thu, 22 Mar 2001 10:11:38 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Iterators bypassing DataAccessor / ImageAdaptors Hi Josh, I just added a Value() method to ImageIteratorWithIndex and to ImageConstIteratorWithIndex. This method bypasses the DataAccessor, and return a direct reference to the pixel data. That should provide a faster access to pixel data, at the price of not supporting ImageAdaptors. The use will be something like: it.Begin(); while( it.IsAtEnd() ) { it.Value() = 5; a = it.Value(); it.Value() += 5; ++it; } There were also a couple of changes in the way iterators access data, and that may improve the performance when using Set/Get. Could you check in your code for testing iterator speed, maybe as a test program ? Thanks a lot Luis From cates@cayenne.cs.utah.edu Thu, 22 Mar 2001 10:21:42 -0700 (MST) Date: Thu, 22 Mar 2001 10:21:42 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] Iterators bypassing DataAccessor / ImageAdaptors Hi Luis, OK. I'll check in my test under the Testing/../Common directory today. I'll add a few more tests that use the new API, too. There was some adaptor discussion at last Friday's TCON about how to support both modes of access while minimizing complexity for developers and users. I don't believe any major conclusions were reached except that the issue needs more study. If you have some specific examples of how you are using image adaptors with your algorithms, these would be good as a reference for discussion. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates On Thu, 22 Mar 2001, Luis Ibanez wrote: > Hi Josh, > > I just added a Value() method to ImageIteratorWithIndex and to > ImageConstIteratorWithIndex. > > This method bypasses the DataAccessor, and return a direct > reference to the pixel data. That should provide a faster access > to pixel data, at the price of not supporting ImageAdaptors. > > The use will be something like: > > it.Begin(); > while( it.IsAtEnd() ) { > it.Value() = 5; > a = it.Value(); > it.Value() += 5; > ++it; > } > > > There were also a couple of changes in the way iterators access > data, and that may improve the performance when using Set/Get. > > Could you check in your code for testing iterator speed, > maybe as a test program ? > > > Thanks a lot > > > > Luis > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From george@stetten.com Thu, 22 Mar 2001 11:32:13 -0500 Date: Thu, 22 Mar 2001 11:32:13 -0500 From: George Stetten george@stetten.com Subject: [Insight-developers] Iterators bypassing DataAccessor /ImageAdaptors Is there going to be official documentation for the alpha release? An overview would be very handy, and we could all be looking it over. George Stetten From will.schroeder@kitware.com Thu, 22 Mar 2001 14:15:00 -0500 Date: Thu, 22 Mar 2001 14:15:00 -0500 From: Will Schroeder will.schroeder@kitware.com Subject: [Insight-developers] PointSet checked in Hi Folks- I checked in the PointSet class. It's a superclass of Mesh. I've added a test (Testing/Code/Common/itkPointSetTest.cxx) and added it to CABLE's instantiation classes. I've got some clean up to do...but please let me know if there are any problems. Will From aylward@unc.edu Thu, 22 Mar 2001 14:13:00 -0500 Date: Thu, 22 Mar 2001 14:13:00 -0500 From: Stephen R. Aylward aylward@unc.edu Subject: [Insight-developers] PointSet checked in This is great news! Thanks! We'll switch our landmark stuff to use it! Stephen Will Schroeder wrote: > > Hi Folks- > > I checked in the PointSet class. It's a superclass of Mesh. I've added a test (Testing/Code/Common/itkPointSetTest.cxx) and added it to CABLE's instantiation classes. I've got some clean up to do...but please let me know if there are any problems. > > Will > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From ibanez@cs.unc.edu Thu, 22 Mar 2001 17:26:58 -0500 Date: Thu, 22 Mar 2001 17:26:58 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Disk full Hi, I got this strange error message compiling the toolkit, and found that the binaries are taken a considerable amount of space. I know that 40Gb disks are getting cheaper and cheaper... but I wonder if I'm doing something wrong in my local build. Using Cygwin, and making an outsource build, the binaries took : 439 Mb (well,... the disk was full at this point). These are the sizes of some of the libraries: BasicLibraries 1.5 Mb Common 9.6 Mb Numerics 24.7 Mb The Testing directory took: 331 Mb ! Algorithms 91 Mb BasicFilters 124 Mb Common 64 Mb Numerics 48 Mb ------ Under WinNT, the binaries are more affordable, the take only: 144 Mb. (That should be wrong... VC++ is doing better that gcc !) Is there something that can be done to reduce the size ? Is that consequence of the manual instantiation ? Thanks Luis From chandra@cs.unc.edu Thu, 22 Mar 2001 17:32:41 -0500 Date: Thu, 22 Mar 2001 17:32:41 -0500 From: Parag Chandra chandra@cs.unc.edu Subject: [Insight-developers] Disk full Luis, I've noticed the same thing. In my case though, I think VC++ is taking up less space than Cygwin because with VC++ it's much easier to just selectively compile the projects you need, and that's what I have done. With Cygwin on the other hand, I just type make from the root directory and it builds everything, because I'm lazy ;-) I don't know if Cygwin works the same way, but if I compile everything in VC++ under the Release target, then all the debug information is left out and the compiled code is much smaller. Perhaps there's some way to do this under Cygwin as well? -Parag From aylward@unc.edu Thu, 22 Mar 2001 18:01:58 -0500 Date: Thu, 22 Mar 2001 18:01:58 -0500 From: Stephen R. Aylward aylward@unc.edu Subject: [Insight-developers] [Fwd: Changes to MetaImage...] How should we reference data files in the example directories if the build is placing the executables in different directories? See below for more details.... Thanks, Stephen Parag Chandra wrote: > > Ok, that solves half the problem. I'll put the test and the accompanying > files into examples. But how would I reference that (the examples) directory from within > the test program? Each platform will place the executable for this test into > something like ${CMAKE_BINARY_DIR}/Examples, but ${CMAKE_BINARY_DIR} isn't > even an environment variable for me to reference, it's a variable that's > internal to CMake. If I reference the file without the pathname, like > "TestInput.mhd", then the file has to be in the same directory as the > executable, and that means I would have to place a copy of the test file > into Insight-Cygwin, Insight-VC++, Insight-Linux, etc. Not only is that > redundant, but there's no way I could foresee the additional platforms we > might target, and so the test running on those platforms will generate an > exception when it can't find the file. The only thing I can see is to place > the test file into one directory, and then run the test for each platform > from that directory by using the full pathname of the executable, e.g. > /Insight-Cygwin/Examples/itkFileIOMetaImageTest.exe. Does anyone have any > other ideas? > > Thanks, > -Parag > > --- > You are currently subscribed to caddlab as: aylward@unc.edu > To unsubscribe send a blank email to leave-caddlab-706N@listserv.unc.edu -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From brad.king@kitware.com Thu, 22 Mar 2001 18:23:03 -0500 (EST) Date: Thu, 22 Mar 2001 18:23:03 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Disk full Luis, > Is there something that can be done to reduce the size ? > Is that consequence of the manual instantiation ? Actually, it is because we are NOT doing manual instantiation for the tests. Every template class that is needed by each test is being instantiated and linked statically into the executable for that test. This means we have a copy of many template classes in every test exectuable. The idea of the manual instantiation is to be able to put the instantiations you need in the libraries, and link to them from the executables. This way, each instantiation only exists in one place, and the code will be much smaller. -Brad From chenting@graphics.cis.upenn.edu Thu, 22 Mar 2001 18:11:29 -0600 Date: Thu, 22 Mar 2001 18:11:29 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] about dataobject update Hi! I am working on developing a recursive segmentation method. But I met this problem. As for itkMRFImageFilter, when I make change to the training image and want to update the segmentation result. The filter seems just did not respond to the update of training image. The problem is at: itkDataObject.cxx: void DataObject ::UpdateOutputData() { // If we need to update due to PipelineMTime, or the fact that our // data was released, then propagate the UpdateOutputData to the source // if there is one. >>>>>>>cannot enter the outer if{...} if ( m_UpdateTime < m_PipelineMTime || m_DataReleased || this->RequestedRegionIsOutsideOfTheBufferedRegion()) { if ( m_Source ) { m_Source->UpdateOutputData(this); } } } it seems I have to do something to make it know it is time for update, but where and what should do? Any ideas? ting From wlorens1@nycap.rr.com Thu, 22 Mar 2001 19:54:38 -0500 Date: Thu, 22 Mar 2001 19:54:38 -0500 From: Bill Lorensen wlorens1@nycap.rr.com Subject: [Insight-developers] Disk full I build shared libraries. Use the --with-shared on configure. I'll check my sizes when I get to work tomorrow. Bill At 05:26 PM 3/22/01 -0500, Luis Ibanez wrote: >Hi, > >I got this strange error message compiling the toolkit, >and found that the binaries are taken a considerable >amount of space. > >I know that 40Gb disks are getting cheaper and cheaper... >but I wonder if I'm doing something wrong in my local build. > >Using Cygwin, and making an outsource build, >the binaries took : > > 439 Mb (well,... the disk was full at this point). > > These are the sizes of some of the libraries: > > BasicLibraries 1.5 Mb > Common 9.6 Mb > Numerics 24.7 Mb > > The Testing directory took: 331 Mb ! > > Algorithms 91 Mb > BasicFilters 124 Mb > Common 64 Mb > Numerics 48 Mb > > >------ > >Under WinNT, the binaries are more affordable, >the take only: 144 Mb. >(That should be wrong... VC++ is doing better that gcc !) > > >Is there something that can be done to reduce the size ? > >Is that consequence of the manual instantiation ? > > > > >Thanks > > >Luis > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From bill.hoffman@kitware.com Thu, 22 Mar 2001 22:39:01 -0500 Date: Thu, 22 Mar 2001 22:39:01 -0500 From: Bill Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] Disk full Configure picks -O2 -g for gcc, which is REALLY HUGE for cygwin. Just -g or -O2 should be quite a bit smaller. Visual C++ uses those program database files to keep the debug info central, and gcc duplicates a lot of the debug info into each .o file, and of course it does not truncate symbols longer than 255, as we know VC++ does. -Bill (father of Max) Hoffman http://www.setonhealth.org/html/ChildB2.html (see Maxwell Robert) At 07:54 PM 3/22/01 -0500, Bill Lorensen wrote: >I build shared libraries. Use the --with-shared on configure. > >I'll check my sizes when I get to work tomorrow. > >Bill > >At 05:26 PM 3/22/01 -0500, Luis Ibanez wrote: > > >Hi, > > > >I got this strange error message compiling the toolkit, > >and found that the binaries are taken a considerable > >amount of space. > > > >I know that 40Gb disks are getting cheaper and cheaper... > >but I wonder if I'm doing something wrong in my local build. > > > >Using Cygwin, and making an outsource build, > >the binaries took : > > > > 439 Mb (well,... the disk was full at this point). > > > > These are the sizes of some of the libraries: > > > > BasicLibraries 1.5 Mb > > Common 9.6 Mb > > Numerics 24.7 Mb > > > > The Testing directory took: 331 Mb ! > > > > Algorithms 91 Mb > > BasicFilters 124 Mb > > Common 64 Mb > > Numerics 48 Mb > > > > > >------ > > > >Under WinNT, the binaries are more affordable, > >the take only: 144 Mb. > >(That should be wrong... VC++ is doing better that gcc !) > > > > > >Is there something that can be done to reduce the size ? > > > >Is that consequence of the manual instantiation ? > > > > > > > > > >Thanks > > > > > >Luis > > > >_______________________________________________ > >Insight-developers mailing list > >Insight-developers@public.kitware.com > >http://public.kitware.com/mailman/listinfo/insight-developers > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From millerjv@crd.ge.com Fri, 23 Mar 2001 07:37:49 -0500 Date: Fri, 23 Mar 2001 07:37:49 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] about dataobject update A change to a pixel does not cause the DataObject to think it has been modified. There are two reasons for this. First, if we ticked the modified time for the data object for every pixel modification, we would quickly roll over the modified time ivar. Second, we'd hate to have to tick the modified time for every pixel modification (that would be an extra add per pixel change). Once you have finished making all your changes to the pixel data, send the DataObject a Modified() call. This will mark the data object as being modified and your pipeline should re-execute. Jim -----Original Message----- From: Ting Chen [mailto:chenting@graphics.cis.upenn.edu] Sent: Thursday, March 22, 2001 7:11 PM To: Insight Developers Subject: [Insight-developers] about dataobject update Hi! I am working on developing a recursive segmentation method. But I met this problem. As for itkMRFImageFilter, when I make change to the training image and want to update the segmentation result. The filter seems just did not respond to the update of training image. The problem is at: itkDataObject.cxx: void DataObject ::UpdateOutputData() { // If we need to update due to PipelineMTime, or the fact that our // data was released, then propagate the UpdateOutputData to the source // if there is one. >>>>>>>cannot enter the outer if{...} if ( m_UpdateTime < m_PipelineMTime || m_DataReleased || this->RequestedRegionIsOutsideOfTheBufferedRegion()) { if ( m_Source ) { m_Source->UpdateOutputData(this); } } } it seems I have to do something to make it know it is time for update, but where and what should do? Any ideas? ting _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From blezek@crd.ge.com Fri, 23 Mar 2001 08:24:27 -0500 (EST) Date: Fri, 23 Mar 2001 08:24:27 -0500 (EST) From: Daniel J. Blezek, Ph.D. blezek@crd.ge.com Subject: [Insight-developers] [Fwd: Changes to MetaImage...] Stephen and Parag, This exact issue drove the discussion about file reading and writing at last week's telephone conference. I have several ideas in mind as to finding images and writing images for regression testing, but have not made them happen just yet. In the mean time, I would welcome any suggestions you may have as to how to address this issue. In our experience with VTK, which may be different for ITK, some platforms require a platform specific "gold image", and require special processing. Here are some of my ideas, strictly related to regression testing: - Have a Toolkit similar to Java, so to get the name of a file you would do something like this: std::string s = Toolkit::GetFileName ( "VHF/Head.png" ); The Toolkit would properly expand the file name to be the path to the image you want, allowing images to be stored on fixed media(CDROM). On the outbound side, you would request an output image in a similar manner: std::string s = Toolkit::GetImageTestResultFileName ( "itkFileIOMetaImageTest" ); The Toolkit would expand this name to a directory where test images sit, and a latter process would pick up the images and compare them to the "gold standard". If the test were run in an example mode, it would simply write the output in the current directory, for the user to take a look at later. - This raises the issue of file formats yet again. Everyone seems to cook up their own file format to meet the needs of whatever problem they have at hand! (We are no exception...) In my view, the current problem at hand is regression testing. I've given this issue some thought. We need: - a file format that is easily displayed locally and through a browser - a format that is easily created by all Insight developers - a format that has 2D support at minimum - a format that supports as many common datatypes as possible The first point drives the selection down considerably. The only real canidates are Gif, Jpeg, and PNG. Gif and Jpeg are generally lossy compression, and don't fit the bill. PNG is a relatively new format, with good support from most OS/viewers/browsers. PNG is also licensed for use in a toolkit such as ITK. The real downside is that PNG only supports 8 and 16 bit datatypes. I feel this is acceptable because medical image data generally comes in these two types, so that should not be a limiting factor. PNG support is built and working on my local checkout. Since I'm doing most of the testing infrastructure, I will offer to serve as the focal point for this issue, and welcome any suggestions. Thanks, -dan On Thu, 22 Mar 2001, Stephen R. Aylward wrote: > > How should we reference data files in the example directories if the > build is placing the executables in different directories? See below > for more details.... > > Thanks, > Stephen > > Parag Chandra wrote: > > > > Ok, that solves half the problem. I'll put the test and the accompanying > > files into examples. But how would I reference that (the examples) directory from within > > the test program? Each platform will place the executable for this test into > > something like ${CMAKE_BINARY_DIR}/Examples, but ${CMAKE_BINARY_DIR} isn't > > even an environment variable for me to reference, it's a variable that's > > internal to CMake. If I reference the file without the pathname, like > > "TestInput.mhd", then the file has to be in the same directory as the > > executable, and that means I would have to place a copy of the test file > > into Insight-Cygwin, Insight-VC++, Insight-Linux, etc. Not only is that > > redundant, but there's no way I could foresee the additional platforms we > > might target, and so the test running on those platforms will generate an > > exception when it can't find the file. The only thing I can see is to place > > the test file into one directory, and then run the test for each platform > > from that directory by using the full pathname of the executable, e.g. > > /Insight-Cygwin/Examples/itkFileIOMetaImageTest.exe. Does anyone have any > > other ideas? > > > > Thanks, > > -Parag > > > > --- > > You are currently subscribed to caddlab as: aylward@unc.edu > > To unsubscribe send a blank email to leave-caddlab-706N@listserv.unc.edu > > -- > =============================================== > Stephen R. Aylward > Assistant Professor of Radiology > Adjunct Assistant Professor of Computer Science > http://www.cs.unc.edu/~aylward > aylward@unc.edu > (919) 966-9695 > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > -- Daniel Blezek, Ph.D. blezek@crd.ge.com Visualization and Computer Vision Program Electronic Systems Lab GE Corporate Research & Development From aylward@unc.edu Fri, 23 Mar 2001 13:52:59 -0500 Date: Fri, 23 Mar 2001 13:52:59 -0500 From: Stephen R. Aylward aylward@unc.edu Subject: [Insight-developers] [Fwd: Changes to MetaImage...] The only difficulty is that PNG doesn't provide element spacing information. How about a medical format - e.g., analyze? Stephen "Daniel J. Blezek, Ph.D." wrote: > > Stephen and Parag, > > This exact issue drove the discussion about file reading and writing at > last week's telephone conference. I have several ideas in mind as to > finding images and writing images for regression testing, but have not > made them happen just yet. In the mean time, I would welcome any > suggestions you may have as to how to address this issue. In our > experience with VTK, which may be different for ITK, some platforms > require a platform specific "gold image", and require special processing. > > Here are some of my ideas, strictly related to regression testing: > > - Have a Toolkit similar to Java, so to get the name of a file you would > do something like this: > > std::string s = Toolkit::GetFileName ( "VHF/Head.png" ); > > The Toolkit would properly expand the file name to be the path to the > image you want, allowing images to be stored on fixed media(CDROM). On > the outbound side, you would request an output image in a similar manner: > > std::string s = Toolkit::GetImageTestResultFileName ( > "itkFileIOMetaImageTest" ); > > The Toolkit would expand this name to a directory where test images > sit, and a latter process would pick up the images and compare them to the > "gold standard". If the test were run in an example mode, it would simply > write the output in the current directory, for the user to take a look at > later. > > - This raises the issue of file formats yet again. Everyone seems to cook > up their own file format to meet the needs of whatever problem they have > at hand! (We are no exception...) In my view, the current problem at hand > is regression testing. I've given this issue some thought. We need: > > - a file format that is easily displayed locally and through a browser > - a format that is easily created by all Insight developers > - a format that has 2D support at minimum > - a format that supports as many common datatypes as possible > > The first point drives the selection down considerably. The only real > canidates are Gif, Jpeg, and PNG. Gif and Jpeg are generally lossy > compression, and don't fit the bill. PNG is a relatively new format, with > good support from most OS/viewers/browsers. PNG is also licensed for use > in a toolkit such as ITK. The real downside is that PNG only supports 8 > and 16 bit datatypes. I feel this is acceptable because medical image > data generally comes in these two types, so that should not be a limiting > factor. PNG support is built and working on my local checkout. > > Since I'm doing most of the testing infrastructure, I will offer to serve > as the focal point for this issue, and welcome any suggestions. > > Thanks, > -dan > > On Thu, 22 Mar 2001, Stephen R. Aylward wrote: > > > > > How should we reference data files in the example directories if the > > build is placing the executables in different directories? See below > > for more details.... > > > > Thanks, > > Stephen > > > > Parag Chandra wrote: > > > > > > Ok, that solves half the problem. I'll put the test and the accompanying > > > files into examples. But how would I reference that (the examples) directory from within > > > the test program? Each platform will place the executable for this test into > > > something like ${CMAKE_BINARY_DIR}/Examples, but ${CMAKE_BINARY_DIR} isn't > > > even an environment variable for me to reference, it's a variable that's > > > internal to CMake. If I reference the file without the pathname, like > > > "TestInput.mhd", then the file has to be in the same directory as the > > > executable, and that means I would have to place a copy of the test file > > > into Insight-Cygwin, Insight-VC++, Insight-Linux, etc. Not only is that > > > redundant, but there's no way I could foresee the additional platforms we > > > might target, and so the test running on those platforms will generate an > > > exception when it can't find the file. The only thing I can see is to place > > > the test file into one directory, and then run the test for each platform > > > from that directory by using the full pathname of the executable, e.g. > > > /Insight-Cygwin/Examples/itkFileIOMetaImageTest.exe. Does anyone have any > > > other ideas? > > > > > > Thanks, > > > -Parag > > > > > > --- > > > You are currently subscribed to caddlab as: aylward@unc.edu > > > To unsubscribe send a blank email to leave-caddlab-706N@listserv.unc.edu > > > > -- > > =============================================== > > Stephen R. Aylward > > Assistant Professor of Radiology > > Adjunct Assistant Professor of Computer Science > > http://www.cs.unc.edu/~aylward > > aylward@unc.edu > > (919) 966-9695 > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > > > -- > Daniel Blezek, Ph.D. > blezek@crd.ge.com > Visualization and Computer Vision Program > Electronic Systems Lab > GE Corporate Research & Development -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From chandra@cs.unc.edu Fri, 23 Mar 2001 14:03:36 -0500 Date: Fri, 23 Mar 2001 14:03:36 -0500 From: Parag Chandra chandra@cs.unc.edu Subject: [Insight-developers] [Fwd: Changes to MetaImage...] Daniel, I think this Toolkit::GetFileName() is exactly what we need, because there has to be some way to get at the contents of variables like ${CMAKE_BINARY_DIR}. Otherwise the test process will have to cd to the directory of the gold-standard images and then run each of the platform-specific binaries via its fully-qualified pathname. With regard to the file formats issue: since ImageIO is abstract, we have to use a concrete reader for a specific file format in order to test. I chose MetaImage because at one point I thought it was going to be one of the "officially" supported formats. If this is no longer true, then we need to decide on a format for testing purposes, and I think we need something more comprehensive than PNG, or perhaps any other single file format for that matter. 3D images are used frequently enough that I think 3D image I/O should be part of the test process, but I realize 3D images would be difficult to show in a browser for comparison. However, instead of a visual comparison, couldn't we just use some sort of binary diff command? -Parag ----- Original Message ----- From: "Daniel J. Blezek, Ph.D." To: "Stephen R. Aylward" Cc: "Insight-Developers (E-mail)" Sent: Friday, March 23, 2001 8:24 AM Subject: Re: [Insight-developers] [Fwd: Changes to MetaImage...] > Stephen and Parag, > > This exact issue drove the discussion about file reading and writing at > last week's telephone conference. I have several ideas in mind as to > finding images and writing images for regression testing, but have not > made them happen just yet. In the mean time, I would welcome any > suggestions you may have as to how to address this issue. In our > experience with VTK, which may be different for ITK, some platforms > require a platform specific "gold image", and require special processing. > > > Here are some of my ideas, strictly related to regression testing: > > - Have a Toolkit similar to Java, so to get the name of a file you would > do something like this: > > std::string s = Toolkit::GetFileName ( "VHF/Head.png" ); > > The Toolkit would properly expand the file name to be the path to the > image you want, allowing images to be stored on fixed media(CDROM). On > the outbound side, you would request an output image in a similar manner: > > std::string s = Toolkit::GetImageTestResultFileName ( > "itkFileIOMetaImageTest" ); > > The Toolkit would expand this name to a directory where test images > sit, and a latter process would pick up the images and compare them to the > "gold standard". If the test were run in an example mode, it would simply > write the output in the current directory, for the user to take a look at > later. > > > - This raises the issue of file formats yet again. Everyone seems to cook > up their own file format to meet the needs of whatever problem they have > at hand! (We are no exception...) In my view, the current problem at hand > is regression testing. I've given this issue some thought. We need: > > - a file format that is easily displayed locally and through a browser > - a format that is easily created by all Insight developers > - a format that has 2D support at minimum > - a format that supports as many common datatypes as possible > > The first point drives the selection down considerably. The only real > canidates are Gif, Jpeg, and PNG. Gif and Jpeg are generally lossy > compression, and don't fit the bill. PNG is a relatively new format, with > good support from most OS/viewers/browsers. PNG is also licensed for use > in a toolkit such as ITK. The real downside is that PNG only supports 8 > and 16 bit datatypes. I feel this is acceptable because medical image > data generally comes in these two types, so that should not be a limiting > factor. PNG support is built and working on my local checkout. > > Since I'm doing most of the testing infrastructure, I will offer to serve > as the focal point for this issue, and welcome any suggestions. > > Thanks, > -dan > > > On Thu, 22 Mar 2001, Stephen R. Aylward wrote: > > > > > How should we reference data files in the example directories if the > > build is placing the executables in different directories? See below > > for more details.... > > > > Thanks, > > Stephen > > > > Parag Chandra wrote: > > > > > > Ok, that solves half the problem. I'll put the test and the accompanying > > > files into examples. But how would I reference that (the examples) directory from within > > > the test program? Each platform will place the executable for this test into > > > something like ${CMAKE_BINARY_DIR}/Examples, but ${CMAKE_BINARY_DIR} isn't > > > even an environment variable for me to reference, it's a variable that's > > > internal to CMake. If I reference the file without the pathname, like > > > "TestInput.mhd", then the file has to be in the same directory as the > > > executable, and that means I would have to place a copy of the test file > > > into Insight-Cygwin, Insight-VC++, Insight-Linux, etc. Not only is that > > > redundant, but there's no way I could foresee the additional platforms we > > > might target, and so the test running on those platforms will generate an > > > exception when it can't find the file. The only thing I can see is to place > > > the test file into one directory, and then run the test for each platform > > > from that directory by using the full pathname of the executable, e.g. > > > /Insight-Cygwin/Examples/itkFileIOMetaImageTest.exe. Does anyone have any > > > other ideas? > > > > > > Thanks, > > > -Parag > > > > > > --- > > > You are currently subscribed to caddlab as: aylward@unc.edu > > > To unsubscribe send a blank email to leave-caddlab-706N@listserv.unc.edu > > > > -- > > =============================================== > > Stephen R. Aylward > > Assistant Professor of Radiology > > Adjunct Assistant Professor of Computer Science > > http://www.cs.unc.edu/~aylward > > aylward@unc.edu > > (919) 966-9695 > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > > > -- > Daniel Blezek, Ph.D. > blezek@crd.ge.com > Visualization and Computer Vision Program > Electronic Systems Lab > GE Corporate Research & Development > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From brad.king@kitware.com Fri, 23 Mar 2001 16:37:07 -0500 (EST) Date: Fri, 23 Mar 2001 16:37:07 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] Simplifying traits Hello, all: Here are some ideas to consider before deciding to throw out the use of ScalarTraits an VectorTraits. Our current approach is not the simplest approach to using traits. We can make traits easier to use. Consider the following filter: template class MyFilter { public: typedef TInputImage InputImageType; typedef typename InputImageType::PixelType InputPixelType; typedef ScalarTraits PixelScalarTraits; typedef typename PixelScalarTraits::ScalarValueType PixelScalarValueType; inline static PixelScalarValueType& GetPixelScalar(PixelType& p) { return PixelScalarTraits::GetScalar(p); } inline static void SetPixelScalar(PixelType& p, const PixelScalarValueType& v) { PixelScalarTraits::SetScalar(p, v); } // .... }; Note that the function definitions can be put in ImageToImageFilter and be inherited into other filters. Then, with minimal setup work, a filter implementation can access a Pixel's scalar value like this: PixelScalarValueType v = GetPixelScalar(myPixel); // do something to v. SetPixelScalar(myPixel, v); This is in place of the current code: typename ScalarTraits::ScalarValueType v = ScalarTraits::GetScalar(myPixel); // do something to v. ScalarTraits::SetScalar(myPixel, v); Also, I have noticed that there are a bunch of extra ScalarTrait specializations for more than the basic types. An example is "ScalarTraits< RGBPixel >". These should not be done, because if someone wants to use an RGBPixel with a template argument other than those defined in itkPixelTraits.h, they will have to figure out how to write their own trait specialization for it. Currently, this can be solved (I think) by putting the proper typedefs (ValueType, etc) into RGBPixel and letting the primary template of ScalarTraits handle it from there. The "real" way to do such a specialization of the ScalarTraits for RGBPixel would be to do a partial specialization: template class ScalarTraits< RGBPixel > { /* ... */ }; Unfortunately, not all of our compilers support partial specialization, so we can't do this. The other option is to not require scalar traits to be a speicalization of ScalarTraits at all. If instead we make such traits a template argument, then any class can be defined and passed to the argument: template > class Image { public: typedef TPixel PixelType; enum { Dimension = VDimension }; typedef TPixelTraits PixelTraits; // .... }; Then, filters could pull the Pixel traits out of their image template parameters: template class MyFilter { public: typedef TInputImage InputImageType; typedef typename InputImageType::PixelTraits InputPixelTraits; // ... use traits as in previous MyFilter example. }; Making traits a template argument is currently the approach that the Mesh class uses. It even encapsulates the "CellTraits" as a member of the "MeshTraits" template argument. We could make the same relationship for the Image. That is: template class DefaultImageTraits { public: typedef TPixel PixelType; enum { Dimension = VDimension }; typedef DefaultPixelTraits PixelTraits; // ... other useful traits? }; template > class Image { public: typedef TImageTraits ImageTraits; typedef typename ImageTraits::PixelType PixelType; typedef typename ImageTraits::PixelTraits PixelTraits; // ... }; Assume that we have encapsulated both the current scalar and vector traits into "DefaultPixelTraits". Thoughts, anyone? -Brad From brad.king@kitware.com Fri, 23 Mar 2001 17:42:03 -0500 (EST) Date: Fri, 23 Mar 2001 17:42:03 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] How to use "typename" Hello, all: 90% of the compiler errors this week have been due to improper use of the "typename" keyword. I would like to try to reduce this trend. This message should help you understand when it should and should not be used. There are actually two meanings of the "typename" keyword. 1.) Easy version: When used to declare a template parameter, it is equivalent to "class". This example demonstrates this case. Both of these are identical: template struct Foo {}; // is identical to template struct Foo {}; 2.) Hard version: The keyword is used to tell the compiler that the next qualified identifier will refer to a type. Rather than explaining the details of why this is necessary, I will just give examples of most of the cases. template class MyClass { // "typename" not needed because there is no "::" access. typedef T MyTemplateArgument; // "typename" needed because "T" is a template parameter of MyClass. typedef typename T::Foo Foo; // "typename" not needed because Vector does not depend // on a template parameter of MyClass. typedef Vector::Iterator VectorIterator_int; // "typename" needed because Vector DEPENDS on a template // parameter of MyClass. typedef typename Vector::Iterator VectorIterator_T; // "typename" not needed because "Vector" is just a type. typedef Vector FloatVector; // "typename" not needed because "FloatVector" does not depend // on a template paramaeter of MyClass. typedef FloatVector::Iterator FloatVectorIterator; // "typename" not needed because there is no "::" access. typedef Vector MyVector; // "typename" needed because "MyVector" depends on a template parameter // of MyClass. typedef typename MyVector::Iterator MyVectorIterator; void MyMethod(); // used later in example }; All of the above rules apply whenever you are referring to the types, not just in a typedef. They are even needed when referring to a type as the template argument for another class. However, once you have the typedef'd name, you can just use that since the compiler knows it is a type. For example: template void MyClass::MyMethod() { typename Vector::Iterator myIter; // is equivalent to typename MyVector::Iterator myIter; // is equivalent to MyVectorIterator myIter; } Whenever you are unsure about whether to use a typename, this email should have an example of your situation. If not, feel free to email the list with the situation, and I'm sure you'll get an answer quickly. -Brad From cates@cayenne.cs.utah.edu Fri, 23 Mar 2001 16:51:55 -0700 (MST) Date: Fri, 23 Mar 2001 16:51:55 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] pipeline update mechanism Hello, Has the Update() mechanism in the pipeline been modified? I am no longer able to get filters to execute via Update() (as of today). Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates From ibanez@cs.unc.edu Fri, 23 Mar 2001 18:25:28 -0500 Date: Fri, 23 Mar 2001 18:25:28 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] itkMatrix Hi, itkMatrix has been reworked. it doesn't derive from vnl_matrix_fixed anymore, now it contains a vnl_matrix_fixed. The product operations are defined for : - itkPoint - itkVector - itkCovariantVector - itkMatrix - vnl_matrix - vnl_vector Access to the internal vnl_matrix can be get through GetVnlMatrix(). it can be initalized with SetIdentity(); and accept assigments from itkMatrix vnl_matrix Luis From lorensen@crd.ge.com Mon, 26 Mar 2001 07:52:46 -0500 Date: Mon, 26 Mar 2001 07:52:46 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] IMPORTANT: pre-commit checking for cvs Folks, I've added pre-commit check scripts to the cvs repository. Currently there are two pre-commit checks. Both operate on txx, cxx, h, htm and html files. pre-commit check #1 scans the file for lines with a trailing ctrl-M. These are probably being inserted by Micorsoft editors. They are easliy removed with emacs. I'm not sure how to remove them otherwise. pre-commit check #2 checks the last line in a file for a newline. This is easliy fixed with any editor. Go to the end of the file and hit enter. If either pre-commit check fails, the entire cvs commit wiill be stopped. I hope this will help folks. I'm not sure about the robustness of these scripts. Please send me e-mail if you try to commit a file and the checkers incorrectly block the commit. Bill From ibanez@cs.unc.edu Mon, 26 Mar 2001 10:15:56 -0500 Date: Mon, 26 Mar 2001 10:15:56 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Dashboard / Registration Hi, We are changing the part of the API in the registration framework. Previously a VectorContainer was used to pass the parameters of the spatial transformation to the optimizers. This was impractical because VectorContainer elements has to be accessed through iterators. So, now the framework is templated the parameters type, and it could be any type with the operator[]() defined. The bad news is that the changes are not completed yet so there are a lot of new error messages on the dashboard, coming from these modifications. We are working now on fixing them.... Luis From blezek@crd.ge.com Mon, 26 Mar 2001 10:38:07 -0500 (EST) Date: Mon, 26 Mar 2001 10:38:07 -0500 (EST) From: Daniel J. Blezek, Ph.D. blezek@crd.ge.com Subject: [Insight-developers] Image file formats for testing Parag and Stephen, Before my life at GE, I worked with Dr. Rick Robb at Mayo on Analyze. Again, the Analyze file format is simply a "roll-your-own" format, that served the need of the group at the time. The current incarnation of Analyze, AVW has a better model of a file format. The file is simply text indicating spacing, scanner, datatype, etc... with filenames to read as each slice. Thus, the individual slices are 2D but wrapped into 3D. I'd like to make it clear that I'm not proposing a fileformat for all of Insight to use forever, just a format to settle on for the purpose of testing our code. I still feel that PNG makes sense. The specification allows you to set the physical scale units(In Meters), and height and width, and we can encode depth into the text comments that PNG allows. I'm really more interested in PNG as an _output_ format, not necessarly as an input format, e.g. a test reads whatever format it likes (assuming it's a cross-platform library), does it's processing, and writes out a PNG file. A later process picks up the PNG files, compares them to the "gold standard" for that algorithm, producing difference images if the test generated a different result. This would allow a developer to produce input data in whatever (supported) format is most convient, and allow everyone to view the testing output, and for the dashboard to easily show the images. On a related note, I've been considering a framework to allow Insight to be more easily streamlined with other packages, sort of an import/export facility, with a simplified pipeline interface. That would make using Insight with VTK or other packages straightforward. In this design, it makes sense to move the ImageIO class under the import/export classes, for after all, file i/o is interaction with an external system. This should be relatively straightforward, and not very invasive, but will involve re-arranging the code a bit. I'm hoping to get some time to work on this later this week, and I'll run my design by you both, before making changes to CVS. Thanks, -dan > The only difficulty is that PNG doesn't provide element spacing > information. How about a medical format - e.g., analyze? > Stephen On Fri, 23 Mar 2001, Parag Chandra wrote: > Daniel, I think this Toolkit::GetFileName() is exactly what we need, because > there has to be some way to get at the contents of variables like > ${CMAKE_BINARY_DIR}. Otherwise the test process will have to cd to the > directory of the gold-standard images and then run each of the > platform-specific binaries via its fully-qualified pathname. > > With regard to the file formats issue: since ImageIO is abstract, we have to > use a concrete reader for a specific file format in order to test. I chose > MetaImage because at one point I thought it was going to be one of the > "officially" supported formats. If this is no longer true, then we need to > decide on a format for testing purposes, and I think we need something more > comprehensive than PNG, or perhaps any other single file format for that > matter. 3D images are used frequently enough that I think 3D image I/O > should be part of the test process, but I realize 3D images would be > difficult to show in a browser for comparison. However, instead of a visual > comparison, couldn't we just use some sort of binary diff command? > > -Parag > > ----- Original Message ----- > From: "Daniel J. Blezek, Ph.D." > To: "Stephen R. Aylward" > Cc: "Insight-Developers (E-mail)" > Sent: Friday, March 23, 2001 8:24 AM > Subject: Re: [Insight-developers] [Fwd: Changes to MetaImage...] > > > > Stephen and Parag, > > > > This exact issue drove the discussion about file reading and writing at > > last week's telephone conference. I have several ideas in mind as to > > finding images and writing images for regression testing, but have not > > made them happen just yet. In the mean time, I would welcome any > > suggestions you may have as to how to address this issue. In our > > experience with VTK, which may be different for ITK, some platforms > > require a platform specific "gold image", and require special processing. > > > > > > Here are some of my ideas, strictly related to regression testing: > > > > - Have a Toolkit similar to Java, so to get the name of a file you would > > do something like this: > > > > std::string s = Toolkit::GetFileName ( "VHF/Head.png" ); > > > > The Toolkit would properly expand the file name to be the path to the > > image you want, allowing images to be stored on fixed media(CDROM). On > > the outbound side, you would request an output image in a similar manner: > > > > std::string s = Toolkit::GetImageTestResultFileName ( > > "itkFileIOMetaImageTest" ); > > > > The Toolkit would expand this name to a directory where test images > > sit, and a latter process would pick up the images and compare them to the > > "gold standard". If the test were run in an example mode, it would simply > > write the output in the current directory, for the user to take a look at > > later. > > > > > > - This raises the issue of file formats yet again. Everyone seems to cook > > up their own file format to meet the needs of whatever problem they have > > at hand! (We are no exception...) In my view, the current problem at hand > > is regression testing. I've given this issue some thought. We need: > > > > - a file format that is easily displayed locally and through a browser > > - a format that is easily created by all Insight developers > > - a format that has 2D support at minimum > > - a format that supports as many common datatypes as possible > > > > The first point drives the selection down considerably. The only real > > canidates are Gif, Jpeg, and PNG. Gif and Jpeg are generally lossy > > compression, and don't fit the bill. PNG is a relatively new format, with > > good support from most OS/viewers/browsers. PNG is also licensed for use > > in a toolkit such as ITK. The real downside is that PNG only supports 8 > > and 16 bit datatypes. I feel this is acceptable because medical image > > data generally comes in these two types, so that should not be a limiting > > factor. PNG support is built and working on my local checkout. > > > > Since I'm doing most of the testing infrastructure, I will offer to serve > > as the focal point for this issue, and welcome any suggestions. > > > > Thanks, > > -dan > > > > > > On Thu, 22 Mar 2001, Stephen R. Aylward wrote: > > > > > > > > How should we reference data files in the example directories if the > > > build is placing the executables in different directories? See below > > > for more details.... > > > > > > Thanks, > > > Stephen > > > > > > Parag Chandra wrote: > > > > > > > > Ok, that solves half the problem. I'll put the test and the > accompanying > > > > files into examples. But how would I reference that (the examples) > directory from within > > > > the test program? Each platform will place the executable for this > test into > > > > something like ${CMAKE_BINARY_DIR}/Examples, but ${CMAKE_BINARY_DIR} > isn't > > > > even an environment variable for me to reference, it's a variable > that's > > > > internal to CMake. If I reference the file without the pathname, like > > > > "TestInput.mhd", then the file has to be in the same directory as the > > > > executable, and that means I would have to place a copy of the test > file > > > > into Insight-Cygwin, Insight-VC++, Insight-Linux, etc. Not only is > that > > > > redundant, but there's no way I could foresee the additional platforms > we > > > > might target, and so the test running on those platforms will generate > an > > > > exception when it can't find the file. The only thing I can see is to > place > > > > the test file into one directory, and then run the test for each > platform > > > > from that directory by using the full pathname of the executable, e.g. > > > > /Insight-Cygwin/Examples/itkFileIOMetaImageTest.exe. Does anyone have > any > > > > other ideas? > > > > > > > > Thanks, > > > > -Parag > > > > > > > > --- > > > > You are currently subscribed to caddlab as: aylward@unc.edu > > > > To unsubscribe send a blank email to > leave-caddlab-706N@listserv.unc.edu > > > > > > -- > > > =============================================== > > > Stephen R. Aylward > > > Assistant Professor of Radiology > > > Adjunct Assistant Professor of Computer Science > > > http://www.cs.unc.edu/~aylward > > > aylward@unc.edu > > > (919) 966-9695 > > > > > > _______________________________________________ > > > Insight-developers mailing list > > > Insight-developers@public.kitware.com > > > http://public.kitware.com/mailman/listinfo/insight-developers > > > > > > > -- > > Daniel Blezek, Ph.D. > > blezek@crd.ge.com > > Visualization and Computer Vision Program > > Electronic Systems Lab > > GE Corporate Research & Development > > > > > > _______________________________________________ > > Insight-developers mailing list > > Insight-developers@public.kitware.com > > http://public.kitware.com/mailman/listinfo/insight-developers > > > -- Daniel Blezek, Ph.D. blezek@crd.ge.com Visualization and Computer Vision Program Electronic Systems Lab GE Corporate Research & Development From hughett@mercur.uphs.upenn.edu Mon, 26 Mar 2001 12:28:09 -0500 Date: Mon, 26 Mar 2001 12:28:09 -0500 From: Paul Hughett hughett@mercur.uphs.upenn.edu Subject: [Insight-developers] Build broken on Linux I just did an update, make clean, configure, and make on Linux (RH 6.2) using an in-source build. I get the following fatal error (after bypassing a couple of optimization tests that won't compile): make[4]: Entering directory `/home/hughett/work/Insight/Testing/Code/Common' /home/hughett/work/Insight/CMake/Source/CMakeBuildTargets `cd .; pwd`/CMakeLists.txt -S`cd .; pwd` -O`pwd` -H/home/hughett/work/Insight -B/home/hughett/work/Insight CMake Error: error cannot find dependencies for itkTransform.h CMake Error: error cannot find dependencies for itkTransform.h make[4]: *** [CMakeTargets.make] Error 255 Paul Hughett From lng@insightful.com Mon, 26 Mar 2001 12:12:08 -0800 Date: Mon, 26 Mar 2001 12:12:08 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] FW: VC++ memccpy warnings Hi, The following VC++ warnings (see below) are due to inclusion of #include instead of #include Are there any reasons why we can't uniformly use the second method? This change should get rid of about 20+ warnings for VC++. Files using the first method are: \CODE\Common\itkImageConstIteratorWithIndex.h(20):#include \CODE\Common\itkImageIteratorWithIndex.h(20):#include \CODE\Common\itkScalarVector.h(21):#include Cheers, Lydia ------------------------------------------ Compiling... itkMutualInformationMetricTest.cxx C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\memory.h(68) : warning C4273: '_memccpy' : inconsistent dll linkage. dllexport assumed. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\memory.h(69) : warning C4273: 'memchr' : inconsistent dll linkage. dllexport assumed. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\memory.h(70) : warning C4273: '_memicmp' : inconsistent dll linkage. dllexport assumed. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\memory.h(85) : warning C4273: 'memccpy' : inconsistent dll linkage. dllexport assumed. C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\memory.h(86) : warning C4273: 'memicmp' : inconsistent dll linkage. dllexport assumed. Linking... Creating library Release/itkMutualInformationMetricTest.lib and object Release/itkMutualInformationMetricTest.exp From aylward@unc.edu Mon, 26 Mar 2001 16:02:39 -0500 Date: Mon, 26 Mar 2001 16:02:39 -0500 From: Stephen R. Aylward aylward@unc.edu Subject: [Insight-developers] IMPORTANT: pre-commit checking for cvs Hi, If you want - via anonymous ftp, there is a 91K zip file at ftp.rad.unc.edu/pub/users/aylward called tofrodos.zip The zip archive contains source and executable for linux, unix, win, and dos for converting files to/from dos/unix. I tested - it will handle the case of only a few lines having ctrl-m's on the end. A good set of options is todos -fodp -f force overwrite -o overwrite original -d convert dos to unix -p preserve file owner and time (important for CVS) Stephen "Lorensen, William E (CRD)" wrote: > > Folks, > I've added pre-commit check scripts to the cvs repository. Currently there are two pre-commit > checks. > Both operate on txx, cxx, h, htm and html files. > > pre-commit check #1 scans the file for lines with a trailing ctrl-M. These are probably being > inserted by Micorsoft > editors. They are easliy removed with emacs. I'm not sure how to remove them otherwise. > > pre-commit check #2 checks the last line in a file for a newline. This is easliy fixed with any > editor. Go to the end of the file and hit enter. > > If either pre-commit check fails, the entire cvs commit wiill be stopped. > > I hope this will help folks. > > I'm not sure about the robustness of these scripts. Please send me e-mail if you try to commit a file > and the checkers incorrectly block the commit. > > Bill > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From blezek@crd.ge.com Mon, 26 Mar 2001 16:18:33 -0500 (EST) Date: Mon, 26 Mar 2001 16:18:33 -0500 (EST) From: Daniel J. Blezek, Ph.D. blezek@crd.ge.com Subject: [Insight-developers] Build broken on Linux Paul, I find that if I re-run make, this clears up. -dan On Mon, 26 Mar 2001, Paul Hughett wrote: > > I just did an update, make clean, configure, and make on Linux (RH > 6.2) using an in-source build. I get the following fatal error (after > bypassing a couple of optimization tests that won't compile): > > make[4]: Entering directory `/home/hughett/work/Insight/Testing/Code/Common' > /home/hughett/work/Insight/CMake/Source/CMakeBuildTargets `cd .; pwd`/CMakeLists.txt -S`cd .; pwd` -O`pwd` -H/home/hughett/work/Insight -B/home/hughett/work/Insight > CMake Error: error cannot find dependencies for itkTransform.h > CMake Error: error cannot find dependencies for itkTransform.h > make[4]: *** [CMakeTargets.make] Error 255 > > > Paul Hughett > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > -- -- Daniel Blezek, Ph.D. blezek@crd.ge.com Visualization and Computer Vision Program Electronic Systems Lab GE Corporate Research & Development From zhuge@mipg.upenn.edu Mon, 26 Mar 2001 16:42:28 -0600 Date: Mon, 26 Mar 2001 16:42:28 -0600 From: Ying Zhuge zhuge@mipg.upenn.edu Subject: [Insight-developers] Check in Hi, I want to check in our VectorFuzzyConnectednessImageFilter, but I fail. The problem is no repository. I use wincvs under windows 98, the command is: cvs add myfile How can I do? Thanks Ying From chenting@graphics.cis.upenn.edu Mon, 26 Mar 2001 15:58:35 -0600 Date: Mon, 26 Mar 2001 15:58:35 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] the warning message hi! Guys, did any of you into the following warning message? vc98\include\xmemory(64) : warning C4786: 'std::allocator,itk: :VectorContainer >,std::set,std::allocator > > > > >' : identifier was truncated to '255' characters in the debug information d:\program files\microsoft visual studio\vc98\include\xmemory(64) : while compiling class-template member function 'void __thiscall std::allocator,itk::VectorContainer >,std::set,std::allocator > > > > >::deallocate(void *,unsigned int)' how to avoid it? Thanks! ting -----Original Message----- From: Ying Zhuge To: insight-developers@public.kitware.com Date: Monday, March 26, 2001 3:42 PM Subject: [Insight-developers] Check in >Hi, >I want to check in our VectorFuzzyConnectednessImageFilter, but I fail. >The problem is no repository. >I use wincvs under windows 98, the command is: > cvs add myfile > >How can I do? Thanks > >Ying > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From lorensen@crd.ge.com Mon, 26 Mar 2001 16:50:43 -0500 Date: Mon, 26 Mar 2001 16:50:43 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] Build broken on Linux Remove CMakeTargets.make and Cxx/*.cxx Then remake -----Original Message----- From: Paul Hughett [mailto:hughett@mercur.uphs.upenn.edu] Sent: Monday, March 26, 2001 12:28 PM To: insight-developers@public.kitware.com Subject: [Insight-developers] Build broken on Linux I just did an update, make clean, configure, and make on Linux (RH 6.2) using an in-source build. I get the following fatal error (after bypassing a couple of optimization tests that won't compile): make[4]: Entering directory `/home/hughett/work/Insight/Testing/Code/Common' /home/hughett/work/Insight/CMake/Source/CMakeBuildTargets `cd .; pwd`/CMakeLists.txt -S`cd .; pwd` -O`pwd` -H/home/hughett/work/Insight -B/home/hughett/work/Insight CMake Error: error cannot find dependencies for itkTransform.h CMake Error: error cannot find dependencies for itkTransform.h make[4]: *** [CMakeTargets.make] Error 255 Paul Hughett _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From brad.king@kitware.com Mon, 26 Mar 2001 17:10:36 -0500 (EST) Date: Mon, 26 Mar 2001 17:10:36 -0500 (EST) From: Brad King brad.king@kitware.com Subject: [Insight-developers] the warning message > did any of you into the following warning message? > > vc98\include\xmemory(64) : warning C4786: > 'std::allocator raitsInfo<3,float,float,unsigned long,unsigned long,unsigned > long,itk::Point,itk: > :VectorContainer >,std::set long,std::less,std::allocator > > > > >' : > identifier was truncated to '255' characters in the debug information > d:\program files\microsoft visual studio\vc98\include\xmemory(64) : > while compiling class-template member function 'void __thiscall > std::allocator aitsInfo<3,float,float,unsigned l > ong,unsigned long,unsigned > long,itk::Point,itk::VectorContainer long,itk::Point >,std::set long>,std::allocator > > > > >::deallocate(void *,unsigned > int)' > > how to avoid it? That is MSVC's debug symbol truncation warning. If you make sure at least one itk header is included before any other headers (including standard onses) in all your files, this will go away. -Brad From lng@insightful.com Mon, 26 Mar 2001 15:09:47 -0800 Date: Mon, 26 Mar 2001 15:09:47 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] removing files & pre-commit Hi, I have moved mutual information registration over to the new registration framework. I am now trying to get rid of the old files but pre-commit is blocking me - see below I should I go about removing the files? Cheers, Lydia plum:lng:131% rm itkMutualInformationTest.cxx plum:lng:132% cvs remove itkMutualInformationTest.cxx cvs server: scheduling `itkMutualInformationTest.cxx' for removal cvs server: use 'cvs commit' to remove this file permanently plum:lng:133% cvs commit -m"ENH: moved mutual information to new registration framework. This test no longer required" itkMutualInformationTest.cxx grep: itkMutualInformationTest.cxx: No such file or directory tail: itkMutualInformationTest.cxx: No such file or directory ========================================================== itkMutualInformationTest.cxx has does not end with a newline. A newline must be added before you can commit it. ========================================================== cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! From wlorens1@nycap.rr.com Mon, 26 Mar 2001 18:35:42 -0500 Date: Mon, 26 Mar 2001 18:35:42 -0500 From: Bill Lorensen wlorens1@nycap.rr.com Subject: [Insight-developers] removing files & pre-commit I'll have to look into that tomorrow. You try an update. Then add the newline at the end. Then a commit. Bill At 03:09 PM 3/26/01 -0800, Lydia Ng wrote: >Hi, > >I have moved mutual information registration over >to the new registration framework. > >I am now trying to get rid of the old files >but pre-commit is blocking me - see below >I should I go about removing the files? > >Cheers, >Lydia > >plum:lng:131% rm itkMutualInformationTest.cxx >plum:lng:132% cvs remove itkMutualInformationTest.cxx >cvs server: scheduling `itkMutualInformationTest.cxx' for removal >cvs server: use 'cvs commit' to remove this file permanently >plum:lng:133% cvs commit -m"ENH: moved mutual information to new >registration framework. This test no longer required" >itkMutualInformationTest.cxx >grep: itkMutualInformationTest.cxx: No such file or directory >tail: itkMutualInformationTest.cxx: No such file or directory >========================================================== >itkMutualInformationTest.cxx has does not end with a newline. A newline must >be added before you can commit it. >========================================================== >cvs server: Pre-commit check failed >cvs [server aborted]: correct above errors first! > > > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From lng@insightful.com Mon, 26 Mar 2001 16:00:42 -0800 Date: Mon, 26 Mar 2001 16:00:42 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] removing files & pre-commit I got around this problem by: 1) move the file to a temporary directory 2) do cvs remove myfile 3) move the file back - to let pre-commit check it 4) do cvs commit 5) remove the files from working directory Lydia > -----Original Message----- > From: insight-developers-admin@public.kitware.com > [mailto:insight-developers-admin@public.kitware.com]On Behalf Of Bill > Lorensen > Sent: Monday, March 26, 2001 3:36 PM > To: lng@insightful.com; 'Lorensen, William E (CRD)'; > insight-developers@public.kitware.com > Subject: Re: [Insight-developers] removing files & pre-commit > > > I'll have to look into that tomorrow. You try an update. Then > add the newline at the end. Then a commit. > > Bill > > At 03:09 PM 3/26/01 -0800, Lydia Ng wrote: > >Hi, > > > >I have moved mutual information registration over > >to the new registration framework. > > > >I am now trying to get rid of the old files > >but pre-commit is blocking me - see below > >I should I go about removing the files? > > > >Cheers, > >Lydia > > > >plum:lng:131% rm itkMutualInformationTest.cxx > >plum:lng:132% cvs remove itkMutualInformationTest.cxx > >cvs server: scheduling `itkMutualInformationTest.cxx' for removal > >cvs server: use 'cvs commit' to remove this file permanently > >plum:lng:133% cvs commit -m"ENH: moved mutual information to new > >registration framework. This test no longer required" > >itkMutualInformationTest.cxx > >grep: itkMutualInformationTest.cxx: No such file or directory > >tail: itkMutualInformationTest.cxx: No such file or directory > >========================================================== > >itkMutualInformationTest.cxx has does not end with a > newline. A newline must > >be added before you can commit it. > >========================================================== > >cvs server: Pre-commit check failed > >cvs [server aborted]: correct above errors first! > > > > > > > > > >_______________________________________________ > >Insight-developers mailing list > >Insight-developers@public.kitware.com > >http://public.kitware.com/mailman/listinfo/insight-developers > > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From lorensen@crd.ge.com Tue, 27 Mar 2001 07:58:51 -0500 Date: Tue, 27 Mar 2001 07:58:51 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] Dashboard / Registration Luis, The optimizer classes are not building on the intel compiler. Could you please correct the ^M problems: ========================================================== Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:117: /* Initialize Linear part*/ Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:124: { Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:125: m_Parameters[ k++ ] = 0.0; Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:126: } Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:127: else Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:174: Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:190: Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:195: std::cout << std::endl; Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx has ^M's. They must be removed before you can commit. ========================================================== ========================================================== Algorithms/itkImageToImageAffinePatternIntensityRegistration.txx:187: Algorithms/itkImageToImageAffinePatternIntensityRegistration.txx:193:*/ Algorithms/itkImageToImageAffinePatternIntensityRegistration.txx has ^M's. They must be removed before you can commit. ========================================================== ========================================================== BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:109: { BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:110: unsigned int i=0; BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:118: m_SmoothingFilters[ i ]->SetDirection( j ); BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:119: i++; BasicFilters/itkGradientRecursiveGaussianImageFilter.txx has ^M's. They must be removed before you can commit. ========================================================== ========================================================== Numerics/itkGradientDescentOptimizer.txx:170: ParametersType newPosition; Numerics/itkGradientDescentOptimizer.txx has ^M's. They must be removed before you can commit. ========================================================== esopus:lorensen> ~/dis1/CVSROOT/checkCtrlM */*.h ========================================================== Algorithms/itkImageToImageAffineMeanSquaresRegistration.h:113: typedef GradientDescentOptimizer OptimizerType; Algorithms/itkImageToImageAffineMeanSquaresRegistration.h:120: Algorithms/itkImageToImageAffineMeanSquaresRegistration.h has ^M's. They must be removed before you can commit. ========================================================== ========================================================== Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:21:#include "itkMultipleValuedNonLinearOptimizer.h" Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:92: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:94: /** Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:95: * MeasureType typedef. Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:96: */ Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:97: typedef typename TCostFunction::MeasureType MeasureType; Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:98: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:99: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:100: /** Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:101: * GradientType typedef. Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:102: */ Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:103: typedef typename TCostFunction::DerivativeType DerivativeType; Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:104: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:105: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:215: { Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:218: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h has ^M's. They must be removed before you can commit. ========================================================== -----Original Message----- From: Luis Ibanez [mailto:ibanez@cs.unc.edu] Sent: Monday, March 26, 2001 10:16 AM To: insight-developers@public.kitware.com Subject: [Insight-developers] Dashboard / Registration Hi, We are changing the part of the API in the registration framework. Previously a VectorContainer was used to pass the parameters of the spatial transformation to the optimizers. This was impractical because VectorContainer elements has to be accessed through iterators. So, now the framework is templated the parameters type, and it could be any type with the operator[]() defined. The bad news is that the changes are not completed yet so there are a lot of new error messages on the dashboard, coming from these modifications. We are working now on fixing them.... Luis _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From millerjv@crd.ge.com Tue, 27 Mar 2001 08:40:05 -0500 Date: Tue, 27 Mar 2001 08:40:05 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Another coding pattern to watch for I know we agreed that GE/Kitware would hold off fixing other people's compiler errors but I couldn't get a build together in order help other people with their requests. So I had to fix a number of problems in Transformation, AffineTransform, AffineRegistrationTransform. The pattern causing the problem was a mismatch between the template parameters in the declaration and the template parameters in the definition. For instance, the header file would have template class .... and the txx file would have template Some of the compilers, particularly the Intel compiler, would not accept this deviation. Please be careful with how you declare and define your template parameters. Jim Miller _____________________________________ Computer Graphics & Systems Program GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 <> begin 600 James Miller (E-mail).vcf M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..DUI;&QE7-T96US(%!R;V=R86T[0DQ$1R!+5RP@4DT@0S(Q.$(] M,$0],$%03R!";W@@.#M38VAE;F5C/0T*=&%D>3M.63LQ,C,P,3M5;FET960@ M4W1A=&5S(&]F($%M97)I8V$-"DQ!0D5,.U=/4DL[14Y#3T1)3D<]455/5$5$ M+5!224Y404),13I#;VUP=71E2P@3ED@,3(S,#$],$0],$%5;FET960@4W1A=&5S(&]F M($%M97)I8V$-"D5-04E,.U!2148[24Y415).150Z;6EL;&5R:G9`8W)D+F=E G+F-O;0T*4D56.C(P,#`P,3(X5#$V,C8U-EH-"D5.1#I60T%21`T* ` end From millerjv@crd.ge.com Tue, 27 Mar 2001 10:20:37 -0500 Date: Tue, 27 Mar 2001 10:20:37 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Dashboard / Registration Luis, The StartOptimization() method of an optimizer (at least the ConjugateGradientOptimizer) takes a const reference to ParametersType. However, your tests are passing in a SmartPointer to ParametersType. The SmartPointer code will cast down to a raw pointer but I do not think it will derefence the pointer automatically to produce the reference type needed for StartOptimization(). The tests could be changed from foo->StartOptimization( initialValue ); to foo->StartOptimization( *initialValue ); or the StartOptimization() method could be changed to take a pointer rather than a reference. Jim -----Original Message----- From: Lorensen, William E (CRD) Sent: Tuesday, March 27, 2001 7:59 AM To: 'luis.ibanez@ieee.org'; insight-developers@public.kitware.com Subject: RE: [Insight-developers] Dashboard / Registration Luis, The optimizer classes are not building on the intel compiler. Could you please correct the ^M problems: ========================================================== Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:117: /* Initialize Linear part*/ Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:124: { Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:125: m_Parameters[ k++ ] = 0.0; Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:126: } Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:127: else Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:174: Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:190: Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx:195: std::cout << std::endl; Algorithms/itkImageToImageAffineMeanSquaresRegistration.txx has ^M's. They must be removed before you can commit. ========================================================== ========================================================== Algorithms/itkImageToImageAffinePatternIntensityRegistration.txx:187: Algorithms/itkImageToImageAffinePatternIntensityRegistration.txx:193:*/ Algorithms/itkImageToImageAffinePatternIntensityRegistration.txx has ^M's. They must be removed before you can commit. ========================================================== ========================================================== BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:109: { BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:110: unsigned int i=0; BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:118: m_SmoothingFilters[ i ]->SetDirection( j ); BasicFilters/itkGradientRecursiveGaussianImageFilter.txx:119: i++; BasicFilters/itkGradientRecursiveGaussianImageFilter.txx has ^M's. They must be removed before you can commit. ========================================================== ========================================================== Numerics/itkGradientDescentOptimizer.txx:170: ParametersType newPosition; Numerics/itkGradientDescentOptimizer.txx has ^M's. They must be removed before you can commit. ========================================================== esopus:lorensen> ~/dis1/CVSROOT/checkCtrlM */*.h ========================================================== Algorithms/itkImageToImageAffineMeanSquaresRegistration.h:113: typedef GradientDescentOptimizer OptimizerType; Algorithms/itkImageToImageAffineMeanSquaresRegistration.h:120: Algorithms/itkImageToImageAffineMeanSquaresRegistration.h has ^M's. They must be removed before you can commit. ========================================================== ========================================================== Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:21:#include "itkMultipleValuedNonLinearOptimizer.h" Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:92: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:94: /** Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:95: * MeasureType typedef. Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:96: */ Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:97: typedef typename TCostFunction::MeasureType MeasureType; Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:98: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:99: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:100: /** Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:101: * GradientType typedef. Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:102: */ Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:103: typedef typename TCostFunction::DerivativeType DerivativeType; Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:104: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:105: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:215: { Numerics/itkMultipleValuedNonLinearVnlOptimizer.h:218: Numerics/itkMultipleValuedNonLinearVnlOptimizer.h has ^M's. They must be removed before you can commit. ========================================================== -----Original Message----- From: Luis Ibanez [mailto:ibanez@cs.unc.edu] Sent: Monday, March 26, 2001 10:16 AM To: insight-developers@public.kitware.com Subject: [Insight-developers] Dashboard / Registration Hi, We are changing the part of the API in the registration framework. Previously a VectorContainer was used to pass the parameters of the spatial transformation to the optimizers. This was impractical because VectorContainer elements has to be accessed through iterators. So, now the framework is templated the parameters type, and it could be any type with the operator[]() defined. The bad news is that the changes are not completed yet so there are a lot of new error messages on the dashboard, coming from these modifications. We are working now on fixing them.... Luis _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From ibanez@cs.unc.edu Tue, 27 Mar 2001 15:10:52 -0500 Date: Tue, 27 Mar 2001 15:10:52 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Amoeba optimizer, Hi, I'm having trouble with the Amoeba optimizer. vnl optimizers have been adapted by creating an adaptor cost function like: +-------------------+ | vnl_cost_function | +-------------------+ ^ | +-----------------------------+ | vnlCostFunctionAdaptor | +--------------+ | has a CostFunction::Pointer |-->| CostFunction | +-----------------------------+ +--------------+ Then, the pointer to vnlCostFunction is passed to the specific vnl_optimizer. It seems that Amoeba makes a copy of itself, and assumes that with the cost_function has no state associated with it. So, it basically creates brand new vnl_cost_function (only respecting the type). That causes that the real CostFunction pointer is never passed to the real optimizer... Any suggestions ... Thanks Luis From millerjv@crd.ge.com Tue, 27 Mar 2001 17:12:09 -0500 Date: Tue, 27 Mar 2001 17:12:09 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Amoeba optimizer, I'm not seeing that. It looks as though itkAmoebaOptimizer has two ivars, a cost function adaptor (which is a subclass of vnl_cost_function) and a vnl_amoeba. Upon construction of itkAmoebaOptimizer is passes the cost_function_adaptor ivar to the vnl_amoeba ivar. vnl_amoeba caches a pointer to this cost_function_adaptor. An itk user, can then set the cost function to use on the itkAmoebaOptimizer which is stored in the cost_function_adaptor. When vnl_amoeba references its function to optimize (which is the cost_function_adaptor), the cost_function_adaptor delegates the call to the cost cost function that the itk user specified to the itkAmoebaOptimizer. So, it looks to me that the itkAmoebaOptimizer should work fine. While the real optimizer never accesses the real cost function, the calls should be delegated properly. Jim -----Original Message----- From: Luis Ibanez [mailto:ibanez@cs.unc.edu] Sent: Tuesday, March 27, 2001 3:11 PM To: insight-developers@public.kitware.com Subject: [Insight-developers] Amoeba optimizer, Hi, I'm having trouble with the Amoeba optimizer. vnl optimizers have been adapted by creating an adaptor cost function like: +-------------------+ | vnl_cost_function | +-------------------+ ^ | +-----------------------------+ | vnlCostFunctionAdaptor | +--------------+ | has a CostFunction::Pointer |-->| CostFunction | +-----------------------------+ +--------------+ Then, the pointer to vnlCostFunction is passed to the specific vnl_optimizer. It seems that Amoeba makes a copy of itself, and assumes that with the cost_function has no state associated with it. So, it basically creates brand new vnl_cost_function (only respecting the type). That causes that the real CostFunction pointer is never passed to the real optimizer... Any suggestions ... Thanks Luis _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From chenting@graphics.cis.upenn.edu Tue, 27 Mar 2001 20:17:03 -0600 Date: Tue, 27 Mar 2001 20:17:03 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] about update method This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C0B6FA.E367BE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! I juse checked in an itkHybridFilter which integrates the deformable model with region based models. It supposed to be a recursive filter. but when I use the following code to test. I found the update() call do not lead to the generatedata method, even though I call modified method just before update. can any of you try to help me find where is the problem? Thanks a lot! ting ------=_NextPart_000_0016_01C0B6FA.E367BE00 Content-Type: text/plain; name="Text1.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Text1.txt" #ifdef _MSC_VER #pragma warning ( disable : 4786 ) #endif #include "itkImage.h" #include "itkScalar.h" #include "itkVector.h" #include "vnl/vnl_matrix_fixed.h" #include "itkSimpleImageRegionIterator.h" #include "itkGaussianSupervisedClassifier.h" #include "itkGibbsPriorFilter.h" #include "itkDeformableMesh.h" #include "itkBalloonForceFilter.h" #include "itkTriangleCell.h" #include "itkImage.h" #include "itkDefaultStaticMeshTraits.h" #include "itkSimpleImageRegionIterator.h" #include "itkHybridFilter.h" #include #include #include #define IMGWIDTH 20 #define IMGHEIGHT 20 #define NFRAMES 1 #define NUMBANDS 1 =20 #define NDIMENSION 3 #define NUM_CLASSES 3 #define MAX_NUM_ITER 20 typedef itk::DeformableMesh DMesh; typedef itk::Mesh MyMesh; typedef itk::BalloonForceFilter BFilter; typedef itk::TriangleCell = TriCell; int main(){ unsigned short TestImage [400]=3D{ 297,277,317,289,300,312,306,283,282,308,308,342,335,325,315,300,304,318,3= 07,308, 319,276,311,282,309,273,308,277,296,313,308,333,322,317,302,330,339,340,3= 25,315, 272,316,296,299,298,310,271,319,315,280,338,342,349,349,330,319,313,314,3= 42,301, 274,274,312,282,277,303,313,300,275,292,341,336,324,310,337,323,322,347,3= 37,305, 296,272,304,304,281,304,302,284,315,270,325,349,337,317,308,332,324,303,3= 34,325, 291,272,289,317,289,310,305,316,292,307,307,343,341,329,309,308,340,323,3= 07,325, 274,286,282,291,270,296,274,288,274,275,341,301,325,333,321,305,347,346,3= 27,317, 282,315,270,314,290,304,297,304,309,290,309,338,341,319,325,344,301,349,3= 28,302, 314,289,296,270,274,277,317,280,278,285,315,347,314,316,307,336,341,335,3= 30,337, 281,291,317,317,302,304,272,277,318,319,305,322,337,334,327,303,321,310,3= 34,314, 321,311,328,326,331,308,325,348,334,346,309,316,308,349,322,349,304,331,3= 04,321, 346,302,344,314,311,338,320,310,331,330,322,323,329,331,342,341,331,336,3= 28,318, 309,336,327,345,312,309,330,334,329,317,324,304,337,330,331,334,340,307,3= 28,343, 345,330,336,302,333,348,315,328,315,308,305,343,342,337,307,316,303,303,3= 32,341, 327,322,320,314,323,325,307,316,336,315,341,347,343,336,315,347,306,303,3= 39,326, 330,347,303,343,332,316,305,325,311,314,345,327,333,305,324,318,324,339,3= 25,319, 334,326,330,319,300,335,305,331,343,324,337,324,319,339,327,317,347,331,3= 08,318, 306,337,347,330,301,316,302,331,306,342,343,329,336,342,300,306,335,330,3= 10,303, 308,331,317,315,318,333,340,340,326,330,339,345,307,331,320,312,306,342,3= 03,321, 328,315,327,311,315,305,340,306,314,339,344,339,337,330,318,342,311,343,3= 11,312 }; // unsigned short TestImage1[400]; typedef itk::Image,NDIMENSION> = VecImageType;=20 typedef itk::Image ClassImageType;=20 typedef itk::HybridFilter = HybridFilterType; HybridFilterType::Pointer hybridFilter =3D HybridFilterType::New(); DMesh::Pointer m_Mesh(DMesh::New()); BFilter::Pointer m_Filter =3D BFilter::New(); hybridFilter->SetBalloonForceFilter(m_Filter); VecImageType::Pointer vecImage =3D VecImageType::New(); VecImageType::SizeType vecImgSize =3D { IMGWIDTH , IMGHEIGHT, NFRAMES = }; VecImageType::IndexType index =3D VecImageType::IndexType::ZeroIndex; VecImageType::RegionType region; region.SetSize( vecImgSize ); region.SetIndex( index ); vecImage->SetLargestPossibleRegion( region ); vecImage->SetBufferedRegion( region ); vecImage->Allocate(); // setup the iterators typedef VecImageType::PixelType::VectorType VecPixelType; enum { VecImageDimension =3D VecImageType::ImageDimension }; typedef itk::SimpleImageRegionIterator< VecImageType > VecIterator; VecIterator outIt( vecImage, vecImage->GetBufferedRegion() ); outIt.Begin(); //Set up the vector to store the image data typedef VecImageType::PixelType DataVector; DataVector dblVec;=20 = //-----------------------------------------------------------------------= --- //Manually create and store each vector = //-----------------------------------------------------------------------= --- int i =3D 0; while ( !outIt.IsAtEnd() ) {=20 dblVec[0] =3D TestImage[i];=20 outIt.Set(dblVec);=20 ++outIt; i++; } //--------------------------------------------------------------- //Generate the initial training data //--------------------------------------------------------------- =20 ClassImageType::Pointer classImage =3D ClassImageType::New(); ClassImageType::SizeType classImgSize =3D { IMGWIDTH , IMGHEIGHT, = NFRAMES }; ClassImageType::IndexType classindex =3D = ClassImageType::IndexType::ZeroIndex; ClassImageType::RegionType classregion; classregion.SetSize( classImgSize ); classregion.SetIndex( classindex ); classImage->SetLargestPossibleRegion( classregion ); classImage->SetBufferedRegion( classregion ); classImage->Allocate(); // setup the iterators typedef ClassImageType::PixelType ClassImagePixelType; unsigned int ClassImageDimension =3D NDIMENSION; typedef itk::SimpleImageRegionIterator = ClassImageIterator; ClassImageIterator classoutIt( classImage, = classImage->GetBufferedRegion() ); classoutIt.Begin(); i =3D 0; while ( !classoutIt.IsAtEnd() ) { classoutIt.Set( 0 ); if ( (i%IMGWIDTH<7) && (i%IMGWIDTH>2) &&=20 (i/IMGWIDTH<7) && (i/IMGWIDTH>2)) { classoutIt.Set( 1 ); } if ( (i%IMGWIDTH<17) && (i%IMGWIDTH>12) &&=20 (i/IMGWIDTH<17) && (i/IMGWIDTH>12)) { classoutIt.Set( 2 ); } ++classoutIt; i++; } = //--------------------------------------------------------------------- // Multiband data is now available in the right format = //--------------------------------------------------------------------- typedef=20 itk::Classifier::Pointer=20 ClassifierType; //Instantiate the classifier to be used typedef itk::GaussianSupervisedClassifier = GaussianSupervisedClassifierType; GaussianSupervisedClassifierType::Pointer=20 myGaussianClassifier =3D GaussianSupervisedClassifierType::New(); //Set the Gibbs Prior labeller typedef itk::GibbsPriorFilter = GibbsPriorFilterType; GibbsPriorFilterType::Pointer applyGibbsImageFilter =3D = GibbsPriorFilterType::New(); hybridFilter->SetGibbsPriorFilter(applyGibbsImageFilter); //Set the Gibbs Prior labeller parameters applyGibbsImageFilter->SetNumClasses(NUM_CLASSES); applyGibbsImageFilter->SetMaxNumIter(MAX_NUM_ITER); applyGibbsImageFilter->SetErrorTollerance(0.00); applyGibbsImageFilter->SetClusterSize(10); applyGibbsImageFilter->SetBoundaryGradient(6); applyGibbsImageFilter->SetObjectLabel(1); =20 applyGibbsImageFilter->SetInput(vecImage); applyGibbsImageFilter ->SetClassifier((ClassifierType) myGaussianClassifier );=20 //Since a suvervised classifier is used, it requires a training image applyGibbsImageFilter->SetTrainingImage(classImage); =20 = //--------------------------------------------------------------------- // Define the deformable Mesh = //--------------------------------------------------------------------- DMesh::Pointer force(DMesh::New()); DMesh::Pointer displace(DMesh::New()); DMesh::Pointer derive(DMesh::New()); DMesh::Pointer normal(DMesh::New()); DMesh::Pointer location(DMesh::New()); =20 m_Mesh->SetDefault(); m_Mesh->SetResolution(1, 40); m_Mesh->SetScale(2.0, 2.0, 1.0); m_Mesh->SetCenter(5, 5, 0); m_Mesh->Allocate(); = //--------------------------------------------------------------------- // Define the Balloon Force filter = //--------------------------------------------------------------------- m_Filter->SetInput(m_Mesh); // m_Filter->SetPotential(outClassImage); hybridFilter->SetPotential(); m_Filter->SetImageOutput(classImage); // hybridFilter->SetObjectRegion(); m_Filter->SetResolution(1, 40, 1); m_Filter->SetCenter(5, 5, 0); m_Filter->SetLocations(location); m_Filter->SetForces(force); m_Filter->SetNormals(normal); m_Filter->SetDisplacements(displace); m_Filter->SetDerives(derive); hybridFilter->Update(); return 0; } ------=_NextPart_000_0016_01C0B6FA.E367BE00-- From ibanez@cs.unc.edu Wed, 28 Mar 2001 02:16:38 -0500 Date: Wed, 28 Mar 2001 02:16:38 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Optimizers / Registration Hi, the Optimizers in Numerics and the registration methods in Algorithms are now compiling under VC++ and gcc (cygwin). The change of parameters allows now to use any type with operator[]() defined, as carrier for the cost function parameters. Luis From lorensen@crd.ge.com Wed, 28 Mar 2001 07:47:01 -0500 Date: Wed, 28 Mar 2001 07:47:01 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] Dashboard Status, Improving but still poor Folks, We need to drive the errors to zero on all platforms. Please check each platform to see if your code is compiling OK. Things may be fine on your platform, but the code must compile on all of them. http://public.kitware.com/Insight/Testing/HTML/TestingResults/Dashboard/MostRecentResults-Nightly/Das hboard.html If you need help, post your questions to the list. Bill From ibanez@cs.unc.edu Wed, 28 Mar 2001 09:52:05 -0500 Date: Wed, 28 Mar 2001 09:52:05 -0500 From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] ICE / itkTranslationTransform Hi, > > If you need help, post your questions to the list. > I will need some help. the class itkTranslationTransform is generating a ICE in Visual C++. It is compiling fine with Cygwin gcc though. This class is basically a simplification of itkAffineTransform, so the structure is almost the same. The error appears on the ostream operator<< () line 96 itkTranslationTransform.h Any ideas ? Thanks From lng@insightful.com Wed, 28 Mar 2001 11:10:01 -0800 Date: Wed, 28 Mar 2001 11:10:01 -0800 From: Lydia Ng lng@insightful.com Subject: [Insight-developers] ICE / itkTranslationTransform The problem seems to be related to one describe by Brad in a previous posting. ---Previous posting------ --------------------------------------------------------------------------- // This version results in the INTERNAL COMPILER ERROR. namespace N { class A {}; } class B { void f(N::A); }; template class C {}; // ICE here, on the ">" after "int V". --------------------------------------------------------------------------- -------------------------- In this case the problem seems to be with the definition of: std::ostream & PrintSelf(std::ostream &s) const; in itkTranslationTransform.h If you move above the definition of PrintSelf up one the ICE goes away - since we are no longer in the above situation. Definitely a compiler problem! I have checked in the change to itkTranslationTransform.h to see if how it goes in the continuous VC++ dashboard. Lydia > -----Original Message----- > From: insight-developers-admin@public.kitware.com > [mailto:insight-developers-admin@public.kitware.com]On Behalf Of Luis > Ibanez > Sent: Wednesday, March 28, 2001 6:52 AM > To: insight-developers@public.kitware.com > Subject: [Insight-developers] ICE / itkTranslationTransform > > > Hi, > > > > > If you need help, post your questions to the list. > > > > I will need some help. > > the class itkTranslationTransform is generating > a ICE in Visual C++. > > It is compiling fine with Cygwin gcc though. > > This class is basically a simplification of > itkAffineTransform, so the structure is almost > the same. > > The error appears on the ostream operator<< () > line 96 itkTranslationTransform.h > > Any ideas ? > > Thanks > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From dmsst59@pitt.edu Wed, 28 Mar 2001 15:15:46 -0500 Date: Wed, 28 Mar 2001 15:15:46 -0500 From: Damion Shelton dmsst59@pitt.edu Subject: [Insight-developers] linked list implementation Hi all... Our work on a linked list pixel type is progressing well, but I have a question of style... would it be considered "uncouth" to use our own linked list class (which already exists), rather than the STL list class? After playing with the STL implementation, the overhead of having to write an allocator and iterator seems a bit wasteful. Here's the pro and con arguments, from my POV, re. STL vs. our own class: Pros: Our linked list does not need the flexibility of templating, since it's only intended to hold one type of object, and I find the STL method of accessing list entries a bit counterintuitive. We would have to derive a specialized class from list in any case, since our "pixels" need to be able to do more than "ordinary" pixels. Cons: We would be duplicating existing functionality (sort of - we would still need to specialize the list class and add extra functionality) The STL implementation would in theory be more general / promote recycling of our work. This seems to be a problem analogous to the ongoing matrix discussion: do we rewrite functionality for the sake of clarity or wrap for the sake of portability? Any thoughts? -Damion- From bill.hoffman@kitware.com Wed, 28 Mar 2001 15:33:28 -0500 Date: Wed, 28 Mar 2001 15:33:28 -0500 From: William A. Hoffman bill.hoffman@kitware.com Subject: [Insight-developers] linked list implementation I would say this should be a last resort. TargetJr had 12 or so lists in it, and it was VERY confusing to users. I don't really see the strong case for using you own list in this case. 1. stl is templated, but it is written, and when you instantiate it over your type, it will be a single class. 2. you may not like the interface, but ever student of C++ will learn that interface, and think that your interface is non-standard and strange. 3. Why do you have to write an allocator and iterator? They should already be part of the stl list. As long as the memory foot print and storage is not an issue, I would say go with the standard. Insight is complicated enough, we don't want people to have to learn our own list class. With the matrix class, there is no standard. The problem is with the memory foot print of the vxl vector. -Bill At 03:15 PM 3/28/01 -0500, Damion Shelton wrote: >Hi all... > >Our work on a linked list pixel type is progressing well, but I have a >question of style... would it be considered "uncouth" to use our own linked >list class (which already exists), rather than the STL list class? After >playing with the STL implementation, the overhead of having to write an >allocator and iterator seems a bit wasteful. Here's the pro and con >arguments, from my POV, re. STL vs. our own class: > >Pros: > >Our linked list does not need the flexibility of templating, since it's only >intended to hold one type of object, and I find the STL method of accessing >list entries a bit counterintuitive. > >We would have to derive a specialized class from list in any case, since our >"pixels" need to be able to do more than "ordinary" pixels. > >Cons: > >We would be duplicating existing functionality (sort of - we would still >need to specialize the list class and add extra functionality) > >The STL implementation would in theory be more general / promote recycling >of our work. > > >This seems to be a problem analogous to the ongoing matrix discussion: do we >rewrite functionality for the sake of clarity or wrap for the sake of >portability? Any thoughts? > >-Damion- > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers From millerjv@crd.ge.com Wed, 28 Mar 2001 16:05:59 -0500 Date: Wed, 28 Mar 2001 16:05:59 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] linked list implementation I side with Bill. The default allocator should be fine for your application and as he pointed out the iterators are already provided. Why do you think that you need derive from stl::list? As for the method of accessing a list, iterators are the way people implement/use link lists now. The concept of separating your position in a list from the list container was a major development in reusable code. Jim -----Original Message----- From: William A. Hoffman [mailto:bill.hoffman@kitware.com] Sent: Wednesday, March 28, 2001 3:33 PM To: Damion Shelton; insight-developers@public.kitware.com Subject: Re: [Insight-developers] linked list implementation I would say this should be a last resort. TargetJr had 12 or so lists in it, and it was VERY confusing to users. I don't really see the strong case for using you own list in this case. 1. stl is templated, but it is written, and when you instantiate it over your type, it will be a single class. 2. you may not like the interface, but ever student of C++ will learn that interface, and think that your interface is non-standard and strange. 3. Why do you have to write an allocator and iterator? They should already be part of the stl list. As long as the memory foot print and storage is not an issue, I would say go with the standard. Insight is complicated enough, we don't want people to have to learn our own list class. With the matrix class, there is no standard. The problem is with the memory foot print of the vxl vector. -Bill At 03:15 PM 3/28/01 -0500, Damion Shelton wrote: >Hi all... > >Our work on a linked list pixel type is progressing well, but I have a >question of style... would it be considered "uncouth" to use our own linked >list class (which already exists), rather than the STL list class? After >playing with the STL implementation, the overhead of having to write an >allocator and iterator seems a bit wasteful. Here's the pro and con >arguments, from my POV, re. STL vs. our own class: > >Pros: > >Our linked list does not need the flexibility of templating, since it's only >intended to hold one type of object, and I find the STL method of accessing >list entries a bit counterintuitive. > >We would have to derive a specialized class from list in any case, since our >"pixels" need to be able to do more than "ordinary" pixels. > >Cons: > >We would be duplicating existing functionality (sort of - we would still >need to specialize the list class and add extra functionality) > >The STL implementation would in theory be more general / promote recycling >of our work. > > >This seems to be a problem analogous to the ongoing matrix discussion: do we >rewrite functionality for the sake of clarity or wrap for the sake of >portability? Any thoughts? > >-Damion- > > >_______________________________________________ >Insight-developers mailing list >Insight-developers@public.kitware.com >http://public.kitware.com/mailman/listinfo/insight-developers _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From chenting@graphics.cis.upenn.edu Wed, 28 Mar 2001 16:11:56 -0600 Date: Wed, 28 Mar 2001 16:11:56 -0600 From: Ting Chen chenting@graphics.cis.upenn.edu Subject: [Insight-developers] SetInput vs GetOutput I found it is not ok to write the following code class1 is belong to class2, I want to transfer the input of class2 to class1 class1->SetInput(class2->GetInput()) while it is ok if I write: classinputtype::pointer c1input(class2->GetInput()); class1->SetInput(c1Input); anyone can explain this to me? Thanks! ting From ibanez@cs.unc.edu Thu, 29 Mar 2001 02:13:03 -0500 (EST) Date: Thu, 29 Mar 2001 02:13:03 -0500 (EST) From: Luis Ibanez ibanez@cs.unc.edu Subject: [Insight-developers] Domain verification in Iterators Hi, I just find a bug produced by initializing an iterator with a region that falls outside the image. Iterators during construction could verify that the region is fully contained in GetBufferedRegion(). This is not done at this moment. It should not be too costly because is done only once. (at construction, or eventualy inside the Begin() method). Then they could throw an exeption if the domain is wrong. Any suggestions ? Luis From zhuge@mipg.upenn.edu Thu, 29 Mar 2001 10:25:09 -0600 Date: Thu, 29 Mar 2001 10:25:09 -0600 From: Ying Zhuge zhuge@mipg.upenn.edu Subject: [Insight-developers] testing Hi, We checked in our class itkVectorFuzzyConnectednessImageFilter, it has been tested OK in our group( Upenn and Columbia) . Can anybody tell me why it can not be passed ? BTW, I just modified the return value of testing program from 1 to 0. any other problems? Thanks! Ying From millerjv@crd.ge.com Thu, 29 Mar 2001 11:17:20 -0500 Date: Thu, 29 Mar 2001 11:17:20 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Simplifying traits I am still leaning towards eliminating scalar traits. I would really like to get back to standard pointer/iterator semantics. foo = *it; *it = garf; The effect of this would be: 1. DataAccessors would have to return a reference. This would mean that data accessors could only be used to map memory (i.e. access a scalar from a pixel that held a scalar and vector). DataAccessors could not be used for casting or for calculating a function of a pixel. 2. A given filter would assume its inputs were of the correct "type". If a filter is expecting to work on scalars, dereferencing an iterator would have to return a scalar. If a filter is expecting to work on vectors, derefencing an iterator would have to return a vector. If an algorithm needed both scalars and vectors, they would be passed in as separate inputs. The reason for leaning in this direction is that the syntax for accessing a pixel within a filter is getting rather complicated. Furthermore, we are having reference and const issues in the current framework. Last night I was working on a line of code that read value = (double) ScalarTraits::GetScalar( it.Get() ); and the compiler was giving the error: GetScalar() cannot convert parameter 1 from "float" to "float &" Note that this error wasn't even a const issue! Just a reference issue. Jim -----Original Message----- From: Brad King [mailto:brad.king@kitware.com] Sent: Friday, March 23, 2001 4:37 PM To: Insight Developers Subject: [Insight-developers] Simplifying traits Hello, all: Here are some ideas to consider before deciding to throw out the use of ScalarTraits an VectorTraits. Our current approach is not the simplest approach to using traits. We can make traits easier to use. Consider the following filter: template class MyFilter { public: typedef TInputImage InputImageType; typedef typename InputImageType::PixelType InputPixelType; typedef ScalarTraits PixelScalarTraits; typedef typename PixelScalarTraits::ScalarValueType PixelScalarValueType; inline static PixelScalarValueType& GetPixelScalar(PixelType& p) { return PixelScalarTraits::GetScalar(p); } inline static void SetPixelScalar(PixelType& p, const PixelScalarValueType& v) { PixelScalarTraits::SetScalar(p, v); } // .... }; Note that the function definitions can be put in ImageToImageFilter and be inherited into other filters. Then, with minimal setup work, a filter implementation can access a Pixel's scalar value like this: PixelScalarValueType v = GetPixelScalar(myPixel); // do something to v. SetPixelScalar(myPixel, v); This is in place of the current code: typename ScalarTraits::ScalarValueType v = ScalarTraits::GetScalar(myPixel); // do something to v. ScalarTraits::SetScalar(myPixel, v); Also, I have noticed that there are a bunch of extra ScalarTrait specializations for more than the basic types. An example is "ScalarTraits< RGBPixel >". These should not be done, because if someone wants to use an RGBPixel with a template argument other than those defined in itkPixelTraits.h, they will have to figure out how to write their own trait specialization for it. Currently, this can be solved (I think) by putting the proper typedefs (ValueType, etc) into RGBPixel and letting the primary template of ScalarTraits handle it from there. The "real" way to do such a specialization of the ScalarTraits for RGBPixel would be to do a partial specialization: template class ScalarTraits< RGBPixel > { /* ... */ }; Unfortunately, not all of our compilers support partial specialization, so we can't do this. The other option is to not require scalar traits to be a speicalization of ScalarTraits at all. If instead we make such traits a template argument, then any class can be defined and passed to the argument: template > class Image { public: typedef TPixel PixelType; enum { Dimension = VDimension }; typedef TPixelTraits PixelTraits; // .... }; Then, filters could pull the Pixel traits out of their image template parameters: template class MyFilter { public: typedef TInputImage InputImageType; typedef typename InputImageType::PixelTraits InputPixelTraits; // ... use traits as in previous MyFilter example. }; Making traits a template argument is currently the approach that the Mesh class uses. It even encapsulates the "CellTraits" as a member of the "MeshTraits" template argument. We could make the same relationship for the Image. That is: template class DefaultImageTraits { public: typedef TPixel PixelType; enum { Dimension = VDimension }; typedef DefaultPixelTraits PixelTraits; // ... other useful traits? }; template > class Image { public: typedef TImageTraits ImageTraits; typedef typename ImageTraits::PixelType PixelType; typedef typename ImageTraits::PixelTraits PixelTraits; // ... }; Assume that we have encapsulated both the current scalar and vector traits into "DefaultPixelTraits". Thoughts, anyone? -Brad _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From millerjv@crd.ge.com Thu, 29 Mar 2001 11:36:22 -0500 Date: Thu, 29 Mar 2001 11:36:22 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Network problems Folks, We have been having network problems at our facility all day. This is keeping us from reliably transmitting the testing results to the dashboard. Our support staff is noncommittal on when our dns system will be back online. Sorry for the inconvenience for those relying on the Continuous Dashboard. Jim Miller _____________________________________ Computer Graphics & Systems Program GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 <> begin 600 James Miller (E-mail).vcf M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..DUI;&QE7-T96US(%!R;V=R86T[0DQ$1R!+5RP@4DT@0S(Q.$(] M,$0],$%03R!";W@@.#M38VAE;F5C/0T*=&%D>3M.63LQ,C,P,3M5;FET960@ M4W1A=&5S(&]F($%M97)I8V$-"DQ!0D5,.U=/4DL[14Y#3T1)3D<]455/5$5$ M+5!224Y404),13I#;VUP=71E2P@3ED@,3(S,#$],$0],$%5;FET960@4W1A=&5S(&]F M($%M97)I8V$-"D5-04E,.U!2148[24Y415).150Z;6EL;&5R:G9`8W)D+F=E G+F-O;0T*4D56.C(P,#`P,3(X5#$V,C8U-EH-"D5.1#I60T%21`T* ` end From aylward@unc.edu Thu, 29 Mar 2001 14:11:14 -0500 Date: Thu, 29 Mar 2001 14:11:14 -0500 From: Stephen R. Aylward aylward@unc.edu Subject: [Insight-developers] Simplifying traits I think this is a great idea - the user has to assume some responsibility for what they are trying to do. Now if only we could have the image class return an iterator so as to better resemble the stl standard....perhaps the simple region iterator or linear iterator. Then, some of our methods could treat an image as it does any type of stl container. Stephen "Miller, James V (CRD)" wrote: > > I am still leaning towards eliminating scalar traits. I would really like to get back to standard > pointer/iterator semantics. > > foo = *it; > *it = garf; > > The effect of this would be: > > 1. DataAccessors would have to return a reference. This would mean that data accessors could only be > used to map memory (i.e. access a scalar from a pixel that held a scalar and vector). DataAccessors > could not be used for casting or for calculating a function of a pixel. > > 2. A given filter would assume its inputs were of the correct "type". If a filter is expecting to > work on scalars, dereferencing an iterator would have to return a scalar. If a filter is expecting > to work on vectors, derefencing an iterator would have to return a vector. If an algorithm needed > both scalars and vectors, they would be passed in as separate inputs. > > The reason for leaning in this direction is that the syntax for accessing a pixel within a filter is > getting rather complicated. Furthermore, we are having reference and const issues in the current > framework. Last night I was working on a line of code that read > > value = (double) ScalarTraits::GetScalar( it.Get() ); > > and the compiler was giving the error: > > GetScalar() cannot convert parameter 1 from "float" to "float &" > > Note that this error wasn't even a const issue! Just a reference issue. > > Jim > > -----Original Message----- > From: Brad King [mailto:brad.king@kitware.com] > Sent: Friday, March 23, 2001 4:37 PM > To: Insight Developers > Subject: [Insight-developers] Simplifying traits > > Hello, all: > > Here are some ideas to consider before deciding to throw out the use of > ScalarTraits an VectorTraits. Our current approach is not the simplest > approach to using traits. > > We can make traits easier to use. Consider the following filter: > > template > class MyFilter > { > public: > typedef TInputImage InputImageType; > typedef typename InputImageType::PixelType InputPixelType; > typedef ScalarTraits PixelScalarTraits; > typedef typename PixelScalarTraits::ScalarValueType > PixelScalarValueType; > > inline static PixelScalarValueType& GetPixelScalar(PixelType& p) > { return PixelScalarTraits::GetScalar(p); } > > inline static void SetPixelScalar(PixelType& p, > const PixelScalarValueType& v) > { PixelScalarTraits::SetScalar(p, v); } > > // .... > }; > > Note that the function definitions can be put in ImageToImageFilter and be > inherited into other filters. Then, with minimal setup work, a filter > implementation can access a Pixel's scalar value like this: > > PixelScalarValueType v = GetPixelScalar(myPixel); > // do something to v. > SetPixelScalar(myPixel, v); > > This is in place of the current code: > > typename ScalarTraits::ScalarValueType v = > ScalarTraits::GetScalar(myPixel); > // do something to v. > ScalarTraits::SetScalar(myPixel, v); > > Also, I have noticed that there are a bunch of extra ScalarTrait > specializations for more than the basic types. An example is > "ScalarTraits< RGBPixel >". These should not be done, because if > someone wants to use an RGBPixel with a template argument other than those > defined in itkPixelTraits.h, they will have to figure out how to write > their own trait specialization for it. Currently, this can be solved (I > think) by putting the proper typedefs (ValueType, etc) into RGBPixel and > letting the primary template of ScalarTraits handle it from there. > > The "real" way to do such a specialization of the ScalarTraits for > RGBPixel would be to do a partial specialization: > > template > class ScalarTraits< RGBPixel > { /* ... */ }; > > Unfortunately, not all of our compilers support partial specialization, so > we can't do this. > > The other option is to not require scalar traits to be a speicalization of > ScalarTraits at all. If instead we make such traits a template argument, > then any class can be defined and passed to the argument: > > template class TPixelTraits = ScalarTraits > > class Image > { > public: > typedef TPixel PixelType; > enum { Dimension = VDimension }; > typedef TPixelTraits PixelTraits; > // .... > }; > > Then, filters could pull the Pixel traits out of their image template > parameters: > > template > class MyFilter > { > public: > typedef TInputImage InputImageType; > typedef typename InputImageType::PixelTraits InputPixelTraits; > // ... use traits as in previous MyFilter example. > }; > > Making traits a template argument is currently the approach that the Mesh > class uses. It even encapsulates the "CellTraits" as a member of the > "MeshTraits" template argument. We could make the same relationship for > the Image. That is: > > template > class DefaultImageTraits > { > public: > typedef TPixel PixelType; > enum { Dimension = VDimension }; > typedef DefaultPixelTraits PixelTraits; > // ... other useful traits? > }; > > template unsigned int VDimension, > class TImageTraits = DefaultImageTraits > > class Image > { > public: > typedef TImageTraits ImageTraits; > typedef typename ImageTraits::PixelType PixelType; > typedef typename ImageTraits::PixelTraits PixelTraits; > > // ... > }; > > Assume that we have encapsulated both the current scalar and vector traits > into "DefaultPixelTraits". > > Thoughts, anyone? > -Brad > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From millerjv@crd.ge.com Thu, 29 Mar 2001 14:15:40 -0500 Date: Thu, 29 Mar 2001 14:15:40 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Simplifying traits Based on the problems I had with the iterator code referencing the image and the image code referencing the iterator, it would seem the only way to do this would be to put all the iterator code in the image class. We could still have a variety of iterator types but the Image.h would get really long (much like std::vector :) I could try this again if people want. Jim -----Original Message----- From: Stephen R. Aylward [mailto:aylward@unc.edu] Sent: Thursday, March 29, 2001 2:11 PM To: Miller, James V (CRD) Cc: 'Brad King'; 'Insight Developers' Subject: Re: [Insight-developers] Simplifying traits I think this is a great idea - the user has to assume some responsibility for what they are trying to do. Now if only we could have the image class return an iterator so as to better resemble the stl standard....perhaps the simple region iterator or linear iterator. Then, some of our methods could treat an image as it does any type of stl container. Stephen "Miller, James V (CRD)" wrote: > > I am still leaning towards eliminating scalar traits. I would really like to get back to standard > pointer/iterator semantics. > > foo = *it; > *it = garf; > > The effect of this would be: > > 1. DataAccessors would have to return a reference. This would mean that data accessors could only be > used to map memory (i.e. access a scalar from a pixel that held a scalar and vector). DataAccessors > could not be used for casting or for calculating a function of a pixel. > > 2. A given filter would assume its inputs were of the correct "type". If a filter is expecting to > work on scalars, dereferencing an iterator would have to return a scalar. If a filter is expecting > to work on vectors, derefencing an iterator would have to return a vector. If an algorithm needed > both scalars and vectors, they would be passed in as separate inputs. > > The reason for leaning in this direction is that the syntax for accessing a pixel within a filter is > getting rather complicated. Furthermore, we are having reference and const issues in the current > framework. Last night I was working on a line of code that read > > value = (double) ScalarTraits::GetScalar( it.Get() ); > > and the compiler was giving the error: > > GetScalar() cannot convert parameter 1 from "float" to "float &" > > Note that this error wasn't even a const issue! Just a reference issue. > > Jim > > -----Original Message----- > From: Brad King [mailto:brad.king@kitware.com] > Sent: Friday, March 23, 2001 4:37 PM > To: Insight Developers > Subject: [Insight-developers] Simplifying traits > > Hello, all: > > Here are some ideas to consider before deciding to throw out the use of > ScalarTraits an VectorTraits. Our current approach is not the simplest > approach to using traits. > > We can make traits easier to use. Consider the following filter: > > template > class MyFilter > { > public: > typedef TInputImage InputImageType; > typedef typename InputImageType::PixelType InputPixelType; > typedef ScalarTraits PixelScalarTraits; > typedef typename PixelScalarTraits::ScalarValueType > PixelScalarValueType; > > inline static PixelScalarValueType& GetPixelScalar(PixelType& p) > { return PixelScalarTraits::GetScalar(p); } > > inline static void SetPixelScalar(PixelType& p, > const PixelScalarValueType& v) > { PixelScalarTraits::SetScalar(p, v); } > > // .... > }; > > Note that the function definitions can be put in ImageToImageFilter and be > inherited into other filters. Then, with minimal setup work, a filter > implementation can access a Pixel's scalar value like this: > > PixelScalarValueType v = GetPixelScalar(myPixel); > // do something to v. > SetPixelScalar(myPixel, v); > > This is in place of the current code: > > typename ScalarTraits::ScalarValueType v = > ScalarTraits::GetScalar(myPixel); > // do something to v. > ScalarTraits::SetScalar(myPixel, v); > > Also, I have noticed that there are a bunch of extra ScalarTrait > specializations for more than the basic types. An example is > "ScalarTraits< RGBPixel >". These should not be done, because if > someone wants to use an RGBPixel with a template argument other than those > defined in itkPixelTraits.h, they will have to figure out how to write > their own trait specialization for it. Currently, this can be solved (I > think) by putting the proper typedefs (ValueType, etc) into RGBPixel and > letting the primary template of ScalarTraits handle it from there. > > The "real" way to do such a specialization of the ScalarTraits for > RGBPixel would be to do a partial specialization: > > template > class ScalarTraits< RGBPixel > { /* ... */ }; > > Unfortunately, not all of our compilers support partial specialization, so > we can't do this. > > The other option is to not require scalar traits to be a speicalization of > ScalarTraits at all. If instead we make such traits a template argument, > then any class can be defined and passed to the argument: > > template class TPixelTraits = ScalarTraits > > class Image > { > public: > typedef TPixel PixelType; > enum { Dimension = VDimension }; > typedef TPixelTraits PixelTraits; > // .... > }; > > Then, filters could pull the Pixel traits out of their image template > parameters: > > template > class MyFilter > { > public: > typedef TInputImage InputImageType; > typedef typename InputImageType::PixelTraits InputPixelTraits; > // ... use traits as in previous MyFilter example. > }; > > Making traits a template argument is currently the approach that the Mesh > class uses. It even encapsulates the "CellTraits" as a member of the > "MeshTraits" template argument. We could make the same relationship for > the Image. That is: > > template > class DefaultImageTraits > { > public: > typedef TPixel PixelType; > enum { Dimension = VDimension }; > typedef DefaultPixelTraits PixelTraits; > // ... other useful traits? > }; > > template unsigned int VDimension, > class TImageTraits = DefaultImageTraits > > class Image > { > public: > typedef TImageTraits ImageTraits; > typedef typename ImageTraits::PixelType PixelType; > typedef typename ImageTraits::PixelTraits PixelTraits; > > // ... > }; > > Assume that we have encapsulated both the current scalar and vector traits > into "DefaultPixelTraits". > > Thoughts, anyone? > -Brad > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers -- =============================================== Stephen R. Aylward Assistant Professor of Radiology Adjunct Assistant Professor of Computer Science http://www.cs.unc.edu/~aylward aylward@unc.edu (919) 966-9695 From millerjv@crd.ge.com Thu, 29 Mar 2001 09:39:23 -0500 Date: Thu, 29 Mar 2001 09:39:23 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] Simplifying traits I am still leaning towards eliminating scalar traits. I would really like to get back to standard pointer/iterator semantics. foo = *it; *it = garf; The effect of this would be: 1. DataAccessors would have to return a reference. This would mean that data accessors could only be used to map memory (i.e. access a scalar from a pixel that held a scalar and vector). DataAccessors could not be used for casting or for calculating a function of a pixel. 2. A given filter would assume its inputs were of the correct "type". If a filter is expecting to work on scalars, dereferencing an iterator would have to return a scalar. If a filter is expecting to work on vectors, derefencing an iterator would have to return a vector. If an algorithm needed both scalars and vectors, they would be passed in as separate inputs. The reason for leaning in this direction is that the syntax for accessing a pixel within a filter is getting rather complicated. Furthermore, we are having reference and const issues in the current framework. Last night I was working on a line of code that read value = (double) ScalarTraits::GetScalar( it.Get() ); and the compiler was giving the error: GetScalar() cannot convert parameter 1 from "float" to "float &" Note that this error wasn't even a const issue! Just a reference issue. Jim -----Original Message----- From: Brad King [mailto:brad.king@kitware.com] Sent: Friday, March 23, 2001 4:37 PM To: Insight Developers Subject: [Insight-developers] Simplifying traits Hello, all: Here are some ideas to consider before deciding to throw out the use of ScalarTraits an VectorTraits. Our current approach is not the simplest approach to using traits. We can make traits easier to use. Consider the following filter: template class MyFilter { public: typedef TInputImage InputImageType; typedef typename InputImageType::PixelType InputPixelType; typedef ScalarTraits PixelScalarTraits; typedef typename PixelScalarTraits::ScalarValueType PixelScalarValueType; inline static PixelScalarValueType& GetPixelScalar(PixelType& p) { return PixelScalarTraits::GetScalar(p); } inline static void SetPixelScalar(PixelType& p, const PixelScalarValueType& v) { PixelScalarTraits::SetScalar(p, v); } // .... }; Note that the function definitions can be put in ImageToImageFilter and be inherited into other filters. Then, with minimal setup work, a filter implementation can access a Pixel's scalar value like this: PixelScalarValueType v = GetPixelScalar(myPixel); // do something to v. SetPixelScalar(myPixel, v); This is in place of the current code: typename ScalarTraits::ScalarValueType v = ScalarTraits::GetScalar(myPixel); // do something to v. ScalarTraits::SetScalar(myPixel, v); Also, I have noticed that there are a bunch of extra ScalarTrait specializations for more than the basic types. An example is "ScalarTraits< RGBPixel >". These should not be done, because if someone wants to use an RGBPixel with a template argument other than those defined in itkPixelTraits.h, they will have to figure out how to write their own trait specialization for it. Currently, this can be solved (I think) by putting the proper typedefs (ValueType, etc) into RGBPixel and letting the primary template of ScalarTraits handle it from there. The "real" way to do such a specialization of the ScalarTraits for RGBPixel would be to do a partial specialization: template class ScalarTraits< RGBPixel > { /* ... */ }; Unfortunately, not all of our compilers support partial specialization, so we can't do this. The other option is to not require scalar traits to be a speicalization of ScalarTraits at all. If instead we make such traits a template argument, then any class can be defined and passed to the argument: template > class Image { public: typedef TPixel PixelType; enum { Dimension = VDimension }; typedef TPixelTraits PixelTraits; // .... }; Then, filters could pull the Pixel traits out of their image template parameters: template class MyFilter { public: typedef TInputImage InputImageType; typedef typename InputImageType::PixelTraits InputPixelTraits; // ... use traits as in previous MyFilter example. }; Making traits a template argument is currently the approach that the Mesh class uses. It even encapsulates the "CellTraits" as a member of the "MeshTraits" template argument. We could make the same relationship for the Image. That is: template class DefaultImageTraits { public: typedef TPixel PixelType; enum { Dimension = VDimension }; typedef DefaultPixelTraits PixelTraits; // ... other useful traits? }; template > class Image { public: typedef TImageTraits ImageTraits; typedef typename ImageTraits::PixelType PixelType; typedef typename ImageTraits::PixelTraits PixelTraits; // ... }; Assume that we have encapsulated both the current scalar and vector traits into "DefaultPixelTraits". Thoughts, anyone? -Brad _______________________________________________ Insight-developers mailing list Insight-developers@public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From cates@cayenne.cs.utah.edu Thu, 29 Mar 2001 15:04:26 -0700 (MST) Date: Thu, 29 Mar 2001 15:04:26 -0700 (MST) From: Joshua Cates cates@cayenne.cs.utah.edu Subject: [Insight-developers] Simplifying traits I also agree that this is good idea. We are running the risk of alienating users by requiring so many levels of indirection for simple data access. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates@cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates On Thu, 29 Mar 2001, Miller, James V (CRD) wrote: > I am still leaning towards eliminating scalar traits. I would really like to get back to standard > pointer/iterator semantics. > > foo = *it; > *it = garf; > > The effect of this would be: > > 1. DataAccessors would have to return a reference. This would mean that data accessors could only be > used to map memory (i.e. access a scalar from a pixel that held a scalar and vector). DataAccessors > could not be used for casting or for calculating a function of a pixel. > > 2. A given filter would assume its inputs were of the correct "type". If a filter is expecting to > work on scalars, dereferencing an iterator would have to return a scalar. If a filter is expecting > to work on vectors, derefencing an iterator would have to return a vector. If an algorithm needed > both scalars and vectors, they would be passed in as separate inputs. > > The reason for leaning in this direction is that the syntax for accessing a pixel within a filter is > getting rather complicated. Furthermore, we are having reference and const issues in the current > framework. Last night I was working on a line of code that read > > value = (double) ScalarTraits::GetScalar( it.Get() ); > > and the compiler was giving the error: > > GetScalar() cannot convert parameter 1 from "float" to "float &" > > Note that this error wasn't even a const issue! Just a reference issue. > > Jim > > > > > > -----Original Message----- > From: Brad King [mailto:brad.king@kitware.com] > Sent: Friday, March 23, 2001 4:37 PM > To: Insight Developers > Subject: [Insight-developers] Simplifying traits > > > Hello, all: > > Here are some ideas to consider before deciding to throw out the use of > ScalarTraits an VectorTraits. Our current approach is not the simplest > approach to using traits. > > We can make traits easier to use. Consider the following filter: > > template > class MyFilter > { > public: > typedef TInputImage InputImageType; > typedef typename InputImageType::PixelType InputPixelType; > typedef ScalarTraits PixelScalarTraits; > typedef typename PixelScalarTraits::ScalarValueType > PixelScalarValueType; > > inline static PixelScalarValueType& GetPixelScalar(PixelType& p) > { return PixelScalarTraits::GetScalar(p); } > > inline static void SetPixelScalar(PixelType& p, > const PixelScalarValueType& v) > { PixelScalarTraits::SetScalar(p, v); } > > // .... > }; > > Note that the function definitions can be put in ImageToImageFilter and be > inherited into other filters. Then, with minimal setup work, a filter > implementation can access a Pixel's scalar value like this: > > PixelScalarValueType v = GetPixelScalar(myPixel); > // do something to v. > SetPixelScalar(myPixel, v); > > This is in place of the current code: > > typename ScalarTraits::ScalarValueType v = > ScalarTraits::GetScalar(myPixel); > // do something to v. > ScalarTraits::SetScalar(myPixel, v); > > Also, I have noticed that there are a bunch of extra ScalarTrait > specializations for more than the basic types. An example is > "ScalarTraits< RGBPixel >". These should not be done, because if > someone wants to use an RGBPixel with a template argument other than those > defined in itkPixelTraits.h, they will have to figure out how to write > their own trait specialization for it. Currently, this can be solved (I > think) by putting the proper typedefs (ValueType, etc) into RGBPixel and > letting the primary template of ScalarTraits handle it from there. > > The "real" way to do such a specialization of the ScalarTraits for > RGBPixel would be to do a partial specialization: > > template > class ScalarTraits< RGBPixel > { /* ... */ }; > > Unfortunately, not all of our compilers support partial specialization, so > we can't do this. > > The other option is to not require scalar traits to be a speicalization of > ScalarTraits at all. If instead we make such traits a template argument, > then any class can be defined and passed to the argument: > > template class TPixelTraits = ScalarTraits > > class Image > { > public: > typedef TPixel PixelType; > enum { Dimension = VDimension }; > typedef TPixelTraits PixelTraits; > // .... > }; > > Then, filters could pull the Pixel traits out of their image template > parameters: > > template > class MyFilter > { > public: > typedef TInputImage InputImageType; > typedef typename InputImageType::PixelTraits InputPixelTraits; > // ... use traits as in previous MyFilter example. > }; > > Making traits a template argument is currently the approach that the Mesh > class uses. It even encapsulates the "CellTraits" as a member of the > "MeshTraits" template argument. We could make the same relationship for > the Image. That is: > > template > class DefaultImageTraits > { > public: > typedef TPixel PixelType; > enum { Dimension = VDimension }; > typedef DefaultPixelTraits PixelTraits; > // ... other useful traits? > }; > > template unsigned int VDimension, > class TImageTraits = DefaultImageTraits > > class Image > { > public: > typedef TImageTraits ImageTraits; > typedef typename ImageTraits::PixelType PixelType; > typedef typename ImageTraits::PixelTraits PixelTraits; > > // ... > }; > > Assume that we have encapsulated both the current scalar and vector traits > into "DefaultPixelTraits". > > Thoughts, anyone? > -Brad > > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From chandra@cs.unc.edu Thu, 29 Mar 2001 17:06:14 -0500 Date: Thu, 29 Mar 2001 17:06:14 -0500 From: Parag Chandra chandra@cs.unc.edu Subject: [Insight-developers] Problems building ITKCommon (and solution) This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C0B872.901658A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just did a checkout around 3 PM, and ITKCommon would not build on VC++ = (or any other platform I suspect). I made the following changes to my = local copy and that seems to fix it, but I am hesitant to check in the = changes since I don't "own" these files. Is anyone else experiencing = this problem? Can the author(s) of these files make the changes, verify = it doesn't mess up anything else in their code, and then commit them to = the repository? Thanks. To itkAffineTransform.h: #include "vnl/vnl_vector_fixed.h" To itkTransformation.h: change method definition from: virtual PointType Transform(PointType &) = =3D 0; to: virtual PointType Transform(const PointType &) const =3D 0; -Parag ------=_NextPart_000_00A1_01C0B872.901658A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I just did a checkout around 3 PM, and = ITKCommon=20 would not build on VC++ (or any other platform I suspect). I made the = following=20 changes to my local copy and that seems to fix it, but I am hesitant to = check in=20 the changes since I don't "own" these files. Is anyone else experiencing = this=20 problem? Can the author(s) of these files make the changes, verify it = doesn't=20 mess up anything else in their code, and then commit them to the = repository?=20 Thanks.
 
To itkAffineTransform.h:
 
#include = "vnl/vnl_vector_fixed.h"
 
To=20 itkTransformation.h:
 
change method definition from: = virtual PointType Transform(PointType = &) =3D=20 0;
 
to:   virtual PointType = Transform(const=20 PointType &) const =3D = 0;

-Parag
------=_NextPart_000_00A1_01C0B872.901658A0-- From chandra@cs.unc.edu Thu, 29 Mar 2001 17:09:45 -0500 Date: Thu, 29 Mar 2001 17:09:45 -0500 From: Parag Chandra chandra@cs.unc.edu Subject: [Insight-developers] vnl problems This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C0B873.0D762410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm getting a couple of strange problems when trying to build my = SplineKernelTransformTest today. It was building fine yesterday, but I = guess I hadn't done an update in a few days because when I updated = today, I now get the following errors from VC++ (two instances of each): d:\development\insight\code\numerics\vxl\vcl\win32\vcl_complex.h(27) : = error C2667: 'norm' : none of 2 overload have a best conversion d:\development\insight\code\numerics\vxl\vnl\vnl_complex.h(43) : = see reference to function template instantiation 'float __cdecl = abs(const class std::complex &)' being compiled d:\development\insight\code\numerics\vxl\vcl\win32\vcl_complex.h(27) : = error C2668: 'norm' : ambiguous call to overloaded function d:\development\insight\code\numerics\vxl\vnl\vnl_complex.h(43) : = see reference to function template instantiation 'float __cdecl = abs(const class std::complex &)' being compiled I use the norm() function in my classes, but have had no problems with = it until just now. I don't get these errors under Cygwin. Has something = changed recently in the numerics library? Thanks, -Parag ------=_NextPart_000_00A9_01C0B873.0D762410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I'm getting a couple of strange = problems when=20 trying to build my SplineKernelTransformTest today. It = was=20 building fine yesterday, but I guess I hadn't done an update in a few = days=20 because when I updated today, I now get the following errors from = VC++ (two=20 instances of each):
 
d:\development\insight\code\numerics\vxl\vcl\win32\vcl_complex.h= (27) :=20 error C2667: 'norm' : none of 2 overload have a best=20 conversion
       =20 d:\development\insight\code\numerics\vxl\vnl\vnl_complex.h(43) : see = reference=20 to function template instantiation 'float __cdecl abs(const class=20 std::complex<float> &)' being=20 compiled
d:\development\insight\code\numerics\vxl\vcl\win32\vcl_comple= x.h(27)=20 : error C2668: 'norm' : ambiguous call to overloaded=20 function
       =20 d:\development\insight\code\numerics\vxl\vnl\vnl_complex.h(43) : see = reference=20 to function template instantiation 'float __cdecl abs(const class=20 std::complex<float> &)' being compiled
I use the norm() function in my = classes, but have=20 had no problems with it until just now. I don't get these errors under = Cygwin.=20 Has something changed recently in the numerics library?
 
Thanks,
-Parag
------=_NextPart_000_00A9_01C0B873.0D762410-- From jjomier@cs.unc.edu Thu, 29 Mar 2001 20:13:37 -0500 Date: Thu, 29 Mar 2001 20:13:37 -0500 From: Julien Jomier jjomier@cs.unc.edu Subject: [Insight-developers] README-Methods documentation This is a multi-part message in MIME format. ------=_NextPart_000_0084_01C0B88C.BCE57360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We just created with Stephen a new documentation file, = Insight\Documentation\README-Methods.doc, which provides a description = of ITK methods. This document is far from being complete so feel free to add your own = documention in it.=20 Basically, now, there are table of contents and description of = Registration and IO hierarchies. Maybe we can talk about content at the TCon tomorrow. Thanks Julien ------=_NextPart_000_0084_01C0B88C.BCE57360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
We just created with Stephen a new = documentation=20 file, Insight\Documentation\README-Methods.doc, which provides a=20 description of ITK methods.
This document is far from = being complete so=20 feel free to add your own documention in it.
Basically, now, there are table of = contents=20 and description of Registration and IO hierarchies.
 
Maybe we can talk about content at the = TCon=20 tomorrow.
 
Thanks
 
Julien
------=_NextPart_000_0084_01C0B88C.BCE57360-- From millerjv@crd.ge.com Fri, 30 Mar 2001 07:26:48 -0500 Date: Fri, 30 Mar 2001 07:26:48 -0500 From: Miller, James V (CRD) millerjv@crd.ge.com Subject: [Insight-developers] All image iterators now support Adaptors I check in all my changes to the ImageIterators to support adaptors. This means: 1. ImageIterators are templated over image type instead of pixel type and dimension. 2. operator* has been removed in favor of Set()/Get() 3. ImageIterators have a method Value() that bypasses the DataAccessor code. I change all the code that uses ImageRegionIterator to the new API. Changing some of the algorithm code was tricky, so there may be a couple of outstanding run-time issues that I missed. I also had to change some of the DataAccessor code to ferret a few reference and const issues. Now that all the image iterators have a uniform API, I'll start looking at simplifying the iterator dereferencing code. Jim Miller _____________________________________ Computer Graphics & Systems Program GE Corporate Research & Development Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv@crd.ge.com (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 <> begin 600 James Miller (E-mail).vcf M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..DUI;&QE7-T96US(%!R;V=R86T[0DQ$1R!+5RP@4DT@0S(Q.$(] M,$0],$%03R!";W@@.#M38VAE;F5C/0T*=&%D>3M.63LQ,C,P,3M5;FET960@ M4W1A=&5S(&]F($%M97)I8V$-"DQ!0D5,.U=/4DL[14Y#3T1)3D<]455/5$5$ M+5!224Y404),13I#;VUP=71E2P@3ED@,3(S,#$],$0],$%5;FET960@4W1A=&5S(&]F M($%M97)I8V$-"D5-04E,.U!2148[24Y415).150Z;6EL;&5R:G9`8W)D+F=E G+F-O;0T*4D56.C(P,#`P,3(X5#$V,C8U-EH-"D5.1#I60T%21`T* ` end From lorensen@crd.ge.com Fri, 30 Mar 2001 09:58:45 -0500 Date: Fri, 30 Mar 2001 09:58:45 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] testing It looks like it's crashing. Probably accessing memory outside its realm. Do you have access to purify? We can try to run purify at GE now that it's building on SGI's. Probably can't do that til Monday. Bill > -----Original Message----- > From: Ying Zhuge [SMTP:zhuge@mipg.upenn.edu] > Sent: Thursday, March 29, 2001 11:25 AM > To: insight-developers@public.kitware.com > Subject: [Insight-developers] testing > > Hi, > > We checked in our class itkVectorFuzzyConnectednessImageFilter, it has > been tested OK in our group( Upenn and Columbia) . Can anybody tell me > why it can not be passed ? > BTW, I just modified the return value of testing program from 1 to 0. > any other problems? > > Thanks! > > Ying > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers From lorensen@crd.ge.com Sat, 31 Mar 2001 09:47:41 -0500 Date: Sat, 31 Mar 2001 09:47:41 -0500 From: Lorensen, William E (CRD) lorensen@crd.ge.com Subject: [Insight-developers] Optimizers / Registration Luis, itkAmoebaOptimizerTest is failing because an exception is being thrown at: itkSingleValuedNonLinearVnlOptimizer.h line 131. Bill > -----Original Message----- > From: Luis Ibanez [SMTP:ibanez@cs.unc.edu] > Sent: Wednesday, March 28, 2001 2:17 AM > To: insight-developers@public.kitware.com > Subject: [Insight-developers] Optimizers / Registration > > Hi, > > the Optimizers in Numerics > and the registration methods in Algorithms > are now compiling under VC++ and gcc (cygwin). > > The change of parameters allows now to use any > type with operator[]() defined, as carrier for the > cost function parameters. > > > > Luis > > > > > _______________________________________________ > Insight-developers mailing list > Insight-developers@public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers