[Insight-developers] Streaming with ImageWriter and IORegion
Bradley Lowekamp
blowekamp at mail.nih.gov
Fri Dec 26 14:46:14 EST 2008
Hello Luis,
I had modified the itkMetaImageStreamingIOTest in a simple fashion
to test this interface. But I added a class to the pipeline similar
to what I mentioned in "Writing a test for streaming" to this list. It
was a simple class that keep tracks of RegionIO requests and related
setup activity. I didn't think there was a good way to test streaming
for filters already. Not sure if this was a good idea or not, so I
didn't include it in Mantis diff.
The CanStream, CanCompress, interface in ImageIO are not as useful as
it should be with ImageFileWriter and Reader. If I recall correctly,
the ImageIO object is created through a factory in the Update/Read/
Write method. So one can not easily configure writing and reading to
make full use of the capabilities of the ImageIO class, with out
knowing the ImageIO before. To further complicate things and ImageIO
class may support Compress and Streaming, but not both at the same
time. If ImageFileWrite/Reader had a separate method to generate the
ImageIO object from the filename, so that it could then be queried for
capabilities they would be more useful.
Thirdly, before I left work for the holiday, I had an idea what the
cause of itkMetaImageStreamingWriterIOTest2 not producing the correct
results. I think that MetaImageIO, streaming functionality does not
work with non-square voxels. But I need to look into this further to
be certain. I was planning on doing this on Monday.
Brad
On Dec 26, 2008, at 1:28 PM, Luis Ibanez wrote:
>
> Hi Brad,
>
> Thanks a lot for taking a look at this problem and implementing
> the missing functionality of streaming.
>
> I'm taking a look at your code in the MANTIS bug tracker.
>
> Stephen has already addressed some of the issues with the
> CanStream () methods in MetaImageIO.
>
> We'll add a test for the streaming capability, and then
> we would be able to add this code to the repository.
>
>
> Thanks !
>
>
> Luis
>
>
>
> --------------------------
> Bradley Lowekamp wrote:
>> Hello,
>> I just placed the changes into Mantis:
>> http://www.itk.org/Bug/view.php?id=8323
>> Please review. And see what other issues are there. And if it's a
>> good idea to add to itk.
>> The itkMetaImageStreamingWriterIOTest still looks like it works the
>> way it did before. This utilized the SetIORegion method. If
>> backwards compatibility is defined that way then we have it.
>> However, itkMetaImageStreamingWriterIOTest2 appears to generating
>> blank images as the output. So, I don't think it should have been
>> passing before. Robustness was added to this approach. Basically
>> the IOregion set in the writer gets propagated (don't need to set
>> it in the reader). And if the input region to the file writer
>> doesn't match it is fixed for ImageIO. Hopefully that works for you
>> Stephen. Brad
>> On Dec 22, 2008, at 11:49 AM, Stephen Aylward wrote:
>>> Hi,
>>>
>>> Quick note...we are using SetIORegion for streaming writing in a
>>> commercial product.
>>>
>>> Streaming reading and writing is working fine when .mhd/.mha files
>>> are used.
>>>
>>> We need to maintain backward compatibility.
>>>
>>> Thanks,
>>> s
>>>
>>> On Mon, Dec 22, 2008 at 10:01 AM, Bill Lorensen <bill.lorensen at gmail.com
>>> <mailto:bill.lorensen at gmail.com>> wrote:
>>>
>>> Brad,
>>>
>>> Sounds great.
>>>
>>> Bill
>>>
>>> On Mon, Dec 22, 2008 at 9:08 AM, Bradley Lowekamp
>>> <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
>>> > Bill,
>>> > I'll implement this method how I think is should work. That is
>>> I'll make is
>>> > so that it requests the ioregion, up the pipeline and will
>>> tolerate if the
>>> > exact region is not supplied. This will maintain the backwards
>>> compatibility
>>> > of the interface, but the behavior may be a little different.
>>> > Then I will submit the changes into mantis so that they can be
>>> quickly
>>> > reviewed or what not.
>>> >
>>> > Brad
>>> > On Dec 19, 2008, at 6:48 PM, Bill Lorensen wrote:
>>> >
>>> > Brad,
>>> >
>>> > Really, we don't know what customers may be using this
>>> method. Maybe
>>> > even correctly in their own ImageIO class. Many customers
>>> write
>>> their
>>> > own ImageIO classes. For example, Slicer3 has two of its own
>>> ImageIO
>>> > classes. To be honest, I have not looked at how it's used in
>>> the
>>> > ImageFileWriter or current ImageIO classes. I'll take a look
>>> over the
>>> > next few days.
>>> >
>>> > But, as I said before, we released the code with these methods.
>>> Since
>>> > we made the mistake, the burden is on us to fix it, not our
>>> customers.
>>> >
>>> > Bill
>>> >
>>> > On Fri, Dec 19, 2008 at 5:05 PM, Bradley Lowekamp
>>> > <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
>>> >
>>> > Bill,
>>> >
>>> > This is a very problematic method; I have strong doubts that
>>> anyone is using
>>> >
>>> > it. It is unclear to me what the appropriate behavior should
>>> be.
>>> If it's
>>> >
>>> > current behavior must be maintained then, we should copy the
>>> current Write
>>> >
>>> > method, so that it can be called only when needed if this
>>> method
>>> has been
>>> >
>>> > set, Then depreciate the method so that it can be removed
>>> later.
>>> >
>>> > MetaImageIO is the only class that can support this method. Use
>>> it with any
>>> >
>>> > other ImageIO (I think) results in no image, or undefined
>>> behavior. I
>>> >
>>> > believe that this method was a start of implementing streaming
>>> that was
>>> >
>>> > never finished. For it to be used the input to ImageFileWrite
>>> must have
>>> >
>>> > already executed and generated this exact region or else the
>>> results would
>>> >
>>> > be wrong, and undefined. Some of these problems could be
>>> reduced if
>>> >
>>> > ImageFileWrite copies the regionIO to a buffer/cache if needed,
>>> then it
>>> >
>>> > would be up to the ImageIO to do what is asked or barf.
>>> >
>>> > I would argue that anyone using this method should not be using
>>> >
>>> > ImageFileWriter and should just use the ImageIO object
>>> directly,
>>> with it's
>>> >
>>> > current behavior, but that's not backwardly compatible.
>>> >
>>> > What's be best solution?
>>> >
>>> > Brad
>>> >
>>> > On Dec 19, 2008, at 3:59 PM, Bill Lorensen wrote:
>>> >
>>> > Brad,
>>> >
>>> > We cannot remove methods from a class that has been released.We
>>> should
>>> >
>>> > do what we can to avoid their improper use.
>>> >
>>> > Bill
>>> >
>>> > On Fri, Dec 19, 2008 at 3:17 PM, Bradley Lowekamp
>>> >
>>> > <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
>>> >
>>> > Hello,
>>> >
>>> > I have essentially completed these modifications. There is just
>>> more testing
>>> >
>>> > to write. All of the current non-IO streaming tests are passing
>>> (that should
>>> >
>>> > be). The only ImageIO class that was ready for streamed writing
>>> was MetaIO,
>>> >
>>> > so that is currently the only file type that is streaming.
>>> >
>>> > Option number 1, was chosen from bellow. It was the least
>>> amount
>>> of code,
>>> >
>>> > since it doesn't double the splitters.
>>> >
>>> > On the down side of these changes, I removed
>>> >
>>> > ImageFileWriter::Set/GetIORegion. These were low level methods
>>> which are not
>>> >
>>> > compatible with the ITK pipeline, and likely to cause segfaults
>>> and crashes
>>> >
>>> > if not used just right.
>>> >
>>> > What is the best way to contribute this code? IJ, attach the
>>> diff to Mantis?
>>> >
>>> > Just submit it to CVS, and hope CDash doesn't light up like a
>>> xmas tree? I
>>> >
>>> > think it's good quality, just may have missed some nuances of
>>> ITK or a
>>> >
>>> > compiler compatibility.
>>> >
>>> > I am excited to be able to process my 13GB RGB data set on my
>>> laptop :)
>>> >
>>> > Brad
>>> >
>>> > On Dec 18, 2008, at 12:23 PM, Bradley Lowekamp wrote:
>>> >
>>> > Hello,
>>> >
>>> > I am implementing streaming in ImageFileWriter, hoping that it
>>> can get on
>>> >
>>> > the fast track to making it into the repository. I have done
>>> most of the
>>> >
>>> > work in ImageFileWriter and now working out some difficulties
>>> with
>>> >
>>> > ImageIOBase. According to the design Luis wrote below, IOBase
>>> should have a
>>> >
>>> > virtual method to create a "region splitter". The difficulties
>>> with this
>>> >
>>> > lies in the differences between ImageIORegion and ImageRegion.
>>> Specifically
>>> >
>>> > ImageRegion is templated over dimension for use with Image,
>>> where
>>> >
>>> > ImageIORegion is not since ImageIO classes are not. The issues
>>> then comes
>>> >
>>> > from with ImageRegionSplitter<#> being templeted. So there
>>> becomes two
>>> >
>>> > choices I see:
>>> >
>>> > 1) Use ImageRegionSplitter in ImageIO, this is have the
>>> >
>>> > following declaration:
>>> >
>>> > template <unsigned int VImageDimension>
>>> >
>>> > typename ImageRegionSplitter<VImageDimension>::Pointer
>>> >
>>> > ImageIOBase::GenerateWriteRegionSplitter(unsigned int
>>> >
>>> > numberOfStreamDivisions, const ImageRegion<VImageDimension>
>>> >
>>> > &largestPossibleRegion);
>>> >
>>> > It will also need a virtual helper function and do some dynamic
>>> casts, as
>>> >
>>> > well as the ugliness of some macro to create the templated
>>> object from a
>>> >
>>> > parameter.
>>> >
>>> > 2) Create a new ImageIORegionSplitter hierarchy, and duplicate
>>> the a bunch
>>> >
>>> > of code from ImageRegionSplitter. This will have a smoother
>>> interface:
>>> >
>>> > virtual ImageIORegionSpliter::Pointer
>>> >
>>> > ImageIOBase::GenerateWriteRegionSplitter(unsigned int
>>> >
>>> > numberOfStreamDivisions, const ImageIORegion<VImageDimension>
>>> >
>>> > largestPossibleRegion);
>>> >
>>> > Any thought and suggestions are welcome!
>>> >
>>> > Thanks,
>>> >
>>> > Brad
>>> >
>>> > On Dec 6, 2008, at 6:25 PM, Luis Ibanez wrote:
>>> >
>>> >
>>> > Hi Brad,
>>> >
>>> >
>>> > The functionality of Streaming is not fully implemented
>>> >
>>> > on the ImageFileWriter.
>>> >
>>> >
>>> > The design proposal for implementing this feature is to move
>>> >
>>> > (copy/paste) part of the code that you find in the
>>> itkStreamingImageFilter
>>> >
>>> > (in Code/BasicFilters) to the
>>> >
>>> > itkImageFileWriter class.
>>> >
>>> > In particular, the proposal is to use the
>>> itkImageRegionSplitter
>>> >
>>> > inside the ImageFileWriter.
>>> >
>>> > During the design discussions, one of the issues that came up
>>> >
>>> > is that only the specific ImageIO classes are qualified to know
>>> >
>>> > what would be the appropriate way to split the data in order to
>>> >
>>> > match the type of blocks that the output image file format can
>>> >
>>> > manage (e.g. DICOM can only stream slices).
>>> >
>>> >
>>> > Therefore, the suggested design is that the ImageFileWriter
>>> >
>>> > will ask the ImageIO class to provide a specific instance of
>>> >
>>> > an itkImageRegionSplitter, and then it will use it in a for
>>> >
>>> > loop for generating sub-regions of the image, and request
>>> >
>>> > them from the preceding image filters.
>>> >
>>> >
>>> > --
>>> >
>>> > Until this is implemented, then your best options, is to do
>>> >
>>> > just what you are doing: using the itkStreamingImageFilter
>>> >
>>> > just before the ImageFileWriter. The drawback of course is
>>> >
>>> > that you have to whole in memory the full-size output image
>>> >
>>> > before being able to write it to disk.
>>> >
>>> >
>>> > Please let us know if you have further questions,
>>> >
>>> >
>>> > Thanks
>>> >
>>> >
>>> > Luis
>>> >
>>> >
>>> > -------------------------
>>> >
>>> > Bradley Lowekamp wrote:
>>> >
>>> > Greetings all!
>>> >
>>> > I am trying to stream my data set. I see that MetaIO supports
>>> streaming for
>>> >
>>> > reading and writing. But I don't seem to be able to use it for
>>> writing. I am
>>> >
>>> > trying to stream my 13GB data set from a ImageFileReader
>>> through a
>>> >
>>> > ShrinkImageFilter then write is out with a ImageFileWriter.
>>> If I
>>> replace the
>>> >
>>> > writer with a StreamingImageFilter it works great, the reader
>>> streams and
>>> >
>>> > everything.
>>> >
>>> > To get the writer to stream (or not) I am doing this:
>>> >
>>> > shrinker->UpdateOutputInformation();
>>> >
>>> > RGBVolumeType::RegionType outputRegion =
>>> >
>>> > shrinker->GetOutput()->GetLargestPossibleRegion();
>>> >
>>> > itk::ImageRegionSplitter<3>::Pointer splitter =
>>> >
>>> > itk::ImageRegionSplitter<3>::New();
>>> >
>>> > numberOfSplits = splitter->GetNumberOfSplits(outputRegion,
>>> numberOfSplits);
>>> >
>>> > writer->SetFileName( outputFilePN.GetPathName());
>>> >
>>> > writer->SetInput(shrinker->GetOutput());
>>> >
>>> > for(unsigned int i = 0; i < numberOfSplits; ++i) {
>>> >
>>> > RGBVolumeType::RegionType streamRegion = splitter-
>>> >GetSplit(i,
>>> >
>>> > numberOfSplits, outputRegion);
>>> >
>>> > ioRegion = streamRegion; // sudo code
>>> >
>>> > writer->SetIORegion(ioRegion);
>>> >
>>> > writer->Update();
>>> >
>>> > }
>>> >
>>> > Is this the correct approach? Does anyone have an example of
>>> streaming
>>> >
>>> > writing? I think I am going to dig though the ImageFileWriter
>>> now to see
>>> >
>>> > what are the updates going on in the pipeline execution. I
>>> still
>>> a bit fuzzy
>>> >
>>> > on these details, so may miss something.
>>> >
>>> > Please let me know of any suggestions.
>>> >
>>> > Thanks,
>>> >
>>> > Brad
>>> >
>>> > ========================================================
>>> >
>>> > Bradley Lowekamp Lockheed Martin Contractor for
>>> >
>>> > Office of High Performance Computing and Communications
>>> >
>>> > National Library of Medicine blowekamp at mail.nih.gov
>>> <mailto:blowekamp at mail.nih.gov>
>>> >
>>> > <mailto:blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>>
>>> >
>>> >
>>>
>>> ------------------------------------------------------------------------
>>> >
>>> > _______________________________________________
>>> >
>>> > Insight-users mailing list
>>> >
>>> > Insight-users at itk.org <mailto:Insight-users at itk.org>
>>> >
>>> > http://www.itk.org/mailman/listinfo/insight-users
>>> >
>>> > ========================================================
>>> >
>>> > Bradley Lowekamp
>>> >
>>> > Lockheed Martin Contractor for
>>> >
>>> > Office of High Performance Computing and Communications
>>> >
>>> > National Library of Medicine
>>> >
>>> > blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>> >
>>> > _______________________________________________
>>> >
>>> > Insight-developers mailing list
>>> >
>>> > Insight-developers at itk.org <mailto:Insight-developers at itk.org>
>>> >
>>> > http://www.itk.org/mailman/listinfo/insight-developers
>>> >
>>> > ========================================================
>>> >
>>> > Bradley Lowekamp
>>> >
>>> > Lockheed Martin Contractor for
>>> >
>>> > Office of High Performance Computing and Communications
>>> >
>>> > National Library of Medicine
>>> >
>>> > blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>> >
>>> >
>>> > _______________________________________________
>>> >
>>> > Insight-developers mailing list
>>> >
>>> > Insight-developers at itk.org <mailto:Insight-developers at itk.org>
>>> >
>>> > http://www.itk.org/mailman/listinfo/insight-developers
>>> >
>>> >
>>> >
>>> > ========================================================
>>> >
>>> > Bradley Lowekamp
>>> >
>>> > Lockheed Martin Contractor for
>>> >
>>> > Office of High Performance Computing and Communications
>>> >
>>> > National Library of Medicine
>>> >
>>> > blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>> >
>>> >
>>> >
>>> > ========================================================
>>> >
>>> > Bradley Lowekamp
>>> >
>>> > Lockheed Martin Contractor for
>>> >
>>> > Office of High Performance Computing and Communications
>>> >
>>> > National Library of Medicine
>>> >
>>> > blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>> >
>>> >
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org <mailto:Insight-developers at itk.org>
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>>>
>>>
>>> --
>>> Stephen R. Aylward, Ph.D.
>>> Chief Medical Scientist
>>> Kitware, Inc. - North Carolina Office
>>> http://www.kitware.com
>>> (518) 371-3971 x300
>> ========================================================
>> Bradley Lowekamp Lockheed Martin Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov
>> >
More information about the Insight-developers
mailing list