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