[Insight-developers] ImageIO Handling of Multi-Image datasets

Matt McCormick matt.mccormick at kitware.com
Tue Jul 2 16:39:06 EDT 2013


Hi Mark,

The assumption that allows the templated itk::ImageFileReader and
itk::ImageSeriesReader to fill an itk::VectorImage, itk::Image< itk::Vector,
Dimension >,
itk::Image< itk::CovariantVector, Dimension >, itk::Image< itk::RGBPixel,
Dimension >, etc. with the contents formed from itk::ImageIO::Read
equally well is that the
itk::Size for the result is the same in all dimensions.

Therefore, if there are multiple series of images with different resolutions,
then the Video framework should be used.

HTH,
Matt

On Tue, Jul 2, 2013 at 6:47 PM, Mark Hiner <hiner at wisc.edu> wrote:
> So if you have multi-series images where the series are of differing
> resolutions, would the ImageIO::Read populate the image array with
> itk::CovariantArrays (or some other array type?) and just fill in the
> positions that exist? Because it's 1 array per position, would that
> necessitate smaller resolutions being stored after larger resolutions?
>
> is there a way, in the ITK API, to request a specific series from the
> ImageIO?
>
>
> On Tue, Jul 2, 2013 at 9:10 AM, Mark Hiner <hinerm at gmail.com> wrote:
>>
>> Yep, the SCIFIOImageIO is actually a gateway to a Bio-Formats ImageReader,
>> which provides support for all the Bio-Formats formats... and it allows
>> updates to Bio-Formats (e.g. new formats) to be automatically supported,
>> without duplicating the work in C++.
>>
>> The SCIFIO source (which is in beta) is just a dynamically extensible
>> ImageIO framework, and we're working on refactoring Bio-Formats to use the
>> SCIFIO API.
>>
>> Eventually I plan on creating a high-level C++ mirror of the SCIFIO API,
>> which will greatly simplify the SCIFIOImageIO... but for today I'll be happy
>> just to get multi-series images working :)
>>
>> Thanks again.
>>
>>
>>
>>
>> On Tue, Jul 2, 2013 at 8:58 AM, Williams, Norman K
>> <norman-k-williams at uiowa.edu> wrote:
>>>
>>> That sounds about right.  The first step (if you haven't done this
>>> already) is to set up a Gerritt account so you can submit patches for
>>> review: http://www.itk.org/Wiki/ITK/Git/Develop
>>>
>>>
>>> I hadn't realized until I looked what a crazy thing the SCIFIOImageIO
>>> was.
>>>  It starts up a java process and passes it commands?
>>>
>>> I'm not volunteering or anything, but I can't imagine that the file
>>> format
>>> is so complex that it wouldn't be worth writing a C++ parser for it.
>>>
>>> On 7/2/13 8:27 AM, "Mark Hiner" <hiner at wisc.edu> wrote:
>>>
>>> >The SCIFIOImageIO doesn't currently have knowledge of the series count,
>>> >but it would be simple to pass that information from the Java portion of
>>> >the ImageIO during the ReadImageInformation step.
>>> >
>>> >
>>> >So it sounds like, if I modify the SCIFIOImageIO to start tracking the
>>> >series count, and use that information to populate the data array
>>> >according to the
>>> >
>>> >VectorImage spec
>>>
>>> > ><http://www.itk.org/Doxygen/html/classitk_1_1VectorImage.html#a62029e56578
>>> >31db8bdec71a5b3482964> during ImageIO::Read, everything will just work..
>>> >right?
>>> >
>>> >Thanks for the help!
>>> >
>>> >
>>> >
>>> >
>>> >On Mon, Jul 1, 2013 at 3:34 PM, Williams, Norman K
>>> ><norman-k-williams at uiowa.edu> wrote:
>>> >
>>> >I haven't worked on the SCIFIO reader, so I'm not sure how it behaves.
>>> >
>>> >In a perfect world, you'd specify an itk::VectorImage as the image type
>>> >for the reader. VectorImage is more efficient in cases where all voxels
>>> >have the same number of vector elements.  Then, when SCIFIO reads the
>>> > file
>>> >initially, it should know enough about the image format to deduce the
>>> >series size, and reorganize the raw Image Buffer such that the
>>> > conversion
>>> >to vector voxels does the right thing.
>>> >
>>> >The image type parameter of the ImageFileReader shouldn't need to
>>> > specify
>>> >the series size.
>>> >
>>> >
>>> >Looking at the SCIFIOImageIO class, it definitely doesn't look that
>>> > smart.
>>> > In that case you'll need to read the image in as a 4D image of scalar
>>> >voxels, and build the 3D VectorImage from the 4D Scalar Image.
>>> >
>>> >On 7/1/13 3:12 PM, "Mark Hiner" <hiner at wisc.edu> wrote:
>>> >
>>> >>Hi all,
>>> >>
>>> >>
>>> >>I'm working on a Bio-Formats / ITK bridge that invokes Bio-Formats
>>> >>(SCIFIO) Readers by piping commands from C++ to Java.
>>> >>
>>> >> I'm having some issues with multi-image datasets. I have a file that
>>> >>contains 580 2048x2048x11 images. If I use a pure Bio-Formats
>>> >> conversion
>>> >>tool, the images are merged as a single image with 580 T slices.
>>> >>
>>> >>
>>> >> First of all, how should an image like this be represented in ITK? My
>>> >>assumption is as a VectorImage type and not by using the
>>> >>ImageSeriesReader.. as the latter says it needs multiple files, and I
>>> >>have multiple series in a single file.
>>> >>
>>> >>
>>> >> Given the proper data structure for this dataset, how do I actually
>>> >>determine (or set) the appropriate series size parameters?
>>> >>
>>> >>
>>> >>e.g. if I do have a VectorImage does its size have to be declared to
>>> >> even
>>> >>make a Reader/Writer, or is there some way I can set it from my ImageIO
>>> >>during the ReadImageInformation call?
>>> >>
>>> >>
>>> >>... or if I do have to explicitly declare the size, how can the ImageIO
>>> >>tell which series is currently being queried during
>>> >> ImageIO::Read/Write,
>>> >>so I can pass that series parameter to a Bio-Formats Reader?
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>Thanks,
>>> >>Mark
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >________________________________
>>> >Notice: This UI Health Care e-mail (including attachments) is covered by
>>> >the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>> >confidential and may be legally privileged.  If you are not the intended
>>> >recipient, you are hereby notified that any
>>> > retention, dissemination, distribution, or copying of this
>>> > communication
>>> >is strictly prohibited.  Please reply to the sender that you have
>>> >received the message in error, then delete it.  Thank you.
>>> >________________________________
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered by
>>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>> confidential and may be legally privileged.  If you are not the intended
>>> recipient, you are hereby notified that any retention, dissemination,
>>> distribution, or copying of this communication is strictly prohibited.
>>> Please reply to the sender that you have received the message in error, then
>>> delete it.  Thank you.
>>> ________________________________
>>
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>


More information about the Insight-developers mailing list