[Insight-developers] Improving support for color in ITK

Karthik Krishnan karthik.krishnan at kitware.com
Mon Jul 27 01:30:04 EDT 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090727/a59dd1f4/attachment.htm>


More information about the Insight-developers mailing list