povray icon indicating copy to clipboard operation
povray copied to clipboard

Port of FS282 - Unrendered region (with +sc/+sr/+ec/+er) should be transparent, not black

Open wfpokorny opened this issue 7 years ago • 1 comments

http://bugs.povray.org/task/282 (Timwi (Timwi))

(Behavior remains unchanged in master and release/3.7.1)


Details:

When rendering only a region of a file, using the command-line options +sc/+sr/+ec/+er, the area of the image that is excluded comes out as black in the final PNG.

Expected behaviour is for it to be transparent.


Comments:


Comment by Thorsten Fröhlich (thorsten) - Sunday, 24 March 2013, 19:28 GMT+5

The behavior is expected. The pixels are never filled, as you explicitl requested them to not be renderd. The background in a scene only applies to pixels rendered.


Comment by Timwi (Timwi) - Monday, 25 March 2013, 01:54 GMT+5

This report is not referring to the background in a scene at all. The unrendered region should simply always be transparent -- after all, as you correctly pointed out, it is not rendered. It should not be filled with black.

Please reopen as the closer misunderstood the bugreport.


Comment by Thorsten Fröhlich (thorsten) - Monday, 25 March 2013, 02:00 GMT+5

Did you read the response to your report 283?


Comment by Timwi (Timwi) - Monday, 25 March 2013, 02:19 GMT+5

Report 283 is completely unrelated to this one. Report 283 is about "background { ... }". This one is not. This one is about +sc/+sr/+ec/+er.


Comment by Timwi (Timwi) - Monday, 25 March 2013, 02:21 GMT+5

But to answer your question, yes, I read it, and I tried +UA, and it still comes out as opaque black.


Comment by Christoph Lipka (clipka) - Monday, 25 March 2013, 03:30 GMT+5

I think it is reasonable to expect unrendered portions of the image to come out transparent when alpha support is enabled for the output file. After all, the preview window also still shows the checkerboard pattern in those regions. I therefore re-opened this issue as a feature request.


Comment by Thorsten Fröhlich (thorsten) - Monday, 25 March 2013, 12:55 GMT+5

I think it is reasonable to expect unrendered portions of the image to come out transparent when alpha support is enabled for the output file. After all, the preview window also still shows the checkerboard pattern in those regions. I therefore re-opened this issue as a feature request.

I agree, it would be a useful feature. Of course, we had been discussing if we want a full image generated for a partial render or not for a long time anyway. Once we add a choice for that, we can also change the current behavior.


Comment by Simon (infoised) - Tuesday, 26 March 2013, 23:36 GMT+5

Just an opinion to consider: outputting a partial render with transparent unrendered parts can be extremely useful. In cases when a small part of the image changes, and the rest stays the same (this is ok if there's no radiosity and reflections), rendering speed can be significantly increased if only the changing part is rendered, and then the partial image is composited over a single render of surroundings. Let's say, a render of animation that includes a rotating or morphing object in static environment (common in scientific presentations). Having a transparent background makes the compositing a trivial operation. The same technique can be used to distribute rendering across different machines (such as ad-hoc cluster over ssh): chunks can be easily merged if the unrendered parts are transparent.

wfpokorny avatar Apr 21 '17 11:04 wfpokorny

I fully agree that unrendered image portions should be transparent (if supported by the output format), rather than simply black - both because it probably makes further processing easier in most cases, and also because it would make the behaviour consistent with that of the output window. So from my perspective the only question remaining is how to implement it.

Maybe the easiest way would be to simply initialize all image data containers with R=G=B=0% and transparency=100%, instead of transparency=0% as it is now.

That, in turn, would be easiest if the image data containers were designed to store opacity rather than transparency, as in that case it would mean simply initializing all components of the image data with 0.

In other words, this looks like a refactoring job to me.

c-lipka avatar May 15 '17 10:05 c-lipka