 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/18/2016 7:47 AM, clipka wrote:
> Since they're not used as commonly as sRGB, I doubt we'll add support
> via a keyword (not until we do a major overhaul of the parser at any
> rate). Note that `colors.inc` does provide various macros to convert to
> and from HSL, HSV and L*a*b, and adding support for other colour models
> in the same manner should be no big deal.
>
It's hard to blend between different values for H in HSL or HSV unless
you sample a lot of steps.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.11.2016 um 01:59 schrieb Mike Horvath:
> On 11/18/2016 7:47 AM, clipka wrote:
>> Since they're not used as commonly as sRGB, I doubt we'll add support
>> via a keyword (not until we do a major overhaul of the parser at any
>> rate). Note that `colors.inc` does provide various macros to convert to
>> and from HSL, HSV and L*a*b, and adding support for other colour models
>> in the same manner should be no big deal.
>
> It's hard to blend between different values for H in HSL or HSV unless
> you sample a lot of steps.
Adding native support for those colour models in the same manner as sRGB
wouldn't change that: Colours you specify via the "srgb" keyword are
immediately converted to linear RGB (presuming you're using
"assumed_gamma 1.0").
To change the blending behaviour, we wouldn't have to implement a
different syntax for specifying colours, but a different mode to
interpolate colour maps (see the `blend_mode` keyword). To add
custom-tailored blend modes for each and every colour model ever
designed would, in my opinion, be unreasonable -- my guess is that most
of those interpolation modes would only be ever used to render scenes
demonstrating that particular colour model.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/19/2016 8:47 PM, clipka wrote:
>my guess is that most
> of those interpolation modes would only be ever used to render scenes
> demonstrating that particular colour model.
>
Yeah, that's probably true.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16-11-19 à 20:47, clipka a écrit :
> Am 20.11.2016 um 01:59 schrieb Mike Horvath:
>> On 11/18/2016 7:47 AM, clipka wrote:
>>> Since they're not used as commonly as sRGB, I doubt we'll add support
>>> via a keyword (not until we do a major overhaul of the parser at any
>>> rate). Note that `colors.inc` does provide various macros to convert to
>>> and from HSL, HSV and L*a*b, and adding support for other colour models
>>> in the same manner should be no big deal.
>>
>> It's hard to blend between different values for H in HSL or HSV unless
>> you sample a lot of steps.
>
> Adding native support for those colour models in the same manner as sRGB
> wouldn't change that: Colours you specify via the "srgb" keyword are
> immediately converted to linear RGB (presuming you're using
> "assumed_gamma 1.0").
>
>
> To change the blending behaviour, we wouldn't have to implement a
> different syntax for specifying colours, but a different mode to
> interpolate colour maps (see the `blend_mode` keyword). To add
> custom-tailored blend modes for each and every colour model ever
> designed would, in my opinion, be unreasonable -- my guess is that most
> of those interpolation modes would only be ever used to render scenes
> demonstrating that particular colour model.
>
It's possible that some of those somewhat obscure colour models are only
used to illustrate that particular colour model.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
