In article <web.3e89f3c7573676b7ba9929f0@news.povray.org> , "Renderdog" 
<slo### [at] hiwaaynet> wrote:

> I was always a little surprised POV-Ray didn't simply create an image the
> size of the partial render, but that appears to be because I never used the
> continued trace feature. Is there a more efficient "partial render"
> technique that I'm missing?

No, continue trace is not meant for what some people seem to continuely be
trying to use them.  Don't get confused be what some popel claim should work
in this thread, because it cannot and will not (and never did!) work the way
they claim.  For no image format.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Partial images are there to continue a trace, not more, not less.  If you
> want to get a partial render of an image, specify it as such on the
> command-line.  The continue trace feature should simply not be used for
> this.

Actually I never do a partial render....what I was actually
replying to was the case where I select a subset range of
columns or rows, on the command line or in an ini file. The
resulting tga file will have the dimensions in the header of 
the full size image and not the subset image. Surely this
is an incorrectly written image.

Having said this (which has certainly been the case for a 
long time), I better check that it hasn't been fixed in the
current release.
-- 
Paul Bourke
pbo### [at] swineduau

Post a reply to this message

> Actually I never do a partial render....what I was actually
> replying to was the case where I select a subset range of
> columns or rows, on the command line or in an ini file. The
> resulting tga file will have the dimensions in the header of 
> the full size image and not the subset image. Surely this
> is an incorrectly written image.

I just checked with ppm output. The file has the subset of rows but
all columns, the unrendered ones filled black. While I do not want to
argue about whether this can be considered correct, I deem it useless.


-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

George Pantazopoulos wrote:
> 
> [...]
> 
> When using the Partial Output Options +sc +ec +sr +er povray incorrectly
> writes the full image size info to the PNG file it generates.
> 
> For example, if we did a render with "povray +w1024 +h768 +sc0 +ec255 +sr0
> +er255 +fn +otile0.png cornell.pov",
> the resulting tile0.png incorrectly reports a width and height of 1024 and
> 768, respectively. In this case it should be 256 for both cases.

A lot of nonsense has been said in this thread so i try to clear a few
things up:

- when rendering a subset of *columns* (+sc/+ec) POV-Ray generates a full
width image and fills the not rendered columns with black pixels.  This
should not be a problem for any image reading program no matter what file
format is used.

- when rendering a subset of *rows* (+sr/+er) POV-Ray writes the full
height into the image file header and only writed those lines into the
image that are rendered.  This can cause problems with image reading
programs that are not checking the file while reading and just read over
the end.

- if POV-Ray wrote the actual height of the partial image into the image
header there would be no way to continue the trace in a later run.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> 
> George Pantazopoulos wrote:
Christoph, 
Thanks for stepping in with a complete description of the behavior. I would like
to see your explanation added to the documentation. To Warp's POV-Ray questions
and tips section or perhaps as a rework/addition to section 5.2.2.1.4 Resuming
Options.  
Bill P.
 
> - when rendering a subset of *columns* (+sc/+ec) POV-Ray generates a full
> width image and fills the not rendered columns with black pixels.  This
> should not be a problem for any image reading program no matter what file
> format is used.
> 
> - when rendering a subset of *rows* (+sr/+er) POV-Ray writes the full
> height into the image file header and only writed those lines into the
> image that are rendered.  This can cause problems with image reading
> programs that are not checking the file while reading and just read over
> the end.
> 
> - if POV-Ray wrote the actual height of the partial image into the image
> header there would be no way to continue the trace in a later run.
>

Post a reply to this message

Paul Bourke wrote:
> 
> > Partial images are there to continue a trace, not more, not less.  If you
> > want to get a partial render of an image, specify it as such on the
> > command-line.  The continue trace feature should simply not be used for
> > this.
> 
> Actually I never do a partial render....what I was actually
> replying to was the case where I select a subset range of
> columns or rows, on the command line or in an ini file. The
> resulting tga file will have the dimensions in the header of
> the full size image and not the subset image. Surely this
> is an incorrectly written image.
> 
> Having said this (which has certainly been the case for a
> long time), I better check that it hasn't been fixed in the
> current release.
> --
> Paul Bourke
> pbo### [at] swineduau

I have used partial renders a lot for a project a couple of years ago. I
used it to animate part of a scene. Rerendering the whole scene would
have taken too much time and I only needed a small portion of the output
anyway. What I remember was that I would get an image at the full size
with the rendered part at the top of the image. The horizontal
orientation was correct, the vertical orientation gone. I had to make a
little tool to get everything back in place again. 
This was with version 3.1 outputting windows bitmaps. My guess is that
image formats can put limitations on the output of partial renders. At
the time I would have liked it if the rendered part had been on it's
right place but I didn't really feel the need to complain. Perhaps this
has changed in newer versions?

Remco

Post a reply to this message