![](/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) |
Glen Berry wrote:
>
> On Fri, 28 Apr 2000 01:14:58 -0400, "Mark Wagner"
> <mar### [at] gte net> wrote:
>
> >There is one way of implementing a plugin system for POV-Ray that would be
> >relatively easy and completely platform-independant: Pov-Script.
>
> That sounds extremely slow for an image processing system.
I don't see why. Once the instructions are parsed the operation
would be performed at the program level.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
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) |
On Thu, 27 Apr 2000 11:29:37 +0200, Gilles Tran <tra### [at] inapg inra fr>
wrote:
>In addition to all the post-process requests that have been made in the
>past few days, there is one that is particularly important to me, which
>is the ability to manipulate separately the highlights/midtone/shadows
>proportions (?) of the image. (if this was already mentioned under
>another name in one of Glen Berry's message, forget about it).
Okay, I took the example you posted in the images group and recreated
it myself. I posted my version in povray.binaries.images for you to
inspect along with the basic formula I used to achieve the effect.
In the case of this particular image, all that was needed was a
certain type of contrast increase. This effect was particularly easy
to replicate. If you want to send other examples, I will attempt to
replicate them as well.
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwv com to email me. )
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 <39092043.AF6883F7@pacbell.net>, lin### [at] povray org
wrote:
> I don't see why. Once the instructions are parsed the operation
> would be performed at the program level.
No, the macro would have to be parsed at least once for every pixel.
Without completely redoing the parser, it can't be parsed once and
executed multiple times. This could be quite slow, and I have no idea
how it would be implemented. Isosurface functions would be a lot faster,
and could do nearly everything a macro could do.
--
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) |
I still think that some type of byte-compiling of the povray script
before parsing it would speed up parsing a lot.
What I mean is that povray could work as perl does (AFAIK): First it
reads the script and byte-compiles it to a binary format, which is kind
of "machine code" or "assembler" into memory. Then it interprets this
byte code.
This makes it much faster then interpreting the raw script, specially when
there are loops. It's much faster because all the keywords are very short
(1 or 2 bytes usually) and can be read into one variable and processed as
a number, it can trust that there are no syntax errors (because all the
possible syntax errors have been caught in the compilation step) and thus
doesn't have to make provision for that, and so on. Macros would be a lot
faster because they could be kept in memory as byte code and parsed when
needed.
Usually the time spent byte-compiling plus then interpreting the byte code
is a lot shorter than interpreting the raw script directly (specially, as I
said, with loops and macros).
Another advantage would be that the byte-compiled version could be written
to a file making the scene file a lot smaller (and saving the compilation
step when reading this binary format; it could just load the file into
memory and start interpreting it).
Of course it would need a lot of work to implement this (perhaps too much?).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
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) |
Glen Berry wrote:
> There is also a function in both Photoshop and Gimp called "Auto
> Levels"
For what I read here,
http://www.geocities.com/SiliconValley/Haven/5179/
it's equivalent to PSP and Picture Publisher H/M/S modification, including
the color balancing alteration. So we're basically talking about the same
thing.
The really nice thing about H/M/S balancing, for a non specialist of photo
touch-up, is that it is very simple to use (unlike color balancing or even
color saturation) and, usually, a subtle extension of the shadow range is
quite enough to enhance nicely a picture. So if something of that sort could
be implemented in pov, it would be nice to have it done along the same
lines, or, if this can be done with a generic model, to ensure that this
model can be used in a macro that does it with the H/M/S logic. Obviously,
such a generic model could be extremely powerful and improve many pov
renders in a dramatic way.
In fact, I wonder why most pov pictures use such a narrow range. I have
always noticed that pics from other renderers tend to be crispier : is it
possible that these renderers include some self-correcting algorithm that
would stretch the range whenever it's needed ? Note that this is a general
statement : HE Day pics, for instance, always seem quite contrasted already.
Anyway, whatever solution Chris Huff (and al) find for this, many thanks in
advance !
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nathan Kopp
Subject: Re: Post-process : highlights/midtone/shadows
Date: 28 Apr 2000 13:41:08
Message: <3909cd34@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote...
> I still think that some type of byte-compiling of the povray script
> before parsing it would speed up parsing a lot.
> What I mean is that povray could work as perl does (AFAIK): First it
> reads the script and byte-compiles it to a binary format, which is kind
> of "machine code" or "assembler" into memory. Then it interprets this
> byte code.
The "byte-code", ususally called "p-code", is also very similar to what Java
does (.java is compiled into .class). Remember that this p-code does still
have to be interpreted, but the interpretation of p-code is relatively
quick.
It would not be practical to compile to true machine code, since that would
require a platform-specific compiler to exist inside POV (and I think I can
saftely say that currently nobody on the POV-Team wants to attempt such a
feat while). (Plus, you'd run into all sorts of problems with
cross-platform compatibility, program bloat, etc. etc.)
-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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3909A3B3.BF05149C@inapg.inra.fr>, Gilles Tran
<tra### [at] inapg inra fr> wrote:
> For what I read here,
> http://www.geocities.com/SiliconValley/Haven/5179/
> it's equivalent to PSP and Picture Publisher H/M/S modification,
> including the color balancing alteration. So we're basically talking
> about the same thing.
> The really nice thing about H/M/S balancing, for a non specialist of
> photo touch-up, is that it is very simple to use (unlike color
> balancing or even color saturation) and, usually, a subtle extension
> of the shadow range is quite enough to enhance nicely a picture. So
> if something of that sort could be implemented in pov, it would be
> nice to have it done along the same lines, or, if this can be done
> with a generic model, to ensure that this model can be used in a
> macro that does it with the H/M/S logic. Obviously, such a generic
> model could be extremely powerful and improve many pov renders in a
> dramatic way.
A dynamic_range filter, which would take two values and scale the input
so that the min value is at 0 and the max at 1? I think it could
probably be done easily with the add and multiply filters, though. Maybe
package it in a macro, this seems to work right:
#macro DynamicRange(Min, Max)
clip_colors {Min, Max}
add {rgb -Min}
multiply {rgb 1/(Max-Min)}
#end
Another filter that might be useful would be a "curves" filter, that
takes a spline(or a color_map?) and adjusts the image according to it.
> In fact, I wonder why most pov pictures use such a narrow range. I
> have always noticed that pics from other renderers tend to be
> crispier : is it possible that these renderers include some
> self-correcting algorithm that would stretch the range whenever it's
> needed ? Note that this is a general statement : HE Day pics, for
> instance, always seem quite contrasted already.
I think that is mostly because HE Day is better at lighting than most
people. I tend to use ambient 0 when possible, and rely on multiple
lights and radiosity(thanks to Nathan Kopp!) to get good lighting. I
find it greatly improves shading and shadows.
--
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) |
Nathan Kopp <Nat### [at] kopp com> wrote:
: It would not be practical to compile to true machine code, since that would
: require a platform-specific compiler to exist inside POV
I didn't mean that either. I was talking about povray's own "machine code"
which it can interpret. Just like perl or java have.
This kind of "machine code" has the advantage that it's a lot easier to
parse and interpret.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
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) |
On 29 Apr 2000 06:58:46 -0400, Warp <war### [at] tag povray org> wrote:
> I didn't mean that either. I was talking about povray's own "machine code"
>which it can interpret. Just like perl or java have.
> This kind of "machine code" has the advantage that it's a lot easier to
>parse and interpret.
Kinda like the .pob format?
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usa net
TAG e-mail : pet### [at] 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) |
Peter Popov <pet### [at] usa net> wrote:
: Kinda like the .pob format?
I have no idea what kind of format it is, but it might not be it. I'm not
just talking about converting the pov-file to a more compact binary format
(which can by itself, of course, speed up the parsing), but to a "machine
code"-type language which is a lot simpler and very fast to interpret.
For example a statement like this:
pigment { White_Marble }
could be, converted to this "machine code", just two or three op-codes (ie.
numbers), one number for the command "pigment with reference to predeclared
identifier" and the other the ID for White_Marble.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
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) |