Hi,

In previous version, 3.6, I have been using something like:

% povray +W640 +H480 +A0.3 -J0.0 +FN +O- source.pov

This was called from a CGI script, and the progressive PNG output went directly
to the client browser.

However, in no way can I trick POVRAY 3.7beta25b to do this. It simply creates
file "-.png", and even this file isn't populated progressively, but on the end
of the rendering from the file -.pov-state.

-.pov-state is of unknown format, and AFAIK there's no way to squeeze a
progressive PNG output out of there.

For bigger interactive rendering it is crucial to have some output progressively
come out, or the browser will timeout, doing unwanted things, like offering i.e.
to save file povdriver.cgi of 0 bytes.

Is there a way to get progressive output out of POV-Ray 3.7 SMP?

Thanks & rgds,
Marvin

Post a reply to this message

Marvin wrote:
> Hi,
> 
> In previous version, 3.6, I have been using something like:
> 
> % povray +W640 +H480 +A0.3 -J0.0 +FN +O- source.pov
> 
> This was called from a CGI script, and the progressive PNG output went directly
> to the client browser.
> 
> However, in no way can I trick POVRAY 3.7beta25b to do this. It simply creates
> file "-.png", and even this file isn't populated progressively, but on the end
> of the rendering from the file -.pov-state.

There never was a guarantee that output would be progressive if you output a 
image to a piped file. What you do is actually not even supposed to work in 
3.6, and in reality it does not work right even in 3.6 as you are not 
receiving a valid PNG image if you display it intermittently. Due to the way 
SMP rendering works with blocks, the only way to output images is at the end.

However, I can indeed see that what you would like to do is very useful! So 
turning your report into a feature suggestion, I would say enabling a kind 
of raw output is what you could most easily use. Given you can set block 
size, your script would know it, you could then use that format of the 
preview blocks within your CGI script for processing and send them wherever 
you want. Of course, you end up with something more like a "web 2.0" 
application that way.

Actually implementation of the output would be relatively simple on the 
POV-Ray side, but I guess this feature will get low priority as long as 
there are major bugs to fix...

	Thorsten, POV-Team

Post a reply to this message

Thorsten Froehlich wrote:
> Actually implementation of the output would be relatively simple on the 
> POV-Ray side, but I guess this feature will get low priority as long as 
> there are major bugs to fix...

one approach we could take is to output the raw blocks of pixels in float
format (basically just the raw pixels along with a simple header saying
what the dimensions are) and allow a post-processing pipe to sort it out.

in the simplest form a user could set the block size to the width of the
render and height of one pixel (just hope they aren't using AA!:) so the
program it's piped to would only need to cache lines that are received out
of sequence before converting and outputting them into whatever format is
desired.

We could probably without too much effort provide a filter program that
caches blocks (of whatever dimension) until entire lines are able to be
resolved in the required sequence and then writes them to stdout in a
format usable by other popular unix graphic filters (e.g. netpbm).

in terms of the original poster's requirements, another option is that (if
each render block is large enough to be useful in the following manner) to
have things so that each block is itself a stand-alone PNG file, and the
web page has a matrix of these PNG's so they form a whole image. I.e. you
use the web browser to do the compositing for you ;)

-- Chris

Post a reply to this message

Chris Cason wrote:
> in terms of the original poster's requirements, another option is that (if
> each render block is large enough to be useful in the following manner) to
> have things so that each block is itself a stand-alone PNG file, and the
> web page has a matrix of these PNG's so they form a whole image. I.e. you
> use the web browser to do the compositing for you ;)

That's what I did to preview how my network rendering was going:
http://impfarm.imp.org/boinc/sample_results/cups.php

Files are put there by the server when clients upload them, so just by
refreshing the webpage I could see what new tiles were finished.

Post a reply to this message

Chris Cason wrote:
> Thorsten Froehlich wrote:
>> Actually implementation of the output would be relatively simple on the 
>> POV-Ray side, but I guess this feature will get low priority as long as 
>> there are major bugs to fix...
> 
> one approach we could take is to output the raw blocks of pixels in float
> format (basically just the raw pixels along with a simple header saying
> what the dimensions are) and allow a post-processing pipe to sort it out.

I was more thinking about byte output as it is easier to process. I.e. two 
bytes x/y each plus one byte block size plus pixels in rgb one byte each. 
Quite enough for a _preview_, and easy to process compared to floats when 
using a scripting language or as a beginner programmer.

	Thorsten

Post a reply to this message

Chris Cason wrote:
> in terms of the original poster's requirements, another option is that (if
> each render block is large enough to be useful in the following manner) to
> have things so that each block is itself a stand-alone PNG file, and the
> web page has a matrix of these PNG's so they form a whole image. I.e. you
> use the web browser to do the compositing for you ;)

Well, big blocks and web preview seem contradictory to me :-) Of course, on 
the script side he will have to do this anyway, but I guess it is more 
flexible if he can compress the bytes he gets himself. As you know, PHP and 
various other scripting languages have image handling built in (with the 
right compile options)...

	Thorsten

Post a reply to this message