Needless to say render and parse time can be very long, thus making it slow
to experiment with the post processes. With a copy{} object one could output
several different versions of the file:

post_process {
   copy { png "no_postprocess.png" }
   copy { png "focal_and_soft.png"
      focal_blur{10,5,2}
      soft_glow{.6,5}
   }
}

sig

Post a reply to this message

In article <391E6A2A.C09319D2@stud.ntnu.no>, Sigmund Kyrre Aas 
<as### [at] studntnuno> wrote:

> Needless to say render and parse time can be very long, thus making 
> it slow to experiment with the post processes. With a copy{} object 
> one could output several different versions of the file:
> 
> post_process {
>    copy { png "no_postprocess.png" }
>    copy { png "focal_and_soft.png"
>       focal_blur{10,5,2}
>       soft_glow{.6,5}
>    }
> }

I think a better solution would be input_image and output_image 
directives for each process. The input_image keyword would load the 
specified image and use it to override the color values, output_image 
would save the results of the filter to the specified file and restore 
the previous version in memory. It would probably have to be clipped 
colors to be a standard image format, but that shouldn't be a big 
problem(you could find or create another image format supporting a 
greater dynamic range).

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Like RGBE! :)

Post a reply to this message

In article <391ec516@news.povray.org>, "TonyB" 
<ben### [at] panamac-comnet> wrote:

> Like RGBE! :)

Perhaps...I have downloaded the source and will be playing around with 
it, maybe I will make a C++ version. I will need to make a converter to 
some other format though...
Anyone know of some good source code for reading/writing TGA, PPM, etc? 
I have looked for some, but the closest thing I could find is the file 
specifications, and since I am extremely inexperienced with file 
handling, I would prefer to work from existing code. I suppose I could 
just look at the POV code, but I would rather have some code already 
separate and useable.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff wrote:
 
> The input_image keyword would load the
> specified image and use it to override the color values, output_image
> would save the results of the filter to the specified file and restore
> the previous version in memory.

Ahh, uuh. 'Fraid I didn't understand this, but if you say it'll do the
trick.. (What is the "previous version"? What do you mean by overriding
colour values?)

sig

Post a reply to this message

In article <391F2151.9BF60326@stud.ntnu.no>, Sigmund Kyrre Aas 
<as### [at] studntnuno> wrote:

> Ahh, uuh. 'Fraid I didn't understand this, but if you say it'll do the
> trick.. (What is the "previous version"? What do you mean by overriding
> colour values?)

The "previous version" is what the in-RAM image looks like before the 
filter is called. If an input file is specified, colors from the file 
are used instead of that version(they override the original colors). If 
an output file is specified, the results of the filter are saved to the 
file and the in-RAM image is not affected.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Sigmund Kyrre Aas <as### [at] studntnuno> wrote...
> Needless to say render and parse time can be very long, thus making it
slow
> to experiment with the post processes. With a copy{} object one could
output
> several different versions of the file:

In MegaPov 0.5, the non-processed file will be kept by default, and a new
file (with "_PP" appended to the end) will be created for the post-processed
version.  You will be able to revert to the old behavior with the keyword
"overwrite_file".

Better file control (such as what you suggest or something like what Chris
proposed) is planned for the future, but not for this release.

-Nathan

Post a reply to this message