"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