In article <3e89d6ed@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I wonder if this could be a nicer solution.

No.


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

>In short: Nowhere is ever said a partial image is good for anything but a
>continued trace.  And the image size is required prior to read the image.
>This is how all image formats work, and how all image formats are output in
>POV-Ray.

I've never used the continued trace feature, but I do partial renders quite
often. The uncompressed Targa format works well for me, as it handles large
image sizes and I can read the partial image (my image program displays the
partial render in the upper left corner, with garbage filling the rest). I
also grab partial renders from the screen.

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?

Post a reply to this message

> When using the Partial Output Options +sc +ec +sr +er povray incorrectly
> writes the full image size info to the PNG file it generates.

This is a long standing problem, not limited to the png output
format. I think I first noticed it about 7 years ago.

I agree totally (with a few of the respondents) that the correct
dimenions should be specified otherwise how can one say the image
file is written correctly. In general image software won't read 
these sub image files correctly, eg: PhotoShop.

And lastly, it was suggested that there aren't reasons to do a
partial render except for a "continued trace". Not so. I use it
extensively for distributed rendering of very long running 
renderings jobs across our cluster. I suspect lots of people
use it to preview parts of their images, as it stands many/most
image viewing tools won't handle the resulting "corrupt" images.
-- 
Paul Bourke
pbo### [at] swineduau

Post a reply to this message

In article <pbo### [at] netplexaussieorg> , Paul Bourke
<pbo### [at] swineduau>  wrote:

> This is a long standing problem, not limited to the png output
> format. I think I first noticed it about 7 years ago.
>
> I agree totally (with a few of the respondents) that the correct
> dimenions should be specified otherwise how can one say the image
> file is written correctly. In general image software won't read
> these sub image files correctly, eg: PhotoShop.

What you are asking for cannot work the way you suggest.  And it isn't and
never was meant to work this way.  The current behavior is exactly as it is
supposed to be and exactly how is is required in order to work as expected.

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.

    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

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