Am 19.10.2016 um 14:09 schrieb William F Pokorny:
> On 10/19/2016 07:16 AM, Thomas de Groot wrote:
>> On 18-10-2016 18:29, William F Pokorny wrote:
>>> [snip]
>>> There is a base image_map texture on a plane. Over the top of that
>>> texture is another with 5 columns of 4 colors (0,0.5,1.0,2.0) where the
>>> 5 columns have transmit values of: 0,0.5,1.0,1.5,2.0. One parallel light
>>> source, camera orthographic, ambient 0, diffuse 1.0.
>>>
>>
>> Out of curiosity: what is a transmit value >1.0?
>>
> People use >1 sometimes to amplify colors or increase contrast.
> 
> I think Norbert used this technique for one of his recent,
> http://www.tc-rtc.co.uk/, metal monster images.
> 
> It isn't the most stable technique as can be seen in the right part of
> the posted images. I'd say use values in the 0 to 1 range as a rule.
> 
> Aside: I have a question rattling around in my head as to why the higher
> values tend toward black.

Because transmit not only controls the brightness of the background that
peeps through, but also of the texture itself. The higher the transmit,
the lower the percentage of the texture itself that gets mixed in -- to
the point where a /negative/ percentage is mixed in.

At the same time, more and more background is mixed in, but if it's
darker than the foreground it can't compensate the loss.

Post a reply to this message

On 19-10-2016 14:09, William F Pokorny wrote:
> On 10/19/2016 07:16 AM, Thomas de Groot wrote:
>> On 18-10-2016 18:29, William F Pokorny wrote:
>>> [snip]
>>> There is a base image_map texture on a plane. Over the top of that
>>> texture is another with 5 columns of 4 colors (0,0.5,1.0,2.0) where the
>>> 5 columns have transmit values of: 0,0.5,1.0,1.5,2.0. One parallel light
>>> source, camera orthographic, ambient 0, diffuse 1.0.
>>>
>>
>> Out of curiosity: what is a transmit value >1.0?
>>
> People use >1 sometimes to amplify colors or increase contrast.
>
> I think Norbert used this technique for one of his recent,
> http://www.tc-rtc.co.uk/, metal monster images.
>
> It isn't the most stable technique as can be seen in the right part of
> the posted images. I'd say use values in the 0 to 1 range as a rule.
>
[snip]

Thanks indeed. This is an unknown effect of /transmit/ to me, in 
contrast to /filter/. Going beyond complete transparency (t=1) is not 
very intuitive :-)

I suppose that most users are unaware of this and possibly it should be 
mentioned in the docs.

-- 
Thomas

Post a reply to this message

Am 20.10.2016 um 08:58 schrieb Thomas de Groot:
> On 19-10-2016 14:09, William F Pokorny wrote:
>> On 10/19/2016 07:16 AM, Thomas de Groot wrote:
>>> On 18-10-2016 18:29, William F Pokorny wrote:
>>>> [snip]
>>>> There is a base image_map texture on a plane. Over the top of that
>>>> texture is another with 5 columns of 4 colors (0,0.5,1.0,2.0) where the
>>>> 5 columns have transmit values of: 0,0.5,1.0,1.5,2.0. One parallel
>>>> light
>>>> source, camera orthographic, ambient 0, diffuse 1.0.
>>>>
>>>
>>> Out of curiosity: what is a transmit value >1.0?
>>>
>> People use >1 sometimes to amplify colors or increase contrast.
>>
>> I think Norbert used this technique for one of his recent,
>> http://www.tc-rtc.co.uk/, metal monster images.
>>
>> It isn't the most stable technique as can be seen in the right part of
>> the posted images. I'd say use values in the 0 to 1 range as a rule.
>>
> [snip]
> 
> Thanks indeed. This is an unknown effect of /transmit/ to me, in
> contrast to /filter/. Going beyond complete transparency (t=1) is not
> very intuitive :-)
> 
> I suppose that most users are unaware of this and possibly it should be
> mentioned in the docs.

What -- that transmit+filter>1 can be used for effect? Or that the
effect is non-intuitive?

Post a reply to this message

On 20-10-2016 9:32, clipka wrote:
> Am 20.10.2016 um 08:58 schrieb Thomas de Groot:
>> On 19-10-2016 14:09, William F Pokorny wrote:
>>> On 10/19/2016 07:16 AM, Thomas de Groot wrote:
>>>> On 18-10-2016 18:29, William F Pokorny wrote:
>>>>> [snip]
>>>>> There is a base image_map texture on a plane. Over the top of that
>>>>> texture is another with 5 columns of 4 colors (0,0.5,1.0,2.0) where the
>>>>> 5 columns have transmit values of: 0,0.5,1.0,1.5,2.0. One parallel
>>>>> light
>>>>> source, camera orthographic, ambient 0, diffuse 1.0.
>>>>>
>>>>
>>>> Out of curiosity: what is a transmit value >1.0?
>>>>
>>> People use >1 sometimes to amplify colors or increase contrast.
>>>
>>> I think Norbert used this technique for one of his recent,
>>> http://www.tc-rtc.co.uk/, metal monster images.
>>>
>>> It isn't the most stable technique as can be seen in the right part of
>>> the posted images. I'd say use values in the 0 to 1 range as a rule.
>>>
>> [snip]
>>
>> Thanks indeed. This is an unknown effect of /transmit/ to me, in
>> contrast to /filter/. Going beyond complete transparency (t=1) is not
>> very intuitive :-)
>>
>> I suppose that most users are unaware of this and possibly it should be
>> mentioned in the docs.
>
> What -- that transmit+filter>1 can be used for effect? Or that the
> effect is non-intuitive?
>

transmit+filter, yes, I understand that; but transmit >1? for me that is 
non-intuitive. I cannot conceive something /more/ transparent than 
complete transparency ;-)

-- 
Thomas

Post a reply to this message

On 10/19/2016 01:29 PM, clipka wrote:
> Am 19.10.2016 um 12:20 schrieb William F Pokorny:
>
>>>
>>> What do you mean by "probabilistic pixel based transmit mode"?
>>>
>> I have in mind some sort of sampling between textures weighted by the
>> transmit values involved. Suppose somewhat like the blending which
>> happened in the tilt shift image I posted recently. I admit though, I'm
>> thinking aloud.
>
> You mean, something like using the "average" pseudo-pattern to textures,
> but with the weight being modulated by the textures' "transmit" channel?
For the base mechanism, yes, this is a good description. On top of which 
I was thinking an element of randomness - that probability element - to 
add some noise in the blend of textures.
>
> While that sounds interesting, a major drawback would be that the
> "transmit" channel couldn't be used for its original purpose, namely
> specifying transparency of the texture.
>
Agree any such a mechanism would have to leave the the current transmit 
channel behavior as is. Pretty sure the noise part of it would also not 
work well with standard AA - larger images scaled down being the AA 
approach instead.

I've been able to play with some elements of the idea using functions 
and the wave modifiers, but it hasn't coalesced into a standard 
technique for me.

Post a reply to this message

On 10/19/2016 11:15 AM, scott wrote:
>> With the recent discussions related to gamma handling I thought I'd post
>> an image comparing how transmit behaves with respect to assumed_gamma in
>> a texture overlaid upon an image base texture. The behavior of transmit
>> at an assumed_gamma (ag) of 1.0 is something I like less well than its
>> behavior at an ag of 2.2.
>
> Is the problem here though is that you're trying to solve this by
> tweaking gamma? Maybe it works for this issue, but it's also going to
> affect all the other lighting and colours in your scene.
>
> The better approach would be to figure out how to achieve what you want
> without changing the scene-wide gamma setting. What if you adjust the
> gamma of the image and the "gamma" of your rgbt values (ie don't step in
> equal steps for each column)? You might have to sit down and work out
> the maths to get what you want without changing assumed_gamma.
>
Indeed, you can make adjustments to colors and transmit instead to 
mostly get there in the 1.0 space. Inserting additional transmit entries 
in the map often helps - sort of a piecewise, linear curve approach.

To be clear, I'm not tweaking assumed_gamma for effect. I use an ag of 
1.0 for all my work.

That said, I've spent a fair bit of time working through Norbert's 
material collection - mapping them to my own ag 1.0 versions and 
variants. I've been doing it as a way to learn from other's texturing 
work as much as anything. In my own work, I've hit upon occasions where 
I want a less linear and tighter blend between textures. The 2.2 space 
offers some of this - I suspect by side effect as much as intent.

With my post I was trying to document a texture layering difference 
between the gamma spaces I think real. One that can be a speed bump of 
sorts - especially when converting ag 2.2 developed overlapping textures 
to an ag of 1.0 working space.

Bill P.

Post a reply to this message

Am 20.10.2016 um 16:28 schrieb William F Pokorny:

> That said, I've spent a fair bit of time working through Norbert's
> material collection - mapping them to my own ag 1.0 versions and
> variants. I've been doing it as a way to learn from other's texturing
> work as much as anything. In my own work, I've hit upon occasions where
> I want a less linear and tighter blend between textures. The 2.2 space
> offers some of this - I suspect by side effect as much as intent.

Maybe we can introduce a new "blend_gamma" parameter to textures, that
governs how the texture blends with the layer beneath it?

Post a reply to this message

On 10/20/2016 12:27 PM, clipka wrote:
> Am 20.10.2016 um 16:28 schrieb William F Pokorny:
>
>> That said, I've spent a fair bit of time working through Norbert's
>> material collection - mapping them to my own ag 1.0 versions and
>> variants. I've been doing it as a way to learn from other's texturing
>> work as much as anything. In my own work, I've hit upon occasions where
>> I want a less linear and tighter blend between textures. The 2.2 space
>> offers some of this - I suspect by side effect as much as intent.
>
> Maybe we can introduce a new "blend_gamma" parameter to textures, that
> governs how the texture blends with the layer beneath it?
>
The idea strikes me as a good one.

Suppose the devil is in the details of implementation and actual use. 
Are you thinking initially of:

effective_transmit=pow(T,new_blend_gamma_parm) for each texture with a 
blend_gamma parameter?

Something this direct would address much of what I believe I'd like.

If we are going to add such a new control, perhaps the mechanism should 
be set up more flexibly than a parameter to a built in function - could 
be as much as complete control of the blend by function I guess.

I'm a fan of flexibility, but it's of course not free in terms of 
implementation, ease of use and support.

Bill P.

Post a reply to this message

Am 21.10.2016 um 15:39 schrieb William F Pokorny:
> On 10/20/2016 12:27 PM, clipka wrote:
>> Am 20.10.2016 um 16:28 schrieb William F Pokorny:
>>
>>> That said, I've spent a fair bit of time working through Norbert's
>>> material collection - mapping them to my own ag 1.0 versions and
>>> variants. I've been doing it as a way to learn from other's texturing
>>> work as much as anything. In my own work, I've hit upon occasions where
>>> I want a less linear and tighter blend between textures. The 2.2 space
>>> offers some of this - I suspect by side effect as much as intent.
>>
>> Maybe we can introduce a new "blend_gamma" parameter to textures, that
>> governs how the texture blends with the layer beneath it?
>>
> The idea strikes me as a good one.
> 
> Suppose the devil is in the details of implementation and actual use.
> Are you thinking initially of:
> 
> effective_transmit=pow(T,new_blend_gamma_parm) for each texture with a
> blend_gamma parameter?

Pretty much precisely that.

Though, thinking about it, for texture stacks that have semi-transparent
portions this raises the question whether the blending of the lowest
texture in the stack and the background should also be affected.

If that is the case, then all we'd really need to do to achieve that
effect would be to use a pigment that already has the desired effective
transmit value.

For pigments with constant transmit value that would mean simply
adapting the transmit component.

For pigments with non-constant transmit, presumably using a colour_map
or pigment_map, we could just extend the existing blend_mode /
blend_gamma mechanism, for example by introducing additional modes that
also cover the transmit and filter components of the pigment.

> Something this direct would address much of what I believe I'd like.
> 
> If we are going to add such a new control, perhaps the mechanism should
> be set up more flexibly than a parameter to a built in function - could
> be as much as complete control of the blend by function I guess.

If POV-Ray had a multi-channel function feature (which is something on
my todo list but still far from implemented), my suggestion would be to
simply provide some blend_function feature as an alternative for the
blend_mode / blend_gamma, that would take a function with eleven
parameters (the 2x5 channels of the pigment colours to be blended, and
the weight of the first colour) and return five result values (the 5
channels of the resulting pigment colour).

But until then, I am reluctant to implement any function-based solution
to the problem, as that would pose the risk of getting in the way of the
solution I would really want to implement.

Post a reply to this message

I hope no one forgets about the alpha channel. although I don't know if that's a
factor in what you're talking about with gamma adjustments, just thought I would
mention it.

Post a reply to this message