[Insight-users] ExtractFilter on VectorImage

Jordi Inglada jordi.inglada at cnes.fr
Thu Feb 16 11:18:13 EST 2006


Hi,

Thank you for the correction. We are now able to deal with VectorImages 
and we have written some IO classes in order to read inhouse remote 
sensing image formats using a more natural formalism (multiband vs. 
volume data).

We have now noticed a particular behaviour when reading vector images. 
Itk is able to convert pixel types from lower bit representation to a 
higher one (char to int, for instance) in a transparent way for the 
user. Our tests show that this does not work for VectorImages. Actually 
it is like no type conversion was made and the raw data buffer was 
passed through the pipeline using the data type of the image file coding.

We are using the itkImageFileReader with the second template parameter 
set to
itk::DefaultConvertPixelTraits< InputPixelType > . This
class used by ConvertPixels to convert blocks of pixels. Since the 
VectorImages data buffer is somewhat particular, I wonder if the block 
conversion is assuming something not compatible with the VectorImages.

Thanks for your help.

Jordi


Karthik Krishnan wrote:
> Thanks for the report. Fixed in CVS HEAD.
> 
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkImageBase.h?root=Insight&r1=1.65&r2=1.66 
> 
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkVectorImage.h?rev=1.12&root=Insight&view=log 
> 
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/BasicFilters/itkExtractImageFilter.txx?rev=1.21&root=Insight&view=log 
> 
> 
> As Luis mentioned, the VectorLength meta-data wasn't propagating down 
> the pipeline.
> 
> The default implementation ProcessObject::GenerateOutputInformation() is 
> responsible for propagating meta-data to the output. This does propagate 
> all meta-data, including the VectorLength to the output. Most filters 
> use the default implementaton or call the superclass method. However, a 
> few filters override this method. For instance the ExtractImageFilter, 
> which must provide its own method cause the input and output images 
> could be of different dimensions ! These filters should have an extra 
> line that propagates VectorLength info, if any
> 
> output->SetNumberOfComponentsPerPixel( 
> input->GetNumberOfComponentsPerPixel() );
> 
> And that was just added.
> 
> Thanks
> karthik
> 
> 
> Luis Ibanez wrote:
> 
>>
>> Hi Jordi
>>
>> Thanks for pointing this out.
>>
>> The support for VectorImages in all ITK filters is being introduced
>> progressively. In principle, most ITK filters should work for Vector
>> images, but there are many filters that have never been tried, so
>> it is quite possible that you will run into some filters that do not
>> manage the VectorImages correctly.
>>
>> In those cases, we appreciate to receive the reports, so we can fix
>> those filters.
>>
>> What is probably happening in the ExtractImage filter is that it is
>> not copying the Length from the input image into the output image.
>> This copy should happen during the invocation of the CopyInformation()
>> method, in the ImageBase class.
>>
>> We will take a look at this filter (and the closely related
>> itkRegionOfInterestImageFilter) and make sure that they can be
>> used for processing VectorImages,... and will let you know when
>> this modifications are available in the CVS repository.
>>
>>
>>
>>
>>     Regards,
>>
>>
>>
>>        Luis
>>
>>
>>
>>
>> -----------------------
>> Jordi Inglada wrote:
>>
>>> Hi,
>>>
>>> As suggested by Karthik as an answer to my post on multi-dimensional 
>>> images, we are now using the itkVectorImage class.
>>>
>>> We are now facing a problem when plugging VectorImages into the 
>>> itkExtractImageFilter. We use
>>>
>>>  typedef itk::VectorImage < PixelType, Dimension>        ImageType;
>>>
>>> and the pipeline is as follows :
>>>
>>> Reader --> ExtractFilter --> Writer
>>>
>>> Our first test used an RGB PNG image. Interestingly, the IO PNG 
>>> ressource knows how to build a 3 channel VectorImage. Actually, if we 
>>> use the very simple pipeline
>>>
>>> Reader --> Writer
>>>
>>> with the ImageType defined above, the output image is the exact copy 
>>> of the input one.
>>>
>>> However, when the extract filter is used, the output PNG image, even 
>>> if it has the right dimensions, it is empty except for some columns. 
>>> In the case where I try to write it in JPEG, I get the following 
>>> message : "Too many color components: 0, max 10".
>>>
>>> I have found a workaround by creating a VectorToRGBImageFilter which 
>>> does the conversion (I wasn't able to make Adaptors work for 
>>> VariableLengthVector pixels). And it works if the conversion is done 
>>> BEFORE the extract filter. The output images are bad if the 
>>> conversion is done AFTER the extract filter.
>>>
>>> By now, this solution is OK for me, but I think that this is not 
>>> really satisfacttory.
>>>
>>> So my question is : can one use the VectorImage as any other 
>>> itk::Image with itk filter, or has one to make the conversion to 
>>> fixed array pixel types in order to make things work?
>>>
>>> Thanks.
>>>
>>> Jordi
>>>
>>>
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
> 

-- 
CNES - DCT/SI/AP - BPI 1219
18, avenue Edouard Belin
31401 Toulouse Cedex 09 - France
Tel. +33.(0)5.61.27.33.97 - Fax. +33.(0)5.61.28.31.09


More information about the Insight-users mailing list