![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <391E6A2A.C09319D2@stud.ntnu.no>, Sigmund Kyrre Aas
<as### [at] stud ntnu no> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Like RGBE! :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <391ec516@news.povray.org>, "TonyB"
<ben### [at] panama c-com net> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <391F2151.9BF60326@stud.ntnu.no>, Sigmund Kyrre Aas
<as### [at] stud ntnu no> 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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Sigmund Kyrre Aas <as### [at] stud ntnu no> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |