"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:

That's a wonderful scene, very mysterious and evocative. And thanks for sharing
the details of your techniques, plus the image of the various assets you used.
>
> As a post-processing step I also wrote a simple brightness mask scene file that
> reads in an existing image and masks off (as black) areas that are below a
> specified brightness threshold.

That idea gave me some thoughts about my recent post regarding AA problems with
very bright objects, where AA fails for those bright pixels (Thanks!) So I put
together something similar(?) to your idea: Rendering a scene the normal way,
then bringing the image back into POV-ray and doing an
image-to-function-to-pigments conversion on it (all 3 color channels). Then
re-combining (using 'average') those 3 pigment functions-- with simple but
proper r-g-b color_maps-- to re-create the image as before. At this point, I
discovered that I could change the color_maps' index values to effectively
mask-off (as black) any pixels over a certain 0-1 brightness threshold... like
your idea. Great, so far!

> A simple 5x5 Gaussian convolution matrix is then
> iterated across the resulting masked image to blur the remaining pixels for a
> simple glow effect...

This is the 2nd part of my task. I looked up 'gaussian blur', and I see that it
involves matrix use in some way. I'm still a rank beginner when it comes to
manipulating matrices, but aside from that small problem (ha), I can't even get
a *basic* experiment with a matrix to work in v3.8xx for Windows:

#declare MY_MATRIX =
transform{
              matrix
              <1,1,1,
              1,1,1,
              1,1,1,
              0,0,1>
              }

.... with or without a semi-colon at the end. "Fatal error in parser:
uncategorized error"

So I must be doing something basically wrong-- or else my syntax is incorrect,
although I don't see where.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> Cool. :-)
>
> The hint of atmosphere in the star field - is that something added to
> the star field, added as fog or is it related to the added luminous bloom?

It's just running some pigments through a couple of compositing macros and
building an averaged texture to "project" onto a background sky plane, something
like this:

#macro Pigment_Attenuate(p1, amt, rgb_clr)

   #local p2 = pigment { rgb rgb_clr }

   // return the new attenuated pigment
   #local pgmt_Attenuated = pigment {
      average
      pigment_map {
         [amt   p1]
         [1-amt p2]
      }
   }
   pgmt_Attenuated
#end

#macro Pigment_Overlay(pgmt_Orig, pgmt_Blend, blendAmt)

   #local pgmt_Blend = pigment {
      Pigment_Attenuate(pgmt_Blend, blendAmt, 0)
   }
   #local fp1 = function { pigment { pgmt_Orig } }
   #local fp2 = function { pigment { pgmt_Blend } }

   // overlay pigments
   #local RedChannel = pigment {
      function {
         (fp2(x,y,z).red*(1-fp1(x,y,z).red)/0.5)
        +(fp1(x,y,z).red-(1-fp1(x,y,z).red))
      }
      color_map { [0 rgb 0][1 rgb <1,0,0>] }
   }

   #local GreenChannel = pigment {
      function {
         (fp2(x,y,z).green*(1-fp1(x,y,z).green)/0.5)
        +(fp1(x,y,z).green-(1-fp1(x,y,z).green))
      }
      color_map { [0 rgb 0][1 rgb <0,1,0>] }
   }

   #local BlueChannel = pigment {
      function {
         (fp2(x,y,z).blue*(1-fp1(x,y,z).blue)/0.5)
        +(fp1(x,y,z).blue-(1-fp1(x,y,z).blue))
      }
      color_map { [0 rgb 0][1 rgb <0,0,1>] }
   }

   // return this new blended pigment
   #local pgmt_Blended = pigment {
      average
      pigment_map {
         [1 RedChannel]
         [1 GreenChannel]
         [1 BlueChannel]
      }
   }
   pgmt_Blended
#end

// stars
#declare P_Stars = pigment {
   image_map { png "starfield_and_moon" interpolate 2 map_type 0 once }
   translate -0.5
}

// atmosphere
#declare P_Clouds = pigment {
   gradient y
   pigment_map {
      [0
         bozo
         pigment_map {
            [0 rgb <44, 43, 58>/255]
            [1 rgb 0]
         }
         turbulence 1
         scale 0.2
      ]
      [0.75 rgb 0]
   }
   translate y*0.5
}

// Combined
plane {z, 200
   texture {
      average
      texture_map {
         [1
            pigment { Pigment_Overlay(P_Stars, P_Clouds, 0.15) }
            finish { emission 1 diffuse 0 }
         ]
         [1
            pigment { P_Stars }
            finish { emission 3 diffuse 0 }
         ]
      }
      scale x*image_width/image_height
      scale 160
      translate y*5
   }
}

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> Excellent! And Thanks for the detailed explanation; I shall note that
> carefully down for future study and use. The pose rig is particularly
> interesting for me. I have done some of this in Poser and there it is -
> not difficult - but demanding a close attention. How is this in Blender?
> more straightforward? Somehow, I guess it needs a close attention there too.

Thanks Thomas. The posing in Blender is pretty straightforward, it just takes
time to get all the bones in situated properly within the mesh. I spent about 3
hours building the rig and trying various poses.

Post a reply to this message

"Norbert Kern" <nor### [at] t-onlinede> wrote:
>
> The figures are excellent - i love them...

Thanks Norbert!

> I dont like the structure and the material - you made materials much more
> elaborate than this...

Well, ancient aliens apparently have a very different design aesthetic!

No, seriously, I'm thinking of doing another version with something else there
instead. I've been working on a simple spaceship...

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ... I can't even get
> a *basic* experiment with a matrix to work in v3.8xx for Windows:
>
> #declare MY_MATRIX =
> transform{
>               matrix
>               <1,1,1,
>               1,1,1,
>               1,1,1,
>               0,0,1>
>               }
>
> .... with or without a semi-colon at the end. "Fatal error in parser:
> uncategorized error"
>
> So I must be doing something basically wrong-- or else my syntax is incorrect,
> although I don't see where.

the problem must be elsewhere, the syntax is correct, tried it on (Linux,
self-compiled) alpha.10064268.


regards, jr.

Post a reply to this message

Op 20/02/2021 om 02:41 schreef Robert McGregor:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Excellent! And Thanks for the detailed explanation; I shall note that
>> carefully down for future study and use. The pose rig is particularly
>> interesting for me. I have done some of this in Poser and there it is -
>> not difficult - but demanding a close attention. How is this in Blender?
>> more straightforward? Somehow, I guess it needs a close attention there too.
> 
> Thanks Thomas. The posing in Blender is pretty straightforward, it just takes
> time to get all the bones in situated properly within the mesh. I spent about 3
> hours building the rig and trying various poses.
> 

Yes, that is pretty close to what Poser needs too. I good incentive to 
explore that direction again.

-- 
Thomas

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > ... I can't even get a *basic* experiment with a matrix to work
> > in v3.8xx for Windows:
> > ...
> > So I must be doing something basically wrong-- or else my syntax is
> > incorrect, although I don't see where.
>
> the problem must be elsewhere, the syntax is correct, tried it on (Linux,
> self-compiled) alpha.10064268.
>

Thanks.
That's strange, though; I just ran my matrix code snippet in v3.7.1 beta 9
(Windows), and it fails there as well, same error.

But I found the cause (at least for Windows builds): It's the matrix vector
values themselves that I used-- which I chose blindly, as just some combination
of 0's and 1's! Thinking that any combination would work for a simple syntax
test; apparently a bad idea. :-[

So I substituted the example values given in POV-ray's "matrix" docs...

matrix < 1, 1, 0,
       0, 1, 0,
       0, 0, 1,
       0, 0, 0 >

....and the #declared transform now runs without an error.

I guess it's not good to play around with things that I don't yet fully
understand ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> That's a wonderful scene, very mysterious and evocative. And thanks for sharing
> the details of your techniques, plus the image of the various assets you used.

Thanks Kenneth, I appreciate that.

> That idea gave me some thoughts about my recent post regarding AA problems with
> very bright objects, where AA fails for those bright pixels (Thanks!) So I put
> together something similar(?) to your idea: Rendering a scene the normal way,
> then bringing the image back into POV-ray and doing an
> image-to-function-to-pigments conversion on it (all 3 color channels). Then
> re-combining (using 'average') those 3 pigment functions-- with simple but
> proper r-g-b color_maps-- to re-create the image as before. At this point, I
> discovered that I could change the color_maps' index values to effectively
> mask-off (as black) any pixels over a certain 0-1 brightness threshold... like
> your idea. Great, so far!

Yes, this sounds very much like what I did (which was orginally inspired by
reading your bright pixels AA problems post and pondering ways to fix that!)

> This is the 2nd part of my task. I looked up 'gaussian blur', and I see that it
> involves matrix use in some way. I'm still a rank beginner when it comes to
> manipulating matrices, but aside from that small problem (ha), I can't even get
> a *basic* experiment with a matrix to work in v3.8xx for Windows

Okay, I didn't use a matrix in that sense, i.e., the matrix keyword as used for
transformations. I just built my own Gaussian smoothing matrix using a 2d array,
like this (note the symmetry):

#declare ConvolutionKernel = array[5][5] {   // Smoothing matrix
   {1,  4,  7,  4, 1},
   {4, 16, 26, 16, 4},
   {7, 26, 41, 26, 7},
   {4, 16, 26, 16, 4},
   {1,  4,  7,  4, 1}
}

This small kernel (matrix) represents pixel weights, and the central element
(with the highest value) is the calculation target, an average of all the
surrounding pixel colors. In a nutshell it works like this:

Place the center weight of the kernel (41 in this case) on an image pixel. The
colors of all pixels under the matrix (from the original image, as sampled from
the function pigment) are multiplied by the overlapping kernel pixel weights,
and the results of all pixels are all added together into a final summed color.

Each kernel weight that is multiplied against a pixel color is added to an
overall matrix sum (at image borders not all weights will have pixels under
them). An average color for the central pixel is then calculated as: summed
color divided by the matrix sum.

Move the center of the kernel to the next pixel and iterate the process until
all pixels have been assigned averaged colors. At that point the averaging has
blurred the image, in this case the 5x5 matrix gives a 3-pixel blur (see
attached sample image, left is a magnified 60x60 test image and right is the
blurred convolution result).

Doing it this way is a *slow* process, especially in SDL, because for a
1920x1080 pixel image the are 2 million+ pixels, and each needs to be averaged
with (for the most part, except edges) 24 neighboring pixels, for an estimated
48 million samples and calculations.

Post a reply to this message

Attachments:
Download 'convolveexample.png' (1219 KB)

Preview of image 'convolveexample.png'

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:

> > This is the 2nd part of my task. I looked up 'gaussian blur', and I see that it
> > involves matrix use in some way. I'm still a rank beginner when it comes to
> > manipulating matrices, but aside from that small problem (ha), I can't even get
> > a *basic* experiment with a matrix to work in v3.8xx for Windows
>
> Okay, I didn't use a matrix in that sense, i.e., the matrix keyword as used for
> transformations. I just built my own Gaussian smoothing matrix using a 2d array,
> like this (note the symmetry):
>
> #declare ConvolutionKernel = array[5][5] {   // Smoothing matrix
>    {1,  4,  7,  4, 1},
>    {4, 16, 26, 16, 4},
>    {7, 26, 41, 26, 7},
>    {4, 16, 26, 16, 4},
>    {1,  4,  7,  4, 1}
> }

Yes, it's a mathematical "matrix" - but with what we're doing with it, it's
implemented as an _array_ in code.   Not many working parts under the hood for
doing matrix math at the moment.

So I guess "array processing algorithm" would most clearly describe the
operation.

I did similar here:

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5e9e3e93521c7ab7fb0b41570%40news.povray.org%3E/?ttop=432310
&toff=50

And probably for the Fast Fourier Transform and other places where I needed the
matrix structure to accomplish what I wanted.

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ...So I put together something similar(?) to your idea: Rendering a scene
> > the normal way, then bringing the image back into POV-ray and doing an
> > image-to-function-to-pigments conversion on it (all 3 color channels)...
>
> Yes, this sounds very much like what I did (which was orginally inspired by
> reading your bright pixels AA problems post and pondering ways to fix that!)

Ha! This is what I love about the newsgroups here: similar ideas feeding off of
each other, to find a common solution.

> > I looked up 'gaussian blur', and I see that it
> > involves matrix use in some way...
>
> Okay, I didn't use a matrix in that sense, i.e., the matrix keyword as
> used for transformations.

Yes, I had a half-formed idea that this might be the case. Honestly, I had no
real idea as to how I was going to proceed with a 'typical' matrix, if I could
even get the darn thing to run ;-)

> I just built my own Gaussian smoothing matrix using a 2d array,
> like this (note the symmetry):
>
> #declare ConvolutionKernel = array[5][5] {   // Smoothing matrix
>    {1,  4,  7,  4, 1},
>    {4, 16, 26, 16, 4},
>    {7, 26, 41, 26, 7},
>    {4, 16, 26, 16, 4},
>    {1,  4,  7,  4, 1}
> }

[clip]
Ah, the key! That's brilliant and elegantly simple. I shall experiment with it.
Thanks again for your willingness to share, and for your clear comments.

Here's an alternate 'brute force' idea for finding / masking off pixels in an
image that go over a certain brightness limit: Years ago, I wrote some code
using eval_pigment to go over each and every pixel of a pre-rendered image, then
storing all of those found color values in a 2-D array. (Or alternately, just
the brightest pixel values according to a particular threshold, and their x/y
positions in the image). The final step was to 're-create' the image by
assigning each original pixel's color-- or black, as the case may be-- to a tiny
flat box or polygon in an x/y grid. For example, an 800X600 re-created image
would be made of 480,000 tiny box shapes! Crude but effective.

But a more elegant solution to this 'many boxes' idea would be to take all of
the arrays' eval_pigment color values (and positions in the image), and somehow
shove them into a FUNCTION of some sort-- to ultimately be applied as a *single*
pigment function to a single flat box. But HOW to do this has always eluded me.
In other words, how can a single function be 'built' using a repetitive
iteration scheme-- other than by assigning each and every pixel color to its own
initial pigment function, then combining/adding(?) all of the 480,000 functions
into 1 for the final image output?? (Which by itself leaves out the *positions*
of the individual pixels, another major problem.)

Can such a pigment function be built piece-by-piece-- in a #for loop, for
example-- AND in correct final order of the pixels? I was wondering if you have
ever devised a scheme to do something like this.

Post a reply to this message