From fredrik.hellman at gmail.com Thu May 9 12:08:32 2019 From: fredrik.hellman at gmail.com (Fredrik Hellman) Date: Thu, 9 May 2019 18:08:32 +0200 Subject: [Rtk-users] Cuda and RTK In-Reply-To: References: Message-ID: Hi, Thanks Simon! I see. I am writing a CUDA application of which where RTK and ITK will be parts, and I want to know how RTK CUDA cooperates with the CUDA functionality I already have in my application. I have found some behaviors that would be nice to be able to control/change or at least understand the design of: * Context handling. It appears the CUDA context manager keeps track of contexts and also can switch between them, I think I would like to be able to control this on a higher level. I can see situations where multple libraries compete with the control of contexts. * Streams. It would be nice to be able to perform data transfer between CPU/GPU in parallell with computations, but that requires that another stream than the default stream is used, since the default stream is always synchronous. * Memory allocations. When CUDA memory is allocated and deallocated, it implicitly synchronizes all operations on the GPU ( https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization). It would be good if one could either provide allocators/deallocates for a memory pool which doesn't need to issue the actual allocation calls, but get buffers from a pre allocated pool. Or find a a way to disable reallocations (which sometimes can be very frequent in ITK, especially if doing streaming). Are these areas that the community would be interested in too? Has there been any developments or discussions about this earlier? Best regards, Fredrik Hellman On Tue, 30 Apr 2019 at 15:02, Simon Rit wrote: > Hi, > Everything you're saying is correct. This development was co-funded by the > RTK consortium and Kitware and the goal was to transfer it to ITK. However, > this has never occurred and at this stage, it is only maintained in RTK. > Ideally, this could become an independent ITK module. > Is it something you'd like/need? > Cheers, > Simon > > On Tue, Apr 30, 2019 at 2:58 PM Fredrik Hellman > wrote: > >> Hi all, >> >> I have a question about the the code that deals with cuda within RTK. >> >> RTK uses itk cuda image, the itk data manager, and itk context manager >> (but not itk kernel manager so much?) to handle cuda data. Is this >> maintained as part of RTK or is it maintained somewhere else and only used >> in RTK? Now when RTK becomes closer to ITK, what will happen to that code? >> >> Best regards, >> Fredrik >> > _______________________________________________ >> 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: From simon.rit at creatis.insa-lyon.fr Thu May 9 15:46:38 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 May 2019 21:46:38 +0200 Subject: [Rtk-users] Cuda and RTK In-Reply-To: References: Message-ID: Hi, I would definitely be interested in improving RTK! We haven't discussed about this earlier and I don't see why the community would not be interested in improvements. If you start coding something, my preferences would be to have backward compatible code. Feel free to propose some PRs. I'm a bit surprised about your comment on streams, I was pretty sure that the computation and the data transfer were asynchronous as is. And about the memory pool, why not, that sounds interesting, as long as we can still allocate as much as before. About the streaming part, if does not reallocate if there is no change in memory size I believe. Are your developments related to tomographic reconstruction? If yes, is there some RTK algorithms for which you expect a significant improvement? Thanks for your suggestions, Simon On Thu, May 9, 2019 at 6:08 PM Fredrik Hellman wrote: > Hi, > > Thanks Simon! I see. > > I am writing a CUDA application of which where RTK and ITK will be parts, > and I want to know how RTK CUDA cooperates with the CUDA functionality I > already have in my application. I have found some behaviors that would be > nice to be able to control/change or at least understand the design of: > > * Context handling. It appears the CUDA context manager keeps track of > contexts and also can switch between them, I think I would like to be able > to control this on a higher level. I can see situations where multple > libraries compete with the control of contexts. > * Streams. It would be nice to be able to perform data transfer between > CPU/GPU in parallell with computations, but that requires that another > stream than the default stream is used, since the default stream is always > synchronous. > * Memory allocations. When CUDA memory is allocated and deallocated, it > implicitly synchronizes all operations on the GPU ( > https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization). > It would be good if one could either provide allocators/deallocates for a > memory pool which doesn't need to issue the actual allocation calls, but > get buffers from a pre allocated pool. Or find a a way to disable > reallocations (which sometimes can be very frequent in ITK, especially if > doing streaming). > > Are these areas that the community would be interested in too? Has there > been any developments or discussions about this earlier? > > Best regards, > Fredrik Hellman > > On Tue, 30 Apr 2019 at 15:02, Simon Rit > wrote: > >> Hi, >> Everything you're saying is correct. This development was co-funded by >> the RTK consortium and Kitware and the goal was to transfer it to ITK. >> However, this has never occurred and at this stage, it is only maintained >> in RTK. Ideally, this could become an independent ITK module. >> Is it something you'd like/need? >> Cheers, >> Simon >> >> On Tue, Apr 30, 2019 at 2:58 PM Fredrik Hellman < >> fredrik.hellman at gmail.com> wrote: >> >>> Hi all, >>> >>> I have a question about the the code that deals with cuda within RTK. >>> >>> RTK uses itk cuda image, the itk data manager, and itk context manager >>> (but not itk kernel manager so much?) to handle cuda data. Is this >>> maintained as part of RTK or is it maintained somewhere else and only used >>> in RTK? Now when RTK becomes closer to ITK, what will happen to that code? >>> >>> Best regards, >>> Fredrik >>> >> _______________________________________________ >>> 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: From simon.rit at creatis.insa-lyon.fr Fri May 10 08:29:19 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 May 2019 14:29:19 +0200 Subject: [Rtk-users] Release of RTK 2.0.0 In-Reply-To: References: Message-ID: Dear all, Please note that the recently released ITK package is not compatible with our previously released RTK package. I plan an RTK release before the next ITK5 release (see their milestones page ). Until then, force the use of ITK 5.0rc1, i.e., use the following commands: python -m pip install --upgrade pip pip install --upgrade --pre itk==5.0rc1 itk-core==5.0rc1 itk-filtering==5.0rc1 itk-io==5.0rc1 itk-numerics==5.0rc1 itk-registration==5.0rc1 itk-segmentation==5.0rc1 python -m pip install itk-rtk Thanks, Simon On Tue, Feb 12, 2019 at 10:53 AM Simon Rit wrote: > The remote module file for RTK v2 has been integrated in ITK's master > branch: > > https://github.com/InsightSoftwareConsortium/ITK/commit/aa9e2d1797a23ba46a78afa294f51d970e6f54c3 > You can now compile RTK when you compile ITK by turning on the advanced > cmake option "Module_RTK". This is a great step! > > Moreover, I have compiled the RTK python packages for all versions > available for ITK (includes several python versions on Linux, MacOS and > Windows). To install the RTK package, simply run > python -m pip install --upgrade pip > python -m pip install --upgrade --pre itk > python -m pip install itk-rtk > You can test the FirstReconstruction.py example (from master, I have just > fixed a small issue). > Let us know if something is not working as expected, this package probably > needs a more thorough testing. > Simon > > On Wed, Feb 6, 2019 at 11:21 AM Simon Rit > wrote: > >> Dear RTK users, >> >> RTK v2.0.0 has just >> been released, about one year after RTK v1.4.0. The change of major version >> indicates that there has been a major refactoring of the code to let RTK >> compile as an ITK external or remote module. >> >> Release notes: >> * Refactoring of the repository to follow the structure of ITK's modules. >> * Removal of SimpleRTK wrapping. >> * Development of ITK's python wrapping. >> * Spectral CT developments: implementation of Mechlem's one-step >> inversion, >> adaptation of the conjugate gradient algorithm to vector projections. >> * Implementation of (ordered subsets) expectation maximization. >> * Development of attenuated forward and backprojectors. >> >> Many thanks to all contributors, in alphabetical order for this release: >> Andreas Gravgaard Andersen, Antoine Robert, Chao Wu, Cyril Mory, D?enan >> Zuki?, >> Hans Johnson, Lucas Gandel, Matt McCormick, S?bastien Brousmiche, Simon >> Rit and >> Thomas Baudier. >> >> As usual, be aware that we don't focus on releases since we have a public >> github repository that we try to keep >> stable. I still recommend the use of the master HEAD over releases to >> enjoy >> the new RTK developments before their release. We still have a few >> on-going >> projects for which we will use and enhance RTK. >> >> Simon (for the RTK consortium) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.a.gh72 at gmail.com Sat May 11 00:04:28 2019 From: e.a.gh72 at gmail.com (Ali ghorbanian) Date: Sat, 11 May 2019 08:34:28 +0430 Subject: [Rtk-users] projectionsreader read pgm format Message-ID: Hi I want to read the PGM format image with projectionsreader function. Can I help me? thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasga22 at gmail.com Sat May 11 03:43:12 2019 From: andreasga22 at gmail.com (Andreas Andersen) Date: Sat, 11 May 2019 09:43:12 +0200 Subject: [Rtk-users] projectionsreader read pgm format In-Reply-To: References: Message-ID: Hi Ali, RTK uses the ITK image readers, and I don't think ITK has a reader for pgm. However, it seems to be a pretty simple format and may be easily converted into a readable format like tiff, or similar as done here: http://itk-users.7.n7.nabble.com/PGM-images-td1108.html Best regards Andreas Gravgaard On Sat, 11 May 2019, 06:04 Ali ghorbanian, wrote: > Hi > I want to read the PGM format image with projectionsreader function. > Can I help me? > thank you. > _______________________________________________ > 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: From e.a.gh72 at gmail.com Sat May 11 03:59:10 2019 From: e.a.gh72 at gmail.com (Ali ghorbanian) Date: Sat, 11 May 2019 12:29:10 +0430 Subject: [Rtk-users] series reader Message-ID: I have a collection file with bmp format. I need to read the series as a series and filter CudaFDKConeBeamReconstructionFilter. I need the command to read these images. Can you help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.a.gh72 at gmail.com Sun May 12 05:53:25 2019 From: e.a.gh72 at gmail.com (Ali ghorbanian) Date: Sun, 12 May 2019 14:23:25 +0430 Subject: [Rtk-users] create series dcm image Message-ID: Hi, How to create a series of jpg collections in dicom? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreasga22 at gmail.com Mon May 13 09:02:02 2019 From: andreasga22 at gmail.com (Andreas Andersen) Date: Mon, 13 May 2019 15:02:02 +0200 Subject: [Rtk-users] create series dcm image In-Reply-To: References: Message-ID: RTK does not provide this functionality, but DCMTK does: https://support.dcmtk.org/docs/img2dcm.html Best regards Andreas __________________________________ Andreas Gravgaard Andersen Danish Center for Particle Therapy, Aarhus University Hospital Palle Juul-Jensens Blvd. 99, 8200, Aarhus Mail: agravgaard at protonmail.com Cell: +45 3165 8140 On Sun, 12 May 2019 at 11:53, Ali ghorbanian wrote: > Hi, > How to create a series of jpg collections in dicom? > _______________________________________________ > 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: From andreasga22 at gmail.com Mon May 13 09:13:20 2019 From: andreasga22 at gmail.com (Andreas Andersen) Date: Mon, 13 May 2019 15:13:20 +0200 Subject: [Rtk-users] series reader In-Reply-To: References: Message-ID: You'll want the ITK ImageSeriesReader: https://itk.org/Doxygen/html/classitk_1_1ImageSeriesReader.html Checkout the example: https://itk.org/Doxygen/html/Examples_2IO_2ImageSeriesReadWrite_8cxx-example.html#_a2 Replace PNG with BMP and let the "writer" would correspond to your CudaFDKConeBeamReconstructionFilter object. Best regards Andreas __________________________________ Andreas Gravgaard Andersen Danish Center for Particle Therapy, Aarhus University Hospital Palle Juul-Jensens Blvd. 99, 8200, Aarhus Mail: agravgaard at protonmail.com Cell: +45 3165 8140 On Sat, 11 May 2019 at 09:59, Ali ghorbanian wrote: > I have a collection file with bmp format. I need to read the series as a > series and filter CudaFDKConeBeamReconstructionFilter. I need the command > to read these images. > > Can you help me? > _______________________________________________ > 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: From fredrik.hellman at gmail.com Tue May 14 09:38:09 2019 From: fredrik.hellman at gmail.com (Fredrik Hellman) Date: Tue, 14 May 2019 15:38:09 +0200 Subject: [Rtk-users] Cuda and RTK In-Reply-To: References: Message-ID: Hi, Ok, thank you! Although I have no concrete changes in mind already now, I at least know that the itk cuda common code is maintained via RTK and open for contributions. As far as I understand from https://devblogs.nvidia.com/gpu-pro-tip-cuda-7-streams-simplify-concurrency, the default stream is always synchronous if the code is not compiled with the special thread-specific default stream flag. Yes, it is for tomographic reconstruction, so I use some RTK code, e.g. FDK reconstruction. But I am writing some of my own filters that should work together with it, using the itk Cuda Image as image type. So no, I don't have any special algorithm from RTK in mind.. / Fredrik Den tors 9 maj 2019 kl 21:46 skrev Simon Rit : > Hi, > I would definitely be interested in improving RTK! We haven't discussed > about this earlier and I don't see why the community would not be > interested in improvements. If you start coding something, my preferences > would be to have backward compatible code. Feel free to propose some PRs. > I'm a bit surprised about your comment on streams, I was pretty sure that > the computation and the data transfer were asynchronous as is. And about > the memory pool, why not, that sounds interesting, as long as we can still > allocate as much as before. About the streaming part, if does not > reallocate if there is no change in memory size I believe. > Are your developments related to tomographic reconstruction? If yes, is > there some RTK algorithms for which you expect a significant improvement? > Thanks for your suggestions, > Simon > > On Thu, May 9, 2019 at 6:08 PM Fredrik Hellman > wrote: > >> Hi, >> >> Thanks Simon! I see. >> >> I am writing a CUDA application of which where RTK and ITK will be parts, >> and I want to know how RTK CUDA cooperates with the CUDA functionality I >> already have in my application. I have found some behaviors that would be >> nice to be able to control/change or at least understand the design of: >> >> * Context handling. It appears the CUDA context manager keeps track of >> contexts and also can switch between them, I think I would like to be able >> to control this on a higher level. I can see situations where multple >> libraries compete with the control of contexts. >> * Streams. It would be nice to be able to perform data transfer between >> CPU/GPU in parallell with computations, but that requires that another >> stream than the default stream is used, since the default stream is always >> synchronous. >> * Memory allocations. When CUDA memory is allocated and deallocated, it >> implicitly synchronizes all operations on the GPU ( >> https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization). >> It would be good if one could either provide allocators/deallocates for a >> memory pool which doesn't need to issue the actual allocation calls, but >> get buffers from a pre allocated pool. Or find a a way to disable >> reallocations (which sometimes can be very frequent in ITK, especially if >> doing streaming). >> >> Are these areas that the community would be interested in too? Has there >> been any developments or discussions about this earlier? >> >> Best regards, >> Fredrik Hellman >> >> On Tue, 30 Apr 2019 at 15:02, Simon Rit >> wrote: >> >>> Hi, >>> Everything you're saying is correct. This development was co-funded by >>> the RTK consortium and Kitware and the goal was to transfer it to ITK. >>> However, this has never occurred and at this stage, it is only maintained >>> in RTK. Ideally, this could become an independent ITK module. >>> Is it something you'd like/need? >>> Cheers, >>> Simon >>> >>> On Tue, Apr 30, 2019 at 2:58 PM Fredrik Hellman < >>> fredrik.hellman at gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> I have a question about the the code that deals with cuda within RTK. >>>> >>>> RTK uses itk cuda image, the itk data manager, and itk context manager >>>> (but not itk kernel manager so much?) to handle cuda data. Is this >>>> maintained as part of RTK or is it maintained somewhere else and only used >>>> in RTK? Now when RTK becomes closer to ITK, what will happen to that code? >>>> >>>> Best regards, >>>> Fredrik >>>> >>> _______________________________________________ >>>> 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: From simon.rit at creatis.insa-lyon.fr Tue May 14 10:42:50 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 May 2019 16:42:50 +0200 Subject: [Rtk-users] Cuda and RTK In-Reply-To: References: Message-ID: Hi, Ok, I think the concept of streams is something different from what I had in mind. We don't use them (i.e., we use the default). What I meant is that I believe that memory transfers (cumemcpy) are asynchronous and overlap with the computation in the current implementation. I'm not sure this is optimally implemented but I believe there is some. Looking forward to your contributions! Simon On Tue, May 14, 2019 at 3:38 PM Fredrik Hellman wrote: > Hi, > > Ok, thank you! Although I have no concrete changes in mind already now, I > at least know that the itk cuda common code is maintained via RTK and open > for contributions. > > As far as I understand from > https://devblogs.nvidia.com/gpu-pro-tip-cuda-7-streams-simplify-concurrency, > the default stream is always synchronous if the code is not compiled with > the special thread-specific default stream flag. > > Yes, it is for tomographic reconstruction, so I use some RTK code, e.g. > FDK reconstruction. But I am writing some of my own filters that should > work together with it, using the itk Cuda Image as image type. So no, I > don't have any special algorithm from RTK in mind.. > > / Fredrik > > Den tors 9 maj 2019 kl 21:46 skrev Simon Rit < > simon.rit at creatis.insa-lyon.fr>: > >> Hi, >> I would definitely be interested in improving RTK! We haven't discussed >> about this earlier and I don't see why the community would not be >> interested in improvements. If you start coding something, my preferences >> would be to have backward compatible code. Feel free to propose some PRs. >> I'm a bit surprised about your comment on streams, I was pretty sure that >> the computation and the data transfer were asynchronous as is. And about >> the memory pool, why not, that sounds interesting, as long as we can still >> allocate as much as before. About the streaming part, if does not >> reallocate if there is no change in memory size I believe. >> Are your developments related to tomographic reconstruction? If yes, is >> there some RTK algorithms for which you expect a significant improvement? >> Thanks for your suggestions, >> Simon >> >> On Thu, May 9, 2019 at 6:08 PM Fredrik Hellman >> wrote: >> >>> Hi, >>> >>> Thanks Simon! I see. >>> >>> I am writing a CUDA application of which where RTK and ITK will be >>> parts, and I want to know how RTK CUDA cooperates with the CUDA >>> functionality I already have in my application. I have found some behaviors >>> that would be nice to be able to control/change or at least understand the >>> design of: >>> >>> * Context handling. It appears the CUDA context manager keeps track of >>> contexts and also can switch between them, I think I would like to be able >>> to control this on a higher level. I can see situations where multple >>> libraries compete with the control of contexts. >>> * Streams. It would be nice to be able to perform data transfer between >>> CPU/GPU in parallell with computations, but that requires that another >>> stream than the default stream is used, since the default stream is always >>> synchronous. >>> * Memory allocations. When CUDA memory is allocated and deallocated, it >>> implicitly synchronizes all operations on the GPU ( >>> https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization). >>> It would be good if one could either provide allocators/deallocates for a >>> memory pool which doesn't need to issue the actual allocation calls, but >>> get buffers from a pre allocated pool. Or find a a way to disable >>> reallocations (which sometimes can be very frequent in ITK, especially if >>> doing streaming). >>> >>> Are these areas that the community would be interested in too? Has there >>> been any developments or discussions about this earlier? >>> >>> Best regards, >>> Fredrik Hellman >>> >>> On Tue, 30 Apr 2019 at 15:02, Simon Rit >>> wrote: >>> >>>> Hi, >>>> Everything you're saying is correct. This development was co-funded by >>>> the RTK consortium and Kitware and the goal was to transfer it to ITK. >>>> However, this has never occurred and at this stage, it is only maintained >>>> in RTK. Ideally, this could become an independent ITK module. >>>> Is it something you'd like/need? >>>> Cheers, >>>> Simon >>>> >>>> On Tue, Apr 30, 2019 at 2:58 PM Fredrik Hellman < >>>> fredrik.hellman at gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I have a question about the the code that deals with cuda within RTK. >>>>> >>>>> RTK uses itk cuda image, the itk data manager, and itk context manager >>>>> (but not itk kernel manager so much?) to handle cuda data. Is this >>>>> maintained as part of RTK or is it maintained somewhere else and only used >>>>> in RTK? Now when RTK becomes closer to ITK, what will happen to that code? >>>>> >>>>> Best regards, >>>>> Fredrik >>>>> >>>> _______________________________________________ >>>>> 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: From simon.rit at creatis.insa-lyon.fr Mon May 20 18:37:30 2019 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 21 May 2019 00:37:30 +0200 Subject: [Rtk-users] Release of RTK v2.0.1 Message-ID: Dear RTK users, RTK v2.0.1 has just been released, about four months after RTK v2.0.0. This release is intended for inclusion in the ITK v5.0.0 release. Python packages will be prepared after the release of ITK v5.0.0. Release notes: * Optimization of the Xim and Hnd readers (Andreas Gravgaard Andersen). * Migration to ITK v5 code style (Lucas Gandel). * Floating point thresholds in spectral CT (Simon Rit). * Compatibility with module TBB (Simon Rit). * Several bug and warning fixes. Many thanks to all contributors, in alphabetical order for this release: Andreas Gravgaard Andersen, Lucas Gandel and Simon Rit. As usual, be aware that we don't focus on releases since we have a public github repository that we try to keep stable. I still recommend the use of the master HEAD over releases to enjoy the new RTK developments before their release. We still have a few on-going projects for which we will use and enhance RTK. Simon (for the RTK consortium)