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

[Andrew Maclean]

Hi all,

I am pleased to see that this has generated so many comments and good ideas.
If we come back and focus on the original intent, I wanted a class
that would do the following:
1) Associate color names with values.
2) Be easily searchable.
3) Some of you also touched on this:
   Have methods like:
       void SetColor( std::string name, double * rgba)
       void SetColorDouble( std::string name, double r, double g,
double b, double a = 1.0)
       void SetColor ( std::string nane, unsigned char r, unsigned
char g, unsigned char b, unsigned char a = 255)

      double * GetColorDouble( std::string name )
      unsigned char* GetColor( std::string name )
      void GetColorDouble( std::string name, double & r, double & g,
double & b, double & a)
      void GetColor ( std::string name, unsigned char & r, unsigned
char & g, unsigned char & b, unsigned char & a)
4) This would allow us to do things like:
     actor->GetProperty()->SetColor(NamedColors()->GetColorDouble(
"antiquewhite" ))
     In Python:
     actor.GetProperty().SetColor(NamedColors().GetColorDouble("antiquewhite" ))
5) I definitely lean towards to using the color names in
http://www.w3.org/TR/css3-color/#svg-color
    Which are better laid out in: http://en.wikipedia.org/wiki/Web_colors
6) The other question is do we use an unsigned int to store the
hexadecimal representation?
    My feeling is no because it limits future expansion and
bit-shifting/masking needs to take into account big/little endian
characteristics.
    So I would prefer storing as an unsigned char vector.
   This raises a question regarding storage in that should we just use
unsigned int instead of unsigned char to cater for future expansion?

In conclusion, I am happy to set up a topic and have a go at creating
a class to encapsulate the above points as an initial starting point.
Then we can refine it.
If people are happy with that this, I propose the class be called:
vtkNamedColors
and it go in:
Common\Core
in the first instance.

If it is a reasonable attempt then I forsee other color classes as
mentioned in the discussions ultimately deriving from it using some of
its features.
It really would be nice to get away from things like:
actor->GetProperty()->SetColor((0.8900, 0.0700, 0.1900, 1.000)
If you don't know what color this is, it is geranium_lake!


Regards
   Andrew


On Mon, Sep 3, 2012 at 3:17 AM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Fri, Aug 31, 2012 at 6:10 PM, David Thompson
> <david.thompson at kitware.com> wrote:
>> 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.
>
> Why not specialize at that level for the high dynamic range images, it
> seems odd to pay the price in the base classes for something not being
> used there too.
>>
>>> ... 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.
>
> That is why I wrote the vtkColor* classes to be POD, you can actually
> use GetData to get at the underlying data, initialize them from
> pointers to their underlying types or if efficiency is a concern you
> can cast, e.g.
>
> double myColors[4 * n];
> ...do something with the colors...
> vtk*Class->SetColor(*(static_cast<vtkColor4d *>(myColors[4 * 1])));
>
> You can also perform conversions if desired (although I feel this is
> way off topic for the thread)
>>
>>> 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?
>>
> It depends what the surgery is, I would be happy to take a look at
> what you want to do/review it. It would be great to get more colors in
> there (I would like to retain the current ones for the tests at least
> even if you add nicer ones), but it has been in for quite some time so
> we should retain the API.
>
> Marcus



-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________