[Insight-users] ITK Dicom Pixeldata
Luis Ibanez
luis.ibanez at kitware.com
Sun Jun 12 14:23:25 EDT 2011
Hi Andy,
On Sun, May 29, 2011 at 2:11 PM, Andy Ettisberger <ettisberger at gmail.com> wrote:
> Hi Luis,
> Thanks a lot for your fast answers on my many questions.
> It works now and I can load dicoms on the ipad and display them - no jpegs
> anymore :)
Excellent !
Thanks for sharing your progress with us.
> The problem is, that its a little bit slow, because with a dicom
> with 400 slices on the ipad, it costs me 50-52seconds to create
> UIImages(ipad image format) out of the dicom slice pixeldata. But I think
> the ipad is probably to slow for that.
Are you compiling for "Release" ?
> In my method I load only one slice, get out the pixel data and create the
> uiimage. The whole process of looping the pixeldata with pointer arhitmetic
> is very fast - I lose the most time in this lines:
>
> reader = ReaderType::New();
>
> reader->SetFileName(path);
>
>
>
> reader->Update();
Well, here is where real processing happens.
When you call Update() is that the pipeline really
goes and loads data from the disk.
What version of ITK are you using ?
There were some recent improvements in ITKv4
to avoid duplicate copies of the data during the
ImageSeriesRead process...
>
> ImageType * tmpImage = reader->GetOutput();
>
> PixelType * pixelData = tmpImage->GetBufferPointer();
>
This part should take no time...
> Is that the fastest way to get out 2d pixel data of one slice? If yes - the
> ipad is probably too slow :o
>
Before you dismiss it...
Let's make sure that the profiling has been done properly.
Why don't you run a baseline tests ?
Just use plain C or C++ to write a file with the equivalent
amount of data to disk. In your case, 400slices (maybe of
512x512, and 2bytes /pixel) = 200Mb.
Do this compiling with -O3 and let us know how long
that takes to run in the iPad.
That will be your baseline measure. ITK won't be able
to do anything faster than that test, since that is the
baseline of IO data transfer in your iPad.
Thanks
Luis
----------------------------
> Cheers,
>
> Andy
>
> On Thu, May 19, 2011 at 6:25 PM, Luis Ibanez <luis.ibanez at kitware.com>
> wrote:
>>
>> On Thu, May 19, 2011 at 10:48 AM, Andy Ettisberger
>> <ettisberger at gmail.com> wrote:
>> > Hi Luis,
>> > I read the chapters :) A lot of open questions are now closed. But I
>> > have
>> > something, which I didn't really found in the documentation or did not
>> > understand. However, I try to explain it :)
>> > In the PDF from Robert and the other students, there was a written
>> > method in
>> > the class itkiOSImageIO.mm called Write(), which has a buffer pointer as
>> > a
>> > parameter. I know, you have not a lot of knowledge about the iOS, but
>> > perhaps you can see a fail in my idea.(I asked Robert in a mail, but
>> > didnt
>> > get a answer at the moment)
>> > I used this code(and I loaded only one slice with SetFileName()):
>> >
>> > PixelType * pixelData = myImage->GetBufferPointer();
>> >
>> > Then I calculated the follow values:
>> >
>> > bits per component = 16 // because of the unsigned short buffer
>> >
>> > bits per pixel = 16 // because it has only one component per pixel
>> >
>> > bytes per row = (bits per pixel/8) * width of the image
>> >
>> > Is that correct?
>>
>>
>> Yes, that's correct.
>>
>>
>> > Or are there other information in the unsigned short
>> > buffer, which I got from GetBufferPointer() ?
>> >
>>
>> Nope,
>> the Buffer has only pixel data, and
>> doesn't do any type of padding.
>>
>> It is a continuous solid block of pixels.
>>
>>
>> Luis
>>
>>
>> -----------------------
>> > Cheers,
>> >
>> > Andy
>> >
>> > On Sun, May 15, 2011 at 4:24 PM, Luis Ibanez <luis.ibanez at kitware.com>
>> > wrote:
>> >>
>> >> Hi Andy,
>> >>
>> >> Please read the chapter on "Data Representation"
>> >> of the ITK Software Guide:
>> >>
>> >> http://www.itk.org/ItkSoftwareGuide.pdf
>> >>
>> >> Particularly the section on "Images".
>> >>
>> >> Then read the chapter on "Image Iterators".
>> >>
>> >> Let us know if you have further questions
>> >> after you have read these two chapters.
>> >>
>> >>
>> >> Thanks
>> >>
>> >>
>> >> Luis
>> >>
>> >>
>> >> ----------------------------
>> >> On Sun, May 15, 2011 at 5:09 AM, Andy Ettisberger
>> >> <ettisberger at gmail.com>
>> >> wrote:
>> >> > Hi Luis,
>> >> > Thanks for your fast answer. But I got a few questions opened :)
>> >> >
>> >> > FileNamesContainer fileNames =
>> >> > nameGenerator->GetInputFileNames();
>> >> >
>> >> > reader->SetFileNames( fileNames );
>> >> >
>> >> > reader->Update();
>> >> >
>> >> > ImageType * imageTest = reader->GetOutput();
>> >> >
>> >> > PixelType * pixelData = imageTest->GetBufferPointer();
>> >> >
>> >> > When I do something like that - in the directory there are 5 slices
>> >> > of
>> >> > the
>> >> > dicom stack. Which slice do I access like that? And how can I go to
>> >> > the
>> >> > next
>> >> > slice?
>> >> >
>> >> > My other problem is that I do not have a lot of knowledge about pixel
>> >> > data
>> >> > and images. Can I loop through the pixel data pointer, which is a
>> >> > unsigned
>> >> > short pointer I think, and access the pixel data? And every
>> >> > sizeof(unsigned
>> >> > short) or something like that is one pixeldata?
>> >> >
>> >> > Sorry for the probably stupid question :)
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Andy
>> >> >
>> >> >
>> >> >
>> >> > On Sat, May 14, 2011 at 6:38 PM, Luis Ibanez
>> >> > <luis.ibanez at kitware.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Andy,
>> >> >>
>> >> >> It is great to hear that the build of ITK in iOS is working for you.
>> >> >>
>> >> >>
>> >> >> At this point you can get the image data by just doing:
>> >> >>
>> >> >>
>> >> >> reader->Update();
>> >> >>
>> >> >> const ImageType * image = reader->GetOutput();
>> >> >>
>> >> >> const PixelType * pixelData = image->GetBufferPointer();
>> >> >>
>> >> >>
>> >> >> Let me know if you find any problems,
>> >> >>
>> >> >>
>> >> >> You will find more details about using ITK in iOS
>> >> >> in these Insight Journal papers:
>> >> >>
>> >> >> http://www.insight-journal.org/browse/publication/755
>> >> >> http://www.insight-journal.org/browse/publication/760
>> >> >>
>> >> >> and the reformatted version in our Newsletter:
>> >> >>
>> >> >>
>> >> >>
>> >> >> http://www.kitware.com/products/html/MedicalImageAnalysisWithITKonAppleiOS.html
>> >> >>
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >>
>> >> >> Luis
>> >> >>
>> >> >>
>> >> >>
>> >> >> ---------------------------
>> >> >> On Sat, May 14, 2011 at 10:24 AM, Andy Ettisberger
>> >> >> <ettisberger at gmail.com> wrote:
>> >> >> > Hello Luis,
>> >> >> > How is it going? First time I have a question for you - without
>> >> >> > any
>> >> >> > problems
>> >> >> > with the Apple iOS. We got the ITK build on the newest version of
>> >> >> > the
>> >> >> > iOS -
>> >> >> > and it works :) I can now access a Dicom stack with the code
>> >> >> > looking
>> >> >> > like
>> >> >> > that:
>> >> >> > nameGenerator->SetInputDirectory("dicom_path"); // any path
>> >> >> > to
>> >> >> > dicom
>> >> >> > slices
>> >> >> >
>> >> >> > typedef std::vector<std::string> FileNamesContainer;
>> >> >> >
>> >> >> > FileNamesContainer fileNames =
>> >> >> > nameGenerator->GetInputFileNames();
>> >> >> >
>> >> >> > reader->SetFileNames( fileNames );
>> >> >> >
>> >> >> > reader->Update();
>> >> >> >
>> >> >> > ......
>> >> >> >
>> >> >> > And it works. I can then load data of the dicom, like the patient
>> >> >> > name
>> >> >> > etc
>> >> >> > like it is described in the ITK documentation. Now I had the idea
>> >> >> > to
>> >> >> > extract
>> >> >> > the image data to create a UIImage(ipad image format) on the ipad
>> >> >> > -
>> >> >> > because
>> >> >> > the ipad cant display other formats. Can you help me, how to get
>> >> >> > now
>> >> >> > the
>> >> >> > data of the dicom images? Is it possible to loop through pixels?
>> >> >> > Perhaps
>> >> >> > it
>> >> >> > is in the documentation - but I didn't found a good example :/
>> >> >> >
>> >> >> > Cheers and rainy greetings from Switzerland,
>> >> >> >
>> >> >> > Andy
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
More information about the Insight-users
mailing list