Picture in picture bug in OSPRay Animation Export

Hey all, I’ve been doing a bunch of rendering using the OSPRay Pathtracing engine. One rather annoying bug that I have found is that when exporting an animation, occasionally you will get a smaller version of the image you are exporting in the bottom left of the main image. I have an example of it below.

image

It seems to happen to random timesteps in the animation but most often in the 2nd and 3rd image generated. In an animation of 100 images, probably about 7-10 of them will be affected by this. The only remedy I have found so far is to go back and export a screenshot of the images afterwards, but this is very time consuming for a large number of images with a high samples per pixel.

I was wondering if anyone else has ran into this bug and had any success addressing it?

Thanks!

Marston

I’ve seen/fixed similar problems in the past where the export was being done from the GUI and the exported image resolution was larger than the view, causing VTK/ParaView to go into stitching mode to make up the large images, which tripped up the accumulation mode we use for progressive refinement.

My guess is that this is happening again.

If you are building ParaView from source you can hardcode progressive refinement off as well here:
https://gitlab.kitware.com/vtk/vtk/blob/master/Rendering/RayTracing/vtkOSPRayRendererNode.cxx#L1170.

Otherwise, please try a smaller image and let me know if this hides the problem.

Hey Dave, thanks for the response. After some investigation it seems to be what you are describing. If I lock the image size to what is given in the view, it seems to fix the issue. I’ll look into the progressive refinement for the our next source build.

If we were running this in a headless mode instead of the GUI export, would this still be an issue?

Yes I expect pvbatch with an offscreen GL (EGL or OSMesa) would avoid the issue.

I experienced the same problem, and it persisted even when using pvbatch. I was initializing renderView1.ViewSize to the correct ratio but not the final size. Changing so that there is no scaling when calling SaveScreenshot fixed the issue. That is, this was fixed by setting the resolution of individual windows in the python script to add to the exact resolution at which they were eventually output. For example

... 
# set desired image resolution, note that (5120, 4320) = (640*4 + 640*4, 1080*4)
res = (5120, 4320) 
renderView1.ViewSize = [640*4, 1080*4] 
renderView2.ViewSize = [640*4, 1080*4] 
# ViewSize was [640, 1080] and this caused the problem 
... 
layout1 = CreateLayout(name='Layout #1')
layout1.SplitHorizontal(0, 0.5)
layout1.AssignView(1, renderView1)
layout1.AssignView(2, renderView2)
... 
SaveScreenshot('name.jpeg', viewOrLayout=layout1, ImageResolution=res, Quality=100, Progressive=1)

Was this ever fixed @Dave_DeMarle?

Most likely the bug is still present.