|
From: Tait <gnu...@t4...> - 2014-03-07 11:06:18
|
> > Currently (version 4) you can plot with RGB colors by saying, for instance
> > plot ... using 1:2:3 linecolor rgb variable
> > where input column 3 contains 24-bit RGB values.
> > Bits 25-32 are ignored, and the lines are all solid color.
>
> Ah, I see, I was thinking of literal RGB values (#AARRGGBB), not their
> binary representation. Hence also my reference to what seems to be
> "common".
>
> > Are you suggesting that any command using the keyword "rgb" should
> > ignore the high bits?
> > I.e. that a new keyword rgba or argb should be introduced everywhere?
> > And than what - the program would invert the high byte during input?
>
> Yes, that seems like a sensible approach to me. Particularly so because
> it will never surprise a user who is expecting RGB, but suddenly gets
> RGBA. In fact, even if you don't invert the high bytes, I think the
> choice to use an alpha channel should be explicit.
There does seem to be a problem with any approach involving using the
alpha channel:
gnuplot> rgba(a,r,g,b)=(a*2**24) | (r*2**16) | (g*2**8) | b
# having << and >> operators here would be nice
gnuplot> print rgba(0,0,0,0)
0
gnuplot> print rgba(0x88,0,0,0)
non-integer passed to boolean operator
gnuplot> print rgba(0x78,0,0,0)
2025521152
The problem, of course, is that gnuplot doesn't have an unsigned
integer data type. The "non-integer" error can be avoided by using +
instead of |, but then the number is promoted to float and it cannot
be used as intended in the plot command like
gnuplot> plot x lw 5 lc rgbcolor rgba(0x88,0x22,0x55,0x88), -x lw 5 lc rgbcolor rgba(0x88,0xBB,0x77,0x33)
Even defining the function as
gnuplot> rgba(a,r,g,b)=int((a*2**24) + (r*2**16) + (g*2**8) + b)
doesnt seem to work right when it comes to the plot command.
(And if I may toss in my 2p, my intuitive expectation is that 0 means transparent, and 1 or 255 or however it ends up means opaque. I think this means a new keyword like rgbacolor or argbcolor makes the most sense.)
|