[yt-dev] Issue #873: volume rendering set_background does not work (yt_analysis/yt)

Matthew Turk matthewturk at gmail.com
Thu Jul 31 09:51:27 PDT 2014


Have to run for a while, but I think the main issue with direct PNG writing
and access is that upper left is pixel 0,0. And then we changed our PNG
engine (John?) which may take different code paths.

As for camera, it's getting there - Sam made a lot of progress, and I even
used it for the final seismodome renders. It's in the "scene" bookmark in
my repo. We only didn't finish it because of a desire for polish.
On Jul 31, 2014 11:23 AM, "Cameron Hummels" <chummels at gmail.com> wrote:

> Hi Michael,
>
> There are a few of us who are working on rewriting the entire camera
> interface.  It was originally supposed to go out in 3.0, but there were
> some delays.  I think once 3.0 is out, the new interface won't be too far
> behind.  So as far as modifying the draw_domain and save_annotated
> functions to work within the new background color stuff, it might make more
> sense to hold off until we get the new framework up and running.  But we'll
> definitely try to keep this functionality interoperable.
>
> About the orientation issue, I'm not sure.  Perhaps Matt or Sam can speak
> to the orientation issues with write_png?  I see that when we call
> "write_png" it does this:
> return write_bitmap(out.swapaxes(0, 1), filename)
>
> But then write_bitmap goes to a different (png_writer) write_png, which
> then goes to use matplotlib's write_png tools.  After all that jumping I'm
> not sure the orientation, but I think there are still some residual
> orientation issues, as you can see here with the two plots generated here
> in the docs from nearly identical recipes (off-axis-projections use the
> camera interface which also makes the volume renderings):
>
>
> http://yt-project.org/docs/dev-3.0/visualizing/plots.html#off-axis-projection-plots
>
>  Again, though, I think this will be mostly addressed through the new
> camera interface in the next few months.
>
> Cameron
>
>
>
>
>
> On Thu, Jul 31, 2014 at 9:07 AM, Michael Zingale <
> michael.zingale at stonybrook.edu> wrote:
>
>> Hi Cameron, this answers a question I've had for a white, since I've been
>> trying to get a white background.  Two comments on the new cookbook recipe
>> you just posted -- are you sure that "up" is "up" in those images?  When I
>> use write_png, my image is upside down.  Secondary, do we want to try to
>> pass the transparent/white background stuff through the draw_domain and
>> save_annotated functions?  At the moment, draw_domain forces things to be
>> black, and save_annotated sets the facecolor of the resulting plot to black.
>>
>> Mike
>>
>>
>> On Thu, Jul 31, 2014 at 12:12 AM, Cameron Hummels <
>> issues-reply at bitbucket.org> wrote:
>>
>>> New issue 873: volume rendering set_background does not work
>>>
>>> https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_background-does-not
>>>
>>> Cameron Hummels:
>>>
>>> I tried to make a VR with different background colors by combining the
>>> two cookbook recipes:
>>>
>>>
>>> http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-background-colors
>>>
>>> http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume-rendering
>>>
>>> The resulting script is here:
>>>
>>> http://paste.yt-project.org/show/4978/
>>>
>>> Unfortunately, the 'background' keyword for `write_png` doesn't seem to
>>> work on real VRs.  All of the options end up yielding the original
>>> all-black background.
>>>
>>> When I dug into the code to figure out what was going on, it appears the
>>> problem is that the color channels are being normalized by the opacity
>>> channel prior to adding in the background color, and then renormalized by
>>> 1-opacity afterwards.  The VRs produced by the standard recipe yield a
>>> opacity=1 uniformly across the image, which essentially wipes out any
>>> changes from the renormalization.
>>>
>>> I can rip out this renormalization, or replace it with a rescale()
>>> function, but I wanted to make sure that wouldn't break other things.
>>>  Maybe this isn't worth changing since VR is getting a makeover soon.
>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>
>>
>>
>> --
>> Michael Zingale
>> Associate Professor
>>
>> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
>> 11794-3800
>> *phone*:  631-632-8225
>> *e-mail*: Michael.Zingale at stonybrook.edu
>> *web*: http://www.astro.sunysb.edu/mzingale
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140731/94a5097e/attachment.htm>


More information about the yt-dev mailing list