"Wolf" <nomail@nomail> wrote:
> 8<==================================================
> When rendering a subset of *columns* (+sc/+ec) POV-Ray generates a full width
> image and fills he 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.
> ===================================================>8

Doesn't the PNG format already support things like a separate set of canvas and
offset attributes? I.e., with this format you can make the image canvas have
greater dimensions than the actual image data, and you can specify how much the
image data is offset from the corner of the canvas. I thought I read something
to the effect in the ImageMagick documentation.



Well, I just looked it up and the format parameters may not provide the same
flexibility as I recalled. See here:

http://www.imagemagick.org/Usage/formats/#png_offsets

While ImageMagick does in fact work in the way I described, the above page
mentions a caveat with regard to the PNG format. I'm not sure to what extent
the format is limited, as I didn't quite understand the explanation completely.
Also, I looked and there's no mention of "canvas" or "offset" in the W3C
specification, so it can't be relied upon to clarify the issue.

http://www.libpng.org/pub/png/spec/iso/index-object.html

-Mike

Post a reply to this message