I am going to implement a retrospective reconstruction on my gadget for cine imaging, in order to add on its flexibility. However, I was stranded with the idea to retrieving data block by block from an array for image processing, while preventing due to the pipeline being disturbed for memory storage.
My plan goes something like this:
First, I would like to store all incoming data in one single buffer array, arranged by the order as same as the regular accumulator had specified, from lines, partitions, coils, slices, to repetitions.
Then, I would calculate the kernel from the data after averaging them in another array, while the original array staying intact.
After that, I would extract the data from the array from block to block. If these procedures I have mentioned are to be done within one gadget, the image header, the image block and the kernel will be the things that leave the gadget, waiting for reconstruction.
I thought my plan could disrupt the pipeline of every image block, since it seems that the regular Accumulator Gadget also plays a role to distinguish one image block from another.
Is there any method to separate the procedures into several gadgets?
Would that be OK to wait for the scan to finish before starting reconstruction?
I have skimmed through a paper written by Mr. Xue et al. about retrospective reconstruction using Gadgetron, so I know there is a way to solve my problem, but I failed to figure it out by myself. I would like to know if my plan can go on smoothly.
(Xue et al.: High spatial and temporal resolution
retrospective cine cardiovascular magnetic resonance from shortened free
breathing real-time acquisitions. Journal of Cardiovascular Magnetic
Resonance 2013 15:102.)
Yours truly,
Edward Lau
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Retrospective cardiac gating is not implemented yet in the distributed code. The paper by Dr Xue does not use retrospective gating in the same way as it is traditionally done, it actually reconstructs real-time frames and these real-time frames are then subsequently processed using a different scheme.
Either way, the steps you describe can easily be done. It is all C++, so you can decide on any buffering structure that you would like to use in order to capture the data and then do the interpolation over time once all the data has been acquired. I would start buffering the data as soon as it comes in, you could do that very simply by creating a multi dimensional array of std::vector or some other flexible structure that you could use to append the data when it comes it. You could then start interpolation for each k-space location when the scan is done or when each slice is done. Up to you.
You should NOT use the AccumulatorGadget, since this assumes that you are not doing anything like retrogating. You essentially have to implement the retrogating equivalent of the accumulator.
I don't know if this helps, but your questions are pretty generic, so it is hard to be more specific with the answers. Let us know how you get on with it.
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everyone,
I am going to implement a retrospective reconstruction on my gadget for cine imaging, in order to add on its flexibility. However, I was stranded with the idea to retrieving data block by block from an array for image processing, while preventing due to the pipeline being disturbed for memory storage.
My plan goes something like this:
First, I would like to store all incoming data in one single buffer array, arranged by the order as same as the regular accumulator had specified, from lines, partitions, coils, slices, to repetitions.
Then, I would calculate the kernel from the data after averaging them in another array, while the original array staying intact.
After that, I would extract the data from the array from block to block. If these procedures I have mentioned are to be done within one gadget, the image header, the image block and the kernel will be the things that leave the gadget, waiting for reconstruction.
I thought my plan could disrupt the pipeline of every image block, since it seems that the regular Accumulator Gadget also plays a role to distinguish one image block from another.
Is there any method to separate the procedures into several gadgets?
Would that be OK to wait for the scan to finish before starting reconstruction?
I have skimmed through a paper written by Mr. Xue et al. about retrospective reconstruction using Gadgetron, so I know there is a way to solve my problem, but I failed to figure it out by myself. I would like to know if my plan can go on smoothly.
(Xue et al.: High spatial and temporal resolution
retrospective cine cardiovascular magnetic resonance from shortened free
breathing real-time acquisitions. Journal of Cardiovascular Magnetic
Resonance 2013 15:102.)
Yours truly,
Edward Lau
Hi Edward,
Some quick notes here...
Retrospective cardiac gating is not implemented yet in the distributed code. The paper by Dr Xue does not use retrospective gating in the same way as it is traditionally done, it actually reconstructs real-time frames and these real-time frames are then subsequently processed using a different scheme.
Either way, the steps you describe can easily be done. It is all C++, so you can decide on any buffering structure that you would like to use in order to capture the data and then do the interpolation over time once all the data has been acquired. I would start buffering the data as soon as it comes in, you could do that very simply by creating a multi dimensional array of std::vector or some other flexible structure that you could use to append the data when it comes it. You could then start interpolation for each k-space location when the scan is done or when each slice is done. Up to you.
You should NOT use the AccumulatorGadget, since this assumes that you are not doing anything like retrogating. You essentially have to implement the retrogating equivalent of the accumulator.
I don't know if this helps, but your questions are pretty generic, so it is hard to be more specific with the answers. Let us know how you get on with it.
Michael