Gang

I am using POV 3.5 under XP Professional.
I am rendering the woodenbox demo at 640 x 480.
When I look at the generated woodenbox.bmp everything is A-OK.

I then move my mouse and select a center region from the rendered image.
I then render it again.
When I look at the woodbox.bmp the background is all black as I had hoped.
But the region I selected is not in the center of the woodenbox.bmp.

The dimensions are correct. and the X offset is correct. But the Y offset is
0 so it is shifted
up against the top of the BMP.

I looked at the MESSAGES window and it said

"Output Options
  Image resolution 640 by 480 (rows 94 to 306, columns 188 to 423)."

The values are correct but the resulting BMP is incorrect.

Is this a bug or am I doing something wrong?

Bob

Post a reply to this message

-[Is this a bug or am I doing something wrong?]-
As far as I'm aware, its a bug. I've noticed the same behaviour too. It's a
fairly easy bug to spot, so perhaps there is an advantage to rendering in
this way which the developers have thought of?

-Chris

Post a reply to this message

Chris Johnson <chr### [at] chris-jcouk> wrote:
> -[Is this a bug or am I doing something wrong?]-
> As far as I'm aware, its a bug.

  As far as I'm aware, it's not a bug.

  AFAIK this behaviour is by design. I don't claim it's the best design,
but there's no programming error, but it works exactly as designed.

  The idea with partial renders is that you can for example put several
computers to render parts of a single image and then have a program join
all the parts. The rendered image is located at the beginning of the image
file in each result.

  I agree, however, that perhaps POV-Ray should support rendering in a
what-you-see-is-what-you-get (in the image file) way as an additional option.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

news:3fd47ce9@news.povray.org...

>   The idea with partial renders is that you can for example put several
> computers to render parts of a single image and then have a program join
> all the parts. The rendered image is located at the beginning of the image
> file in each result.

The confusing part is that this not true when the rendered image starts at
+SCx.x with x>0.
The starting x position is apparently saved in the BMP while the starting y
is not. When I render +sc0.8 +ec0.9 +sr0.5, all the viewers I have return an
image with a strip of rendered bits at +sc0.8 +ec0.9 but at y=0. The
consequence is that it's not possible to layer directly the re-rendered part
on the original render and that it has to be repositioned by hand (I make
the pixels half transparent to make sure that the superposition is precise).
It's not a major issue for most people, but it still makes things a little
more difficult for the few who make composite POV-Ray images.
Ditto for TGA images, btw, with the difference that the lines below the last
one repeat it (they're interepreted as black in a BMP).

G.

-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Mon, 8 Dec 2003 17:33:59 +0100, "Gilles Tran" <tra### [at] inapginrafr> wrote:
> "Warp" <war### [at] tagpovrayorg> a écrit dans le message de
> news:3fd47ce9@news.povray.org...
>
> >   The idea with partial renders is that you can for example put several
> > computers to render parts of a single image and then have a program join
> > all the parts. The rendered image is located at the beginning of the image
> > file in each result.
>
> The confusing part is that this not true when the rendered image starts at
> +SCx.x with x>0.

I suppose that's because joining complete rows is much more popular (could
require less memory if any) than joining parts of rows for large images.

ABX

Post a reply to this message

Gilles Tran wrote:
> 
> The confusing part is that this not true when the rendered image starts at
> +SCx.x with x>0.
> The starting x position is apparently saved in the BMP while the starting y
> is not. When I render +sc0.8 +ec0.9 +sr0.5, all the viewers I have return an
> image with a strip of rendered bits at +sc0.8 +ec0.9 but at y=0. The
> consequence is that it's not possible to layer directly the re-rendered part
> on the original render and that it has to be repositioned by hand (I make
> the pixels half transparent to make sure that the superposition is precise).
> It's not a major issue for most people, but it still makes things a little
> more difficult for the few who make composite POV-Ray images.
> Ditto for TGA images, btw, with the difference that the lines below the last
> one repeat it (they're interepreted as black in a BMP).

This is exactly as it should be, notwithstanding Warp's suggestion for 
an additional feature.  You have to bear in mind a few things:

- a lot of file formats do not support any information about the image 
geometry except width and height.
- for those file formats that support additional information (for TGA 
for example POV-Ray stores more than just width and height) nearly no 
imaging program reads it.
- while the height of the image is not necessary to know for reading 
most file formats (you can conclude it from the file size) the width is 
required to correctly display the image.  Therefore POV-Ray has to use 
the width of the actual render size.  For the height it uses the 
complete image height (which is necessary for a continued trace) 
although a lot of imaging programs blindly rely on height information 
and actual size being identical (what you see below the actual image 
data in your imaging program completely depends on that program).
- adding a 'black rim' around the render would be possible but at the 
cost of much larger images, slower renders, increased network traffic 
for render farms, ...

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Even so, putting the rendered part of the image where it would appear if the
full image had been rendered would not require any more memory or additional
information in the image file, since Pov-ray exports the full sized image
anyway. I have no problem with exporting a full size image with the
unrendered parts in black, but I still don't see the circumstance in which
having the part of the image that is rendered shifted by some amount is more
useful than having it in its original position. It's not as if one could
save file size this way by omitting the end bytes of the image, since in
most file formats this would be illegal anyway, and in formats that are
stored "upside-down" such as .bmp, the data comes at the end of the image
anyway.

Perhaps I just don't understand though...

-Chris

Post a reply to this message

On Tue, 9 Dec 2003 01:58:38 -0000, "Chris Johnson" <chr### [at] chris-jcouk>
wrote:
> Even so, putting the rendered part of the image where it would appear if the
> full image had been rendered would not require any more memory or additional
> information in the image file

But would require to manually specify to external processes where rendered
part starts. Having only important rows makes it easy to glue list of images.

> I have no problem with exporting a full size image with the
> unrendered parts in black, but I still don't see the circumstance in which
> having the part of the image that is rendered shifted by some amount is more
> useful than having it in its original position.

I see it that way: You are probably GUI oriented with thinking that you can
everything see, everything click, everything select, everything control trough
dialog boxes. You have to remember that POV-Ray is mature, over 10 years old
universal engine and a few persons used and still use it from command line to
operate on render farm from one console. Then rendered parts are glued into
resulting image using some single command line like:

  join_images image1.png+image2.png+image3.png > image.png

Do you imagine how difficoult it would be to maintain coordinates for every
prerendered part by hand for such command line ?

ABX

Post a reply to this message

-[Having only important rows makes it easy to glue list of images]-
But Pov-ray exports all the rows, not just the important ones.

-[You are probably GUI oriented]-
No, but carry on...

-[rendered parts are glued into resulting image using some single command
line like]-
That's fair enough, but the way pov-ray currently works requires extra
coordinates being maintained separately, since the y position of rendered
parts is "forgotten" by moving them all to zero. If I was writing a program
to glue images as you describe, and if pov-ray exported images in the
correct place, all I would have to do is allocate memory for the final image
size (found by looking at the size of any one of the parts) and then scan
each of the parts, copying to the allocated memory every pixel that was
opaque / non-black (depending on the image format).

With the current method, I would have to provide an extra file specifying in
what order the images came vertically, since I would not know just by
looking at the content of the files.

-Chris

Post a reply to this message

On Tue, 9 Dec 2003 01:58:38 -0000, "Chris Johnson" <chr### [at] chris-jcouk>
wrote:
> Perhaps I just don't understand though...

I really shouldn't answer base only on memory. After some testing I see your
observations are correct I'm not sure it was intentionall behaviour or not.

ABX

Post a reply to this message