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

[Michael Zingale]

Ok, if the new VR will follow shortly, then I agree, we should wait.  I
almost figured out all the of hacks needed to get a white background (we
discard alpha in some places, like in show_mpl(), we do:

        ax = self._pylab.imshow(nim[:,:,:3]/nim[:,:,:3].max(),
origin='lower')

instead of

        ax = self._pylab.imshow(nim[:,:,:]/nim[:,:,:].max(), origin='lower')

but there is more going on.  So I'll stick with black for now, and help
test the new renderer when it comes online.

But I do think we should have up be up in all the output for 3.0.


On Thu, Jul 31, 2014 at 12:23 PM, 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
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140731/16874814/attachment.html>