|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Earlier versions of POV-Ray had problems when a subset
> of rows (+sr/+er) was rendered. The full height information was written into the
> image file header but it only wrote image data for those lines that were
> actually rendered...
>
> So, maybe if you set the version back, you'd get the same behaviour?
> Or maybe do the experiment in an old version?
>
> Perhaps there's a way to get the start/end columns and rows by looking at that
> data.
>
Strangely enough, I actually read that section in the docs this afternoon,
before posting-- but I didn't 'see' the implications you're talking about.
Yes, it's quite an interesting experiment to try. Until you mentioned it, it
didn't occur to me that POV-Ray might be able to actually #read an image's
header information-- which I assume is just some lines of text? (Although, I
just tried 'loading' a 'typical' JPEG image into POV-Ray, to see what would
happen; all I see are four strange-looking symbols, beginning with what looks
like a y. Maybe the 'true' header info isn't visible?)
For the 'old' behavior of POV-ray, per the new docs, it appears that the header
information may not even be usable anyway ("The FULL height information was
written into the image file header but it only wrote image DATA for those lines
that were actually rendered.") Sounds like one of those pieces of data was
correct, but not the other(?).
I do remember some partial-render problems from the old days, having to do with
such .png images not being viewable in other apps.
Post a reply to this message
|
|