[vtk-developers] Manual conversion of some Tcl to Python tests.

[David Thompson]

Hi David,

>> There would be only two functions e.g GetColor(std::string) returning
>> a std::vector and SetColor(std::string, std::vector) - this function
>> would allow the user to add new colours.
>> 
>> Hopefully this would be wrapped and easy to use in Python etc. thus
>> removing the need for colors.py.
> 
> Well, std::string is wrapped but std::vector is not.  You could use the
> new vtkColor type instead.

Yes, although it might be easier to have

    void SetColor( std::string, double* rgba, int numRGBATuples = 1 );
    double* GetColor( std::string, int swatch = 0 );

and just use a std::map<std::string,std::vector<double> > internally.

> I notice that vtkBrewerColors used vtkColor4ub, i.e. unsigned char RGBA.
> This highlights a problem with any GetColor method... what format is the
> color going to be returned in?  Most VTK classes like vtkProperty  expect
> "double[3]" or "double *" as the color type.

I would like to get rid of vtkBrewerColors (the class, not the palettes) before a VTK release contains it in favor of a more generic way of providing palettes. I prefer doubles and a 4-tuple (RGBA) instead of a 3-tuple (RGB). Doubles have a larger dynamic range which is useful for internal representations even if devices can't really present more than 8 bits/channel (although some are starting to). And it seems silly not to accommodate alpha values.

	David