Hey Maik, here is some example code for a forwardprojection on GPU from a numpy array volume.
https://gist.github.com/clemisch/9ec752430b2eb65d9840d69fc8c058bb You may write a projector class around that to save the proj_spacing, img_spacing, ... parameters and projector objects. Maybe even re-use the GPU images. I constructed this snipped from my framework but did not test it by itself; there might be bugs. Let me know if that helps you. Best Clemens Am Di., 16. Juli 2019 um 08:18 Uhr schrieb imt <[email protected]>: > Hej Clemens, > > I was following your conversation with Simon. I am quite interested in the > problem. Do you have some simple example source code of your solution? That > would be really helpful. > > Thank you in advance > Maik > On 9 Jul 2019, 18:24 +0200, C S <[email protected]>, wrote: > > Hi Simon, > > I think I understood the issue. > > *Problem:* The CPUBufferPointer of the CudaImage gets altered after > calling .Update() on the backprojection/forwardprojection filter. Because > of that, the existing numpy array (I created the CPU and GPU images from) > does not get changed from the filter. > *Solution:* Obtain the CudaDataManager of the CudaImage *before* applying > the back-/forwardprojection filter, apply the filter and .Update(), set cpu > pointer and update buffer via > > manager.SetCPUBufferPointer(cpu_img.GetBufferPointer()) > manager.UpdateCPUBuffer() > > The data from the cuda_img is correctly written in-place into the numpy > array I constructed the cpu_img from. > > I don't know the underlying problem and cause why the CPUBuffer gets > mangled, but this method achieves what I need. Thank you very much for your > advice! > > > Best > Clemens > > Am Mo., 8. Juli 2019 um 18:07 Uhr schrieb C S <[email protected]>: > > Hi Simon, > > I'm not sure I understand but have you tried grafting the Image or > CudaImage to an existing itk::Image (the Graft function)? > > I tried that but when I call itk.GetArrayFromImage(cuda_img) on the > grafted image (cpu_img.Graft(cuda_img)) I get the error ```ValueError: > PyMemoryView_FromBuffer(): info->buf must not be NULL``` from within ITK > (or its Python bindings). > > > Again, I'm not sure I understand but you should be able to graft a > CudaImage to another CudaImage. > > If anything I'd like to graft an Image into a CudaImage. When I try > something like `cuda_img.Graft(cpu_img)` I get a TypeError. If this and > the Graft'ing above would work (including the array view), that would be > exactly my initial wish. > > > You can always ask explicit transfers by calling the functions of the data > manager (accessible via CudaImage::GetCudaDataManager()) > > I assume you mean manager.UpdateCPUBuffer()? When I run that, the CPU > image I used to create the GPU image (by this > <https://github.com/SimonRit/RTK/blob/master/examples/FirstReconstruction/FirstCudaReconstruction.py#L64-L70>) > is not updated. > > My scenario is this: I give a numpy array as a volume to be forward > projected. I get a ImageView from that array, set origin and spacing of > that image and transfer to GPU via your method > <https://github.com/SimonRit/RTK/blob/master/examples/FirstReconstruction/FirstCudaReconstruction.py#L64-L70>. > For the output projections, I use an ImageView from a numpy.zeros array > with according shape, spacing and origin and transfer that to GPU the same > way. I then use the CudaForwardProjection filter. Now I'd like to have the > projection data on CPU. Unfortunately, none of the suggested methods worked > for me other than using an itk.ImageDuplicator on the CudaImage :( > > Sorry for the lenghty mail. > > Best > Clemens > > > > > > Best > Clemens > > Am Mo., 8. Juli 2019 um 16:20 Uhr schrieb Simon Rit < > [email protected]>: > > Hi, > Conversion from Image to CudaImage is not optimal. The way I'm doing it > now is shown in an example in these few lines > <https://github.com/SimonRit/RTK/blob/master/examples/FirstReconstruction/FirstCudaReconstruction.py#L64-L70>. > I am aware of the problem and discussed it on the ITK forum > <https://discourse.itk.org/t/shadowed-functions-in-gpuimage-or-cudaimage/1614> > but I don't have a better solution yet. > I'm not sure what you mean by explicitely transferring data from/to GPU > but I guess you can always work with itk::Image and do your own CUDA > computations in the GenerateData of the ImageFilter if you don't like the > CudaImage mechanism. > I hope this helps, > Simon > > On Mon, Jul 8, 2019 at 10:06 PM C S <[email protected]> wrote: > > Dear RTK users, > > I'm looking for a way to use exisiting ITK Images (either on GPU or in > RAM) when transfering data from/to GPU. That is, not only re-using the > Image object, but writing into the memory where its buffer is. > > Why: As I'm using the Python bindings, I guess this ties in with ITK > wrapping the CudaImage type. In > https://github.com/SimonRit/RTK/blob/master/utilities/ITKCudaCommon/include/itkCudaImage.h#L32 > I > read that the memory management is done implicitly and the CudaImage can be > used with CPU filters. However when using the bindings, > only rtk.BackProjectionImageFilter can be used with CudaImages. The other > filters complain about not being wrapped for that type. > > That is why I want to explicitely transfer the data from/to GPU, but > preferably using the exisiting Images and buffers. I can't rely on RTK > managing GPU memory implicitly. > > > Thank you very much for your help! > Clemens > > > _______________________________________________ > Rtk-users mailing list > [email protected] > https://public.kitware.com/mailman/listinfo/rtk-users > > _______________________________________________ > Rtk-users mailing list > [email protected] > https://public.kitware.com/mailman/listinfo/rtk-users > >
_______________________________________________ Rtk-users mailing list [email protected] https://public.kitware.com/mailman/listinfo/rtk-users
