From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> > From Cyril.Mory at philips.com Tue Sep 3 12:26:43 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Tue, 3 Sep 2013 16:26:43 +0000 Subject: [Rtk-users] Angular weighting in gated FDK Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi RTK users, I'm working on ECG-gated FDK reconstruction, and I'd like to obtain realistic absorption coefficients, because my gated FDK images have to compared to other reconstruction results which do have realistic values. In FDK, projections are weighted by their angular gaps. I have replaced that by a weighting by 1, because some angular gaps are huge in ECG-gated projection data, and there is no reason why a single projection should be weighed ten times as much as the others. But 1 obviously isn't the right value (with a 20%-wide gating window, I'm getting values about ten times too high). I'm experimenting with smarter choices, like the minimum of the angular gaps (this time it's 10 times too low), and I'll keep experimenting until I find something satisfying. Does anyone know if there is a standard way of weighting the projections in ECG-gated FDK ? I've made a quick search (maybe too quick), but couldn't find anything on this topic. Regards, ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Sep 3 12:38:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 3 Sep 2013 18:38:41 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I?m working on ECG-gated FDK reconstruction, and I?d like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic values. In > FDK, projections are weighted by their angular gaps. I have replaced that by > a weighting by 1, because some angular gaps are huge in ECG-gated projection > data, and there is no reason why a single projection should be weighed ten > times as much as the others. But 1 obviously isn?t the right value (with a > 20%-wide gating window, I?m getting values about ten times too high). I?m > experimenting with smarter choices, like the minimum of the angular gaps > (this time it?s 10 times too low), and I?ll keep experimenting until I find > something satisfying. > > > > Does anyone know if there is a standard way of weighting the projections in > ECG-gated FDK ? I?ve made a quick search (maybe too quick), but couldn?t > find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Wed Sep 4 05:14:26 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Wed, 4 Sep 2013 09:14:26 +0000 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Hi Simon, I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. It is also unclear to me whether I should perform Parker weighting or not (prior to gating). Thanks for your answers. I'll investigate this matter further when I have time. Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : mardi 3 septembre 2013 18:39 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Angular weighting in gated FDK Hi Cyril, I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. Simon On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: > Hi RTK users, > > > > I'm working on ECG-gated FDK reconstruction, and I'd like to obtain > realistic absorption coefficients, because my gated FDK images have to > compared to other reconstruction results which do have realistic > values. In FDK, projections are weighted by their angular gaps. I have > replaced that by a weighting by 1, because some angular gaps are huge > in ECG-gated projection data, and there is no reason why a single > projection should be weighed ten times as much as the others. But 1 > obviously isn't the right value (with a 20%-wide gating window, I'm > getting values about ten times too high). I'm experimenting with > smarter choices, like the minimum of the angular gaps (this time it's > 10 times too low), and I'll keep experimenting until I find something satisfying. > > > > Does anyone know if there is a standard way of weighting the > projections in ECG-gated FDK ? I've made a quick search (maybe too > quick), but couldn't find anything on this topic. > > > > Regards, > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simon.rit at creatis.insa-lyon.fr Wed Sep 4 05:47:53 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 4 Sep 2013 11:47:53 +0200 Subject: [Rtk-users] Angular weighting in gated FDK In-Reply-To: <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F180133501BD02@011-DB3MPN1-041.MGDPHG.emi.philips.com> <3B67D2F1029933428E0E93E2C2F180133501BD88@011-DB3MPN1-041.MGDPHG.emi.philips.com> Message-ID: Ok I get it. My conclusion on this exact same matter was that using one or two projections per cycle was probably the best option with FDK: http://www.creatis.insa-lyon.fr/site/en/publications/RIT-07c I know that others came up to the same conclusion. The idea is that what you lack is not projections in general but well sampled projections to fill this integral over the angle I was referring to. Simon On Wed, Sep 4, 2013 at 11:14 AM, MORY, CYRIL wrote: > Hi Simon, > > I have those gaps because ECG-gating on a single-sweep acquisition gives you clusters of consecutive projections separated by large gaps. > It is also unclear to me whether I should perform Parker weighting or not (prior to gating). > > Thanks for your answers. I'll investigate this matter further when I have time. > > Cyril > > -----Message d'origine----- > De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit > Envoy? : mardi 3 septembre 2013 18:39 > ? : MORY, CYRIL > Cc : rtk-users at openrtk.org > Objet : Re: [Rtk-users] Angular weighting in gated FDK > > Hi Cyril, > I am a bit lost by what you say. FDK comes from a continous formula and the angular weighting is the discretization of the integral on gantry angle. I don't see how it could be smarter than the gap with the neighbors and this is precisely why we obtain the attenuation. > How come you have a factor 10 between projections? Isn't it regular since heart beating is rather regular? > The only improvement I know off is to use a gating function which takes other values than 0 and 1 but I can't remember it is accounted for in the reconstruction. > Simon > > On Tue, Sep 3, 2013 at 6:26 PM, MORY, CYRIL wrote: >> Hi RTK users, >> >> >> >> I'm working on ECG-gated FDK reconstruction, and I'd like to obtain >> realistic absorption coefficients, because my gated FDK images have to >> compared to other reconstruction results which do have realistic >> values. In FDK, projections are weighted by their angular gaps. I have >> replaced that by a weighting by 1, because some angular gaps are huge >> in ECG-gated projection data, and there is no reason why a single >> projection should be weighed ten times as much as the others. But 1 >> obviously isn't the right value (with a 20%-wide gating window, I'm >> getting values about ten times too high). I'm experimenting with >> smarter choices, like the minimum of the angular gaps (this time it's >> 10 times too low), and I'll keep experimenting until I find something satisfying. >> >> >> >> Does anyone know if there is a standard way of weighting the >> projections in ECG-gated FDK ? I've made a quick search (maybe too >> quick), but couldn't find anything on this topic. >> >> >> >> Regards, >> >> ========================================== >> >> Cyril Mory >> >> PhD student at Philips Medisys and CREATIS >> >> >> >> Groupement Hospitalier Est >> >> H?pital Cardiologique Louis Pradel >> >> Laboratoire CREATIS - B?t. B13 >> >> CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 >> >> 28, Avenue du Doyen LEPINE >> >> 69677 Bron cedex FRANCE >> >> >> >> Office : +33 4 72 35 74 12 >> >> Cell : +33 6 69 46 73 79 >> >> >> >> >> ________________________________ >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended solely >> for the addressee(s). If you are not the intended recipient, you are >> hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> > > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From simon.rit at creatis.insa-lyon.fr Fri Sep 6 01:52:48 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 6 Sep 2013 07:52:48 +0200 Subject: [Rtk-users] New itk::CudaImage Message-ID: Dear users, Yesterday, I have merged the branch ITK-Cuda in the master branch. This development introduces a new image format, itk::CudaImage. This format has been developed by Kitware for us (and, eventually, ITK). It is based on itk::GPUImage which is for OpenCL. The goal of this class is to avoid unnecessary memory transfers between the CPU and the GPU memories. They have also developed a mechanism to generate kernels for any pixel type but this is not yet used in RTK. If you want to use it, you can look at this commitbut be aware that the mechanism requires the use of the same compiler for both the normal and the CUDA code. I am very pleased with the result and I'll let you discover the details of this mechanism in the code. The one and only drawback (to my knowledge) is that we lose the compability with CUDA 3.2 so you must upgrade to a newer CUDA version if you still use this one. For the rest, we have managed to preserve the ITK 3.20 compatibility. These observations are based on our regression testsand we are looking forward to your experience. Let us know via this mailing list if you encounter any other problem. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From emaddox at planet.nl Mon Sep 9 06:33:33 2013 From: emaddox at planet.nl (emaddox at planet.nl) Date: 9 Sep 2013 12:33:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans Message-ID: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Dear RTK users, Is it possible to do image reconstruction of spiral/helical scans with RTK? So while scanning the object, it moves along the rotation axis. Kind regards, Erik Maddox. From simon.rit at creatis.insa-lyon.fr Mon Sep 9 06:42:33 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 9 Sep 2013 12:42:33 +0200 Subject: [Rtk-users] reconstruction of helical/spiral scans In-Reply-To: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> References: <22520470.480971378722814164.JavaMail.defaultUser@defaultHost> Message-ID: No. You can simulate the data but we haven't developed any reconstruction algorithm so far. You are welcome to do it! Simon On Mon, Sep 9, 2013 at 12:33 PM, emaddox at planet.nl wrote: > Dear RTK users, > > Is it possible to do image reconstruction of spiral/helical scans with RTK? > > So while scanning the object, it moves along the rotation axis. > > Kind regards, > Erik Maddox. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spollmann at robarts.ca Mon Sep 9 12:03:55 2013 From: spollmann at robarts.ca (Steven Pollmann) Date: Mon, 9 Sep 2013 18:03:55 +0200 Subject: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. In-Reply-To: References: <51FACADE.10909@robarts.ca> <3B67D2F1029933428E0E93E2C2F18013350097B0@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <522DF16B.40102@robarts.ca> Thanks for looking into this. (And sorry I haven't responded earlier. I've been away in Germany/Poland for about a month, and this is my first day back). The 3D FFT explains why the result is a total catastrophe. I didn't have time to submit a bug report on this issue, as requested by Marc, before I left. I don't think the report is necessary any more. It is a case of garbage in, garbage out. I was just expecting garbage on the first few slices, but as I said, the 3D FFT explains the blank data set after the RAMP filter. If you still want a report submitted, however, I can still do that. I did come across another issue before I left (again, that I didn't have time to report). It is related to the CUDA Forward projection generating moire/aliasing artifacts that does not occur in the CPU implementation (which was a good enough workaround for the limited time I had :). I will dig up that data tomorrow, and report back to the mailing list. Anyhow, thanks again for looking into the Rubiks data. The 3D FFT makes perfect sense. Steve On 13-08-12 03:39 PM, Simon Rit wrote: > Hi Steven, > Thanks for sharing the dataset. I had a look and it seems that some of > your pixels contain nan values. In this case, one pixel can > contaminate all the others, especially since RTK uses a 3D FFT (for > speed). To illustrate this, I have enclosed a vv snapshot of the mhd > of projection 525. At location of the crosshair, i.e. pixel (924,679), > the value is nan. > Surprisingly, when I ran statistics on the file, I found like you that > nan values did not contaminate min/max but it did contaminate the sum. > Simon > > On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann wrote: >> Grrr.... >> e-mail program is auto-correcting! >> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd >> >> >> Steve >> >> ________________________________________ >> From: Steven Pollmann >> Sent: August 4, 2013 2:20 PM >> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org >> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just a quick correction... >> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd >> >> Steve >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca] >> Sent: August 4, 2013 2:19 PM >> To: MORY, CYRIL; rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hello, >> I have finally been able to upload the Rubiks projections to Box.com. It is about 2GB. This is the link: >> https://app.box.com/s/bgh5a2i3grxi6lkltrj2 >> >> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh). The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info. >> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections). If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok. It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero? >> >> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!) >> :) >> Anyhow, thanks for looking at this data. >> Steven >> >> ________________________________________ >> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com] >> Sent: August 2, 2013 3:09 AM >> To: rtk-users at openrtk.org >> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Hi Steve, >> >> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ? >> >> Cyril >> >> -----Message d'origine----- >> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann >> Envoy? : jeudi 1 ao?t 2013 22:54 >> ? : rtk-users at openrtk.org >> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images. >> >> Just an update on this issue I am having. >> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied). So I target my efforts to look into the Ramp Filter. It seems that this is where the issue stems from. I have included 2 image screenshots. The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp). The black lines contain "NaN" >> values, and for that particular projection image, the entire image is turned into NaN. So the backprojection obciously fails through those values. >> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values. >> >> Any suggestions from here? >> Thanks! >> Steve >> >> >> >> On 13-08-01 11:57 AM, Steven Pollmann wrote: >>> Hey RTK Users, >>> >>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them. Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation. The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing. Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me. If anyone has insight into what change in the projection data may cause this, that would be appreciated. The dataset isn't proprietary (it is a scan >>> of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...). >>> >>> Thanks again, >>> Steve >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at openrtk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> >> ________________________________ >> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at openrtk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Fri Sep 13 00:06:37 2013 From: croow at yahoo.com (M Miller) Date: Thu, 12 Sep 2013 21:06:37 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data Message-ID: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. It can be found at: https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. Thanks From simon.rit at creatis.insa-lyon.fr Fri Sep 13 03:31:58 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 13 Sep 2013 09:31:58 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, Thanks for your email. Please prefer the mailing list for questions of general interest, you might get quicker answer! It is correct that BoellaardScatterCorrectionImageFilter it not activated. But it is in place. So let me try to describe how that works: - many RTK programs use the filter rtkProjectionsReader.h to read raw data and convert them to attenuation. These two steps correspond to filters that are scanner dependent. The pointers to these filters are stored in m_RawDataReader and m_RawToProjectionsFilter. - the raw to attenuation conversion of Elekta Synergy is rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a so-called mini-pipeline filter, i.e., a pipeline of filters. One of them is the BoellaardScatterCorrection. - you should have a look at the implementation of this filter. You will notice that you have some parameters to set. One of them is the m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it is set to 0 so there is no scatter correction. But you can modify it to test the scatter correction. FYI, it was by default set to 0.33 in the first versions of XVI (it might have been lowered since because we had observed that it was not always ideal but I did not check). There is no mechanism to set it from the command line of rtkfdk yet but that could quite easily be done. Simon On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: > Dear Simon, > > > > I?m still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From Uffe.Bernchou at rsyd.dk Fri Sep 13 04:10:12 2013 From: Uffe.Bernchou at rsyd.dk (Uffe Bernchou) Date: Fri, 13 Sep 2013 08:10:12 +0000 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Dear Simon, Thank you very much for your reply. It will help me a lot. I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code *** for(unsigned int i=0; i=m_AirThreshold) { averageBehindPatient += itInSlice.Get(); } ++itInSlice; } averageBehindPatient /= npixelPerSlice; *** correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: *** // Compute constant correction double correction = averageBehindPatient * m_ScatterToPrimaryRatio; // Apply non-negativity constraint if(smallestValue-correction wrote: > Dear Simon, > > > > I'm still very curious as to whether a simple solution to correct for > scatter is attempted in rtkfdk. I can see that the procedure for scatter > correction used in XVI is implemented in > BoellaardScatterCorrectionImageFilter, but this code does not seem to be > used anywhere when running rtkfdk. However, it could just be me getting lost > in the code J > > > > It would help me a lot if you could inform me as to whether any solution > scatter subtraction is done when running rtkfdk. > > > > Best Regards > > Uffe > From simon.rit at creatis.insa-lyon.fr Sun Sep 15 16:40:35 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 15 Sep 2013 22:40:35 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I think you're right but I must take the time to look into it carefully. The algorithm is that of Boellaard, no doubt about it. But I think I should have split rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in betwee. I'll try to fix that asap but I have a very busy week. I'll keep you posted... Simon On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: > > Dear Simon, > > Thank you very much for your reply. It will help me a lot. > > I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. > > The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code > > *** > for(unsigned int i=0; i { > smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); > if(itInSlice.Get()>=m_AirThreshold) > { > averageBehindPatient += itInSlice.Get(); > } > ++itInSlice; > } > averageBehindPatient /= npixelPerSlice; > *** > > correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: > > *** > // Compute constant correction > double correction = averageBehindPatient * m_ScatterToPrimaryRatio; > > // Apply non-negativity constraint > if(smallestValue-correction correction = smallestValue - m_NonNegativityConstraintThreshold; > *** > > However, then the correction is subtracted: > > *** > // Remove constant factor > for(unsigned int i=0; i { > itOut.Set( itIn.Get() - correction ); > ++itIn; > ++itOut; > } > *** > > But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. > > Maybe I'm missing something and would be happy to be proven wrong :-) > > Best regards, > Uffe > > > > -----Oprindelig meddelelse----- > Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit > Sendt: 13. september 2013 09:32 > Til: Uffe Bernchou > Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org > Emne: Re: RTK code correction > > Hi Uffe, > Thanks for your email. Please prefer the mailing list for questions of > general interest, you might get quicker answer! > It is correct that BoellaardScatterCorrectionImageFilter it not > activated. But it is in place. So let me try to describe how that > works: > - many RTK programs use the filter rtkProjectionsReader.h to read raw > data and convert them to attenuation. These two steps correspond to > filters that are scanner dependent. The pointers to these filters are > stored in m_RawDataReader and m_RawToProjectionsFilter. > - the raw to attenuation conversion of Elekta Synergy is > rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a > so-called mini-pipeline filter, i.e., a pipeline of filters. One of > them is the BoellaardScatterCorrection. > - you should have a look at the implementation of this filter. You > will notice that you have some parameters to set. One of them is the > m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it > is set to 0 so there is no scatter correction. But you can modify it > to test the scatter correction. FYI, it was by default set to 0.33 in > the first versions of XVI (it might have been lowered since because we > had observed that it was not always ideal but I did not check). There > is no mechanism to set it from the command line of rtkfdk yet but that > could quite easily be done. > Simon > > On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >> Dear Simon, >> >> >> >> I'm still very curious as to whether a simple solution to correct for >> scatter is attempted in rtkfdk. I can see that the procedure for scatter >> correction used in XVI is implemented in >> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >> used anywhere when running rtkfdk. However, it could just be me getting lost >> in the code J >> >> >> >> It would help me a lot if you could inform me as to whether any solution >> scatter subtraction is done when running rtkfdk. >> >> >> >> Best Regards >> >> Uffe >> From marc.vila-oliva at creatis.insa-lyon.fr Thu Sep 19 07:29:20 2013 From: marc.vila-oliva at creatis.insa-lyon.fr (Marc Vila Oliva) Date: Thu, 19 Sep 2013 13:29:20 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> References: <1379045197.3625.YahooMailBasic@web163806.mail.gq1.yahoo.com> Message-ID: <1379590160.2165.14.camel@mvila-laptop> Hello Mr. Miller, I have tried to reconstruct your data-set but I ran into some problems regarding the data size. When I launch the FDK reconstruction I get the following information: rtkfdk --verbose -g geo500.xml -p . -r CT_121029a_quarter.mhd -o test.mhd --dimension 500 --spacing 0.08 Regular expression matches 1 file(s)... Reading... MetaImage: M_ReadElementsData: data not read completely ideal = 3142000000 : actual = 67698688 It took 0.818956 s Reading geometry information from geo500.xml... Reconstructing and writing... The reader is not able to read all the data. It reads 67698688 bytes out of 3142000000 bytes. Then I checked if the raw data had 3142000000 bytes, but it is not the case. The size of CT_121029a_quarter.raw is 67698688 bytes but if you check the header file CT_121029a_quarter.mhd, it says that the dimension of your projections is 500 x 500 x 3142 (in total 3142000000 bytes). The size information of the header file is inconsistent with the raw data. Do you really have 3142 projections? Have you cropped the raw data? Good luck, Marc On Thu, 2013-09-12 at 21:06 -0700, M Miller wrote: > I've been trying sporadically over the last year to reconstruct some CT data using RTK and have had only modest success. So, I'm making > available a small data set in the hopes that someone can point out what I'm doing wrong, or why RTK won't work for this problem. > It can be found at: > https://drive.google.com/folderview?id=0BwEyKtwqqtqhVDBqcncwQzVjRVk&usp=sharing > > The data was acquired on a Nikon XTH320 system and also reconstructed using the vendor's CT-Pro software. Each of the projections was initially a 16bit tif image sized 2000x2000 pixels. These have been converted to attenuations, resized to 500x500, and stacked in a metaIO container. Along with the image data (mhd/raw) there are two text files created by the acquisition system that describe all of the geometry and imaging conditions. I've posted small renderings of one z-slice reconstructed with the vendor software ("CT_121029a_250.tif") and the best I've been able to get using RTK ("rtk_500.jpg"). I also included a batch file listing the rtk command line options I've been using. > > I don't think there's anything else I could add that isn't in the posted configuration files, but I'd be happy to answer any questions that might help. > Thanks > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From croow at yahoo.com Thu Sep 19 15:06:58 2013 From: croow at yahoo.com (M Miller) Date: Thu, 19 Sep 2013 12:06:58 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379590160.2165.14.camel@mvila-laptop> Message-ID: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> > Do you really have 3142 projections? Have you cropped the raw data? The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. Thank you for your time. From simon.rit at creatis.insa-lyon.fr Fri Sep 20 06:07:56 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 12:07:56 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379590160.2165.14.camel@mvila-laptop> <1379617618.16512.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From Cyril.Mory at philips.com Fri Sep 20 07:37:32 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 11:37:32 +0000 Subject: [Rtk-users] Cura Error #216 Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Hi, I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, using the following command line calls : echo "Starting ungated SART with GPU forward projection and CPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd echo "Starting ungated SART with CPU forward projection and GPU back projection" rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd I know that the change is recent, so it might be normal. Cyril ========================================== Cyril Mory PhD student at Philips Medisys and CREATIS Groupement Hospitalier Est H?pital Cardiologique Louis Pradel Laboratoire CREATIS - B?t. B13 CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 28, Avenue du Doyen LEPINE 69677 Bron cedex FRANCE Office : +33 4 72 35 74 12 Cell : +33 6 69 46 73 79 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Sep 20 08:18:16 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 20 Sep 2013 14:18:16 +0200 Subject: [Rtk-users] Cura Error #216 In-Reply-To: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the pipeline, > using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp CudaVoxelBased > --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From Cyril.Mory at philips.com Fri Sep 20 08:50:07 2013 From: Cyril.Mory at philips.com (MORY, CYRIL) Date: Fri, 20 Sep 2013 12:50:07 +0000 Subject: [Rtk-users] Cura Error #216 In-Reply-To: References: <3B67D2F1029933428E0E93E2C2F18013359C6850@011-DB3MPN1-042.MGDPHG.emi.philips.com> Message-ID: <3B67D2F1029933428E0E93E2C2F18013359C68B8@011-DB3MPN1-042.MGDPHG.emi.philips.com> Interesting indeed. "nvcc --version" returns this : nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2012 NVIDIA Corporation Built on Fri_Sep_21_17:28:58_PDT_2012 Cuda compilation tools, release 5.0, V0.2.1221 Should I update to a newer version ? Cyril -----Message d'origine----- De : simon.rit at gmail.com [mailto:simon.rit at gmail.com] De la part de Simon Rit Envoy? : vendredi 20 septembre 2013 14:18 ? : MORY, CYRIL Cc : rtk-users at openrtk.org Objet : Re: [Rtk-users] Cura Error #216 Interesting, I cannot reproduce the bug. I have launched these commands without any problem (the phantom is here http://midas3.kitware.com/midas/download?items=27326): rtksimulatedgeometry -n 180 -o geometry.xml rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml --spacing 2 --dimension 256 rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp VoxelBasedBackProjection --sart CudaSart -n 1 -i fdk.mha rtksart -g geometry.xml -p. -r projections.mha -o sart.mha --bp CudaVoxelBased --sart Sart -n 1 -i fdk.mha It doesn't work for you? What version of Cuda do you use? On Fri, Sep 20, 2013 at 1:37 PM, MORY, CYRIL wrote: > Hi, > > > > I get a Cuda Error #216 when mixing CPU and GPU filters in the > pipeline, using the following command line calls : > > echo "Starting ungated SART with GPU forward projection and CPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.GPUForward_CPUBack.mhd --bp > VoxelBasedBackProjection --sart CudaSart -n 1 -i > _2_fbp/SheppLogan.fdk.mhd > > > > echo "Starting ungated SART with CPU forward projection and GPU back > projection" > > rtksart -g _1_pro/SheppLogan.geo -p _1_pro/ -r SheppLogan.mhd -o > _3_art/SheppLogan.ungatedSART.CPUForward_GPUBack.mhd --bp > CudaVoxelBased --sart Sart -n 1 -i _2_fbp/SheppLogan.fdk.mhd > > > > I know that the change is recent, so it might be normal. > > Cyril > > > > ========================================== > > Cyril Mory > > PhD student at Philips Medisys and CREATIS > > > > Groupement Hospitalier Est > > H?pital Cardiologique Louis Pradel > > Laboratoire CREATIS - B?t. B13 > > CNRS UMR5220, INSERM U1044, INSA-Lyon, Univ. Lyon 1 > > 28, Avenue du Doyen LEPINE > > 69677 Bron cedex FRANCE > > > > Office : +33 4 72 35 74 12 > > Cell : +33 6 69 46 73 79 > > > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From croow at yahoo.com Fri Sep 20 17:02:52 2013 From: croow at yahoo.com (M Miller) Date: Fri, 20 Sep 2013 14:02:52 -0700 (PDT) Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: Message-ID: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> The sid/sdd values can be seen in the *.xtekct file at line 17: SrcToObject=68.4973907470703 SrcToDetector=870.86 Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. Thanks -------------------------------------------- On Fri, 9/20/13, Simon Rit wrote: Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data To: "M Miller" Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" Date: Friday, September 20, 2013, 3:07 AM Hi, I have been looking at your data. You're right, it's complete, Marc's download probably stopped. Clearly you have a geometry problem and it's going to be hard for us to solve it for you. Where did you get your sid / sdd from ? I have also noticed something weird, you use positive offsets in your projection images that you compensate for with negative offsets in the geometry file. I would advise you to center your projection images with negative offset ("Offset = -250 -250 0" in the mhd file) and to remove your projection offsets if the detector is centered. Simon On Thu, Sep 19, 2013 at 9:06 PM, M Miller wrote: >> Do you really have 3142 projections? Have you cropped the raw data? > > The data does have 3142 projections. The CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. I downloaded it onto another computer and the size was also ~3GB. I also viewed the downloaded data with Avizo and it wasn't corrupted. Maybe your download was interrupted? > > I've uploaded another mhd/raw pair that is much smaller (500x500x 500 projections) and may be easier to handle. This projection set is equivalent to the 3GB set (*quarter.raw) with the number of projections resized to 500. > > Thank you for your time. > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at openrtk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users From simon.rit at creatis.insa-lyon.fr Sat Sep 21 11:14:04 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sat, 21 Sep 2013 17:14:04 +0200 Subject: [Rtk-users] Reconstruct Nikon XTH320 data In-Reply-To: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> References: <1379710972.85121.YahooMailBasic@web163802.mail.gq1.yahoo.com> Message-ID: I hadn't noticed the xtekct file but now that you mention it, your pixel spacing is also completely wrong in the projection image. With this header file ObjectType = Image NDims = 3 BinaryData = True BinaryDataByteOrderMSB = False CompressedData = False TransformMatrix = 1 0 0 0 1 0 0 0 1 Offset = -50 -50 0 CenterOfRotation = 0 0 0 AnatomicalOrientation = RAI ElementSpacing = 0.2 0.2 1 DimSize = 500 500 3142 ElementType = MET_FLOAT ElementDataFile = CT_121029a_quarter.raw I observe a large improvement. You just have to be sure that you understand well the rest of the geometry to obtain a good result I believe. Simon On Fri, Sep 20, 2013 at 11:02 PM, M Miller wrote: > > The sid/sdd values can be seen in the *.xtekct file at line 17: > SrcToObject=68.4973907470703 > SrcToDetector=870.86 > > Changing the .mhd file is a good suggestion. I didn't know the offset value was used by rtk. I had previously just guessed the proj_iso_* values until the output looked better. > I never use the metaIO format myself, but I thought it would be easier to interface it with rtk than the raw count tiff files. I have two additional CT systems that output similar tiff files and I was hoping that if I can get the Nikon data to reconstruct using metaIO I could later address using tiffs as the input without the mhd conversion. > > > Thanks > > -------------------------------------------- > On Fri, 9/20/13, Simon Rit wrote: > > Subject: Re: [Rtk-users] Reconstruct Nikon XTH320 data > To: "M Miller" > Cc: "Marc Vila Oliva" , "rtk-users at openrtk.org" > Date: Friday, September 20, 2013, 3:07 AM > > Hi, > I have been looking at your data. You're right, it's > complete, Marc's > download probably stopped. > Clearly you have a geometry problem and it's going to be > hard for us > to solve it for you. Where did you get your sid / sdd from ? > I have > also noticed something weird, you use positive offsets in > your > projection images that you compensate for with negative > offsets in the > geometry file. I would advise you to center your projection > images > with negative offset ("Offset = -250 -250 0" in the mhd > file) and to > remove your projection offsets if the detector is centered. > Simon > > On Thu, Sep 19, 2013 at 9:06 PM, M Miller > wrote: > >> Do you really have 3142 projections? Have you > cropped the raw data? > > > > The data does have 3142 projections. The > CT_121029a_quarter.raw that I uploaded is 3142000000 bytes. > I downloaded it onto another computer and the size was also > ~3GB. I also viewed the downloaded data with Avizo and it > wasn't corrupted. Maybe your download was interrupted? > > > > I've uploaded another mhd/raw pair that is much smaller > (500x500x 500 projections) and may be easier to handle. This > projection set is equivalent to the 3GB set (*quarter.raw) > with the number of projections resized to 500. > > > > Thank you for your time. > > > > > > > > _______________________________________________ > > Rtk-users mailing list > > Rtk-users at openrtk.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 08:05:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 14:05:44 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <2D0C637E6574499583973E974E87AD05@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> Message-ID: Hi, Please send your questions in English on the RTK mailing list. In general, we keep the OpenCL filters to not lose previous developments but the current version is extremely slow and the CPU version is probably better. Try to find a machine with a Cuda compatible graphics card (NVidia) if you want faster reconstruction... (you can use CREATIS cluster since you're a member). I have no idea what is the problem you are encountering with 64 bits but my guess is that your OpenCL drivers are 32 bits. For volumes that are too large, you can automatically have it divided in pieces by using the option --divisions. But 64 bits would indeed be preferable to be able to use more that 2 Go of RAM on Windows. Simon 2013/9/26 psperceval : > Bonjour, > > 1) Windows 7 x64, compile 64bit > J?ai compil? une version 64bit de ITK/RTK. > Pas de soucis sans OpenCL (CPU only). > Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de openCL) > la configuration semble ok: >>>>?Found OpenCL: ....? > > Mais pendant la configuration de CMake un programme ?TryCompil...? s?execute > et plante. > Malgr? ca, Cmake fini correctement la configuration ainsi que la generation. > Ensuite la commande make genere l?application RTK OK. > > Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. > mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait > ?rtkfdk.exe a cess? de fonctionner?. > > > Question: > > 2) Compile 32bits > Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en > 32bits. > Cette fois si toute la partie Cmake et make se fait sans problemes. > La commande ?rtkfdk --hardware cpu? passe sans soucis. > > > Par contre la commande ?rtkfdk--hardware opencl? coince avec des images > d?une taile >500x500x360 mais cette fois ci l?executable retourne l?erreur > suivante: > > ???? > rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 > --dimension=560,609,360 --hann 1.0 --hardware opencl > ExceptionObject caught with writer->Update() > > itk::ExceptionObject (0x353bbe8) > Location: "unknown" > File: > C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx > Line: 69 > Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): > Could not allocate OpenCL volume buffer, error code: -6 > ???? > > or > > ???? > ExceptionObject caught with writer->Update() > > itk::MemoryAllocationError (0x37d5910) > Location: "unknown" > File: > C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx > Line: 191 > Description: Failed to allocate memory for image. > ??? > > > Question: > > 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec ou > sans openCL) > 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + > OpenCL64) > > > Merci pour votre aide. > Cordialement, > Perceval > > From simon.rit at creatis.insa-lyon.fr Thu Sep 26 09:12:28 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 26 Sep 2013 15:12:28 +0200 Subject: [Rtk-users] RTK + OPEN CL 64bits In-Reply-To: <169970B079794F5DBF5DA93E308E8EF9@Neutrino> References: <2D0C637E6574499583973E974E87AD05@Neutrino> <169970B079794F5DBF5DA93E308E8EF9@Neutrino> Message-ID: Hi, I don't think it's related to the processor. Maybe you haven't installed the nvidia drivers for your graphic card? If yes, the best is probably to investigate this issue on the nvidia website / forums. Simon On Thu, Sep 26, 2013 at 3:05 PM, psperceval wrote: > Hi Simon, > > Thanks for your quick answer. > Ok I will forgot about openCL. > > I've just downloaded the CUDA installer > (cuda_5.5.20_winvista_win7_win8_general_64.exe) > My graphic card is a GeForce-GT-555M listed as GPU compatible on NVIDIA > website. > My computer is Win7-64, Intel-i5 proc. > > Unfortunatelly in the very first steps of the CUDA installation, the > installer says that it can't see a CUDA compatible graphic card. > > Any idea about that? > Do you know if intel i5 processor graphic capacities may prevent the NVIDIA > Card detection by CUDA installer? > > best regards, > Perceval > > > > > > > > > -----Message d'origine----- From: Simon Rit > Sent: Thursday, September 26, 2013 2:05 PM > To: psperceval > Cc: rtk-users at openrtk.org > Subject: Re: RTK + OPEN CL 64bits > > Hi, > Please send your questions in English on the RTK mailing list. > In general, we keep the OpenCL filters to not lose previous > developments but the current version is extremely slow and the CPU > version is probably better. Try to find a machine with a Cuda > compatible graphics card (NVidia) if you want faster reconstruction... > (you can use CREATIS cluster since you're a member). > I have no idea what is the problem you are encountering with 64 bits > but my guess is that your OpenCL drivers are 32 bits. > For volumes that are too large, you can automatically have it divided > in pieces by using the option --divisions. But 64 bits would indeed be > preferable to be able to use more that 2 Go of RAM on Windows. > Simon > > 2013/9/26 psperceval : >> >> Bonjour, >> >> 1) Windows 7 x64, compile 64bit >> J?ai compil? une version 64bit de ITK/RTK. >> Pas de soucis sans OpenCL (CPU only). >> Si dans le Cmake j?active l?openCL (pointant sur la version 64bit de >> openCL) >> la configuration semble ok: >>>>> >>>>> ?Found OpenCL: ....? >> >> >> Mais pendant la configuration de CMake un programme ?TryCompil...? >> s?execute >> et plante. >> Malgr? ca, Cmake fini correctement la configuration ainsi que la >> generation. >> Ensuite la commande make genere l?application RTK OK. >> >> Enfin si j?appelle ?rtkfdk --hardware cpu? pas de soucis. >> mais ?rtkfdk ?hardware opencl? plante et une fenetre popup apparait >> ?rtkfdk.exe a cess? de fonctionner?. >> >> >> Question: >> >> 2) Compile 32bits >> Dans un deuxieme temps j?ai essay? la meme chose mais avec ITK/RTK en >> 32bits. >> Cette fois si toute la partie Cmake et make se fait sans problemes. >> La commande ?rtkfdk --hardware cpu? passe sans soucis. >> >> >> Par contre la commande ?rtkfdk--hardware opencl? coince avec des images >> d?une taile >500x500x360 mais cette fois ci l?executable retourne >> l?erreur >> suivante: >> >> ???? >> rtkfdk -p . -r scan1.mha -o scan1_CT.tif -g geometry.xml --spacing 1 >> --dimension=560,609,360 --hann 1.0 --hardware opencl >> ExceptionObject caught with writer->Update() >> >> itk::ExceptionObject (0x353bbe8) >> Location: "unknown" >> File: >> C:\PSLwork\Tomography\RTK\code\rtkOpenCLFDKBackProjectionImageFilter.cxx >> Line: 69 >> Description: itk::ERROR: OpenCLFDKBackProjectionImageFilter(0x3537e90): >> Could not allocate OpenCL volume buffer, error code: -6 >> ???? >> >> or >> >> ???? >> ExceptionObject caught with writer->Update() >> >> itk::MemoryAllocationError (0x37d5910) >> Location: "unknown" >> File: >> >> C:/PSLwork/Tomography/ITK/Modules/Core/Common/include/itkImportImageContainer.hxx >> Line: 191 >> Description: Failed to allocate memory for image. >> ??? >> >> >> Question: >> >> 1) Comment traiter des stacks d?images de taille >600x600 (x360)? (avec >> ou >> sans openCL) >> 2) ?RTKFDK ? opencl? est-il compatible avec une compilation 64bit (RTK64 + >> OpenCL64) >> >> >> Merci pour votre aide. >> Cordialement, >> Perceval >> >> >