clipka <ano### [at] anonymousorg> wrote:
> Am 23.01.2011 13:41, schrieb Jim Holsenback:
> > On 01/22/2011 09:05 AM, Le_Forgeron wrote:
> >> It might happen that the filesize has changed and that the file is not
> >> yet finished... loading partial file is a bad idea.
> >>
> >> (For RC2, if the full image is more than 1 048 576 pixels, disk I/O
> >> would occurs, resulting in a slow creation of the final image at the end
> >> of the render)
> >> (For RC3, it's tunable, check the release note)
> >
> > the I/O bottleneck fix correct? When running RC2 I /may/ have seen the
> > problem manifest itself on my system. As the scene was completing I had
> > jumped to the scene file text to make a change and save ... I had to
> > ctrl s a second time. Happened more than once, so now I think I know
> > what I was seeing. It might be a good idea for the blender folks to grab
> > RC3 and see if that gives them any joy!
> >
> > also now that I've re-read:
> >
http://wiki.povray.org/content/Documentation:Reference_Section_1#Partial_Output_Options
> >
> > given the comments that have been made the last three paragraphs are
> > what needs to be changed ... the rows exception doesn't apply now
> > correct? and since that exception isn't valid anymore the last line can
> > go ...
>
> Yup. To my understanding, the text
>
>
> --------------------
> 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 writes 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.
> --------------------
>
> should be replaced with something like
>
> --------------------
> When rendering a subset of columns and/or rows, 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.
> --------------------
>
> Maybe add:
>
> --------------------
> (When rendering a subset of *rows* (+sr/+er) earlier versions of POV-Ray
> wrote the full height into the image file header but only wrote image
> data for those lines that were actually rendered, making such output
> files incompatible with various image processing tools. This is no
> longer the case as of POV-Ray 3.7.)
> --------------------

Thanks for all your answers and for the update to the documentation. I am using
latest(RC3 as of today) pov 3.7.

 After discussing with Blender developers, it appears that when we use border
render, Blender expects a partial image not one with black, so the problem was
actually opposite to what I thought it was: POV-Ray's filling its image with
black provides a full size image whereas blender is expecting a tile. Blender
developers have chosen to provide a cropped partial image to allow more
flexibility for things like renderfarm setups or custom compositing pipelines,
if I understood correctly.
Now that the problem is clearer Blender developers will probably work around it,
but an option to chose tile/padded from POV could also be nice for the future if
it doesn't exist already.

Post a reply to this message