From simon.rit at creatis.insa-lyon.fr  Tue Dec 12 09:52:04 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 12 Dec 2017 15:52:04 +0100
Subject: [Rtk-users] Question about RTK
In-Reply-To: <2054c9af.26f1b.1604b305601.Coremail.xk.liang@siat.ac.cn>
References: <2054c9af.26f1b.1604b305601.Coremail.xk.liang@siat.ac.cn>
Message-ID: <CAF0oig2fetdMT4=5QKMVJAN15Uve1EnKKLQPcXrmFDNZDMo+Yg@mail.gmail.com>

Hi,
Thanks for your interest and please use the mailing list. This issue has
been solved in the current master version:
https://github.com/SimonRit/RTK/commit/cac2d7bd864116a364af64819ba0d5b7647d478c
Please upgrade to the github master version.
Best regards,
Simon

On Tue, Dec 12, 2017 at 3:45 PM, ??? <xk.liang at siat.ac.cn> wrote:

> Dear Dr Simon Rit,
>
> RTK is a great toolkit for cone-beam CT reconstruction. Now, I'm trying to
> compile RTK. But some error confused me. The error is shown as the
> following picture.
>
>
> Do you know the reason why the error generated? How to solve the error?
> Thank you.
>
> --
>
> Yours sincerely
> Xiaokun Liang
>
>
> Research Centre for Medical Robotics and Minimally Invasive Surgical
> Devices
> Institute of Biomedical and Health Engineering
> Shenzhen Institutes of Advanced Technology, Chinese Academy of Sciences
>
> Tel:      0086-13129578215
> Zip:      518055
> Add:      No. 1068 Xueyuan Avenue
> <https://maps.google.com/?q=No.+1068+Xueyuan+Avenue&entry=gmail&source=g>,
> Shenzhen University Town, Xili, Nanshan District, Shenzhen City,
> Guangdong Province, China
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171212/b42fb2e7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ????_20171212223502.png
Type: image/png
Size: 4774 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171212/b42fb2e7/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ????_20171212223511.png
Type: image/png
Size: 91634 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171212/b42fb2e7/attachment-0003.png>

From boursier at cppm.in2p3.fr  Mon Dec 18 10:07:25 2017
From: boursier at cppm.in2p3.fr (Yannick BOURSIER)
Date: Mon, 18 Dec 2017 16:07:25 +0100 (CET)
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file for
 CudaBackProjectionImageFilter
Message-ID: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>

Hello all, 

I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).

I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :

/data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
/data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
   typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;

I would very much appreciate some help please because at this point, I have no idea about the problem...
Thanks in advance, 
Best regards, 
Yannick Boursier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CudaBackProjectionImageFilter.json
Type: application/json
Size: 821 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171218/5590e4c8/attachment.json>

From cyril.mory at creatis.insa-lyon.fr  Mon Dec 18 10:52:18 2017
From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory)
Date: Mon, 18 Dec 2017 16:52:18 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
Message-ID: <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>

Hi again Yannick,

Simply removing the <InputImageType> on line 9 of your .json file made 
it compile. I didn't test it yet. Let us know if that works for you.

Cyril


On 18/12/2017 16:31, Cyril Mory wrote:
>
> Hi Yannick,
>
> You seem to be in a hurry, so I'll start with an incomplete answer: 
> the CudaForwardProjectionImageFilter is templated over its input and 
> output image type, but the CudaBackProjectionImageFilter isn't 
> (compare rtkCudaForwardProjectionImageFilter.h and 
> rtkCudaBackProjectionImageFilter.h, there is not "template <>" before 
> the class definition in ...Back..., while it is there in ...Forward...).
>
> I'm trying to modify your .json file accordingly, recompile and test, 
> but I never use SimpleRTK myself, so you might find the solution 
> before I do. If so, please report back on this mailing list.
>
> Cyril
>
>
> On 18/12/2017 16:07, Yannick BOURSIER wrote:
>> Hello all,
>>
>> I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>> Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>
>> I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>
>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>     typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>
>> I would very much appreciate some help please because at this point, I have no idea about the problem...
>> Thanks in advance,
>> Best regards,
>> Yannick Boursier
>>
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171218/c5974a4a/attachment.html>

From cyril.mory at creatis.insa-lyon.fr  Mon Dec 18 10:31:34 2017
From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory)
Date: Mon, 18 Dec 2017 16:31:34 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
Message-ID: <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>

Hi Yannick,

You seem to be in a hurry, so I'll start with an incomplete answer: the 
CudaForwardProjectionImageFilter is templated over its input and output 
image type, but the CudaBackProjectionImageFilter isn't (compare 
rtkCudaForwardProjectionImageFilter.h and 
rtkCudaBackProjectionImageFilter.h, there is not "template <>" before 
the class definition in ...Back..., while it is there in ...Forward...).

I'm trying to modify your .json file accordingly, recompile and test, 
but I never use SimpleRTK myself, so you might find the solution before 
I do. If so, please report back on this mailing list.

Cyril


On 18/12/2017 16:07, Yannick BOURSIER wrote:
> Hello all,
>
> I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
> Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>
> I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>
> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>     typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>
> I would very much appreciate some help please because at this point, I have no idea about the problem...
> Thanks in advance,
> Best regards,
> Yannick Boursier
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171218/0e1ad903/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Wed Dec 20 07:19:38 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 20 Dec 2017 13:19:38 +0100
Subject: [Rtk-users] helical cone-beam CT reconstruction
In-Reply-To: <5ee1ffc0d1cc45118c8d05bd29a52a8d@EXCH3.localdom.net>
References: <5ee1ffc0d1cc45118c8d05bd29a52a8d@EXCH3.localdom.net>
Message-ID: <CAF0oig2MBZyeQ=DBXBgmqd+n5b__T0xPO4LZjc6hm48pZnk7aQ@mail.gmail.com>

Hi Dennis,
You can do a helical trajectory and I have used our iterative
reconstruction tools in this work
<http://www.creatis.insa-lyon.fr/~srit/biblio/clackdoyle2017.pdf> to do
helical reconstructions. It works. However, RTK does not have any filtered
backprojection reconstruction for helical CT.
You can check FreeCT <http://dx.doi.org/10.1118/1.4941953>, I think that
what it does.
Simon

On Wed, Dec 20, 2017 at 12:51 PM, Dennis Brandborg Nielsen <
dbn at teknologisk.dk> wrote:

>
>
>
>
> Dear Simon..
>
> I have tryied post a question on the rtk-user mailing list.
>
> However I get some mail delevery errors. And hope you would take the time
> to answer a shoort question..
>
> I am new to CT reconstruction - Before I start to get familiar with RTK I
> have an question.
>
> At the wiki-help-site is says that is possible to do "fast circular
> cone-beam CT reconstruction" does this mean that RCT can do reconstruction
> of helical cone-beam CT reconstruction?  Or is this only possible for
> sequential scanning/step-and-shoot.
>
>
>
> Are there any other possible reconstructions-tools for helical cone-beam
> reconstruction that you would recommend?.
>
>
>
>
>
> Kind regards
>
> Dennis
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171220/d2841ea5/attachment.html>

From mathis.hoffmann at fau.de  Thu Dec 21 09:20:14 2017
From: mathis.hoffmann at fau.de (Mathis Hoffmann)
Date: Thu, 21 Dec 2017 15:20:14 +0100
Subject: [Rtk-users] RTK + Cuda 9 + gcc 6.4 segfaults
Message-ID: <1513866014.1011.0@smtp-auth.fau.de>

Hello,

I was able to build RTK using Cuda 9 on an Arch Linux machine with gcc 
6.4 with only small modifications:

 #=========================================================
diff --git a/cmake/nvcc-check.cmake b/cmake/nvcc-check.cmake
index c625b421..0e5c34e9 100644
--- a/cmake/nvcc-check.cmake
+++ b/cmake/nvcc-check.cmake
@@ -46,6 +46,9 @@ if(CUDA_FOUND)
   if((CMAKE_SYSTEM_NAME MATCHES "Linux" AND CMAKE_COMPILER_IS_GNUCC) 
OR APPLE)
     # Compatible gcc can be checked in host_config.h
     set(GCC_PATH "")
+    if(${CUDA_VERSION} VERSION_GREATER "8.99")
+      FIND_GCC(GCC_PATH "6" "4")
+    endif()
     if(${CUDA_VERSION} VERSION_GREATER "6.99")
       FIND_GCC(GCC_PATH "4" "9")
     endif()


In addition I had to set CMAKE_CXX_FLAGS to -std=gnu++11 manually in 
the ccmake dialog (unfortunately I was not able to integrate this in 
the top-level CMakeLists so far, CMake simply ignored it there..).

So far, so good. Unfortunately all Cuda tests fail with the same 
segfault. For example, rtkimportcudatest finishes with

****** Case 1: unsigned short ******

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!


****** Case 2: int ******

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!


****** Case 3: float ******

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!


****** Case 4: double ******

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!

Error per Pixel = 0
MSE = 0
PSNR = infdB
QI = 1


Test PASSED!
Segmentation fault (core dumped)

To further investigate what is going wrong here, I ran valgrind. I 
think the most important message is this:

==30633== Process terminating with default action of signal 11 
(SIGSEGV): dumping core
==30633==  Access not within mapped region at address 0x8
==30633==    at 0x12240072: (anonymous 
namespace)::ObjectFactoryBasePrivateInitializer::~ObjectFactoryBasePrivateInitializer() 
(in /home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
==30633==    by 0x1402B7B1: __cxa_finalize (in /usr/lib/libc-2.26.so)
==30633==    by 0x121771D3: ??? (in 
/home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
==30633==    by 0x400FB92: _dl_fini (in /usr/lib/ld-2.26.so)
==30633==    by 0x1402B447: __run_exit_handlers (in 
/usr/lib/libc-2.26.so)
==30633==    by 0x1402B499: exit (in /usr/lib/libc-2.26.so)
==30633==    by 0x14014F50: (below main) (in /usr/lib/libc-2.26.so)
==30633==  If you believe this happened as a result of a stack
==30633==  overflow in your program's main thread (unlikely but
==30633==  possible), you can try to increase the size of the
==30633==  main thread stack using the --main-stacksize= flag.
==30633==  The main thread stack size used in this run was 8388608.

I've put the full log here: https://pastebin.com/CBjJmUpB

Does someone have any idea, what is going wrong here?

Thanks for any help!
Mathis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171221/7aac4de3/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Thu Dec 21 09:50:46 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 21 Dec 2017 15:50:46 +0100
Subject: [Rtk-users] RTK + Cuda 9 + gcc 6.4 segfaults
In-Reply-To: <1513866014.1011.0@smtp-auth.fau.de>
References: <1513866014.1011.0@smtp-auth.fau.de>
Message-ID: <CAF0oig3rBH-=sooMwWtcsiuf7n6kkPp3NHAt3A4TLV5TE=kbaQ@mail.gmail.com>

Hi,
Thanks for the report. Seems like something is happening in the ITK code.
Are other non cuda tests failing?
Did you also compile ITK with C++11? BTW, why is it required?
Best regards,
Simon

On Thu, Dec 21, 2017 at 3:20 PM, Mathis Hoffmann <mathis.hoffmann at fau.de>
wrote:

> Hello,
>
> I was able to build RTK using Cuda 9 on an Arch Linux machine with gcc 6.4
> with only small modifications:
>
>  #=========================================================
> diff --git a/cmake/nvcc-check.cmake b/cmake/nvcc-check.cmake
> index c625b421..0e5c34e9 100644
> --- a/cmake/nvcc-check.cmake
> +++ b/cmake/nvcc-check.cmake
> @@ -46,6 +46,9 @@ if(CUDA_FOUND)
>    if((CMAKE_SYSTEM_NAME MATCHES "Linux" AND CMAKE_COMPILER_IS_GNUCC) OR
> APPLE)
>      # Compatible gcc can be checked in host_config.h
>      set(GCC_PATH "")
> +    if(${CUDA_VERSION} VERSION_GREATER "8.99")
> +      FIND_GCC(GCC_PATH "6" "4")
> +    endif()
>      if(${CUDA_VERSION} VERSION_GREATER "6.99")
>        FIND_GC C(GCC_PATH "4" "9")
>      endif()
>
>
> In addition I had to set CMAKE_CXX_FLAGS to -std=gnu++11 manually in the
> ccmake dialog (unfortunately I was not able to integrate this in the
> top-level CMakeLists so far, CMake simply ignored it there..).
>
> So far, so good. Unfortunately all Cuda tests fail with the same segfault.
> For example, rtkimportcudatest finishes with
>
> ****** Case 1: unsigned short ******
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
>
>
> ****** Case 2: int ******
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB< /div>
> QI = 1
>
>
> Test PASSED!
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
>
>
> ****** Case 3: float ******
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
>
>
> ****** Case 4: double ******
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
>
> Error per Pixel = 0
> MSE = 0
> PSNR = infdB
> QI = 1
>
>
> Test PASSED!
> Segmentation fault (core dumped)
>
> To further investigate what is going wrong here, I ran valgrind. I think
> the most important message is this:
>
> ==30633== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==30633==  Access not within mapped region at address 0x8
> ==30633==    at 0x12240072: (anonymous namespace)::
> ObjectFactoryBasePrivateInitializer::~ObjectFactoryBasePrivateInitializer()
> (in /home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
> ==30633==    by 0x1402B7B1: __cxa_finalize (in /usr/lib/libc-2.26.so)
> ==30633==    by 0x121771D3: ??? (in /home/mathis/dev/RTK/RTK-bin/
> bin/libRTK.so)
> ==30633==    by 0x400FB92: _dl_fini (in /usr/lib/ld-2.26.so)
> ==30633==    by 0x1402B447: __run_exit_handlers (in /usr/lib/libc-2.26.so)
> ==30633==    by 0 x1402B499: exit (in /usr/lib/libc-2.26.so)
> ==30633==    by 0x14014F50: (below main) (in /usr/lib/libc-2.26.so)
> ==30633==  If you believe this happened as a result of a stack
> ==30633==  overflow in your program's main thread (unlikely but
> ==30633==  possible), you can try to increase the size of the
> ==30633==  main thread stack using the --main-stacksize= flag.
> ==30633==  The main thread stack size used in this run was 8388608.
>
> I've put the full log here: https://pastebin.com/CBjJmUpB
>
> Does someone have any idea, what is going wrong here?
>
> Thanks for any help!
> Mathis
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171221/8d6c7cb6/attachment.html>

From mathis.hoffmann at fau.de  Thu Dec 21 10:41:39 2017
From: mathis.hoffmann at fau.de (Mathis Hoffmann)
Date: Thu, 21 Dec 2017 16:41:39 +0100
Subject: [Rtk-users] RTK + Cuda 9 + gcc 6.4 segfaults
In-Reply-To: <CAF0oig3rBH-=sooMwWtcsiuf7n6kkPp3NHAt3A4TLV5TE=kbaQ@mail.gmail.com>
References: <1513866014.1011.0@smtp-auth.fau.de>
 <CAF0oig3rBH-=sooMwWtcsiuf7n6kkPp3NHAt3A4TLV5TE=kbaQ@mail.gmail.com>
Message-ID: <0c10e1bf-158c-4906-8a33-2757ba77f5fc@fau.de>

Hey Simon, 

Thanks for your instant reply! I did not run all tests so far, but at least the non cuda tests that I tried were successful. I can check the others this evening. 

I compiled ITK with the same flag, yes. It Was necessary for RTK, otherwise there were compile errors and I thought that RTK might not be c++14 complient.

Regards 
Mathis 

?Gesendet mit TypeApp ?

Am 21. Dez. 2017, 15:51, um 15:51, Simon Rit <simon.rit at creatis.insa-lyon.fr> schrieb:
>Hi,
>Thanks for the report. Seems like something is happening in the ITK
>code.
>Are other non cuda tests failing?
>Did you also compile ITK with C++11? BTW, why is it required?
>Best regards,
>Simon
>
>On Thu, Dec 21, 2017 at 3:20 PM, Mathis Hoffmann
><mathis.hoffmann at fau.de>
>wrote:
>
>> Hello,
>>
>> I was able to build RTK using Cuda 9 on an Arch Linux machine with
>gcc 6.4
>> with only small modifications:
>>
>>  #=========================================================
>> diff --git a/cmake/nvcc-check.cmake b/cmake/nvcc-check.cmake
>> index c625b421..0e5c34e9 100644
>> --- a/cmake/nvcc-check.cmake
>> +++ b/cmake/nvcc-check.cmake
>> @@ -46,6 +46,9 @@ if(CUDA_FOUND)
>>    if((CMAKE_SYSTEM_NAME MATCHES "Linux" AND CMAKE_COMPILER_IS_GNUCC)
>OR
>> APPLE)
>>      # Compatible gcc can be checked in host_config.h
>>      set(GCC_PATH "")
>> +    if(${CUDA_VERSION} VERSION_GREATER "8.99")
>> +      FIND_GCC(GCC_PATH "6" "4")
>> +    endif()
>>      if(${CUDA_VERSION} VERSION_GREATER "6.99")
>>        FIND_GC C(GCC_PATH "4" "9")
>>      endif()
>>
>>
>> In addition I had to set CMAKE_CXX_FLAGS to -std=gnu++11 manually in
>the
>> ccmake dialog (unfortunately I was not able to integrate this in the
>> top-level CMakeLists so far, CMake simply ignored it there..).
>>
>> So far, so good. Unfortunately all Cuda tests fail with the same
>segfault.
>> For example, rtkimportcudatest finishes with
>>
>> ****** Case 1: unsigned short ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>>
>> ****** Case 2: int ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB< /div>
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>>
>> ****** Case 3: float ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>>
>> ****** Case 4: double ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>> Segmentation fault (core dumped)
>>
>> To further investigate what is going wrong here, I ran valgrind. I
>think
>> the most important message is this:
>>
>> ==30633== Process terminating with default action of signal 11
>(SIGSEGV):
>> dumping core
>> ==30633==  Access not within mapped region at address 0x8
>> ==30633==    at 0x12240072: (anonymous namespace)::
>>
>ObjectFactoryBasePrivateInitializer::~ObjectFactoryBasePrivateInitializer()
>> (in /home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
>> ==30633==    by 0x1402B7B1: __cxa_finalize (in /usr/lib/libc-2.26.so)
>> ==30633==    by 0x121771D3: ??? (in /home/mathis/dev/RTK/RTK-bin/
>> bin/libRTK.so)
>> ==30633==    by 0x400FB92: _dl_fini (in /usr/lib/ld-2.26.so)
>> ==30633==    by 0x1402B447: __run_exit_handlers (in
>/usr/lib/libc-2.26.so)
>> ==30633==    by 0 x1402B499: exit (in /usr/lib/libc-2.26.so)
>> ==30633==    by 0x14014F50: (below main) (in /usr/lib/libc-2.26.so)
>> ==30633==  If you believe this happened as a result of a stack
>> ==30633==  overflow in your program's main thread (unlikely but
>> ==30633==  possible), you can try to increase the size of the
>> ==30633==  main thread stack using the --main-stacksize= flag.
>> ==30633==  The main thread stack size used in this run was 8388608.
>>
>> I've put the full log here: https://pastebin.com/CBjJmUpB
>>
>> Does someone have any idea, what is going wrong here?
>>
>> Thanks for any help!
>> Mathis
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171221/b6e8f25b/attachment-0001.html>

From mathis.hoffmann at fau.de  Thu Dec 21 17:30:18 2017
From: mathis.hoffmann at fau.de (Mathis Hoffmann)
Date: Thu, 21 Dec 2017 23:30:18 +0100
Subject: [Rtk-users] RTK + Cuda 9 + gcc 6.4 segfaults
In-Reply-To: <CAF0oig3rBH-=sooMwWtcsiuf7n6kkPp3NHAt3A4TLV5TE=kbaQ@mail.gmail.com>
References: <1513866014.1011.0@smtp-auth.fau.de>
 <CAF0oig3rBH-=sooMwWtcsiuf7n6kkPp3NHAt3A4TLV5TE=kbaQ@mail.gmail.com>
Message-ID: <1513895418.2625.0@smtp-auth.fau.de>

Ok, I was a bit early with the conclusion that this is Cuda related. 
Seems not. The only tests that pass are:
- rtkappsimulatedgeometrytest
- rtkappprojectshepploganphantomtest
- rtkwaveletstest
- rtkargsinfomanagertest

Kind regards
Mathis Hoffmann

On Do, Dez 21, 2017 at 3:50 PM, Simon Rit 
<simon.rit at creatis.insa-lyon.fr> wrote:
> Hi,
> Thanks for the report. Seems like something is happening in the ITK 
> code. Are other non cuda tests failing?
> Did you also compile ITK with C++11? BTW, why is it required?
> Best regards,
> Simon
> 
> On Thu, Dec 21, 2017 at 3:20 PM, Mathis Hoffmann 
> <mathis.hoffmann at fau.de> wrote:
>> Hello,
>> 
>> I was able to build RTK using Cuda 9 on an Arch Linux machine with 
>> gcc 6.4 with only small modifications:
>> 
>>  #=========================================================
>> diff --git a/cmake/nvcc-check.cmake b/cmake/nvcc-check.cmake
>> index c625b421..0e5c34e9 100644
>> --- a/cmake/nvcc-check.cmake
>> +++ b/cmake/nvcc-check.cmake
>> @@ -46,6 +46,9 @@ if(CUDA_FOUND)
>>    if((CMAKE_SYSTEM_NAME MATCHES "Linux" AND 
>> CMAKE_COMPILER_IS_GNUCC) OR APPLE)
>>      # Compatible gcc can be checked in host_config.h
>>      set(GCC_PATH "")
>> +    if(${CUDA_VERSION} VERSION_GREATER "8.99")
>> +      FIND_GCC(GCC_PATH "6" "4")
>> +    endif()
>>      if(${CUDA_VERSION} VERSION_GREATER "6.99")
>>        FIND_GC C(GCC_PATH "4" "9")
>>      endif()
>> 
>> 
>> In addition I had to set CMAKE_CXX_FLAGS to -std=gnu++11 manually in 
>> the ccmake dialog (unfortunately I was not able to integrate this in 
>> the top-level CMakeLists so far, CMake simply ignored it there..).
>> 
>> So far, so good. Unfortunately all Cuda tests fail with the same 
>> segfault. For example, rtkimportcudatest finishes with
>> 
>> ****** Case 1: unsigned short ******
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> 
>> ****** Case 2: int ******
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB< /div>
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> 
>> ****** Case 3: float ******
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> 
>> ****** Case 4: double ******
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> 
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>> 
>> 
>> Test PASSED!
>> Segmentation fault (core dumped)
>> 
>> To further investigate what is going wrong here, I ran valgrind. I 
>> think the most important message is this:
>> 
>> ==30633== Process terminating with default action of signal 11 
>> (SIGSEGV): dumping core
>> ==30633==  Access not within mapped region at address 0x8
>> ==30633==    at 0x12240072: (anonymous 
>> namespace)::ObjectFactoryBasePrivateInitializer::~ObjectFactoryBasePrivateInitializer() 
>> (in /home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
>> ==30633==    by 0x1402B7B1: __cxa_finalize (in /usr/lib/libc-2.26.so)
>> ==30633==    by 0x121771D3: ??? (in 
>> /home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
>> ==30633==    by 0x400FB92: _dl_fini (in /usr/lib/ld-2.26.so)
>> ==30633==    by 0x1402B447: __run_exit_handlers (in 
>> /usr/lib/libc-2.26.so)
>> ==30633==    by 0 x1402B499: exit (in /usr/lib/libc-2.26.so)
>> ==30633==    by 0x14014F50: (below main) (in /usr/lib/libc-2.26.so)
>> ==30633==  If you believe this happened as a result of a stack
>> ==30633==  overflow in your program's main thread (unlikely but
>> ==30633==  possible), you can try to increase the size of the
>> ==30633==  main thread stack using the --main-stacksize= flag.
>> ==30633==  The main thread stack size used in this run was 8388608.
>> 
>> I've put the full log here: https://pastebin.com/CBjJmUpB
>> 
>> Does someone have any idea, what is going wrong here?
>> 
>> Thanks for any help!
>> Mathis
>> 
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171221/c164e34a/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Fri Dec 22 07:44:23 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 22 Dec 2017 13:44:23 +0100
Subject: [Rtk-users] RTK + Cuda 9 + gcc 6.4 segfaults
In-Reply-To: <1513895418.2625.0@smtp-auth.fau.de>
References: <1513866014.1011.0@smtp-auth.fau.de>
 <CAF0oig3rBH-=sooMwWtcsiuf7n6kkPp3NHAt3A4TLV5TE=kbaQ@mail.gmail.com>
 <1513895418.2625.0@smtp-auth.fau.de>
Message-ID: <CAF0oig1kouynhj5JynuvNdg0jpW18R=ene33qWyM3VgoShi2dA@mail.gmail.com>

Hi,
I tried to reproduce the bug but I couldn't. See
http://my.cdash.org/buildSummary.php?buildid=1341867
Can you check if there is a difference in config? Are you compiling ITK
with shared libs? If yes, are you sure RTK uses the correct ones (check ldd
failing_binary)?
Otherwise, no clue what's the problem here.
Simon

On Thu, Dec 21, 2017 at 11:30 PM, Mathis Hoffmann <mathis.hoffmann at fau.de>
wrote:

> Ok, I was a bit early with the conclusion that this is Cuda related. Seems
> not. The only tests that pass are:
> - rtkappsimulatedgeometrytest
> - rtkappprojectshepploganphantomtest
> - rtkwaveletstest
> - rtkargsinfomanagertest
>
> Kind regards
> Mathis Hoffmann
>
> On Do, Dez 21, 2017 at 3:50 PM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
> wrote:
>
> Hi,
> Thanks for the report. Seems like something is happening in the ITK code.
> Are other non cuda tests failing?
> Did you also compile ITK with C++11? BTW, why is it required?
> Best regards,
> Simon
>
> On Thu, Dec 21, 2017 at 3:20 PM, Mathis Hoffmann
> <mathis.hoffmann at fau.de>< /span> wrote:
>
>> Hello,
>>
>> I was able to build RTK using Cuda 9 on an Arch Linux machine with gcc
>> 6.4 with only small modifications:
>>
>>  #=========================================================
>> diff --git a/cmake/nvcc-check.cmake b/cmake/nvcc-check.cmake
>> index c625b421..0e5c34e9 100644
>> --- a/cmake/nvcc-check.cmake
>> +++ b/cmake/nvcc-check.cmake
>> @@ -46,6 +46,9 @@ if(CUDA_FOUND)
>>    if((CMAKE_SYSTEM_NAME MATCHES "Linux" AND CMAKE_COMPILER_IS_GNUCC) OR
>> APPLE)
>>      # Compatible gcc can be checked in host_config.h
>>      set(GCC_PATH "")
>> +    if(${CUDA_VERSION} VERSION_GREATER "8.99")
>> +      FIND_GCC(GCC_PATH "6" "4")
>> +    endif()
>>      if(${CUDA_VERSION} VERSION_GREATER "6.99")
>>        FIND_GC C(GCC_PATH "4" "9")
>>      endif()
>>
>>
>> In addition I had to set CMAKE_CXX_FLAGS to -std=gnu++11 manually in the
>> ccmake dialog (unfortunately I was not able to integrate this in the
>> top-level CMakeLists so far, CMake simply ignored it there..).
>>
>> So far, so good. Unfortunately all Cuda tests fail with the same
>> segfault. For example, rtkimportcudatest finishes with
>>
>> ****** Case 1: unsigned short ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>>
>> ****** Case 2: int ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB& lt; /div>
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>>
>> ****** Case 3: float ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>>
>> ****** Case 4: double ******
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> Test PASSED!
>>
>> Error per Pixel = 0
>> MSE = 0
>> PSNR = infdB
>> QI = 1
>>
>>
>> < u>
>> Test PASSED!
>> Segmentation fault (core dumped)
>>
>> To further investigate what is going wrong here, I ran valgrind. I think
>> the most important message is this:
>>
>> ==30633== Process terminating with default action of signal 11 (SIGSEGV):
>> dumping core
>> ==30633==  Access not within mapped region at address 0x8
>> ==30633==    at 0x12240072: (anonymous namespace)::ObjectFactoryBaseP
>> rivateInitializer::~ObjectFactoryBasePrivateInitializer() (in
>> /home/mathis/dev/RTK/RTK-bin/bin/libRTK.so)
>> ==30633==    by 0x1402B7B1: __cxa_finalize (in /usr/lib/libc-2.26.so)
>> ==30633==    by 0x121771D3: ??? (in /home/mathis/dev/RTK/RTK-bin/b
>> in/libRTK.so)
>> ==30633==    by 0x400FB92: _dl_fini (in /usr/lib/ld-2.26.so)< /div>
>> ==30633==    by 0x1402B447: __run_exit_handlers (in /usr/lib/libc-2.26.so
>> )
>> ==30633==    by 0 x1402B499: exit (in /usr/lib/libc-2.26.so)
>> ==30633==    by 0x14014F50: (below main) (in /usr/lib/libc-2.26.so)
>> ==30633==  If you believe this happened as a result of a stack
>> ==30633==  overflow in your program's main thread (unlikely but
>> ==30633==  possible), you can try to increase the size of the
>> ==30633==  main thread stack using the --main-stacksize= flag.
>> ==30633==  The main thread stack size used in this run was 8388608.
>>
>> I've put the full log here: https://pastebin.com/CBjJmUpB
>>
>> Does someone have any idea, what is going wrong here?
>>
>> Thanks for any help!
>> Mathis
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/0f3b8ad2/attachment-0001.html>

From boursier at cppm.in2p3.fr  Fri Dec 22 15:17:13 2017
From: boursier at cppm.in2p3.fr (Yannick Boursier)
Date: Fri, 22 Dec 2017 21:17:13 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
Message-ID: <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>

Hi Cyril,

Sorry for my late answer. First thank you because your last trick 
(removing <InpuImageType>) worked, I correctly compiled and installed 
everything.

I am late because I thought that I did something wrong since when I 
tested the code by simply projecting then backprojecting a simple 
volume, the results between the CPU-codes and GPU-codes were different 
and the GPU result cas clearly wrong.

I understood this morning the problem and put it in evidence : the 
CudaForwardProjectionImageFilter seems to be not adapted to the case 
when the size of voxels and pixels are not equal to 1 whereas the 
CudaBackProjectionImageFilter is OK for that !!

I will try to debug it and let you know.

I wish to all of you a Merry Christmas and relaxing holidays.

Best ,

Yannick


Le 18/12/2017 ? 16:52, Cyril Mory a ?crit?:
>
> Hi again Yannick,
>
> Simply removing the <InputImageType> on line 9 of your .json file made 
> it compile. I didn't test it yet. Let us know if that works for you.
>
> Cyril
>
>
> On 18/12/2017 16:31, Cyril Mory wrote:
>>
>> Hi Yannick,
>>
>> You seem to be in a hurry, so I'll start with an incomplete answer: 
>> the CudaForwardProjectionImageFilter is templated over its input and 
>> output image type, but the CudaBackProjectionImageFilter isn't 
>> (compare rtkCudaForwardProjectionImageFilter.h and 
>> rtkCudaBackProjectionImageFilter.h, there is not "template <>" before 
>> the class definition in ...Back..., while it is there in ...Forward...).
>>
>> I'm trying to modify your .json file accordingly, recompile and test, 
>> but I never use SimpleRTK myself, so you might find the solution 
>> before I do. If so, please report back on this mailing list.
>>
>> Cyril
>>
>>
>> On 18/12/2017 16:07, Yannick BOURSIER wrote:
>>> Hello all,
>>>
>>> I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>>> Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>>
>>> I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>>
>>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>>     typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>>
>>> I would very much appreciate some help please because at this point, I have no idea about the problem...
>>> Thanks in advance,
>>> Best regards,
>>> Yannick Boursier
>>>
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/3c786973/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Fri Dec 22 16:55:26 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 22 Dec 2017 22:55:26 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
 <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
Message-ID: <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>

Hi Yannick,
I would just try to change the step size
<http://www.openrtk.org/Doxygen/classrtk_1_1CudaForwardProjectionImageFilter.html#a93671bae5219bada43b9a00b6046dbed>.
Indeed, the CPU version is the Joseph projector and it adapts automatically
the step size to each ray for bilinear interpolation in each slice. The GPU
version is a fixed step size combined with a trilinear interpolation.
Merry Christmas to you,
Simon

On Fri, Dec 22, 2017 at 9:17 PM, Yannick Boursier <boursier at cppm.in2p3.fr>
wrote:

> Hi Cyril,
>
> Sorry for my late answer. First thank you because your last trick
> (removing <InpuImageType>) worked, I correctly compiled and installed
> everything.
>
> I am late because I thought that I did something wrong since when I tested
> the code by simply projecting then backprojecting a simple volume, the
> results between the CPU-codes and GPU-codes were different and the GPU
> result cas clearly wrong.
>
> I understood this morning the problem and put it in evidence : the
> CudaForwardProjectionImageFilter seems to be not adapted to the case when
> the size of voxels and pixels are not equal to 1 whereas the
> CudaBackProjectionImageFilter is OK for that !!
>
> I will try to debug it and let you know.
>
> I wish to all of you a Merry Christmas and relaxing holidays.
>
> Best ,
>
> Yannick
>
> Le 18/12/2017 ? 16:52, Cyril Mory a ?crit :
>
> Hi again Yannick,
>
> Simply removing the <InputImageType> on line 9 of your .json file made it
> compile. I didn't test it yet. Let us know if that works for you.
>
> Cyril
>
> On 18/12/2017 16:31, Cyril Mory wrote:
>
> Hi Yannick,
>
> You seem to be in a hurry, so I'll start with an incomplete answer: the
> CudaForwardProjectionImageFilter is templated over its input and output
> image type, but the CudaBackProjectionImageFilter isn't (compare
> rtkCudaForwardProjectionImageFilter.h and rtkCudaBackProjectionImageFilter.h,
> there is not "template <>" before the class definition in ...Back..., while
> it is there in ...Forward...).
> I'm trying to modify your .json file accordingly, recompile and test, but
> I never use SimpleRTK myself, so you might find the solution before I do.
> If so, please report back on this mailing list.
>
> Cyril
>
>
> On 18/12/2017 16:07, Yannick BOURSIER wrote:
>
> Hello all,
>
> I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
> Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>
> I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>
> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>    typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>
> I would very much appreciate some help please because at this point, I have no idea about the problem...
> Thanks in advance,
> Best regards,
> Yannick Boursier
>
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttps://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/3c8de0de/attachment.html>

From boursier at cppm.in2p3.fr  Fri Dec 22 17:31:31 2017
From: boursier at cppm.in2p3.fr (Yannick Boursier)
Date: Fri, 22 Dec 2017 23:31:31 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
 <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
 <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>
Message-ID: <2e18165e-b970-3307-ee07-f5bf6ec88530@cppm.in2p3.fr>

Hi Simon,

Thank you a lot for your answer, I will try to put the step size to the 
voxel size then (if I understand well). It seems that the implementation 
of the CudaBackProjectionImageFilter doesn't use any stepsize. I'll let 
you know.

Merry Christmas to you,
Yannick


Le 22/12/2017 ? 22:55, Simon Rit a ?crit?:
> Hi Yannick,
> I would just try to change the step size 
> <http://www.openrtk.org/Doxygen/classrtk_1_1CudaForwardProjectionImageFilter.html#a93671bae5219bada43b9a00b6046dbed>. 
> Indeed, the CPU version is the Joseph projector and it adapts 
> automatically the step size to each ray for bilinear interpolation in 
> each slice. The GPU version is a fixed step size combined with a 
> trilinear interpolation.
> Merry Christmas to you,
> Simon
>
> On Fri, Dec 22, 2017 at 9:17 PM, Yannick Boursier 
> <boursier at cppm.in2p3.fr <mailto:boursier at cppm.in2p3.fr>> wrote:
>
>     Hi Cyril,
>
>     Sorry for my late answer. First thank you because your last trick
>     (removing <InpuImageType>) worked, I correctly compiled and
>     installed everything.
>
>     I am late because I thought that I did something wrong since when
>     I tested the code by simply projecting then backprojecting a
>     simple volume, the results between the CPU-codes and GPU-codes
>     were different and the GPU result cas clearly wrong.
>
>     I understood this morning the problem and put it in evidence : the
>     CudaForwardProjectionImageFilter seems to be not adapted to the
>     case when the size of voxels and pixels are not equal to 1 whereas
>     the CudaBackProjectionImageFilter is OK for that !!
>
>     I will try to debug it and let you know.
>
>     I wish to all of you a Merry Christmas and relaxing holidays.
>
>     Best ,
>
>     Yannick
>
>
>     Le 18/12/2017 ? 16:52, Cyril Mory a ?crit?:
>>
>>     Hi again Yannick,
>>
>>     Simply removing the <InputImageType> on line 9 of your .json file
>>     made it compile. I didn't test it yet. Let us know if that works
>>     for you.
>>
>>     Cyril
>>
>>
>>     On 18/12/2017 16:31, Cyril Mory wrote:
>>>
>>>     Hi Yannick,
>>>
>>>     You seem to be in a hurry, so I'll start with an incomplete
>>>     answer: the CudaForwardProjectionImageFilter is templated over
>>>     its input and output image type, but the
>>>     CudaBackProjectionImageFilter isn't (compare
>>>     rtkCudaForwardProjectionImageFilter.h and
>>>     rtkCudaBackProjectionImageFilter.h, there is not "template <>"
>>>     before the class definition in ...Back..., while it is there in
>>>     ...Forward...).
>>>
>>>     I'm trying to modify your .json file accordingly, recompile and
>>>     test, but I never use SimpleRTK myself, so you might find the
>>>     solution before I do. If so, please report back on this mailing
>>>     list.
>>>
>>>     Cyril
>>>
>>>
>>>     On 18/12/2017 16:07, Yannick BOURSIER wrote:
>>>>     Hello all,
>>>>
>>>>     I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>>>>     Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>>>
>>>>     I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>>>
>>>>     /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>>>>     /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>>>         typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>>>
>>>>     I would very much appreciate some help please because at this point, I have no idea about the problem...
>>>>     Thanks in advance,
>>>>     Best regards,
>>>>     Yannick Boursier
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Rtk-users mailing list
>>>>     Rtk-users at public.kitware.com <mailto:Rtk-users at public.kitware.com>
>>>>     https://public.kitware.com/mailman/listinfo/rtk-users
>>>>     <https://public.kitware.com/mailman/listinfo/rtk-users>
>>>
>>
>
>
>     _______________________________________________
>     Rtk-users mailing list
>     Rtk-users at public.kitware.com <mailto:Rtk-users at public.kitware.com>
>     https://public.kitware.com/mailman/listinfo/rtk-users
>     <https://public.kitware.com/mailman/listinfo/rtk-users>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/42d4a64e/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Fri Dec 22 17:34:40 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 22 Dec 2017 23:34:40 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <2e18165e-b970-3307-ee07-f5bf6ec88530@cppm.in2p3.fr>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
 <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
 <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>
 <2e18165e-b970-3307-ee07-f5bf6ec88530@cppm.in2p3.fr>
Message-ID: <CAF0oig0omPKDMr5q0D4x1Rnor_CY2A7k7wAoOLBPHipOJnPCWQ@mail.gmail.com>

No it doesn't, it's voxel based. The adjoint which uses the step size is
CudaRayCastBackProjectionImageFilter
<http://www.openrtk.org/Doxygen/classrtk_1_1CudaRayCastBackProjectionImageFilter.html>
but it's very slow and we never use it in practice because it's not
practical. When we want to use adjoint operators, we mainly use the CPU
version, with double precision when adjointness is very important.
Simon

On Fri, Dec 22, 2017 at 11:31 PM, Yannick Boursier <boursier at cppm.in2p3.fr>
wrote:

> Hi Simon,
>
> Thank you a lot for your answer, I will try to put the step size to the
> voxel size then (if I understand well). It seems that the implementation of
> the CudaBackProjectionImageFilter doesn't use any stepsize. I'll let you
> know.
>
> Merry Christmas to you,
> Yannick
>
> Le 22/12/2017 ? 22:55, Simon Rit a ?crit :
>
> Hi Yannick,
> I would just try to change the step size
> <http://www.openrtk.org/Doxygen/classrtk_1_1CudaForwardProjectionImageFilter.html#a93671bae5219bada43b9a00b6046dbed>.
> Indeed, the CPU version is the Joseph projector and it adapts automatically
> the step size to each ray for bilinear interpolation in each slice. The GPU
> version is a fixed step size combined with a trilinear interpolation.
> Merry Christmas to you,
> Simon
>
> On Fri, Dec 22, 2017 at 9:17 PM, Yannick Boursier <boursier at cppm.in2p3.fr>
> wrote:
>
>> Hi Cyril,
>>
>> Sorry for my late answer. First thank you because your last trick
>> (removing <InpuImageType>) worked, I correctly compiled and installed
>> everything.
>>
>> I am late because I thought that I did something wrong since when I
>> tested the code by simply projecting then backprojecting a simple volume,
>> the results between the CPU-codes and GPU-codes were different and the GPU
>> result cas clearly wrong.
>>
>> I understood this morning the problem and put it in evidence : the
>> CudaForwardProjectionImageFilter seems to be not adapted to the case
>> when the size of voxels and pixels are not equal to 1 whereas the
>> CudaBackProjectionImageFilter is OK for that !!
>>
>> I will try to debug it and let you know.
>>
>> I wish to all of you a Merry Christmas and relaxing holidays.
>>
>> Best ,
>>
>> Yannick
>>
>> Le 18/12/2017 ? 16:52, Cyril Mory a ?crit :
>>
>> Hi again Yannick,
>>
>> Simply removing the <InputImageType> on line 9 of your .json file made it
>> compile. I didn't test it yet. Let us know if that works for you.
>>
>> Cyril
>>
>> On 18/12/2017 16:31, Cyril Mory wrote:
>>
>> Hi Yannick,
>>
>> You seem to be in a hurry, so I'll start with an incomplete answer: the
>> CudaForwardProjectionImageFilter is templated over its input and output
>> image type, but the CudaBackProjectionImageFilter isn't (compare
>> rtkCudaForwardProjectionImageFilter.h and rtkCudaBackProjectionImageFilter.h,
>> there is not "template <>" before the class definition in ...Back..., while
>> it is there in ...Forward...).
>> I'm trying to modify your .json file accordingly, recompile and test, but
>> I never use SimpleRTK myself, so you might find the solution before I do.
>> If so, please report back on this mailing list.
>>
>> Cyril
>>
>>
>> On 18/12/2017 16:07, Yannick BOURSIER wrote:
>>
>> Hello all,
>>
>> I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>> Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>
>> I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>
>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>    typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>
>> I would very much appreciate some help please because at this point, I have no idea about the problem...
>> Thanks in advance,
>> Best regards,
>> Yannick Boursier
>>
>>
>>
>> _______________________________________________
>> Rtk-users mailing listRtk-users at public.kitware.comhttps://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
>>
>>
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/ce3152a4/attachment.html>

From boursier at cppm.in2p3.fr  Fri Dec 22 17:42:38 2017
From: boursier at cppm.in2p3.fr (Yannick Boursier)
Date: Fri, 22 Dec 2017 23:42:38 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <CAF0oig0omPKDMr5q0D4x1Rnor_CY2A7k7wAoOLBPHipOJnPCWQ@mail.gmail.com>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
 <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
 <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>
 <2e18165e-b970-3307-ee07-f5bf6ec88530@cppm.in2p3.fr>
 <CAF0oig0omPKDMr5q0D4x1Rnor_CY2A7k7wAoOLBPHipOJnPCWQ@mail.gmail.com>
Message-ID: <a5a6c232-3a2c-a75a-6793-d5b241b59d8a@cppm.in2p3.fr>

Ok thanks for this important precision.

Just a remark, I don't have access to the SetStepSize() function through 
SimpleRTK. Is it normal ? Does it come from the .json file or the template ?

Thanks in advance.
Yannick


Le 22/12/2017 ? 23:34, Simon Rit a ?crit?:
> No it doesn't, it's voxel based. The adjoint which uses the step size 
> is CudaRayCastBackProjectionImageFilter 
> <http://www.openrtk.org/Doxygen/classrtk_1_1CudaRayCastBackProjectionImageFilter.html> 
> but it's very slow and we never use it in practice because it's not 
> practical. When we want to use adjoint operators, we mainly use the 
> CPU version, with double precision when adjointness is very important.
> Simon
>
> On Fri, Dec 22, 2017 at 11:31 PM, Yannick Boursier 
> <boursier at cppm.in2p3.fr <mailto:boursier at cppm.in2p3.fr>> wrote:
>
>     Hi Simon,
>
>     Thank you a lot for your answer, I will try to put the step size
>     to the voxel size then (if I understand well). It seems that the
>     implementation of the CudaBackProjectionImageFilter doesn't use
>     any stepsize. I'll let you know.
>
>     Merry Christmas to you,
>     Yannick
>
>
>     Le 22/12/2017 ? 22:55, Simon Rit a ?crit?:
>>     Hi Yannick,
>>     I would just try to change the step size
>>     <http://www.openrtk.org/Doxygen/classrtk_1_1CudaForwardProjectionImageFilter.html#a93671bae5219bada43b9a00b6046dbed>.
>>     Indeed, the CPU version is the Joseph projector and it adapts
>>     automatically the step size to each ray for bilinear
>>     interpolation in each slice. The GPU version is a fixed step size
>>     combined with a trilinear interpolation.
>>     Merry Christmas to you,
>>     Simon
>>
>>     On Fri, Dec 22, 2017 at 9:17 PM, Yannick Boursier
>>     <boursier at cppm.in2p3.fr <mailto:boursier at cppm.in2p3.fr>> wrote:
>>
>>         Hi Cyril,
>>
>>         Sorry for my late answer. First thank you because your last
>>         trick (removing <InpuImageType>) worked, I correctly compiled
>>         and installed everything.
>>
>>         I am late because I thought that I did something wrong since
>>         when I tested the code by simply projecting then
>>         backprojecting a simple volume, the results between the
>>         CPU-codes and GPU-codes were different and the GPU result cas
>>         clearly wrong.
>>
>>         I understood this morning the problem and put it in evidence
>>         : the CudaForwardProjectionImageFilter seems to be not
>>         adapted to the case when the size of voxels and pixels are
>>         not equal to 1 whereas the CudaBackProjectionImageFilter is
>>         OK for that !!
>>
>>         I will try to debug it and let you know.
>>
>>         I wish to all of you a Merry Christmas and relaxing holidays.
>>
>>         Best ,
>>
>>         Yannick
>>
>>
>>         Le 18/12/2017 ? 16:52, Cyril Mory a ?crit?:
>>>
>>>         Hi again Yannick,
>>>
>>>         Simply removing the <InputImageType> on line 9 of your .json
>>>         file made it compile. I didn't test it yet. Let us know if
>>>         that works for you.
>>>
>>>         Cyril
>>>
>>>
>>>         On 18/12/2017 16:31, Cyril Mory wrote:
>>>>
>>>>         Hi Yannick,
>>>>
>>>>         You seem to be in a hurry, so I'll start with an incomplete
>>>>         answer: the CudaForwardProjectionImageFilter is templated
>>>>         over its input and output image type, but the
>>>>         CudaBackProjectionImageFilter isn't (compare
>>>>         rtkCudaForwardProjectionImageFilter.h and
>>>>         rtkCudaBackProjectionImageFilter.h, there is not "template
>>>>         <>" before the class definition in ...Back..., while it is
>>>>         there in ...Forward...).
>>>>
>>>>         I'm trying to modify your .json file accordingly, recompile
>>>>         and test, but I never use SimpleRTK myself, so you might
>>>>         find the solution before I do. If so, please report back on
>>>>         this mailing list.
>>>>
>>>>         Cyril
>>>>
>>>>
>>>>         On 18/12/2017 16:07, Yannick BOURSIER wrote:
>>>>>         Hello all,
>>>>>
>>>>>         I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>>>>>         Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>>>>
>>>>>         I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>>>>
>>>>>         /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>>>>>         /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>>>>             typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>>>>
>>>>>         I would very much appreciate some help please because at this point, I have no idea about the problem...
>>>>>         Thanks in advance,
>>>>>         Best regards,
>>>>>         Yannick Boursier
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         Rtk-users mailing list
>>>>>         Rtk-users at public.kitware.com
>>>>>         <mailto:Rtk-users at public.kitware.com>
>>>>>         https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>         <https://public.kitware.com/mailman/listinfo/rtk-users>
>>>>
>>>
>>
>>
>>         _______________________________________________
>>         Rtk-users mailing list
>>         Rtk-users at public.kitware.com
>>         <mailto:Rtk-users at public.kitware.com>
>>         https://public.kitware.com/mailman/listinfo/rtk-users
>>         <https://public.kitware.com/mailman/listinfo/rtk-users>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/f57a4485/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Fri Dec 22 17:54:02 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 22 Dec 2017 23:54:02 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <a5a6c232-3a2c-a75a-6793-d5b241b59d8a@cppm.in2p3.fr>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
 <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
 <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>
 <2e18165e-b970-3307-ee07-f5bf6ec88530@cppm.in2p3.fr>
 <CAF0oig0omPKDMr5q0D4x1Rnor_CY2A7k7wAoOLBPHipOJnPCWQ@mail.gmail.com>
 <a5a6c232-3a2c-a75a-6793-d5b241b59d8a@cppm.in2p3.fr>
Message-ID: <CAF0oig3wrfc76iqmuG8KpRS-VDJkTcN9wSiHp9gjSVaaCc2NWQ@mail.gmail.com>

It depends on how you define normal... It hasn't been wrapped so it's
expected but we should have wrapped it when creating the json file. You
need to add
    },
    {
      "name" : "StepSize",
      "type" : "double",
      "default" : "1."
after the line containing custom_itk_cast in the members section, i.e.,
before the curly bracket closing the Geometry section (which, after
pasting, will close the StepSize section). Don't forget the note on the
wiki about json files:

*Note that you might need to rebuild the solution in order for CMake to
take the changes into account.* Another solution is to manually delete the
file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure.
This wrapping is a bit annoying so we do it when we need to access one
class or member. We will soon move to a new python wrapping which will
hopefully be easier (this is the purpose of the RTK-ExternalModule branch
on the repository). We'll keep you posted!
Simon

On Fri, Dec 22, 2017 at 11:42 PM, Yannick Boursier <boursier at cppm.in2p3.fr>
wrote:

> Ok thanks for this important precision.
>
> Just a remark, I don't have access to the SetStepSize() function through
> SimpleRTK. Is it normal ? Does it come from the .json file or the template ?
>
> Thanks in advance.
> Yannick
>
> Le 22/12/2017 ? 23:34, Simon Rit a ?crit :
>
> No it doesn't, it's voxel based. The adjoint which uses the step size is
> CudaRayCastBackProjectionImageFilter
> <http://www.openrtk.org/Doxygen/classrtk_1_1CudaRayCastBackProjectionImageFilter.html>
> but it's very slow and we never use it in practice because it's not
> practical. When we want to use adjoint operators, we mainly use the CPU
> version, with double precision when adjointness is very important.
> Simon
>
> On Fri, Dec 22, 2017 at 11:31 PM, Yannick Boursier <boursier at cppm.in2p3.fr
> > wrote:
>
>> Hi Simon,
>>
>> Thank you a lot for your answer, I will try to put the step size to the
>> voxel size then (if I understand well). It seems that the implementation of
>> the CudaBackProjectionImageFilter doesn't use any stepsize. I'll let you
>> know.
>>
>> Merry Christmas to you,
>> Yannick
>>
>> Le 22/12/2017 ? 22:55, Simon Rit a ?crit :
>>
>> Hi Yannick,
>> I would just try to change the step size
>> <http://www.openrtk.org/Doxygen/classrtk_1_1CudaForwardProjectionImageFilter.html#a93671bae5219bada43b9a00b6046dbed>.
>> Indeed, the CPU version is the Joseph projector and it adapts automatically
>> the step size to each ray for bilinear interpolation in each slice. The GPU
>> version is a fixed step size combined with a trilinear interpolation.
>> Merry Christmas to you,
>> Simon
>>
>> On Fri, Dec 22, 2017 at 9:17 PM, Yannick Boursier <boursier at cppm.in2p3.fr
>> > wrote:
>>
>>> Hi Cyril,
>>>
>>> Sorry for my late answer. First thank you because your last trick
>>> (removing <InpuImageType>) worked, I correctly compiled and installed
>>> everything.
>>>
>>> I am late because I thought that I did something wrong since when I
>>> tested the code by simply projecting then backprojecting a simple volume,
>>> the results between the CPU-codes and GPU-codes were different and the GPU
>>> result cas clearly wrong.
>>>
>>> I understood this morning the problem and put it in evidence : the
>>> CudaForwardProjectionImageFilter seems to be not adapted to the case
>>> when the size of voxels and pixels are not equal to 1 whereas the
>>> CudaBackProjectionImageFilter is OK for that !!
>>>
>>> I will try to debug it and let you know.
>>>
>>> I wish to all of you a Merry Christmas and relaxing holidays.
>>>
>>> Best ,
>>>
>>> Yannick
>>>
>>> Le 18/12/2017 ? 16:52, Cyril Mory a ?crit :
>>>
>>> Hi again Yannick,
>>>
>>> Simply removing the <InputImageType> on line 9 of your .json file made
>>> it compile. I didn't test it yet. Let us know if that works for you.
>>>
>>> Cyril
>>>
>>> On 18/12/2017 16:31, Cyril Mory wrote:
>>>
>>> Hi Yannick,
>>>
>>> You seem to be in a hurry, so I'll start with an incomplete answer: the
>>> CudaForwardProjectionImageFilter is templated over its input and output
>>> image type, but the CudaBackProjectionImageFilter isn't (compare
>>> rtkCudaForwardProjectionImageFilter.h and rtkCudaBackProjectionImageFilter.h,
>>> there is not "template <>" before the class definition in ...Back..., while
>>> it is there in ...Forward...).
>>> I'm trying to modify your .json file accordingly, recompile and test,
>>> but I never use SimpleRTK myself, so you might find the solution before I
>>> do. If so, please report back on this mailing list.
>>>
>>> Cyril
>>>
>>>
>>> On 18/12/2017 16:07, Yannick BOURSIER wrote:
>>>
>>> Hello all,
>>>
>>> I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>>> Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>>
>>> I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>>
>>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>>> /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>>    typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>>
>>> I would very much appreciate some help please because at this point, I have no idea about the problem...
>>> Thanks in advance,
>>> Best regards,
>>> Yannick Boursier
>>>
>>>
>>>
>>> _______________________________________________
>>> Rtk-users mailing listRtk-users at public.kitware.comhttps://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/d94ad901/attachment.html>

From boursier at cppm.in2p3.fr  Fri Dec 22 17:57:03 2017
From: boursier at cppm.in2p3.fr (Yannick Boursier)
Date: Fri, 22 Dec 2017 23:57:03 +0100
Subject: [Rtk-users] SimpleRTK : help for defining a correct json file
 for CudaBackProjectionImageFilter
In-Reply-To: <CAF0oig3wrfc76iqmuG8KpRS-VDJkTcN9wSiHp9gjSVaaCc2NWQ@mail.gmail.com>
References: <642366356.16048050.1513609645522.JavaMail.zimbra@cppm.in2p3.fr>
 <fc099918-f2b2-a5ba-6521-71373a47744d@creatis.insa-lyon.fr>
 <52b09be5-3a24-ddb7-98f2-6934932f38ba@creatis.insa-lyon.fr>
 <f72f0329-475a-4681-c0c6-cbc612d016e4@cppm.in2p3.fr>
 <CAF0oig0CFOhcWtT5DJ1hYrj0geGCSxjsrca50W7KhuzAiexbSA@mail.gmail.com>
 <2e18165e-b970-3307-ee07-f5bf6ec88530@cppm.in2p3.fr>
 <CAF0oig0omPKDMr5q0D4x1Rnor_CY2A7k7wAoOLBPHipOJnPCWQ@mail.gmail.com>
 <a5a6c232-3a2c-a75a-6793-d5b241b59d8a@cppm.in2p3.fr>
 <CAF0oig3wrfc76iqmuG8KpRS-VDJkTcN9wSiHp9gjSVaaCc2NWQ@mail.gmail.com>
Message-ID: <5be0fb4f-6da8-049f-4d14-594c69766c4e@cppm.in2p3.fr>

Really thanks a lot Simon. You're kind of Santa Claus :)

I will re-compile this night, we will see the results next week !

Best,
Yannick


Le 22/12/2017 ? 23:54, Simon Rit a ?crit?:
> It depends on how you define normal... It hasn't been wrapped so it's 
> expected but we should have wrapped it when creating the json file. 
> You need to add
> ??? },
> ??? {
> ????? "name" : "StepSize",
> ????? "type" : "double",
> ????? "default" : "1."
> after the line containing custom_itk_cast in the members section, 
> i.e., before the curly bracket closing the Geometry section (which, 
> after pasting, will close the StepSize section). Don't forget the note 
> on the wiki about json files:
>
> *Note that you might need to rebuild the solution in order for CMake 
> to take the changes into account.* Another solution is to manually 
> delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure.
>
> This wrapping is a bit annoying so we do it when we need to access one 
> class or member. We will soon move to a new python wrapping which will 
> hopefully be easier (this is the purpose of the RTK-ExternalModule 
> branch on the repository). We'll keep you posted!
> Simon
>
> On Fri, Dec 22, 2017 at 11:42 PM, Yannick Boursier 
> <boursier at cppm.in2p3.fr <mailto:boursier at cppm.in2p3.fr>> wrote:
>
>     Ok thanks for this important precision.
>
>     Just a remark, I don't have access to the SetStepSize() function
>     through SimpleRTK. Is it normal ? Does it come from the .json file
>     or the template ?
>
>     Thanks in advance.
>     Yannick
>
>
>     Le 22/12/2017 ? 23:34, Simon Rit a ?crit?:
>>     No it doesn't, it's voxel based. The adjoint which uses the step
>>     size is CudaRayCastBackProjectionImageFilter
>>     <http://www.openrtk.org/Doxygen/classrtk_1_1CudaRayCastBackProjectionImageFilter.html>
>>     but it's very slow and we never use it in practice because it's
>>     not practical. When we want to use adjoint operators, we mainly
>>     use the CPU version, with double precision when adjointness is
>>     very important.
>>     Simon
>>
>>     On Fri, Dec 22, 2017 at 11:31 PM, Yannick Boursier
>>     <boursier at cppm.in2p3.fr <mailto:boursier at cppm.in2p3.fr>> wrote:
>>
>>         Hi Simon,
>>
>>         Thank you a lot for your answer, I will try to put the step
>>         size to the voxel size then (if I understand well). It seems
>>         that the implementation of the CudaBackProjectionImageFilter
>>         doesn't use any stepsize. I'll let you know.
>>
>>         Merry Christmas to you,
>>         Yannick
>>
>>
>>         Le 22/12/2017 ? 22:55, Simon Rit a ?crit?:
>>>         Hi Yannick,
>>>         I would just try to change the step size
>>>         <http://www.openrtk.org/Doxygen/classrtk_1_1CudaForwardProjectionImageFilter.html#a93671bae5219bada43b9a00b6046dbed>.
>>>         Indeed, the CPU version is the Joseph projector and it
>>>         adapts automatically the step size to each ray for bilinear
>>>         interpolation in each slice. The GPU version is a fixed step
>>>         size combined with a trilinear interpolation.
>>>         Merry Christmas to you,
>>>         Simon
>>>
>>>         On Fri, Dec 22, 2017 at 9:17 PM, Yannick Boursier
>>>         <boursier at cppm.in2p3.fr <mailto:boursier at cppm.in2p3.fr>> wrote:
>>>
>>>             Hi Cyril,
>>>
>>>             Sorry for my late answer. First thank you because your
>>>             last trick (removing <InpuImageType>) worked, I
>>>             correctly compiled and installed everything.
>>>
>>>             I am late because I thought that I did something wrong
>>>             since when I tested the code by simply projecting then
>>>             backprojecting a simple volume, the results between the
>>>             CPU-codes and GPU-codes were different and the GPU
>>>             result cas clearly wrong.
>>>
>>>             I understood this morning the problem and put it in
>>>             evidence : the CudaForwardProjectionImageFilter seems to
>>>             be not adapted to the case when the size of voxels and
>>>             pixels are not equal to 1 whereas the
>>>             CudaBackProjectionImageFilter is OK for that !!
>>>
>>>             I will try to debug it and let you know.
>>>
>>>             I wish to all of you a Merry Christmas and relaxing
>>>             holidays.
>>>
>>>             Best ,
>>>
>>>             Yannick
>>>
>>>
>>>             Le 18/12/2017 ? 16:52, Cyril Mory a ?crit?:
>>>>
>>>>             Hi again Yannick,
>>>>
>>>>             Simply removing the <InputImageType> on line 9 of your
>>>>             .json file made it compile. I didn't test it yet. Let
>>>>             us know if that works for you.
>>>>
>>>>             Cyril
>>>>
>>>>
>>>>             On 18/12/2017 16:31, Cyril Mory wrote:
>>>>>
>>>>>             Hi Yannick,
>>>>>
>>>>>             You seem to be in a hurry, so I'll start with an
>>>>>             incomplete answer: the
>>>>>             CudaForwardProjectionImageFilter is templated over its
>>>>>             input and output image type, but the
>>>>>             CudaBackProjectionImageFilter isn't (compare
>>>>>             rtkCudaForwardProjectionImageFilter.h and
>>>>>             rtkCudaBackProjectionImageFilter.h, there is not
>>>>>             "template <>" before the class definition in
>>>>>             ...Back..., while it is there in ...Forward...).
>>>>>
>>>>>             I'm trying to modify your .json file accordingly,
>>>>>             recompile and test, but I never use SimpleRTK myself,
>>>>>             so you might find the solution before I do. If so,
>>>>>             please report back on this mailing list.
>>>>>
>>>>>             Cyril
>>>>>
>>>>>
>>>>>             On 18/12/2017 16:07, Yannick BOURSIER wrote:
>>>>>>             Hello all,
>>>>>>
>>>>>>             I really need in "relative" emergency to execute the kernel CudaBackProjectionImageFilter using the Python Wrapper provided by SimpleRTK.
>>>>>>             Unfortunately, this is not implemented in cuda (CudaForwardProjectionImageFilter is but not the BackProjection).
>>>>>>
>>>>>>             I tried to define a json file (in attachement) on the base of CudaForwardProjectionImageFilter (since all the h, hxx, cxx, files I looked at seemed to be the same for these two kernels) but it does not compile (cmake instruction OK but not the make instruction) with the following error :
>>>>>>
>>>>>>             /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx: In member function ?rtk::simple::Image rtk::simple::CudaBackProjectionImageFilter::ExecuteInternal(const rtk::simple::Image&, const rtk::simple::Image&)?:
>>>>>>             /data/boursier/Compile/rtk-bin-extended/SimpleRTK-build/Code/BasicFilters/src/srtkCudaBackProjectionImageFilter.cxx:132:16: error: ?rtk::CudaBackProjectionImageFilter? is not a template
>>>>>>                 typedef rtk::CudaBackProjectionImageFilter<InputImageType> FilterType;
>>>>>>
>>>>>>             I would very much appreciate some help please because at this point, I have no idea about the problem...
>>>>>>             Thanks in advance,
>>>>>>             Best regards,
>>>>>>             Yannick Boursier
>>>>>>
>>>>>>
>>>>>>             _______________________________________________
>>>>>>             Rtk-users mailing list
>>>>>>             Rtk-users at public.kitware.com
>>>>>>             <mailto:Rtk-users at public.kitware.com>
>>>>>>             https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>             <https://public.kitware.com/mailman/listinfo/rtk-users>
>>>>>
>>>>
>>>
>>>
>>>             _______________________________________________
>>>             Rtk-users mailing list
>>>             Rtk-users at public.kitware.com
>>>             <mailto:Rtk-users at public.kitware.com>
>>>             https://public.kitware.com/mailman/listinfo/rtk-users
>>>             <https://public.kitware.com/mailman/listinfo/rtk-users>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171222/2eb26ed6/attachment-0001.html>

From ry.meng at siat.ac.cn  Mon Dec 25 03:36:49 2017
From: ry.meng at siat.ac.cn (ry.meng)
Date: Mon, 25 Dec 2017 16:36:49 +0800
Subject: [Rtk-users] problem while determining the interpolation weights in
 4D ROOSTER Reconstruction
Message-ID: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171225/8f7f180c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1514190593(1).png
Type: image/png
Size: 192406 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171225/8f7f180c/attachment-0001.png>

From simon.rit at creatis.insa-lyon.fr  Tue Dec 26 04:12:40 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 26 Dec 2017 10:12:40 +0100
Subject: [Rtk-users] problem while determining the interpolation weights
 in 4D ROOSTER Reconstruction
In-Reply-To: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn>
References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn>
Message-ID: <CAF0oig155HwxZHkOxEcm3ksFxV+cAQyZVrwbT3cJkQ7yZxOFAA@mail.gmail.com>

Hi,
If you look at the code
<https://github.com/SimonRit/RTK/blob/master/code/rtkPhasesToInterpolationWeights.hxx#L154>,
you'll see that the error message corresponds to the case where you have a
phase which equals the number of frames. This cannot be since it is
0-based. In other words, with the option "--frames 5", you cannot have a
value larger or equal to 5 in your file sphase.txt.
Simon

On Mon, Dec 25, 2017 at 9:36 AM, ry.meng <ry.meng at siat.ac.cn> wrote:

>
> Hi:
>
> When I tried  the application of 4D ROOSTER Reconstruction with my own
> data, it will stop for the following reason: problem while determining
> the interpolation weights. Maybe you guys have met this problem before
> and have a solution for it. Thank you very much and I hope to receive your
> reply soon.
>
>
> Happy Holidays!
>
>
> Regards
>
> Ruoyan Meng
>
>
>
> ------------------------------------------------------------
> ------------------------------
>
> Research Center for Medical Robotics and Minimally Invasive Surgical
> Devices,
> Institute of Biomedical and Health Engineering,
> Shenzhen Institutes of Advanced Technology, Chinese Academy of Sciences
> Tel:       +86-18576617767 <+86%20185%207661%207767>
> Email:   ry.meng at siat.ac.cn <qs.zhu at siat.ac.cn>
> Zip:       518055
> Add:      No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, China
> <https://maps.google.com/?q=No.+1068+Xueyuan+Avenue,+Nanshan,+Shenzhen,+China&entry=gmail&source=g>
>
>
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171226/5ca67df0/attachment.html>

From ry.meng at siat.ac.cn  Tue Dec 26 04:47:29 2017
From: ry.meng at siat.ac.cn (ry.meng)
Date: Tue, 26 Dec 2017 17:47:29 +0800
Subject: [Rtk-users] problem while determining the interpolation weights
 in 4D ROOSTER Reconstruction
In-Reply-To: <CAF0oig155HwxZHkOxEcm3ksFxV+cAQyZVrwbT3cJkQ7yZxOFAA@mail.gmail.com>
References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn>
 <CAF0oig155HwxZHkOxEcm3ksFxV+cAQyZVrwbT3cJkQ7yZxOFAA@mail.gmail.com>
Message-ID: <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171226/75556835/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Tue Dec 26 05:23:26 2017
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 26 Dec 2017 11:23:26 +0100
Subject: [Rtk-users] problem while determining the interpolation weights
 in 4D ROOSTER Reconstruction
In-Reply-To: <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn>
References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn>
 <CAF0oig155HwxZHkOxEcm3ksFxV+cAQyZVrwbT3cJkQ7yZxOFAA@mail.gmail.com>
 <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn>
Message-ID: <CAF0oig2dUX_Kq9uONUL3QkDXsu4X_J1p_LmJNLbuUPjoAVpECQ@mail.gmail.com>

Maybe you can share your sphase.txt file?

On Tue, Dec 26, 2017 at 10:47 AM, ry.meng <ry.meng at siat.ac.cn> wrote:

> Hi
>
> Thank you for your reply. I have checked the value in sphase.txt and don't
> have any value larger or equal to 5. Maybe the problem lies elsewhere?
> Thanks.
>
> Regards
>
> Ruoyan Meng
> On 12/26/2017 17:14?Simon Rit<simon.rit at creatis.insa-lyon.fr>
> <simon.rit at creatis.insa-lyon.fr> wrote?
>
> Hi,
> If you look at the code
> <https://github.com/SimonRit/RTK/blob/master/code/rtkPhasesToInterpolationWeights.hxx#L154>,
> you'll see that the error message corresponds to the case where you have a
> phase which equals the number of frames. This cannot be since it is
> 0-based. In other words, with the option "--frames 5", you cannot have a
> value larger or equal to 5 in your file sphase.txt.
> Simon
>
> On Mon, Dec 25, 2017 at 9:36 AM, ry.meng <ry.meng at siat.ac.cn> wrote:
>
>>
>> Hi:
>>
>> When I tried  the application of 4D ROOSTER Reconstruction with my own
>> data, it will stop for the following reason: problem while determining
>> the interpolation weights. Maybe you guys have met this problem before
>> and have a solution for it. Thank you very much and I hope to receive your
>> reply soon.
>>
>>
>> Happy Holidays!
>>
>>
>> Regards
>>
>> Ruoyan Meng
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------------------
>>
>> Research Center for Medical Robotics and Minimally Invasive Surgical
>> Devices,
>> Institute of Biomedical and Health Engineering,
>> Shenzhen Institutes of Advanced Technology, Chinese Academy of Sciences
>> Tel:       +86-18576617767 <+86%20185%207661%207767>
>> Email:   ry.meng at siat.ac.cn <qs.zhu at siat.ac.cn>
>> Zip:       518055
>> Add:      No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, China
>> <https://maps.google.com/?q=No.+1068+Xueyuan+Avenue,+Nanshan,+Shenzhen,+China&entry=gmail&source=g>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20171226/f0c56e48/attachment-0001.html>