![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
If you have been avoiding assumed_gamma 1.0 because it causes the named
colors in colors.inc to look wrong, the attached file remedies this.
File colors_srgb.inc redefines these colors, reinterpreting them as
sRGB. They render to the appearance they had in pre-3.7 scenes that
omitted assumed_gamma, and probably as the author of colors.inc intended.
The excuses fall.
Some additional international spellings are also defined.
Note that, although colors_srgb.inc redeclares some identifiers in
colors.inc, it is intended only to complement colors.inc, not replace it.
If the development team would like to include this in the official
POV-Ray release, you have my blessing.
Post a reply to this message
Attachments:
Download 'colors_srgb.inc.zip' (2 KB)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7-5-2016 23:12, Cousin Ricky wrote:
> If you have been avoiding assumed_gamma 1.0 because it causes the named
> colors in colors.inc to look wrong, the attached file remedies this.
> File colors_srgb.inc redefines these colors, reinterpreting them as
> sRGB. They render to the appearance they had in pre-3.7 scenes that
> omitted assumed_gamma, and probably as the author of colors.inc intended.
>
> The excuses fall.
>
Thank you indeed! Much appreciated.
--
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I second Thomas's comment. Thanks, this looks very useful.
I'm curious about something though. In 3.7.0's "colors.inc" file, there are some
macros for converting between RGB, HSL and HSV, and vice-versa. I've never used
those, but I thought I would take a look at them anyway. Most of the macros seem
OK to use, even in an srgbt world. But one macro looks suspicious ;-) ...
// Converts a color in RGB color space to a color in HSL color space.
// Input: < Red, Green, Blue, Filter, Transmit >
// Output: < Hue, Saturation, Lightness, Filter, Transmit >
#macro CRGB2HSL(Color)
......
#end
Would the equations there still be correct when giving the macro an srgb color?
For example, let's say I'm rendering a scene with srgb <.3,.5,.7> as an
*on-screen* color (a 'gamma-bent' color, although I realize that the rgb colors
themselves are actually 'linear' colors.) Feeding those linear rgb colors to the
macro would result (by my thinking) in an HSL color that wouldn't quite match
what I was seeing on-screen. (Assume that I'm running v3.7xx with the proper
assumed_gamma 1.0).
At least, that's how it seems to me, although I could be wrong.
Does that macro need updating for your "colors_srgb.inc" file?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> I second Thomas's comment. Thanks, this looks very useful.
>
> I'm curious about something though. In 3.7.0's "colors.inc" file, there are some
> macros for converting between RGB, HSL and HSV, and vice-versa. I've never used
> those, but I thought I would take a look at them anyway. Most of the macros seem
> OK to use, even in an srgbt world. But one macro looks suspicious ;-) ...
>
> // Converts a color in RGB color space to a color in HSL color space.
> // Input: < Red, Green, Blue, Filter, Transmit >
> // Output: < Hue, Saturation, Lightness, Filter, Transmit >
> #macro CRGB2HSL(Color)
> ......
> #end
>
> Would the equations there still be correct when giving the macro an srgb color?
> For example, let's say I'm rendering a scene with srgb <.3,.5,.7> as an
> *on-screen* color (a 'gamma-bent' color, although I realize that the rgb colors
> themselves are actually 'linear' colors.) Feeding those linear rgb colors to the
> macro would result (by my thinking) in an HSL color that wouldn't quite match
> what I was seeing on-screen. (Assume that I'm running v3.7xx with the proper
> assumed_gamma 1.0).
>
> At least, that's how it seems to me, although I could be wrong.
>
> Does that macro need updating for your "colors_srgb.inc" file?
>
>
>
When you define a colour as srgb, it's converted to rgb space at parse time.
So, if you feed that macro a colour as srgb, you are realy feeding it
the srgb colour converted to rgb.
Alain
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Kenneth" <kdw### [at] gmail com> wrote:
> Would the equations there still be correct when giving the macro an srgb color?
> For example, let's say I'm rendering a scene with srgb <.3,.5,.7> as an
> *on-screen* color (a 'gamma-bent' color, although I realize that the rgb colors
> themselves are actually 'linear' colors.) Feeding those linear rgb colors to the
> macro would result (by my thinking) in an HSL color that wouldn't quite match
> what I was seeing on-screen. (Assume that I'm running v3.7xx with the proper
> assumed_gamma 1.0).
>
> At least, that's how it seems to me, although I could be wrong.
>
> Does that macro need updating for your "colors_srgb.inc" file?
I haven't figured out the best way to proceed on this. However, it's clear to
me that if these macros (which include HSV conversions as well) are rewritten,
they should be given new names, and not replace the existing macros.
This seems more of an issue for colors from 3rd party color pickers, anyway, and
not so much relevant to POV-Ray declared colors.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |