 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 17-5-2021 om 00:00 schreef Bald Eagle:
> For your consideration:
>
> #macro Convert (Csc, SatBoost, BrightBoost, Color)
> #switch (Csc)
> #case (1)
> #local MyColour = srgb Color;
> #break
> #case (2)
> #local sRGB_Gamma = function(C) {select(C-0.0031308, C*12.92, 1.055*pow(C,
> 1/2.4)-0.055)}
>
> #local SB = SatBoost; // Saturation boost
> #local VB = BrightBoost; // Brightness ("volume") boost
> #local RawColour = srgb <sRGB_Gamma(Color.red), sRGB_Gamma(Color.green),
> sRGB_Gamma(Color.blue)>;
> #local SatColour = RawColour-SB;
> #local MyColour = SatColour*(1+VB)*RawColour.gray/SatColour.gray;
> #break
> #else
> #local MyColour = Color;
> #end
>
> MyColour
>
> #end
>
Yes. Smart indeed.
> #declare CSC = 1;
>
> #local CM = array {
> <0.00, not_0, not_0, not_0>,
> <0.25, 0.059, 0.059, 0.059>,
>
> <0.25, 0.086, 0.027, 0.059>,
> <0.35, 0.086, 0.027, 0.059>,
>
> <0.35, 0.118, 0.118, 0.078>,
> <0.45, 0.118, 0.118, 0.078>,
>
> <0.45, 0.200, 0.137, 0.110>,
> <0.50, 0.150, 0.087, 0.060>,
> <0.57, 0.200, 0.137, 0.110>,
>
> <0.57, 0.400, 0.337, 0.310>,
> <0.60, 0.350, 0.287, 0.260>,
> <0.63, 0.400, 0.337, 0.310>,
>
> <0.63, 0.769, 0.329, 0.298>,
> <0.70, 0.669, 0.229, 0.198>,
> <0.75, 0.769, 0.329, 0.298>,
>
> <0.75, 0.600, 0.600, 0.600>,
> <0.85, 0.550, 0.550, 0.550>,
> <1.00, 0.650, 0.650, 0.650>
> }
>
You make an error here I believe. The first expression is /not/ the
x-value but the *color_map entry*! And so the last one is /not/ a filter
value. Below, this gets wrong as a consequence:
> #local C_gr21_DakotaRed_map1 = //the granite colour_map proper
> color_map {
> #if (version >= 3.8)
> blend_mode 2
> #end
> #local Entries = dimension_size (CM, 1)-1;
> #for (E, 0, Entries)
> [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
This line is confusing. How would you write the line above? Like this?
(? used for unknown expression):
[CM[E].? rgb <CM[E].x, CM[E].y, CM[E].z>]
> #end
> }
>
Also, in the above example with CSC=1 ('raw' srgb option) should 'rgb'
not be 'srgb'? I am getting ab bit lost here.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> You make an error here I believe. The first expression is /not/ the
> x-value but the *color_map entry*! And so the last one is /not/ a filter
> value. Below, this gets wrong as a consequence:
Nope.
I converted the entire color map into an array of /4-component/ vectors, with
the color map entry as the first number. And, as I anticipated, this might be
confusing. Maybe this should be rearranged to have the color map entry be the
filter, or (better?) constructed as a 2D array?
It was just a quick example of how to not write out the whole color map twice,
and make any changes easier.
>
> > #local C_gr21_DakotaRed_map1 = //the granite colour_map proper
> > color_map {
> > #if (version >= 3.8)
> > blend_mode 2
> > #end
> > #local Entries = dimension_size (CM, 1)-1;
> > #for (E, 0, Entries)
> > [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
> This line is confusing. How would you write the line above? Like this?
> (? used for unknown expression):
> [CM[E].? rgb <CM[E].x, CM[E].y, CM[E].z>]
>
> > #end
> > }
> >
>
> Also, in the above example with CSC=1 ('raw' srgb option) should 'rgb'
> not be 'srgb'? I am getting ab bit lost here.
That line above is wrong, but for a different reason.
It's SUPPOSED to be:
[CM[E].x Convert (CSC, SatBoost, BrightBoost, <CM[E].y, CM[E].z,
CM[E].filter>)]
That way the one macro gets used for every CSC, and the rgb / srgb / function
gets implemented in the macro, not directly in the color map.
I got distracted and made an oopsie.
See if anything special needs to be done in the full macro so that the srgb
option works even though SatBoost, BrightBoost are not explicitly specified - in
other words, an unused default placeholder value just gets passed into the
macro.
Attaching file so it's all (hopefully) clearer.
Post a reply to this message
Attachments:
Download 'smallcolormap.pov.txt' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 17/05/2021 om 19:42 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> You make an error here I believe. The first expression is /not/ the
>> x-value but the *color_map entry*! And so the last one is /not/ a filter
>> value. Below, this gets wrong as a consequence:
>
> Nope.
> I converted the entire color map into an array of /4-component/ vectors, with
> the color map entry as the first number. And, as I anticipated, this might be
> confusing. Maybe this should be rearranged to have the color map entry be the
> filter, or (better?) constructed as a 2D array?
I need to plunge more seriously into arrays, but yes, I believe a 2D
array would be better in this context. I shall have a look and try to
work out something by myself (good practice!). First to cool smoking
brain cells... :-)
> It was just a quick example of how to not write out the whole color map twice,
> and make any changes easier.
>
>>
>>> #local C_gr21_DakotaRed_map1 = //the granite colour_map proper
>>> color_map {
>>> #if (version >= 3.8)
>>> blend_mode 2
>>> #end
>>> #local Entries = dimension_size (CM, 1)-1;
>>> #for (E, 0, Entries)
>>> [CM[E].x rgb <CM[E].y, CM[E].z, CM[E].filter>]
>> This line is confusing. How would you write the line above? Like this?
>> (? used for unknown expression):
>> [CM[E].? rgb <CM[E].x, CM[E].y, CM[E].z>]
>>
>>> #end
>>> }
>>>
>>
>> Also, in the above example with CSC=1 ('raw' srgb option) should 'rgb'
>> not be 'srgb'? I am getting ab bit lost here.
>
> That line above is wrong, but for a different reason.
> It's SUPPOSED to be:
> [CM[E].x Convert (CSC, SatBoost, BrightBoost, <CM[E].y, CM[E].z,
> CM[E].filter>)]
>
> That way the one macro gets used for every CSC, and the rgb / srgb / function
> gets implemented in the macro, not directly in the color map.
> I got distracted and made an oopsie.
>
> See if anything special needs to be done in the full macro so that the srgb
> option works even though SatBoost, BrightBoost are not explicitly specified - in
> other words, an unused default placeholder value just gets passed into the
> macro.
>
> Attaching file so it's all (hopefully) clearer.
>
Ok. Going to wrap that up somehow. Thanks for this. I have done very
little in the way of arrays in the past, so this is a good opportunity
to get better acquainted.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 17/05/2021 om 12:40 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>>> I'm thinking that my suggestion for
>>> #local not_0 = 1/256;
>>> was close, but that would not give a pure black. Maybe 1/257 to give a pure
>>> black monitor color but still not 0;
>>>
>> I think it is a trivial difference. As Alain said, no real black in
>> nature, and the black pigments here represent micas, which are far from
>> pitch black anyway.
>
> I suppose it is .. trivial ... but my thought was as a general point, we should
> provide the users with the fullest range of colors as possible, realistic or
> not, so that we don't code another 20 scenes that 20 years from now people with
> throw up their hands and cry "Why did they DO *this*???"
>
> So I was thinking it would allow the representation of the purest black
> possible, but still not be zero. What color is a dark hole or a lightless room?
> There may also be scenes later on where people are rendering heightfields, etc,
> and want a pixel rgb that numerically is integer 0.
>
> Nothing really to do with the present granite, just thinking ahead.
> That's all.
>
I think there are two tracks here to consider: (1) the use of 'pitch
black' in pigments and textures, where the use of 1/256 or 1/257 would
be the way to go; (2) the use of <0,0,0> in a 'geometrical' construction
like a height_field or, I suppose, an isosurface or a parametric object
or whatever, where 'true' zero would be a must. this should be clear
from the onset in any scene. Height_fields in particular certainly make
good use of 'true' zero. Approximations should be reserved for
pigments/textures.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Thomas de Groot <tho### [at] degrootorg> wrote:
> ... I have done very
> little in the way of arrays in the past, so this is a good opportunity
> to get better acquainted.
an array of 'array mixed' will allow to keep "sets" of parameters together.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> I think there are two tracks here to consider: (1) the use of 'pitch
> black' in pigments and textures, where the use of 1/256 or 1/257 would
> be the way to go; (2) the use of <0,0,0> in a 'geometrical' construction
> like a height_field or, I suppose, an isosurface or a parametric object
> or whatever, where 'true' zero would be a must. this should be clear
> from the onset in any scene. Height_fields in particular certainly make
> good use of 'true' zero. Approximations should be reserved for
> pigments/textures.
If I may offer a humble opinion/observation, using a value of 1/256 for the
purpose of multiplying the brightness of an object does not make sense (to me,
anyway) for this reason: Assuming the base scene is lit such that a fully-lit
part of an object will have the same approximate output RGB value as the
corresponding RGB value of the input pigment, a value of 1/256 will result in a
pixel value of 0. In my opinion, that should be considered the true base value.
What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
foresee what value is actually going to be desired.
Also, even the best monitors don't display pure black anyway. Maybe future
technological developments will change that...
Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 18-5-2021 om 12:52 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I think there are two tracks here to consider: (1) the use of 'pitch
>> black' in pigments and textures, where the use of 1/256 or 1/257 would
>> be the way to go; (2) the use of <0,0,0> in a 'geometrical' construction
>> like a height_field or, I suppose, an isosurface or a parametric object
>> or whatever, where 'true' zero would be a must. this should be clear
>> from the onset in any scene. Height_fields in particular certainly make
>> good use of 'true' zero. Approximations should be reserved for
>> pigments/textures.
>
> If I may offer a humble opinion/observation, using a value of 1/256 for the
> purpose of multiplying the brightness of an object does not make sense (to me,
> anyway) for this reason: Assuming the base scene is lit such that a fully-lit
> part of an object will have the same approximate output RGB value as the
> corresponding RGB value of the input pigment, a value of 1/256 will result in a
> pixel value of 0. In my opinion, that should be considered the true base value.
> What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
> foresee what value is actually going to be desired.
>
> Also, even the best monitors don't display pure black anyway. Maybe future
> technological developments will change that...
>
> Kind regards,
> Dave Blandston
> Suggested motto: "With POV-Ray anything is possible, but nothing is easy"
>
Well, personally I am no expert on the question, and I prefer to let
others answer/discuss this point. Who's next? :-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Blandston" <IsN### [at] protonmailch> wrote:
> If I may offer a humble opinion/observation, using a value of 1/256 for the
> purpose of multiplying the brightness of an object does not make sense (to me,
> anyway) for this reason: Assuming the base scene is lit such that a fully-lit
> part of an object will have the same approximate output RGB value as the
> corresponding RGB value of the input pigment, a value of 1/256 will result in a
> pixel value of 0. In my opinion, that should be considered the true base value.
> What is the alternative? 1/256 is arbitrary. Why not 1/317? It's not possible to
> foresee what value is actually going to be desired.
>
> Also, even the best monitors don't display pure black anyway. Maybe future
> technological developments will change that...
http://news.povray.org/web.607425886a35d6561f9dae3025979125%40news.povray.org
So, the idea here is that we have some "pigment" color value that defines the
visible color.
If it were considered in a vacuum, where everything would be static, and you'd
be directly mapping that value onto the monitor, then all would be fine.
The complication comes in when other things begin to happen in the scene, and
you wonder why your scene looks weird / not good / off.
And that's where the not_0 thing comes into play. We want to define a non-zero
color component for each of the channels. If I focus the rays of the sun onto a
black object with a big parabolic mirror or magnifying glass, then there needs
to be - from a computational standpoint, some way of calculating what the
resulting object would look like under those conditions. And that is usually a
result of multiplying the object pigment by the light source. If I define
reflection, metallic, or shine a red light on something, then a zero r channel
value would give a 0 * whatever result. Zero. And that's not going to give
you "the expected" visual result. The same thing happens with radiosity. I
might have a "blue" wall, but when white light reflected off of red and green
objects hit the wall, they affect the perceived color of the wall - and so you
need a non-zero value for the r and g color channels. There needs to be
_something_ there to get multiplied, and I just figured that a value _just_
below the perceptible / representable threshold value would be a good place to
start.
You are correct, that it IS arbitrary, however it is a value that has a basis /
reason as the current starting point. I just wanted to make sure it was
actually below the threshold and not above it.
Inigo Quilex worked for Pixar, so I'm making the grounded presumption that he
learned a lot of good professional tricks / best practices.
https://www.youtube.com/channel/UCdmAhiG8HQDlz8uyekw4ENw
And Martijn Steinrucken also seems to really know his way around the inner
workings of colors, lighting, and reflections.
https://www.youtube.com/c/TheArtofCodeIsCool/videos
So if you have a few hours, they both mention this point in their videos
multiple times, and might possibly do a quick few lines of throwaway code that
they execute to demonstrate the concept. Somewhere.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> So if you have a few hours, they both mention this point in their videos
> multiple times, and might possibly do a quick few lines of throwaway code that
> they execute to demonstrate the concept. Somewhere.
OK I'm a believer in "Not_0" now (even without spending hours researching).
One other consideration (not a suggestion, just a thought) might be to allow a
margin of error since a value of 1/256 seems to indicate that the intended
result is a value of 0 barring any of the conditions you mentioned. So if the
lighting is even the slightest bit too bright then an unintentional "1" could
result. So perhaps a default value with a little "wiggle room" might be
appropriate, like 1/265 since it's an arbitrary starting point anyway.
Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 19/05/2021 om 09:44 schreef Dave Blandston:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> So if you have a few hours, they both mention this point in their videos
>> multiple times, and might possibly do a quick few lines of throwaway code that
>> they execute to demonstrate the concept. Somewhere.
>
> OK I'm a believer in "Not_0" now (even without spending hours researching).
>
:-)
> One other consideration (not a suggestion, just a thought) might be to allow a
> margin of error since a value of 1/256 seems to indicate that the intended
> result is a value of 0 barring any of the conditions you mentioned. So if the
> lighting is even the slightest bit too bright then an unintentional "1" could
> result. So perhaps a default value with a little "wiggle room" might be
> appropriate, like 1/265 since it's an arbitrary starting point anyway.
>
Seems a good idea. Done for next beta.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
