[Insight-developers] Improving support for color in ITK

[Dan Mueller]

Hi Karthik

> Perhaps. In this case, you do know the number of color components a-priori,
> for a given color space. Its not a variable. Hence perhaps, there isn't a
> strong enough argument to use a VectorImage, instead of defining a new pixel
> type (and going through the trouble of adding traits for it).

Indeed: VectorImage has variable length vectors for pixels. I was
meaning to use a fixed sized vector ie. Image< Vector<unsigned char,
2> >.

Numeric traits already exist for fixed sized vector pixels (in
Common/itkNumericTraitsVectorPixel.h) so the same holds: if I use
Vector as the pixel type, there will be no need to create "yet
another" pixel type. My question still remains: if I don't create a
new pixel type, is this too confusing for users?

> You may also want to see if there any synergies with the following
> publication :
>   http://www.insight-journal.org/browse/publication/285

Thanks for the pointer. I can't see any synergies.

Cheers, Dan

2009/7/27 Karthik Krishnan <karthik.krishnan at kitware.com>:
> Thanks for taking a stab at this.
>
> On Sun, Jul 26, 2009 at 11:26 AM, Dan Mueller <dan.muel at gmail.com> wrote:
>>
>> typedef itk::RGBToVectorImageAdaptor< BasePixelType > AdapterType;
>> typedef itk::VectorImage< BasePixelType, 2 > VectorImageType;
>> typedef itk::ConvertColorSpaceImageFilter< BasePixelType, 2 >
>> ConvertFilterType;
>> VectorImageType::Pointer imageCielab = converter->GetOutput( );
>> VectorImageType::IndexType index;
>
> Should be
>   VectorImageType::IndexType
> index(converter->GetOutput()->GetNumberOfComponents());
>
>>
>> The advantage of using vectors to hold the color images is that no new
>> pixel types (or traits) need to be added/maintained. The disadvantage
>> is that the user now needs to be careful which color components are
>> currently held by the vector. For example pixel.GetElement( 0 ) may
>> return R(GB), L*(a*b*), X(YZ), or H(SV). Do you feel this is too
>> confusing?
>
> Perhaps. In this case, you do know the number of color components a-priori,
> for a given color space. Its not a variable. Hence perhaps, there isn't a
> strong enough argument to use a VectorImage, instead of defining a new pixel
> type (and going through the trouble of adding traits for it).
>
> You may also want to see if there any synergies with the following
> publication :
>   http://www.insight-journal.org/browse/publication/285
>
> Although that has more to do with lookup tables for mapping scalar to color,
> rather than colorspaces.
>
> Thanks
> --
> karthik
>