[PD] [pix_data] - convert rgb values to pd canvas format

[Jonathan Wilkes]

What I mean is that iemgui color format is so complicated and difficult to understand, saying "represents white" is probably the most accurate way to explain how that number maps to a human readable color.
On the bright side, this thread has convinced me not to add an animation api in my GUI port.  While I think it would serve my own peculiar interests just fine, I really don't understand the implications for more sophisticated use-cases.  (And I can easily imagine a user getting stuck because I didn't consider the downsides of my approach.)
-Jonathan


 

    On Monday, January 11, 2016 3:08 AM, Roman Haefeli <reduzent at gmail.com> wrote:
 

 On Sun, 2016-01-10 at 22:08 +0000, Jonathan Wilkes wrote:


> > This limitation is worked-around by reducing the resolution to 6
> bits per 
> 
> > channel. The highest number (the one representing white) is -262144.
> It does 
> 
> > not exceed 6 digits and can be stored at full precision.
> 
> 
> It's probably worth explaining why you say "the one representing
> white" and not simply "white". 

Oh, I'd attribute this to my tendency to sometimes express things too
verbosely.

> (I.e., what every other sane color format calls "white" does 
> not equal what iemgui's file color format calls -262144.)

I wasn't thinking of that, but you're right. It's not possible to create
white (as in #ffffff) iemguis dynamically. If one needs white, one needs
to set the color by message. But still when you save it in the patch, it
won't be white on the next patch load. 

Roman 

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160111/6232c359/attachment-0001.html>