CSOP, inverted through a magic trick...

Post a reply to this message

Attachments:
Download 'test.png' (98 KB)

Preview of image 'test.png'

Am 08.04.2016 um 19:43 schrieb clipka:
> CSOP, inverted through a magic trick...

Same magic, different effect.

Post a reply to this message

Attachments:
Download 'test.png' (145 KB)

Preview of image 'test.png'

On 08.04.2016 19:43, clipka wrote:

> CSOP, inverted through a magic trick...

negative strength of light source?

Post a reply to this message

Am 08.04.2016 um 21:47 schrieb Christian Froeschlin:
> On 08.04.2016 19:43, clipka wrote:
> 
>> CSOP, inverted through a magic trick...
> 
> negative strength of light source?

Better than that: A new feature under development.

Anyone want to take a guess?

I give you a hint: My primary motivation for implementing this feature
is to once and for all put an end to the misuse of assumed_gamma; once
this feature is released, there won't be any more excuses.

Got an idea already?

Here's another hint: While I'm implementing the feature from scratch, it
will be similar in function to a patch developed by a namesake of mine a
decade ago. (My implementation will be a bit more limited in one way
though, while providing more flexibility in another way.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Anyone want to take a guess?

Um, it looks like some sort of film exposure feature, with solarization
occurring at the bright spot on the sphere.

It's been WAY too long since I've dabbled with real photography and played with
film gamma, artistic effects, and alternative photographic processes...

Hot or cold?  :)

Post a reply to this message

Am 09.04.2016 um 01:03 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> Anyone want to take a guess?
> 
> Um, it looks like some sort of film exposure feature, with solarization
> occurring at the bright spot on the sphere.
> 
> It's been WAY too long since I've dabbled with real photography and played with
> film gamma, artistic effects, and alternative photographic processes...
> 
> Hot or cold?  :)

Burnt your skin on a tip of the feature, but caught frostbite on the
specifics of the sample image. And you didn't get hold of everything yet.

Fact is, the image is an exact negative of one of the insert menu samples.

But I think you got close enough: It is indeed a generic tonemapping
feature.

The predecessor is, of course, Christoph Hormann's tonemapping
implementation in MegaPOV.

What this new incarnation will lack is the post-aliasing part of the
feature. All tonemapping will be done before aliasing, for various reasons.

What this new incarnation will add is the ability to apply different
tonemapping functions to each colour channel, perform cross-channel
colour maths, and as an extra bonus even use functions that depend on
the screen location.

(As for the post-aliasing part, that will be covered by a generic
post-processing feature /some/ day in the future.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Fact is, the image is an exact negative of one of the insert menu samples.

Tone reversed and color reversed, just like a typical color negative (without
the orange color mask).  I guess "it's [just] a negative" seemed too simple an
answer.


> What this new incarnation will add is the ability to apply different
> tonemapping functions to each colour channel, perform cross-channel
> colour maths, and as an extra bonus even use functions that depend on
> the screen location.

So, this would be analogous to various image processing features and "filters"
that a lot of graphics programs have?
I find the screen location feature interesting, and am wondering how that will
function, and what inspired its development.

I would imagine that various functions could be used to adjust brightness and
colour using gradients, concentric-type adjustment such as the cos^4 brightness
dropoff typically seen in camera lenses, etc.
I guess you could also use one image to map/adjust tones onto/in another kind of
like a pigment/texture/image map.

Sounds like a very cool project indeed, with lots of potential!

Post a reply to this message

Am 09.04.2016 um 22:32 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:

>> What this new incarnation will add is the ability to apply different
>> tonemapping functions to each colour channel, perform cross-channel
>> colour maths, and as an extra bonus even use functions that depend on
>> the screen location.
> 
> So, this would be analogous to various image processing features and "filters"
> that a lot of graphics programs have?
> I find the screen location feature interesting, and am wondering how that will
> function, and what inspired its development.

"Because we can".

Actually the chain of thought was something like this:

(1) "To really wrap up the topic I want to provide the user with a means
to effect gamma adjustment for purely artistic purposes, so that they'll
never again have to misuse any of the gamma handling stuff intended for
purely technical purposes. Some global 'artistic_gamma' setting might do
the job."

(2) "Then again, artistic gamma adjustment is just a special case of
tonemapping, and possibly not even the best choice for what the users
actually want to achieve with it, so a dedicated 'artistic_gamma'
feature would be pretty short-sighted, wouldn't it? Better implement a
generic tonemapping feature."

(3) "Thinking about it, we do have this plan to add a generic full-image
postprocessing feature somwehere further down the road, which would make
this dedicated tonemapping feature obsolete. It would be wise to plan
ahead now, lay out the syntax we'll want for that future feature, and
already implement whatever subset we can, most notably tonemapping; of
course we can also throw in some other goodies like doing fancy stuff
based on the screen coordinates."

(4) "The full-image postprocessing feature will need to run after the
entire image has been raytraced, but the current architecture provides
no clean place to hook it up there. Let's see where I can hook it up for
now... ah, there's a nice place for it."

(5) "Damn, I forgot about anti-aliasing: It'll make a difference whether
we apply tonemapping before or after that step. The final full-image
postprocessing feature will inevitably need to operate
post-anti-aliasing, but the preliminary place I've chosen is
pre-anti-aliasing, so we're guaranteed to break the behaviour as soon as
we move it to its final place. I need to put it someplace else already."

(6) "Wait, hold it -- I think doing the tonemapping _before_ the
anti-aliasing actually looked better. So we probably need a switdh to
choose whether to apply it before or after anti-aliasing... then again,
in pre-anti-aliasing mode we'd have only limited functionality; and some
poeple might want to use both pre- _and_ post-anti-aliasing
postprocessing... Dang, this gets more complicated than I expected."

(7) "You know what? Sod it! I'll just name the pre-anti-aliasing
tampering with image data 'tonemapping', and the post-anti-aliasing
tampering will be called 'postprocessing'."

(8) "Hm, what about the non-tonemapping stuff like the screen location?
Ah, I'll just keep it in there. It doesn't hurt, and someone might find
it useful for something some day."

And that's how the screen coordinates have ended up in the tonemapping
feature.


> I would imagine that various functions could be used to adjust brightness and
> colour using gradients, concentric-type adjustment such as the cos^4 brightness
> dropoff typically seen in camera lenses, etc.
> I guess you could also use one image to map/adjust tones onto/in another kind of
> like a pigment/texture/image map.

With the x and y screen coordinates available, it should be possible to
write tonemapping functions that overlay a pattern onto the image (via a
pattern function); such a pattern could in turn be arbitrarily complex,
from a simple spherical pattern creating a vignette effect to a complex
object pattern based on one or more text objects overlaying textual
information like a singature or frame number.

Post a reply to this message

Am 08.04.2016 um 19:43 schrieb clipka:
> CSOP, inverted through a magic trick...

Just in case nobody noticed my post in povray.beta-test -- an
experimental version supporting tonemapping can be found at:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8558038%2Bav124

See my post in povray.beta-test for a detailed description with
examples. Alternatively, you can find a short description in the commit
description at:

https://github.com/POV-Ray/povray/commit/6cb824e1bcbd752eb44e31745f7258af8de9c13c

But yeah, go out and enjoy the beautiful spring weekend. Desert me. Go
ahead and see if I care. ;)

Post a reply to this message

El 10/04/16 a las 17:10, clipka escribió:
> But yeah, go out and enjoy the beautiful spring weekend. Desert me.
> Go ahead and see if I care. ;)

   I'm really curious about that new feature and wanted to test it today,
but your derivatives example and my broken washing machine kept me busy
all day... luckily, I could repair the washing machine, and somehow I
worked out the derivatives example into a functional foam pattern (tough
I'm still fine-tuning it).

--
jaime

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.04.2016 um 22:32 schrieb Bald Eagle:
> > clipka <ano### [at] anonymousorg> wrote:
>
> >> What this new incarnation will add is the ability to apply different
> >> tonemapping functions to each colour channel, perform cross-channel
> >> colour maths, and as an extra bonus even use functions that depend on
> >> the screen location.
> >
> > So, this would be analogous to various image processing features and "filters"
> > that a lot of graphics programs have?
> > I find the screen location feature interesting, and am wondering how that will
> > function, and what inspired its development.
>
> "Because we can".
>
> Actually the chain of thought was something like this:
>
<snip>
>
> And that's how the screen coordinates have ended up in the tonemapping
> feature.
>
>
> > I would imagine that various functions could be used to adjust brightness and
> > colour using gradients, concentric-type adjustment such as the cos^4 brightness
> > dropoff typically seen in camera lenses, etc.
> > I guess you could also use one image to map/adjust tones onto/in another kind of
> > like a pigment/texture/image map.
>
> With the x and y screen coordinates available, it should be possible to
> write tonemapping functions that overlay a pattern onto the image (via a
> pattern function); such a pattern could in turn be arbitrarily complex,
> from a simple spherical pattern creating a vignette effect to a complex
> object pattern based on one or more text objects overlaying textual
> information like a singature or frame number.

In the spirit of foresightedness... I'm going to shill for my idea of a plugin
api again.  Because:

1) New functionality should be added by new code, not modification of old,
working code.

2) Adding a plugin to a directory and using dependency injection would be vastly
preferable to recompiling multiple un-official versions.

In fact, I would imagine that large parts of the current codebase could be
abstracted out as plugins (necessary core plugins, perhaps, but plugins)

I would also imagine that this would be a task of more than somewhat Herculean
porportions, so I completely understand resistance.

Unfortunately, I wouldn't know where to begin with such a thing, as I have a
hard time following the patterns in the codebase. (to put it lightly)

*kicks the hornet nest and hides*

Regards,
A.D.B.

Post a reply to this message

Am 11.04.2016 um 03:13 schrieb Anthony D. Baye:

> In the spirit of foresightedness... I'm going to shill for my idea of a plugin
> api again.  Because:

Your motion is moot, because:

> 1) New functionality should be added by new code, not modification of old,
> working code.

While that may be true in an ideal world, in reality sometimes (actually
more often than not) new code needs to be hooked up someplace nobody had
ever imagined that code might have to be hooked up there, so plugins are
always more limited than patches.

> 2) Adding a plugin to a directory and using dependency injection would be vastly
> preferable to recompiling multiple un-official versions.

Providing hooks to inject user-defined code wherever suitable is already
on the agenda. Except that there most likely won't be a plugin
directory; instead, such user-defined code would be written in a
next-generation scene description language, compiled to some virtual
machine bytecode, and uiltimately just-in-time-compiled to native code.

> In fact, I would imagine that large parts of the current codebase could be
> abstracted out as plugins (necessary core plugins, perhaps, but plugins)

Not yet.

> I would also imagine that this would be a task of more than somewhat Herculean
> porportions, so I completely understand resistance.

You're perfectly right as far as the proportions are concerned, but
you're off the mark concerning resistance. Herculean work is already
going on in the background.

> Unfortunately, I wouldn't know where to begin with such a thing, as I have a
> hard time following the patterns in the codebase. (to put it lightly)

Don't even try. The current codebase is still far too monolithic to bolt
on any way to inject user code. But we're working on it, slowly but
thoroughly.

Post a reply to this message

On 10-4-2016 20:30, Jaime Vives Piqueres wrote:
> El 10/04/16 a las 17:10, clipka escribió:
>> But yeah, go out and enjoy the beautiful spring weekend. Desert me.
>> Go ahead and see if I care. ;)
>
>    I'm really curious about that new feature and wanted to test it today,
> but your derivatives example and my broken washing machine kept me busy
> all day... luckily, I could repair the washing machine, and somehow I
> worked out the derivatives example into a functional foam pattern (tough
> I'm still fine-tuning it).
>

What lame excuses! :-)

I am curious about the foam pattern. I have tried some ideas of my own 
yesterday but to no conclusive results.

-- 
Thomas

Post a reply to this message

On 4/11/2016 7:50 AM, Thomas de Groot wrote:

> I am curious about the foam pattern. I have tried some ideas of my own
> yesterday but to no conclusive results.
>

This is PovRay's - Fermat's Last Theorem

I shall cheer on from the sidelines. And watch with interest.


-- 

Regards
     Stephen

Post a reply to this message

El 11/04/16 a las 08:50, Thomas de Groot escribió:
> What lame excuses! :-)

    No, really... my back hurts now, as I had to be laying on the ground 
almost 2 hours to remove the obstruction on the drain pump. And my brain 
hurts too, after some more hours fiddling with the derivatives result to 
convert them into an usable pattern.

> I am curious about the foam pattern. I have tried some ideas of my own
> yesterday but to no conclusive results.

    I will publish the code soon, but here it is an extract:


// the derivatives
#declare EPSILON = 1e-4;
#declare 
f1x=function{(f_water(x+EPSILON,y,0)-f_water(x-EPSILON,y,0))/2*EPSILON}
#declare 
f1y=function{(f_water(x,y+EPSILON,0)-f_water(x,y-EPSILON,0))/2*EPSILON}
#declare f2x=function{(f1x(x+EPSILON,y,0)-f1x(x-EPSILON,y,0))/2*EPSILON}
#declare f2y=function{(f1y(x,y+EPSILON,0)-f1y(x,y-EPSILON,0))/2*EPSILON}

// the texture from them
#declare t_ocean=
texture{
    pigment_pattern{
function{select(f2x(x,y,0)+f2y(x,y,0),abs(f2x(x,y,0)+f2y(x,y,0))*1000000000*4,0)}
    }
    texture_map{
      [0.0 t_water]
      [0.1 t_foam]
    }
}

    As you can see, the final pattern using the derivatives is tricky... 
I had to play with EPSILON to find a value suitable for the scale of my 
height_field and the "precision" I wanted. Then used select find the 
negative parts and convert them to positive, and scaling the values up 
because they are extremely small. Don't ask me how the hell I worked 
that out... attached is a first render showing the result. Still not 
what I want, but seems this is the way to go.

--
jaime

Post a reply to this message

Attachments:
Download 'ocean-16.jpg' (147 KB)

Preview of image 'ocean-16.jpg'

On 4/11/2016 11:13 AM, Jaime Vives Piqueres wrote:
> Still not what I want, but seems this is the way to go.


That looks just like before the foam starts streaming.
It is more than acceptable. Quite realistic, the horizon is not swamped 
with small detail but my eye can see the longer frequency waves as you 
would. It is only the foreground wave that needs a bit of breaking foam. 
You could hang it on your wall. :)

I think that you are working in the right area. What sort of time did it 
take? And what is the camera's FOV? I'm just curious.


-- 

Regards
     Stephen

Post a reply to this message

On 11-4-2016 12:13, Jaime Vives Piqueres wrote:
...
>     As you can see, the final pattern using the derivatives is tricky...
> I had to play with EPSILON to find a value suitable for the scale of my
> height_field and the "precision" I wanted. Then used select find the
> negative parts and convert them to positive, and scaling the values up
> because they are extremely small. Don't ask me how the hell I worked
> that out... attached is a first render showing the result. Still not
> what I want, but seems this is the way to go.
>

phew...! That is pretty good Jaime. Not yet there but very very close. I 
wanted to explore further some ideas proposed by Marc Jacquier in his 
sea code but I am not getting really anywhere. It probably is a dead 
end, but worth looking into.


-- 
Thomas

Post a reply to this message

El 11/04/16 a las 12:54, Stephen escribió:
> I think that you are working in the right area. What sort of time
> did it take? And what is the camera's FOV? I'm just curious.

   Thanks... this one took only 11 seconds to parse (because the sea HF
is only 2048x2048, versus the final one of 10240x10240), and 17 minutes
to render (yes, the derivatives pattern is not much faster than the
proximity pattern, after all).

   About the camera, if you meant the angle... I don't know, I used
direction here:

   up 9*y right 16*x
   direction 16*z


--
jaime

Post a reply to this message

El 11/04/16 a las 13:08, Thomas de Groot escribió:
> On 11-4-2016 12:13, Jaime Vives Piqueres wrote: phew...! That is
> pretty good Jaime. Not yet there but very very close. I wanted to
> explore further some ideas proposed by Marc Jacquier in his sea code
> but I am not getting really anywhere. It probably is a dead end, but
> worth looking into.
>

   Thanks! I tried almost everything, and the only two approaches getting
some believable foam patterns are proximity and derivatives. I'm
suspecting a mix of the two would really do it...

--
jaime

Post a reply to this message

On 4/11/2016 12:23 PM, Jaime Vives Piqueres wrote:
> El 11/04/16 a las 12:54, Stephen escribió:
>> I think that you are working in the right area. What sort of time
>> did it take? And what is the camera's FOV? I'm just curious.
>
>    Thanks... this one took only 11 seconds to parse (because the sea HF
> is only 2048x2048, versus the final one of 10240x10240), and 17 minutes
> to render (yes, the derivatives pattern is not much faster than the
> proximity pattern, after all).
>
>    About the camera, if you meant the angle... I don't know, I used
> direction here:
>
>    up 9*y right 16*x
>    direction 16*z
>


It looks really good full screen. I can actually see what looks like 
waves that have been reflected off a shore. Amazing what the brain will 
make of images. :-)

As it was a test you might have used a wide angle along the horizontal. 
To get a wider view.

That's not too bad a time. I would not want to put it in an animation at 
the larger resolution, though.


-- 

Regards
     Stephen

Post a reply to this message

On 04/11/2016 12:13 PM, Jaime Vives Piqueres wrote:
> El 11/04/16 a las 08:50, Thomas de Groot escribió:
>> What lame excuses! :-)
> 
>     No, really... my back hurts now, as I had to be laying on the groun
d 
> almost 2 hours to remove the obstruction on the drain pump. And my brai
n 
> hurts too, after some more hours fiddling with the derivatives result t
o 
> convert them into an usable pattern.
> 
>> I am curious about the foam pattern. I have tried some ideas of my own

>> yesterday but to no conclusive results.
> 
>     I will publish the code soon, but here it is an extract:
> 
> 
> // the derivatives
> #declare EPSILON = 1e-4;
> #declare 
> f1x=function{(f_water(x+EPSILON,y,0)-f_water(x-EPSILON,y,0))/2*EPSILO
N}
> #declare 
> f1y=function{(f_water(x,y+EPSILON,0)-f_water(x,y-EPSILON,0))/2*EPSILO
N}
> #declare f2x=function{(f1x(x+EPSILON,y,0)-f1x(x-EPSILON,y,0))/2*EPSIL
ON}
> #declare f2y=function{(f1y(x,y+EPSILON,0)-f1y(x,y-EPSILON,0))/2*EPSIL
ON}
> 
	Well strictly speaking, you're missing a pair of parentheses around the
2*EPSILON. They should make it easier to tweak your parameters (for one
thing you can probably replace the 1000000000 with 10 which makes for
less unwieldy values).

	That being said, the result you got here is pretty good. Keep up the
good work!

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

El 11/04/16 a las 23:05, Jérôme M. Berger escribió:
> 	Well strictly speaking, you're missing a pair of parentheses around the
> 2*EPSILON. They should make it easier to tweak your parameters (for one
> thing you can probably replace the 1000000000 with 10 which makes for
> less unwieldy values).

Ouch! Corrected... but now the multiplier has to be around 0.0000005.

>
> 	That being said, the result you got here is pretty good. Keep up the
> good work!

   Thanks!

--
jaime

Post a reply to this message

On 04/11/2016 11:31 PM, Jaime Vives Piqueres wrote:
> El 11/04/16 a las 23:05, Jérôme M. Berger escribió:
>> 	Well strictly speaking, you're missing a pair of parentheses around t
he
>> 2*EPSILON. They should make it easier to tweak your parameters (for on
e
>> thing you can probably replace the 1000000000 with 10 which makes for
>> less unwieldy values).
> 
> Ouch! Corrected... but now the multiplier has to be around 0.0000005.
> 
	BTW, it would probably be faster to replace your code with:

// Will probably need tweaking
#declare M=0.0000005;

#declare d2xpd2y=function{
   (f_water(x+EPSILON,y,0)+f_water(x-EPSILON,y,0)+
    f_water(x,y+EPSILON,0)+f_water(x,y-EPSILON,0)-
    4*f_water(x,y,0))/
   (EPSILON*EPSILON)
}

#declare selected=function{select(x,abs(x))}

#declare t_ocean=
texture{
  pigment_pattern{
    function{selected(d2xpd2y(x,y,0))*M,0)}
  }
  texture_map{
    [0.0 t_water]
    [0.1 t_foam]
  }
}

	This only calls f_water 5 times where your code called it 16 times...

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

El 12/04/16 a las 18:40, Jérôme M. Berger escribió:
> 	BTW, it would probably be faster to replace your code with:
>
> // Will probably need tweaking
> #declare M=0.0000005;
>
> #declare d2xpd2y=function{
>     (f_water(x+EPSILON,y,0)+f_water(x-EPSILON,y,0)+
>      f_water(x,y+EPSILON,0)+f_water(x,y-EPSILON,0)-
>      4*f_water(x,y,0))/
>     (EPSILON*EPSILON)
> }
>
> #declare selected=function{select(x,abs(x))}
>
> #declare t_ocean=
> texture{
>    pigment_pattern{
>      function{selected(d2xpd2y(x,y,0))*M,0)}
>    }
>    texture_map{
>      [0.0 t_water]
>      [0.1 t_foam]
>    }
> }
>
> 	This only calls f_water 5 times where your code called it 16 times...
>

   Yes, it seems to render noticeably faster... but I had to correct 
some things:

#declare M=0.0000005;

#declare d2xpd2y=function{
    (f_water(x+EPSILON,y,0)+f_water(x-EPSILON,y,0)+
     f_water(x,y+EPSILON,0)+f_water(x,y-EPSILON,0)-
     4*f_water(x,y,0))/
    (EPSILON*EPSILON)
}

#declare selected=function(x){select(x,abs(x),0)}

#declare t_ocean=
texture{
   pigment_pattern{
     function{selected(d2xpd2y(x,y,0))*M}
   }
   texture_map{
     [0.0 t_water]
     [0.1 t_foam]
   }
}

That works! Thanks!

--
jaime

Post a reply to this message