Re: [Rtk-users] Errors occurred during configuring RTK examples: RTKTargets.cmake is missing
Hi again, First: "CUDA_SDK_ROOT_DIR-NOTFOUND" "CUDA_nvcuvenc_LIBRARY-NOTFOUND" Doesn't matter, i.e. these are not necessary for cmake to find the necessary files. Second: If rtkcuda.lib is not in [your biuld directory]/bin/[Debug or Release]/ it would mean something went wrong - probably in your configuration. Make sure to enable CUDA in the RTK CMake config, i.e. tick "RTK_USE_CUDA". Also, build RTK in the same configuration (release, debug or whatever) as the project that depends on it (otherwise visual studio might complain) If this does not solve your problem try to build the rtkcuda project (when the entire solution is open in Visual studio) by itself and watch the output for anything suspicious. Beset regards Andreas __________ Andreas Gravgaard Andersen Department of Oncology, Aarhus University Hospital Nørrebrogade 44, 8000, Aarhus C Mail: andre...@phys.au.dk Cell: +45 3165 8140 On 24 February 2018 at 00:26, Daniel lee <lkylove2...@gmail.com> wrote: > Dear Andersen > > There is no rtkcuda.lib in my RTK directory. > > Could you give me some tips to solve it? > > I will reinstall CUDA and build ITK, RTK again though. > > Thank you for your kind attention. > > Sincerely, > > K. Y. Daniel > > 2018-02-24 8:01 GMT+09:00 Daniel lee <lkylove2...@gmail.com>: > >> Thanks for your reply >> >> I have already configured, generated and built ITK and RTK. (without any >> error) >> >> and I tried to do cmake inside of RTK directory that I made. >> >> Now I doubt that RTK is built properly or even CUDA 8.0. >> >> I tried to do all things again composedly, I get some option is not found >> >> CUDA_SDK_ROOT_DIR-NOTFOUND >> CUDA_nvcuvenc_LIBRARY-NOTFOUND >> >> If it is possible, It will be very helpful for me to get screen shot of >> proper cmake options from others >> >> >> -Configuration >> RTK-1.4.0 >> ITK4.13.0 >> MSVS2015 64bit >> >> My basic question is still open to help. >> >> Best regards, >> >> K.Y.Daniel Lee >> >> >> 2018-02-24 5:48 GMT+09:00 Andreas Gravgaard Andersen <andre...@phys.au.dk >> >: >> >>> Hi Daniel >>> >>> I'm not exactly sure what you attempted, but it could look like you were >>> trying to make CMake configure the path >>> "E:/Source/RTK-1.4.0(ITK4.13.0)/examples" >>> *alone*. >>> In which case: You will need to configure, generate and build ITK and >>> RTK first. >>> Follow the instructions on http://wiki.openrtk.org/ind >>> ex.php/RTK_wiki_help >>> Start at "Step 0" and see if you have missed anything on the way. >>> >>> Best regards >>> Andreas >>> >>> >>> __ >>> >>> Andreas Gravgaard Andersen >>> >>> Department of Oncology, >>> >>> Aarhus University Hospital >>> >>> Nørrebrogade 44, >>> <https://maps.google.com/?q=N%C3%B8rrebrogade+44,+8000,+Aarhus+C=gmail=g> >>> >>> 8000, Aarhus C >>> <https://maps.google.com/?q=N%C3%B8rrebrogade+44,+8000,+Aarhus+C=gmail=g> >>> >>> Mail: andre...@phys.au.dk >>> >>> Cell: +45 3165 8140 >>> >>> >>> >>> On 23 February 2018 at 16:08, Daniel lee <lkylove2...@gmail.com> wrote: >>> >>>> Hi, I`m almost newbie for RTK. >>>> >>>> >>>> When I try to configure example (e.g. HelloWorld or >>>> FirstReconstruction), there is an error message like following. >>>> >>>> [image: 본문 이미지 1] >>>> >>>> I don`t have the file, RTKTargets.cmake. >>>> >>>> >>>> I tried with RTK 1.4.0, ITK 4.13.0, VS2015 >>>> >>>> >>>> I`m just looking for someone who will help me to make it. >>>> >>>> >>>> Sincerely >>>> >>>> >>>> K.Y. Daniel Lee >>>> >>>> >>>> ___ >>>> Rtk-users mailing list >>>> Rtk-users@public.kitware.com >>>> https://public.kitware.com/mailman/listinfo/rtk-users >>>> >>>> >>> >> > ___ Rtk-users mailing list Rtk-users@public.kitware.com https://public.kitware.com/mailman/listinfo/rtk-users
Re: [Rtk-users] Varian’s *.seq filetype
Dear Sam, There are a tiff reader in ITK. You can use that to convert your projections to a format RTK can read (i.e. mha). However, you'll still have to figure out how to get the geometry if you do not have a compatible xml file? I have worked with other Varian image formats (cps, hnd, hnc and xim), but I have not seen a seq file yet. Best regards Andreas __ Andreas Gravgaard Andersen Department of Oncology, Aarhus University Hospital Nørrebrogade 44, 8000, Aarhus C Mail: andre...@phys.au.dk Cell: +45 3165 8140 2017-04-17 22:39 GMT-04:00 商 宏杰 <shang...@hotmail.com>: > Hello RTK’s users, > > I was using Varian's FPD and it stored a serials of projections > as a single *.seq file. Is there anybody using Varian’s *.seq filetype to > finish reconstruction? Do you converting the *.seq file into a series > *.tiff or use the *.seq file directly? Do you have some descriptions of the > .seq filetype and how to convert it to .tiff filetype. Can anyone give me > some tips about this question? Thanks in advance. > > > > > > Sam > > > > ___ > Rtk-users mailing list > Rtk-users@public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > ___ Rtk-users mailing list Rtk-users@public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users
Re: [Rtk-users] Fwd: Have you encountered this artifact?
Dear Simon, I have created a pull-request with the XIM file reader. I'm sorry for being late with the promised pull-request (there were a lot of merge conflicts, so it got postponed). I have cleaned it up, but it is still not flawless as mentioned in the pull-request-message. I have tried to keep the RTK coding-style by creating it as a modified HND file reader, but I have only a year of experience with C++, so I apologize if I've left some ugly code in there.. Best regards Andreas __ Andreas Gravgaard Andersen Department of Oncology, Aarhus University Hospital Nørrebrogade 44, 8000, Aarhus C Mail: andre...@phys.au.dk Cell: +45 3165 8140 2016-11-23 18:44 GMT+01:00 Simon Rit <simon@creatis.insa-lyon.fr>: > Dear Andreas, > Today we had the RTK training and some users were looking for a XIM file > reader. I pointed to your contributions but any chance to have it put in > RTK soon? > Thanks in advance, > Simon > > On Mon, Sep 19, 2016 at 9:26 AM, Simon Rit <simon@creatis.insa-lyon.fr > > wrote: > >> Hi, >> Thanks for sharing. There still seems to be some streak artefacts, do you >> see the same in the Varian reconstruction? >> I'm looking forward to the pull-request, I think we should try to make >> the bzip2 optional. >> Simon >> >> On Fri, Sep 16, 2016 at 10:37 PM, Andreas Gravgaard Andersen < >> andre...@phys.au.dk> wrote: >> >>> Thanks for the fast response Simon! >>> >>> I flipped the angles (360 - angle[deg]) and it worked! Thanks, you were >>> right all along! >>> I just didn't get why it makes a difference. I think I do now, as the >>> resulting image was flipped upside down and not left/right as I expected. >>> [attached] >>> >>> The reconstruction is significantly better, I'll look into what should >>> be included in the reader and what I should keep in my program to keep >>> conformity with the other readers. Then I'll create a pull request. >>> >>> Just for the purpose of others hitting the same or a similar bug, I also >>> attempted: >>> I did the SART reconstruction with 10 iterations, lambda=0.3, and >>> Joseph back/forward projection, *but with no* significant improvement >>> [attached] >>> >>> And: >>> If you want you can download the data set from: [Dropbox link to 460MB >>> zip <https://www.dropbox.com/s/hg2k50vw3f7bt4b/CatPhan.zip?dl=0> (I'll >>> keep it up as long as Dropbox allows me)] Only the Acquisitions/subfolder >>> is used along with the Scan.xml (Calibrations folder may be used in the >>> future in my program, but I'm not sure if you can rely on the existence of >>> the content). >>> >>> A MatLab XimReader is available: link >>> <https://github.com/agravgaard/RTK/blob/master/code/ReadXim.m> (also >>> available from Varian bitbucket along a with a python version and a >>> C#->matlab plugin >>> <https://bitbucket.org/dmoderesearchtools/ximreader/downloads>). >>> Otherwise my fork with the RTK-style reader is available from the same >>> repository (I have also added Hnc support, thanks to the Geoff Hugo fork, >>> so bzip2 is a new dependancy). >>> >>> Best regards >>> Andreas >>> >>> >>> __ >>> >>> Andreas Gravgaard Andersen >>> >>> Department of Oncology, >>> >>> Aarhus University Hospital >>> >>> Nørrebrogade 44, >>> >>> 8000, Aarhus C >>> >>> Mail: andre...@phys.au.dk >>> >>> Cell: +45 3165 8140 >>> >>> >>> >>> 2016-09-16 16:13 GMT+02:00 Simon Rit <simon@creatis.insa-lyon.fr>: >>> >>>> Hi, >>>> You can try any iterative reconstruction, they can also handle short >>>> scans. Start with a few iterations of rtksart or rtkconjugategradient. >>>> However, the nature of the artifacts indicate more a problem in the >>>> geometry in my opinion. I have seen such errors when, for example, rotating >>>> in the wrong direction. I can have a look if you share the dataset. >>>> Cheers, >>>> Simon >>>> >>>> On Fri, Sep 16, 2016 at 2:56 PM, Andreas Gravgaard Andersen < >>>> andre...@phys.au.dk> wrote: >>>> >>>>> Thanks for the suggestions, Simon and Cyril! >>>>> >>>>> I have been carefully looking though the geometry and from what I >>&
Re: [Rtk-users] Fwd: Have you encountered this artifact?
Thanks for the suggestions, Simon and Cyril! I have been carefully looking though the geometry and from what I understand of the transformations matrices, the geometry looks correct/(as expected). HOWEVER: I found out that the reason for the Hnd to behave differently were because had used half-fan scans (full-arc). When I used a full-fan (half-arc) scan of Hnd projections the same artifacts occurs! Are there other (built-in) means of improving half-arc scans, than the parker short scan filter? Parker short scan does a decent job, but the result is still far from the quality of the Varian software reconstruction at least for the CatPhan. Best regards Andreas __ Andreas Gravgaard Andersen Department of Oncology, Aarhus University Hospital Nørrebrogade 44, 8000, Aarhus C Mail: andre...@phys.au.dk Cell: +45 3165 8140 2016-09-14 9:10 GMT+02:00 Cyril Mory <cyril.m...@creatis.insa-lyon.fr>: > One suggestion since it works with the Hnd projections: > You can run rtkprojections twice (with the Hnd projections, then with Xim > projections) and output two projection stack files and two geometry files, > then compare the projection stack files by subtracting one to the other > (with SimpleRTK or clitk) and the geometry files with diff. If they are > identical, then I do not see any reason why the reconstructions should be > different, so my guess is that you will find differences. > > > On 09/13/2016 10:18 PM, Simon Rit wrote: > >> Hi, >> I have almost never worked with Varian data but it looks like a >> geometry problem. Maybe the problem comes from a bad ordering of the >> projections which results in assigning a bad geometry to each >> projection. How did you name your projections? Maybe check that the >> order matches that of the RTK geometry file. Otherwise, there might be >> an issue in the creation of the geometry file itself. >> All this sounds good, happy bug hunt and don't hesitate to share your >> code when you feel it's ready. >> Simon >> >> On Tue, Sep 13, 2016 at 7:06 PM, Andreas Gravgaard Andersen >> <andre...@phys.au.dk> wrote: >> >>> Dear RTK experts, >>> >>> I am reconstructing Varian ProBeam projections of the Xim image format. I >>> have written the reader myself - very similar to the Hnd one already >>> available with RTK. >>> Links to my fork: [XimReader, XMLReader, GeometryReader] >>> >>> The reader apparently works (Images and angles displays as expected in >>> UI), >>> however when reconstructing with a regular FDK I get a reconstructed >>> image >>> that is smeared out around the high and low density areas [see attached >>> image] >>> >>> I'm using half arc, full fan images with no bow-tie filter from Scripps >>> (~520 projections). Fixed detector and source (offset=0) with SID=2m, >>> SDD=3m. >>> >>> For the Hnd projections the reconstruction works perfectly (Same >>> algorithm). >>> The reconstruction of the Xim projections performed on Varian software >>> works >>> perfectly. >>> >>> Without the Parker Short Scan Filter the first and last projections >>> creates >>> streaks across the reconstruction as if they were way too bright. >>> If the first few projections are excluded, the following projection will >>> act >>> the same way. >>> >>> The projections are corrected for beam hardening and all the projections >>> have the expected attenuation. >>> No "smearing" filters (like median) is used, and iterative reconstruction >>> makes the same artifacts. >>> >>> Setting the value of the first and last projection to zero has the same >>> effect as excluding. Changing the ramp filter only changes noise, not the >>> artifacts. >>> >>> Have any of you had a similar problem? Am I missing something? >>> Any suggestions are welcome I'm running out of ideas. >>> >>> Best regards >>> Andreas >>> >>> __ >>> >>> Andreas Gravgaard Andersen >>> >>> Department of Oncology, >>> >>> Aarhus University Hospital >>> >>> Nørrebrogade 44, >>> >>> 8000, Aarhus C >>> >>> Mail: andre...@phys.au.dk >>> >>> Cell: +45 3165 8140 >>> >>> >>> ___ >>> Rtk-users mailing list >>> Rtk-users@public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> ___ >> Rtk-users mailing list >> Rtk-users@public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> > ___ Rtk-users mailing list Rtk-users@public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users
