"Wolf" <nomail@nomail> wrote:
> The main issue with the partial images is that Povray writes the image file in a
> non-standard way in order to keep the created image files small, this prevents
> most image manipulation programs from reading the file.
> The file declares itself to contain the data of the complete image (the image
> headers width and height information is set to the full image size), but in
> reality it contains just the number of rows having been rendered by the partial
> image. Most image manipulation programs are trying to read as many data as
> declared in the image header, resulting in an unexpected-end-of-file while

>

> behaviour:
> 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
>
> The main problem is to find a image manipulation program being able to handle

> file.
>
> Cheers,
> Wolf

Like I explained before, I render partial images in order not to have to render
again for days in case anything goes wrong.
So, in that case it's better to define each partial image at the full height,
and only limit the number of columns. I briefly tested this, and indeed I can
open the partial image in Photoshop! Thanks.

BTW, I guess you meant GIMP is *indeed* able to read a partial-image PNG.

Steven

Post a reply to this message

"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

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> "stevenvh" <nomail@nomail> wrote:
> > Warp <war### [at] tagpovrayorg> wrote:
> > > stevenvh <nomail@nomail> wrote:
> > > > I made a set of partial images using Start_Column, End_Column, Start_Row and
> > > > End_Row.
> > > > Now I want to combine them, but Photoshop can't read the images. Are the files
> > > > not standard bitmap files (PNG in my case)?
> > > > Any tools around to do this?
> > >
> > >   Try with the Gimp. IIRC, it ignores the errors and reads the images.
> > > You can then re-save them.

GIMP seems to have a problem with the images after all. My complete image is
square and I made 4 partial square images, one for each quadrant.

1. The top-left opens all right, and after saving it again I can open it in
Photoshop.

2. The top-right, however, opens, but the image seems to be offset: the left
half is empty (shows checkerboard pattern), and the right half is black, which
makes sense since these are probably the top-left and bottom-left quadrants,
which weren't rendered anyway. How do I get rid of the offset?

3. Bottom-left opens and saves alright, though afterward it seems to have moved
to the top-left position.

4. Bottom-right only shows a black square in the bottom-right quadrant, no
rendering.

Since neither GIMP and Photoshop (and possibly other image editors as well) can
open the partial images properly, I think POV-Ray should change the way partial
images are saved, i.e. not truncated.
This should not be too hard, and the change is limited to saving. (It doesn't
involve the render engine, for instance.)

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
> This should not be too hard, and the change is limited to saving. (It doesn't
> involve the render engine, for instance.)

It appears more problematic than you suggest.  As the documentation reflects
(and Wolf mentioned above):

"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." (3.1.2.2.2)

This behavior was a deliberate choice.  Not that this means the behavior
shouldn't be reconsidered, just that it isn't arbitrary or accidental.

Post a reply to this message

"How Camp" <hac### [at] gmailcom> wrote:
> "stevenvh" <nomail@nomail> wrote:
> > This should not be too hard, and the change is limited to saving. (It doesn't
> > involve the render engine, for instance.)
>
> It appears more problematic than you suggest.  As the documentation reflects
> (and Wolf mentioned above):
>
> "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." (3.1.2.2.2)
>
> This behavior was a deliberate choice.  Not that this means the behavior
> shouldn't be reconsidered, just that it isn't arbitrary or accidental.

I guess you're right.
For PNG (and other formats that support it) the alpha channel could be used to
indicate which areas have been rendered. This also makes sense if you look at
the partial image as a common one: the rendered area is opaque, while the rest
of the image would appear transparent.
Alternatively, can't the information be included in the image's metadata. Again,
this may not be a solution for every image format.

Steven

Post a reply to this message

"stevenvh"  wrote in message
<web.48784dd67ec83d1bc0721a1d0@news.povray.org>:
> For PNG (and other formats that support it) the alpha channel could be used to
> indicate which areas have been rendered.

That does not work because of the Output_Alpha option, where the alpha
channel of the output image is significant.

Post a reply to this message

Slime wrote:
> Are you sure you're writing to a format that supports transparency?
> Specifying a filename that ends in .png isn't sufficient. You need to set
> the output file type to PNG or else you're just writing a bitmap file with
> a .png extension. The ini file you put in your other post doesn't have the
> output file type specified.

If he wasn't really using PNG, the files would open fine with any program.
AFAIK the PNG format is the only one where POV-Ray does something strange
in partial renders.

Post a reply to this message

stevenvh wrote:
> I made a set of partial images using Start_Column, End_Column, Start_Row
> and End_Row.
> Now I want to combine them, but Photoshop can't read the images. Are the
> files not standard bitmap files (PNG in my case)?
> Any tools around to do this?

I had to do some *ugly* stuff (modifying POV code) to get this right for my
purposes. I wanted: a correct PNG image output when rendering tiles, saving
to disk at specific "checkpoints" (by default every minute) instead of
letting POV save every few rows, and ability to resume rendering.

I disabled POV-Ray's built-in file output (-f), and in the hook that
notifies when a pixel is rendered, store the pixel in an in-memory buffer.
Every minute, I save that to disk (uncompressed), along with a header with
width, height, and last row rendered. When the render is restarted, if the
file exists, I load it, and use Start_Row(!) to make it resume on the last
row rendered. When the render finishes, I save it to a proper PNG.

I'm *sure* POV-Ray 3.7 new intermediate file format would help me avoid that
big mess...

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
> I made a set of partial images using Start_Column, End_Column, Start_Row and
> End_Row.
> Now I want to combine them, but Photoshop can't read the images. Are the files
> not standard bitmap files (PNG in my case)?
> Any tools around to do this?
>
> TIA
> Steven

If nothing else, PPM images are easier to parse, and you can manually fix the
dimensions with any old text editor.  They show up on about line three.  A very
short program could be made to parse the parts and assemble them, but of course
this is an exercise left for the reader...

 - Ricky

Post a reply to this message

triple_r wrote:
> short program could be made to parse the parts and assemble them, but of course
> this is an exercise left for the reader...

Actually, it isn't really. It's a few lines of shell script, if you take 
advantage of the pamcut and pamcomp programs. Google the man pages for 
details.  http://netpbm.sourceforge.net/doc/index.html

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message