In article <chr### [at] netplexaussieorg> , Chris Huff
<chr### [at] maccom>  wrote:

>>   (How exactly
>> this would be done is not the point here.)
>
> This would be impossible (or just unnecessarily difficult)

As I said "How exactly this would be done is not the point here." -- it is
the short and nice way of saying I don't want to get into a 4.0 feature
discussion here and now ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Imagine the following solution:

To enable a "full data" format (unclipped floating point values for color,
normal, depth etc.) you would write a special keyword in the global_settings
block or maybe specify it in the command line.

Together with the POV-Ray raytracer engine would be a post-process engine.
You control post-processing through a separate and very simple scripting
language which you write in separate files with a different extension
(.ppp?).

You could use the pp-engine in at least two ways:

1) You could call it from within your POV-script file (by specifying it in
global_settings). This way the PP-script would be automatically run after an
image is rendered, or after each frame in an animation are rendered.

2) You could run it directly. This would require that you'd somehow specify
which input images (in "full data" format) to process.

programmers could also write their own pp-engines that would read and
process "full data" files.

Also, in the raytracing engine could be a command-line switch to disable
rendering (so only parsing is done). That way you could render an image or
animation once (with post-processing), and if you find out you want to make
changes in the post-processing you could render it several times with
different post-process options without having to re-raytrace every time.

You could even use the I/O features in POV-Ray to write the pp-script (or
parts of it) and pass on variables to it that way.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3b76b2f3@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Together with the POV-Ray raytracer engine would be a post-process engine.
> You control post-processing through a separate and very simple scripting
> language which you write in separate files with a different extension
> (.ppp?).

Exactly (this is along the lines I have been thinking).  There are numerous
benefits.  One would be that such an engine (or its framework, i.e. a simple
sample filter) could be distributed under a completely different license,
maybe real GPL or an even less restrictive license.  It would allow
everybody to write filters based on the output without having to deal with
the core code.  Those filters could be integrated into comfortable programs
and experimenting could be done realtime rather than the current and very
clumsy parse-render-postprocess method.  And, the POV-Team would not have to
integrate them immediately, etc, etc, etc...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

>
> Am I the only person who has the impression it is also a convenient way to
> get around the post-processing rules of the IRTC? ;-)

The only post-processing feature that I use is "Depth", which is extremely
useful when I need to work on the POV image in PhotoShop. Makes a lot of things
easier.

Tom Stone

Post a reply to this message

I agree with all of Thorsten's comments. I think this would be the
best future for POV-Ray post-processing.

Just to stir things up a little, does anyone want to create "import"
and "filter" plugins for Photshop (and compatible programs) that would
enable it to be used as a POV-Ray post-processor? Of course, you'll
need to make an "export" option for a custom version of POV-Ray, which
outputs a customized file type that supports all the raw POV-Ray data.


Remember, the Photoshop SDK is freely available and is fairly
cross-platform, if I'm not mistaken. There are also programs other
than Photoshop which support it.

Later,
Glen

Post a reply to this message

GIMP has a very powerful imaging engine that is fully script-able and it is 
GPL as well as xplatform.

Glen Berry wrote:

> I agree with all of Thorsten's comments. I think this would be the
> best future for POV-Ray post-processing.
> 
> Just to stir things up a little, does anyone want to create "import"
> and "filter" plugins for Photshop (and compatible programs) that would
> enable it to be used as a POV-Ray post-processor? Of course, you'll
> need to make an "export" option for a custom version of POV-Ray, which
> outputs a customized file type that supports all the raw POV-Ray data.
> 
> 
> Remember, the Photoshop SDK is freely available and is fairly
> cross-platform, if I'm not mistaken. There are also programs other
> than Photoshop which support it.
> 
> Later,
> Glen

Post a reply to this message

On Tue, 11 Sep 2001 16:54:50 +1000, Daniel Matthews <dan### [at] 3-enet>
wrote:

>GIMP has a very powerful imaging engine that is fully script-able and it is 
>GPL as well as xplatform.

I like GIMP. It's almost as good as Photoshop. (Please no stone
throwing from the Linux crowd.) However, I wonder if it supports
16-bit-per-color images? This would seem an advantage when doing
post-processing work. Of course, if it could be made to support
floating-point images, that would be even better.

One strong point in Photoshop's favor is its nearly universal
acceptance in the professional imaging community. It certainly
wouldn't hurt POV-Ray to be able to interact well with what is
probably the most respected photo-image editor in the world.


Later,
Glen

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: However, I wonder if it supports 16-bit-per-color images?

  Nope, it doesn't seem to support them (unless a really recent version has
the addition...).

-- 
#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

On Tue, 11 Sep 2001 05:20:07 -0400, Glen Berry wrote:
>On Tue, 11 Sep 2001 16:54:50 +1000, Daniel Matthews <dan### [at] 3-enet>
>wrote:
>
>>GIMP has a very powerful imaging engine that is fully script-able and it is 
>>GPL as well as xplatform.
>
>I like GIMP. It's almost as good as Photoshop. (Please no stone
>throwing from the Linux crowd.) 

Too bad Photoshop is an Adobe product (hack, spit.)

(My personal opinions only.)

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Glen Berry wrote:

> I like GIMP. It's almost as good as Photoshop. (Please no stone
> throwing from the Linux crowd.) However, I wonder if it supports
> 16-bit-per-color images?

No, but yes.

There is a 'Hollywood' branch of the Gimp that has been hacked for 16-bit color
support.

http://film.gimp.org/

--
Wind the Frog!

Post a reply to this message