In article <39092043.AF6883F7@pacbell.net>, lin### [at] povrayorg 
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] 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

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

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

Warp <war### [at] tagpovrayorg> 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

In article <3909A3B3.BF05149C@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> 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] 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

Nathan Kopp <Nat### [at] koppcom> 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

On 29 Apr 2000 06:58:46 -0400, Warp <war### [at] tagpovrayorg> 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] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov <pet### [at] usanet> 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

Warp <war### [at] tagpovrayorg> wrote...
> Nathan Kopp <Nat### [at] koppcom> 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.

So by "machine code" you mean "virtual machine code".  Like a Java VM.  Or,
in this case, a POV VM.

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: So by "machine code" you mean "virtual machine code".  Like a Java VM.  Or,
: in this case, a POV VM.

  Yes. I should have used that term from the very beginning but it didn't
come to my mind.

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