POV-Ray

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.

Tasklist

FS#29 - Re-implement image output to STDOUT

Attached to Project: POV-Ray
Opened by Chris Cason (chrisc) - Monday, 18 May 2009, 04:09 GMT
Last edited by Christoph Lipka (clipka) - Saturday, 09 February 2013, 10:39 GMT
Task Type Unimp. Feature/TODO
Category Frontend → Image format
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version 3.70 beta 32
Due in Version 3.70 beta 39
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.

This task depends upon

Closed by  Christoph Lipka (clipka)
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)
Comment by Christoph Lipka (clipka) - Monday, 18 May 2009, 18:43 GMT

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.

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 24 September 2009, 19:23 GMT

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.

Comment by Thorsten Fröhlich (thorsten) - Sunday, 20 June 2010, 07:05 GMT

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.

Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 24 October 2010, 13:52 GMT

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 ?))

Comment by Christoph Lipka (clipka) - Saturday, 30 October 2010, 15:32 GMT

"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.)

Loading...