[yt-users] Consistent brightness in volume rendering movies

[Wolfgang Kastaun]

Ok, thanks for clarifying the situation.

I think the first part of my problem, preventing the rescaling, is just 
a matter of not calling draw_domain(), but copy the part that does the 
actual drawing. The code of draw_domain() turns out to be very short:


-------------------
#This is what I want to avoid, so just don't copy it:
nim = im.rescale(inline=False)
enhance_rgba(nim)

#This does not seem to have any effect anyway, changing color to white 
still gives a black background. Probably the alpha channel is 1 everywhere.
nim.add_background_color('black', inline=True)


#This is the only part I actually need:
self.draw_box(nim, self.ds.domain_left_edge, self.ds.domain_right_edge,
                         color=np.array([1.0,1.0,1.0,alpha]))
-------------------


For the second part, choosing a constant scaling factor for the 
luminosity, I'll compute it for one representative frame, then keep it 
constant throughout the movie, and limit it to the maximum possible 
value. This will replace my problem by a lesser one, that is possible 
over-saturated parts.


On 10/30/2015 04:37 PM, Nathan Goldbaum wrote:
> Hi Wolfgang,
>
> Yes, this is definitely an issue with the volume rendering infrastructure.
> I *think* the reason this is happening is because the draw_domain function
> is calling the `enhance_rgba` function internally, which is supposed to
> yield a more pleasing contrast. As far as I can see, there isn't a way to
> prevent this from happening, and i'm not sure off-hand why it was
> originally written that way. A quick hack would be to see what happens when
> the call to enhance_rgba in the draw_domain function is commented out.
>
> In any case, we are currently in the middle of refactoring the volume
> rendering interface to use a new "scene" paradigm (see
> http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0010.html for a high-level
> description). This code is currently available on the 'experimental'
> bookmark in the main yt repository. That said, I'm not sure whether this is
> still an issue in the new VR infrastructure.
>
> Overall, getting pleasing-looking movies without flickering is still
> somewhat difficult due to the design of yt's ray-tracing volume renderer.
> The absolute luminance of any cell can vary quite a lot depending on the
> structure being volume rendered and the transfer function.
>
> Sorry to not have a more satisfactory answer. I hope this offers a bit more
> context about why what you're seeing is happening.
>
> -Nathan
>
> On Fri, Oct 30, 2015 at 9:54 AM, Wolfgang Kastaun <physik at fangwolg.de>
> wrote:
>
>> Hi,
>>
>> I am trying to assemble Yt volume renderings into a movie using moviepy,
>> which essentially takes a numpy rgb array for each frame and produces a
>> video.
>>
>> However, I am a bit confused on the absolute luminosity in volume
>> renderings.
>>
>> It seems that adding annotations via cam.draw_domain() does not only draw
>> the domain, but also adjusts the image brightness, which is a bit
>> surprising. I did not notice that when using cam.save_image() for a single
>> frame instead using the image array directly, apparently the former does
>> adjust brightness as well.
>>
>> I want to avoid rescaling based on average or maximum brightness *of a
>> single frame* in a movie, because this is misleading.
>> The brightness of a pixel should only depend on the data along the
>> corresponding ray, not on the other rays as well. Rather, the scale should
>> be constant during the movie. I know it is probably difficult, but is there
>> a way to estimate a reasonable scaling from the expected data range of the
>> whole evolution and the size of the domain? Also which other functions
>> besides cam.draw_domain() do implicitly adjust the brightness?
>>
>> Regards,
>> Wolfgang Kastaun.
>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>