Hi,

I've just been tinkering with post_process focal_blur, and came up against 1
question, and 1 problem.

Question first. I could only manage to get focal_blur BEYOND the field_start
point, never in front of it, as would be possible using standard focal_blur.
Is this the correct behaviour of post_process fb?

Secondly, the few times I tried using keep_data_file, and then re-rendering
with +c to try different fb values, I got a "cannot open aborted data file"
error. Any ideas?

Thanks,

Andy Cocker

Post a reply to this message

I'd like to hear answer on your second question.  I tried to render a large
image (10240 x 7680) and got a out of memory error when it came to creating
the focal blur version.  I then tried to clear up enough memory and re-run
with +c and get the same error: "cannot open aborted data file".  Since it
took me over 2 weeks for this to render I'm not real happy that I have no
way to continue.

"Andy Cocker" <big### [at] mariner9fsnetcouk> wrote in message
news:3b959271@news.povray.org...
> Hi,
>
> I've just been tinkering with post_process focal_blur, and came up against
1
> question, and 1 problem.
>
> Question first. I could only manage to get focal_blur BEYOND the
field_start
> point, never in front of it, as would be possible using standard
focal_blur.
> Is this the correct behaviour of post_process fb?
>
> Secondly, the few times I tried using keep_data_file, and then
re-rendering
> with +c to try different fb values, I got a "cannot open aborted data
file"
> error. Any ideas?
>
> Thanks,
>
> Andy Cocker
>
>

Post a reply to this message

This is exactly what I have been saying about post-processing from the
very beginning: It takes huge amounts of memory. There's little we can do
about that fact.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

I was curious why the post processing was not being included with the 3.5
version.
I just wish there was some way to speed up a focal blurred trace in regular
povray.   With smaller images the PP was a godsend for speed increases.
Of course considering the size of my image I may never have enough memory to
create the focal blurred version within Megapov anyway.

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3b9ce1a2@news.povray.org...
>   This is exactly what I have been saying about post-processing from the
> very beginning: It takes huge amounts of memory. There's little we can do
> about that fact.
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Any chance I could get an answer to my original question please, or is
everyone 3.5 mad at the moment? ;-)

Andy Cocker

Post a reply to this message

I didn't mean to steal your question. I feel it is not being addressed
though.  I ran some experiments using small spheres on a checkered floor
that vary in distance from the camera.  I made the focal blur very tight and
very blurry (extreme short range of focus.)  from the focal center out (away
from the camera) the blur hits hard and fast, towards the camera (despite
being a good distance from the focal center) is all in focus.  The docs seem
to indicate "field_depth specifies the length of the focal range.  All
objects within the range of (field_start) to (field_start+field_depth) will
be fully in focus. " to me means objects close to the camera would also
become blurry when they are out of the range.  Testing shows this is not
true.

Here is the code I used:

////////////////////////////////////////////// CODE START
////////////////////////////////////////
#include "colors.inc"
#include "textures.inc"

#version unofficial MegaPov 0.7;
global_settings {
   assumed_gamma 2.2
   max_trace_level 25
   post_process{focal_blur{ 5, 0.010, 5,5 }}
}

light_source {<-80, 800, -80> color White * 1}

camera {
   location <0,0.75,-5>
   look_at  <0,0,0>
}

#declare CheckMe =
   texture {
      tiles {
         texture {
            pigment {Black
            }
         }
         tile2
         texture {
            pigment {White
            }
         }
      }
   }



#declare Board =
   box { <-32, -1, -32> <32, 0, 32>
      texture {CheckMe}
      hollow
   }


object {Board}

sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate < 2.0,0.5, 2.0>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate < 1.5,0.5, 1.5>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate < 1.0,0.5, 1.0>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate < 0.5,0.5, 0.5>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate < 0.0,0.5, 0.0>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate <-0.5,0.5,-0.5>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate <-1.0,0.5,-1.0>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate <-1.5,0.5,-1.5>}
sphere {<0,0,0>, 1 scale 0.3 texture {CheckMe} translate <-2.0,0.5,-2.0>}

//////////////////////////////////////////////////////////////// END OF CODE
/////////////////////////



I have emailed Nathan Kopp about the second issue but I have not heard back
from him yet.  I assume he may be quite busy with povray 3.5 beta at this
point.



"Andy Cocker" <big### [at] mariner9fsnetcouk> wrote in message
news:3b9cf843@news.povray.org...
> Any chance I could get an answer to my original question please, or is
> everyone 3.5 mad at the moment? ;-)
>
> Andy Cocker
>
>

Post a reply to this message

"Patrick Dugan" <pat### [at] usnetcomcorpcom> wrote in message
news:3b9d1fd9$1@news.povray.org...
> I didn't mean to steal your question.

;-)

>I feel it is not being addressed
> though.  I ran some experiments using small spheres on a checkered floor
> that vary in distance from the camera.  I made the focal blur very tight
and
> very blurry (extreme short range of focus.)  from the focal center out
(away
> from the camera) the blur hits hard and fast, towards the camera (despite
> being a good distance from the focal center) is all in focus.  The docs
seem
> to indicate "field_depth specifies the length of the focal range.  All
> objects within the range of (field_start) to (field_start+field_depth)
will
> be fully in focus. " to me means objects close to the camera would also
> become blurry when they are out of the range.  Testing shows this is not
> true.

I agree, according to the docs, there should be blur between the camera and
field_start-field_depth. But, like your experiments show, this doesn't
happen. It's a shame, 'cos post_process focal blur is really quick.

Still no joy on the 'error reading aborted data file' though. :-(

All the best,

Andy Cocker

Post a reply to this message

Patrick Dugan <pat### [at] usnetcomcorpcom> wrote:
: I just wish there was some way to speed up a focal blurred trace in regular
: povray.

  You should be aware that the post-process focal blur doesn't give a correct
result if there are reflections/refractions in the scene. It also has other
minor problems (not related to reflections/refractions).

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Andy Cocker <big### [at] mariner9fsnetcouk> wrote:
: It's a shame, 'cos post_process focal blur is really quick.

  The more I use focal blur, the more I'm becoming an
anti-prostprocess-focalblur activist... :)
  The post-process focal blur may be fast, but it just doesn't give the correct
result. Reflections and refractions do not work at all as they should. It
also has other problems (related to the fact that it doesn't add any
information to the image but just blurs existing pixels).

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Patrick Dugan" <pat### [at] usnetcomcorpcom> wrote...
>  The docs seem
> to indicate "field_depth specifies the length of the focal range.  All
> objects within the range of (field_start) to (field_start+field_depth)
will
> be fully in focus. " to me means objects close to the camera would also
> become blurry when they are out of the range.  Testing shows this is not
> true.

It USED to work.  Really, it did!  I remember testing it.  It actually uses
two different algorithms (both ad-hoc, neither based in reality) for
camera->field_start and field_end->infinity.  I remember coding and testing
both algorithms, so I _know_ it used to work.  However, there have been many
"hands in the pot" of MegaPov and things have a tendancy to get broken.
Sorry.

> I have emailed Nathan Kopp about the second issue but I have not heard
back
> from him yet.  I assume he may be quite busy with povray 3.5 beta at this
> point.

Yes.  Lately I've been to busy to devote any time to MegaPov.  The
keep_data_file also USED to work (again, I remember testing it), but again
it probably got broken along the way somewhere and nobody noticed until now.

Anyway, hopefully whenever we get a 3.5 version of MegaPov, we'll get better
post-processing that uses less memory.  Currently, it loads the whole
stinkin' PP data file into memory before processing.  This is horribly
inefficient.  That is one of the many reasons why this feature is not in POV
3.5.  This is also why POV 3.5 was so long in coming -  many features were
much like PP in that they had sloppy or inefficient code.  It took a long
time to clean things up.

-Nathan

Post a reply to this message