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

David Thompson david.thompson at kitware.com
Fri Aug 31 18:10:11 EDT 2012


Hi Marcus,

>> ... How about the following for SetColor()?
>> 
>>   void InsertColor( std::string name, double* rgba, int swatch = 0 );
>>   void InsertColor( std::string name, double r, double g, double b, double a=1., int swatch = 0 );
>>   void RemoveColor( std::string name );
>>   int  GetNumberOfSwatches( std::string name );
>> 
>> That seems wrappable and the vector could just be increased in size to accommodate whatever swatch number was provided (hence the name change from SetXXX to InsertXXX).
>> 
> The vtkColor4d is just a double[4] in memory, and an
> std::vector<vtkColor4d> colors would be laid out as 4*N doubles. The
> color classes can also convert between different representations and
> you don't need to guess the size. I personally prefer the compactness
> of the vtkColor4ub, and the representation is easy to send to GL (as
> is the vtkColor4d but it does use more space).

My problem with vtkColor4ub is that if you want to use VTK to generate or process high dynamic range images, it could be a problem to standardize on this as internal storage for base classes.

> ... I would love to see us move towards using actual types to represent
> things like color, with accessors that can give the pointers for
> older/C function calls.

I have conflicting feelings about that. I really enjoy the convenience of actual types but it seems like VTK, as a library instead of an application, should be capable of accepting data in whatever form it is provided.

> My $0.02, there is another color table class in the charts modules
> that lets us pass around color sequences for plot colors too.

Argh! I was looking for that the other day and missed it. Would you object to me performing a little surgery on it to reconcile it with vtkBrewerColors?

	David


More information about the vtk-developers mailing list