"SharkD"  wrote in message
<web.48748d777ec83d1be2244ea70@news.povray.org>:
> Alternately, try ImageMagick. It's a command-line tool that, though more
> powerful, takes a while to learn the ropes on.

Unfortunately, ImageMagick chokes on truncated files.

Post a reply to this message

"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.
> >
> > --
> >                                                           - Warp
>
> Hi Warp,
> thanks for the suggestion. Installed GIMP and it does read the files alright.
> However. In the POV-Ray render window the non-rendered area is checkered, so I
> presumed it would be transparent. My Photoshop-idea was to load all the files
> as individual layers, and then simply flatten the image.
> GIMP shows the non-rendered area as black, so the simple trick won't do.

Steven, you can use GIMP to do what you proposed doing with PhotoShop, scripted
or manually. Here's the manual method:

1. Open the first partial image in GIMP.
2. Use the Dialogs > Layers menu (F7 on Windows) to pull up a list of layers
3. Open the second partial image in GIMP and copy it.
4. Paste this partial image onto the first partial image
   (this makes a separate layer for the pasted image).
5. User menu Layer > New Layer (Shift+Ctrl+N)
6. In the Layers dialog set the pasted layer to mode: Screen.
7. Repeat 3-6 for each partial image.

This will ignore the black areas and make all the layers visible as a single
image at each step.

You can do the same thing in PhotoShop - experiment with the different layer
merge modes (Multiply, Lighten, etc.).

Hope this helps.

-Rob

"There is no spoon..."

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> Steven, you can use GIMP to do what you proposed doing with PhotoShop, scripted
> or manually. Here's the manual method:
>
> 1. Open the first partial image in GIMP.
> 2. Use the Dialogs > Layers menu (F7 on Windows) to pull up a list of layers
> 3. Open the second partial image in GIMP and copy it.
> 4. Paste this partial image onto the first partial image
>    (this makes a separate layer for the pasted image).
> 5. User menu Layer > New Layer (Shift+Ctrl+N)
> 6. In the Layers dialog set the pasted layer to mode: Screen.
> 7. Repeat 3-6 for each partial image.
>
> This will ignore the black areas and make all the layers visible as a single
> image at each step.
>
> You can do the same thing in PhotoShop - experiment with the different layer
> merge modes (Multiply, Lighten, etc.).
>
> Hope this helps.
>
> -Rob
>
> "There is no spoon..."

I would just like to add that if you do manage to create a script to do so,
please upload it to the wiki.

If not, posting this tutorial there would be a big help.

-Mike

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:

> Steven, you can use GIMP to do what you proposed doing with PhotoShop, scripted
> or manually. Here's the manual method:
>
> 1. Open the first partial image in GIMP.
> 2. Use the Dialogs > Layers menu (F7 on Windows) to pull up a list of layers
> 3. Open the second partial image in GIMP and copy it.
> 4. Paste this partial image onto the first partial image
>    (this makes a separate layer for the pasted image).
> 5. User menu Layer > New Layer (Shift+Ctrl+N)
> 6. In the Layers dialog set the pasted layer to mode: Screen.
> 7. Repeat 3-6 for each partial image.
>
> This will ignore the black areas and make all the layers visible as a single
> image at each step.
>
> You can do the same thing in PhotoShop - experiment with the different layer
> merge modes (Multiply, Lighten, etc.).
>

Thanks Rob, that's indeed what I would do in Photoshop if only it would open the
files :-)
Actually, F7 is the Photoshop way to bring up the Layers menu, in GIMP it seems
to be Ctrl-L. Screening is also what you do in PS. And in your manual method
step 5 isn't necessary.

The thing is, this is a HUGE image (400 megapixels) and placing layer upon layer
asks a lot of computer resources, unless you flatten layers after every step 6.
Still takes a lot of time though.
And I guess I made a wrong choice about the size of the partial images; there's
too many of them to do the operation by hand.

Thanks again.
Steven

Post a reply to this message

Nicolas George wrote:

> Why in the world would you suggest to quit Gimp and start another bloatware
> that does the same work.


He declared he's more knowledgeable with photoshop and wanted to use it
for the actual "merge".

I'd personally never merge together partial images, I consider that
feature for scene *development* only. The final rendering is, in my
opinion, a sacred process never to be interrupted :)

Post a reply to this message

Alessio Sangalli <ale### [at] manowebcom> wrote:
> Nicolas George wrote:
>
> I'd personally never merge together partial images, I consider that
> feature for scene *development* only. The final rendering is, in my
> opinion, a sacred process never to be interrupted :)

True, but the process doesn't always see it that way. Very frustrating if a job
aborts after being rendering for a week. All in agreement with the Laws of
Conservation of Misery. :-)


huge image + radiosity > 1 week

Post a reply to this message

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

Post a reply to this message

So, in the end, is this a problem with POV-Ray (i.e., should the program be
altered to make it more convenient for users to accomplish tasks such as
these), or a problem with image editing software not supporting the PNG format
properly??

-Mike

Post a reply to this message

"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