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

Jeff Baumes jeff.baumes at kitware.com
Fri Aug 31 16:12:19 EDT 2012


On Fri, Aug 31, 2012 at 2:37 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Fri, Aug 31, 2012 at 12:39 PM, David Thompson
> <david.thompson at kitware.com> wrote:
>> Hi David,
>>
>>>> Yes, although it might be easier to have
>>>>
>>>>    void SetColor( std::string, double* rgba, int numRGBATuples = 1 );
>>>>    double* GetColor( std::string, int swatch = 0 );
>>>
>>> But then you are making unwrappable methods.  It's possible to
>>> have a wrapper hint that "double *rgba" is a 4-tuple, but it isn't
>>> possible to hint that it is a "4*N-tuple".
>>
>> I agree SetColor would not be wrappable as-is.
>>
>>> If you want to support swatches, you should have a GetColorSwatch()
>>> method, rather than complicate the GetColor() method.
>>
>> ... but why wouldn't GetColor() work? It would always return a pointer to a 4-tuple of doubles. Or do the wrappers prefer
>>
>>    void GetColor( double color[4], std::string name, int swatch = 0 );
>>
>> 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).
>>

A central place for color schemes/palettes would be great, but I think
it would be better to separate the class for named colors (single
colors) from the class for color schemes (groups of colors). So I like
something similar to Andrew's simpler API. Is there any reason not to
use the exact color strings used in HTML/CSS/SVG, which came from the
X11 colors (e.g. why "antique_white" in the original email on this
thread instead of the standard "antiquewhite"?). I suppose we can
support both legacy non-standard names and current standards.

http://www.w3.org/TR/css3-color/#svg-color

> 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).
>
> 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.
>
> My $0.02, there is another color table class in the charts modules
> that lets us pass around color sequences for plot colors too.

I'd also like to see vtkColor4ub being used internally and in new API
where possible. Since 0-255 is what rendering engines often use (and
what people familiar with modern standards like HTML, CSS, SVG are
used to) it seems vtkColor4ub should be the preferred internal format,
with vtkColor4d API being used for compatibility with existing VTK
code. The vtkNamedColors class could for example store a map of string
to vtkColor4ub internally and have functions that return vtkColor4d to
be compatible with many existing VTK color-setting functions.
So to me, this is good:

actor->GetProperty()->SetColor(vtkNamedColors::GetColorDouble("antiquewhite").GetData());

Eventually we would have a vtkColor4ub function overload for
vtkProperty::SetColor:

actor->GetProperty()->SetColor(vtkNamedColors::GetColor("antiquewhite"));

Jeff



More information about the vtk-developers mailing list