POV-Ray : Newsgroups : povray.binaries.scene-files : Reinterpreting colors.inc colors as sRGB Server Time: 18 Jun 2019 05:21:54 GMT
  Reinterpreting colors.inc colors as sRGB (Message 1 to 5 of 5)  
From: Cousin Ricky
Subject: Reinterpreting colors.inc colors as sRGB
Date: 7 May 2016 21:12:27
Message: <572e5a3b$1@news.povray.org>
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)

From: Thomas de Groot
Subject: Re: Reinterpreting colors.inc colors as sRGB
Date: 8 May 2016 07:24:14
Message: <572ee99e$1@news.povray.org>
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

From: Kenneth
Subject: Re: Reinterpreting colors.inc colors as sRGB
Date: 9 May 2016 11:10:00
Message: <web.57306f5d4aeaea2333c457550@news.povray.org>
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

From: Alain
Subject: Re: Reinterpreting colors.inc colors as sRGB
Date: 9 May 2016 15:25:59
Message: <5730ac07@news.povray.org>
Le 16-05-09 07:07, Kenneth a écrit :
> 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

From: Cousin Ricky
Subject: Re: Reinterpreting colors.inc colors as sRGB
Date: 9 May 2016 16:30:00
Message: <web.5730ba364aeaea239fa916e90@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> 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

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.