The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Chris Cason - 2009-05-18
Last edited by Christoph Lipka - 2013-02-09
FS#29 - Re-implement image output to STDOUT
Versions of POV-Ray prior to 3.7 had the ability to write the image output as a stream to STDOUT. This was particularly useful in unix as it allowed POV-Ray output to be directly piped to other processes.
The introduction of SMP and the associated non-linear generation of pixels complicates stream output to the extent that it is not currently available in v3.7.
At a minimum 3.7 must at least be able to write the completed image to STDOUT after a render - this is not an optimal solution but is better than nothing. Ideally however once entire lines are complete (most likely this will occur in batches due to the block nature of the render subdivision) these lines will be written immediately to STDOUT (after possibly being processed through the appropriate image format routines).
NB currently the image format routines are not invoked until the entire render is completed, so to do this would be a significant modification. However if we limit real-time stream output to “simple” non-compressed formats (e.g. PPM), it would not be overly difficult, and from the point of view of Unix-like operating systems (where the piping feature is most useful), if the data is in PPM format it can easily be transformed into anything else.
Saturday, 09 February 2013, 10:39 GMT
Reason for closing: Fixed
Additional comments about closing:
Reported as working in 3.70 beta 39;
opened a new task to request
re-implementation of progressive output
(FS#172)
Progressive file output should not only be re-implemented for STDOUT, but also for regular file output, e.g. to preview already-rendered parts of a shot when preview window is not available for some reason.
Is the initial need about getting pixel as they are rendered, or as a linear flow (possibly at the very end of the rendering) ?
To get back to linear pixel rendering, with the current block distribution code, one could limit the number of thread to 1 (WT/Work_Threads) and the block size to 1 (BS / Render_Block_Size).
That would make preview as before.
But it won't provide data before the last pixel is ready.
Linear flow is already there, if it is possible to indicate (and trap) the "-" filename (as in "-O - ") : check needed, afraid not working.
I do not see a need for progressive output, though I imagine that final output would be useful for piping on Unix. One simple solution (without major tweaks to existing code, and with the added benefit of long term robustness for network transfers) would be to write to a temporary file and simply pass that on afterwards. This would avoid all the wacky code that depends on the output file libraries handling stdout streams correctly.
For what it is worth, "-O- " does work. (in beta 39 at least, on linux). So no need to change anything.
(progressive output: it's a no-no now; moreover, most output format have a header, some compression which are usually more that 1D and often a trailer, so no real gain for the consuming process to get the picture's bits on the fly (excepted for uncompressed raw output format ?))
"Semi-progressive" output could (theoretically) still be implemented (with file formats fit for it), by outputting data every time a row of blocks has been fully completed. Only question is whether it would be worth the pain of doing a major re-design of file output. (Current file format writing code only supports writing a complete image.)