So, I have been working with functions and patterns for a while now, and 
aside from not having vector functions to easily create color values 
with, I have run into an issue with the way POV-Ray maps things - 
colors, pigments, textures.

Since I haven't experimented extensively with these mapping mechanisms 
or gone through the source code to see exactly how they are handled, I 
as far as I know, they only handle values in the range from zero to one.

I'm interested in knowing if anyone has done any work that contradicts 
this notion, or to hear how I might use negative numbers, large numbers, 
or ways to get around the auto-wrapping-around of the color map.  I'd 
like to subtract part of one color channel from the overall result of an 
average {} pigment using a negative value, or saturate the color (to 
white) by allowing large values.

Any data would be helpful.

Thanks!

Post a reply to this message

On 3/21/21 9:56 AM, Bald Eagle wrote:
> So, I have been working with functions and patterns for a while now, and 
> aside from not having vector functions to easily create color values 
> with, I have run into an issue with the way POV-Ray maps things - 
> colors, pigments, textures.
> 
> Since I haven't experimented extensively with these mapping mechanisms 
> or gone through the source code to see exactly how they are handled, I 
> as far as I know, they only handle values in the range from zero to one.
> 
> I'm interested in knowing if anyone has done any work that contradicts 
> this notion, or to hear how I might use negative numbers, large numbers, 
> or ways to get around the auto-wrapping-around of the color map.  I'd 
> like to subtract part of one color channel from the overall result of an 
> average {} pigment using a negative value, or saturate the color (to 
> white) by allowing large values.
> 
> Any data would be helpful.
> 
> Thanks!

The short answer if you are using v3.7 or v3.8 more or less stock, is 
you can use the 0-1 map range only(1).

(1) - And even with this there are some general issues/bugs.

For more information look at the series of postings working backward 
from to the first few starting here:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5fdfc14f%40news.povray.org%3E/

Bill P.

Post a reply to this message

On 3/22/21 7:27 AM, William F Pokorny wrote:

> The short answer if you are using v3.7 or v3.8 more or less stock, is 
> you can use the 0-1 map range only(1).

That's what I thought.
Any chances on future alternate mechanism for color/pattern/texture 
mapping in POV-Ray or povr?

> (1) - And even with this there are some general issues/bugs.

I hadn't known.  :O

> For more information look at the series of postings working backward 
> from to the first few starting here:
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5fdfc14f%40news.povray.org%3E/


No idea what you're directing me to.  But I will make do with 0-1.

Could I fake/simulate a wider range using an attenuated function output 
coupled with a color map ranging from negative color values to color 
values above 1?

Do you know where the "color math" happens in source?   I'm wondering if 
it's as simple as summing the rgb values.
Does <-n, 1, 1> = <0, 1-n, 1-n>?

And how do HDRI ... things ... get encoded?

Post a reply to this message

On 3/23/21 2:06 PM, Bald Eagle wrote:
> On 3/22/21 7:27 AM, William F Pokorny wrote:
> 
>> The short answer if you are using v3.7 or v3.8 more or less stock, is 
>> you can use the 0-1 map range only(1).
> 
> That's what I thought.
> Any chances on future alternate mechanism for color/pattern/texture 
> mapping in POV-Ray or povr?

In my povr branch, extensions, yes.

Therein I've as much been clearing issues as adding function. The core 
map mechanism itself doesn't care what the map range is. It's the wave 
modifier functionality and the "bridge code" between pattern(s) / 
function(s) and the map mechanism which have limits <= v3.8 today. Some 
of these bridge limitations enabling real issues in current patterns to 
go 'mostly' unnoticed.

> 
>> (1) - And even with this there are some general issues/bugs.
> 
> I hadn't known.  :O
> 
>> For more information look at the series of postings working backward 
>> from to the first few starting here:
>>
>>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5fdfc14f%40news.povray.org%3E/

> 
> 
> No idea what you're directing me to.  But I will make do with 0-1.
> 

A collection of posts with my ramblings on some of the issues and 
proposed changes/fixes - raw_wave, function_interval, etc. - which I'm 
giving a go in my povr branch.

Partly, these some answer to your last offline question regarding links 
related to working with functions.

> Could I fake/simulate a wider range using an attenuated function output 
> coupled with a color map ranging from negative color values to color 
> values above 1?
> 

Yep, probably so... We have functions v3.5 on. You 'can' do a lot from 
that point onward working around the 'gotchas'. Whether easy or 
efficient to do is another question - as you know. :-)

> Do you know where the "color math" happens in source?   I'm wondering if 
> it's as simple as summing the rgb values.
> Does <-n, 1, 1> = <0, 1-n, 1-n>?
> 

./source/base/image/colourspace.* ./source/base/colour.* has a lot of 
it. I have no complete list.

> And how do HDRI ... things ... get encoded?
> 

Posted very recently some details on this elsewhere. :-) I only just 
figured this question out myself while otherwise chasing a ghost-bug 
really my own doing...

The hdr format uses rgbe and exr uses half floats (16 bits) making both 
useful ONLY for dynamic range images and light / environment maps.

I've tossed a good chunk of time in the bit bucket trying to use our exr 
implementation as a deep bit per channel format due not really 
understanding POV-Ray's implementations... :-(

Aside:
-------
I've started to look at adding the .pfm/pfm(extended) format (32 bit 
floats per channel) as another image file type in my povr branch.  It's 
supported by quite a few tools (like gimp). It's simple. It's been 
around a long time. However, it's not all that far up on my to-do list 
at the moment due having new inbuilt functions in povr which can do deep 
bit in existing formats using multiple channels.

There, though, I've since found some issues in the ppm/png formats (of 
v3.8) if using other than linear encoding/decoding of those images. 
Still not sorted everything with png and it's the format I'd most want 
to use due the non-lossy compression.

Anyway... Onward! :-)

Bill P.

Post a reply to this message

On 3/24/21 6:20 AM, William F Pokorny wrote:
> On 3/23/21 2:06 PM, Bald Eagle wrote:
>> On 3/22/21 7:27 AM, William F Pokorny wrote:
>>
>>> The short answer if you are using v3.7 or v3.8 more or less stock, is 
>>> you can use the 0-1 map range only(1).
>>
>> That's what I thought.
>> Any chances on future alternate mechanism for color/pattern/texture 
>> mapping in POV-Ray or povr?
> 
> In my povr branch, extensions, yes.
> 
> Therein I've as much been clearing issues as adding function. The core 
> map mechanism itself doesn't care what the map range is. It's the wave 
> modifier functionality and the "bridge code" between pattern(s) / 
> function(s) and the map mechanism which have limits <= v3.8 today. Some 
> of these bridge limitations enabling real issues in current patterns to 
> go 'mostly' unnoticed.

Ah, ok.  That's the part I was missing.  I thought maybe it was a

#if (PointE > 1)
#declare PointE = 0
#end

Sort of thing.

I just did a bunch of function/pattern work, and I think I know what 
you're talking about.  Which patterns have the hidden problems?  Part of 
what I'm doing is discussing how POV-Ray generates and uses its 
patterns, so I could weave that into what I already have, and maybe 
knowing what the underlying problems are, the ole' brain might come up 
with something - - - when I'm _trying_ to sleep.   ;)



> ./source/base/image/colourspace.* ./source/base/colour.* has a lot of 
> it. I have no complete list.


Ah, right.  Thanks for the reminder.

>> And how do HDRI ... things ... get encoded?

Have you looked at .raw?  I know next to nothing about it except that it 
seemed flexible, was used for ultra high-end digital cameras, and you 
can jam a whole lot of information into it besides the image data.

> Anyway... Onward! :-)
> 
> Bill P.


Indeed.   Ever onward.

- and -

If you ever have ramblings on the C / C++ code you're writing, I'd be 
interested in reading that - maybe in the programming section.


Thanks for the info as always

Post a reply to this message

On 3/24/21 6:20 AM, William F Pokorny wrote:

> There, though, I've since found some issues in the ppm/png formats (of 
> v3.8) if using other than linear encoding/decoding of those images. 
> Still not sorted everything with png and it's the format I'd most want 
> to use due the non-lossy compression.
> 
> Anyway... Onward! :-)
> 
> Bill P.

Thought I'd check Warp's site - it's defunct.
archive.org has a snapshot.
He's got a git
https://github.com/WarpRules/WPngImage

Maybe you'd be interested in that library - might hold some clues.

Post a reply to this message

On 3/24/21 8:04 PM, Bald Eagle wrote:
> On 3/24/21 6:20 AM, William F Pokorny wrote:
> 
>> There, though, I've since found some issues in the ppm/png formats (of 
>> v3.8) if using other than linear encoding/decoding of those images. 
>> Still not sorted everything with png and it's the format I'd most want 
>> to use due the non-lossy compression.
>>
>> Anyway... Onward! :-)
>>
>> Bill P.
> 
> Thought I'd check Warp's site - it's defunct.
> archive.org has a snapshot.
> He's got a git
> https://github.com/WarpRules/WPngImage
> 
> Maybe you'd be interested in that library - might hold some clues.

Thanks for the pointer. I wasn't aware of his work there.

On .raw support not looked much at it because it isn't that deep per 
channel bit wise at 12-14 bits usually(1), but might still be useful to 
support I guess.

(1) - Not that experienced with .raw myself, but the high dynamic range 
is often achieved with bracketed exposures I believe. Been away from the 
details of digital cameras for a while though.

With Warp's library though I wonder, if we are looking to make larger 
image io / color support changes, whether POV-Ray shouldn't be looking 
at all the work under the https://www.aswf.io/# umbrella.

I believe Blender not that long ago moved to those libraries for much 
(all?) of their image and color space support. We might for example get 
icc png profile support for 'free' - so to speak - using it, where 
POV-Ray doesn't support such things today.

If just 32 bit floats / channel max as I expect, it might still be 
limited for some of the function related stuff we've been playing with. 
In other words, even with it we might want a little more.

There is too netpbm's .pam format - a form of which can be used almost 
directly for df3 files.

:-) All sorts of stuff possible.

Bill P.

Post a reply to this message