<div dir="ltr">Matt, does this explain why in a notebook the orientation of a volume rendering resulting from cam.show() is wrong compared to when you do write_png() on the result of cam.snapshot() <div><br></div><div>(I see gravity going sideways instead of vertically in one of my plots)</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 15, 2014 at 11:47 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
Here's step one:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/pull-request/821/abstract-out-all-axis-information/diff" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-request/821/abstract-out-all-axis-information/diff</a><br>
<br>
-Matt<br>
<br>
On Fri, Jan 31, 2014 at 12:03 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> On the hangout today we talked about this and I did some digging into<br>
> how yt manages arrays, and how this comes out in matplotlib.<br>
> Basically, there are two things going on.<br>
><br>
> One is: what do we want our pixel coordinates to be?  When dealing<br>
> with images, typically [0,0] is the upper left of the *image*.  This<br>
> is also what yt does -- except, it corresponds to the origin in the<br>
> coordinate system.  Basically, our origin corresponds to the origin,<br>
> but in images, this is y-axis flipped.<br>
><br>
> Fortunately, matplotlib handles this gracefully with an origin=<br>
> keyword.  You can state that origin='lower', which flips the y-axis of<br>
> the image, thus putting 0,0 at the bottom left.  This works if you<br>
> only care about using matplotlib to plot things -- but if you want to<br>
> take your image buffer somewhere else and save it, it's now opposite<br>
> what you'd get out of matplotlib.<br>
><br>
> And thus we enter into the issue of the volume rendering, which we<br>
> typically save out using a direct png writer, which by default will<br>
> flip the axes and write it out.  But I'm wondering what the right<br>
> approach is.  I see two options:<br>
><br>
>  * Fix the way we pixelize images so that the *lower left* matches the<br>
> origin of the coordinate system.  We would no longer use<br>
> origin='lower' in our matplotlib calls.<br>
>  * Use origin='lower' everywhere, and assume that FRBs and whatnot<br>
> will be correctly pixelized by the individual getting them back out.<br>
><br>
> I am inclined toward the first option, but because it's invasive and<br>
> actually changes the way our images are generated, I wanted to get a<br>
> feeling from the group.  We're now breaking convention somewhat, and<br>
> our integer and coordinate system values won't match up in the y axis<br>
> anymore.<br>
><br>
> -Matt<br>
><br>
> On Fri, Jan 17, 2014 at 1:45 PM, Cameron Hummels <<a href="mailto:chummels@gmail.com">chummels@gmail.com</a>> wrote:<br>
>> I agree with Nathan.  I filed a bug to this effect a few weeks ago<br>
>> demonstrating that one gets different orientations (transposes) out of the<br>
>> volume rendering infrastructure than out of the Projection infrastructure<br>
>> with the same inputs.  This is very confusing and I think should be<br>
>> remedied.  Good call, Matt.<br>
>><br>
>><br>
>> On Fri, Jan 17, 2014 at 11:38 AM, John ZuHone <<a href="mailto:jzuhone@gmail.com">jzuhone@gmail.com</a>> wrote:<br>
>>><br>
>>> On Jan 17, 2014, at 1:35 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> To clarify further: I'd ideally like to see these two function calls<br>
>>> produce identical plots:<br>
>>><br>
>>> ProjectionPlot(pf, 2, 'Density')<br>
>>> OffAxisProjectionPlot(pf, [0,0,1], 'Density')<br>
>>><br>
>>> without having to specify a north_vector by hand for the second plot.<br>
>>><br>
>>><br>
>>> This is my biggest reason for wanting to see this fixed.<br>
>>><br>
>>> _______________________________________________<br>
>>> yt-dev mailing list<br>
>>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Cameron Hummels<br>
>> Postdoctoral Researcher<br>
>> Steward Observatory<br>
>> University of Arizona<br>
>> <a href="http://chummels.org" target="_blank">http://chummels.org</a><br>
>><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Michael Zingale</div><div>Associate Professor</div><div><br></div><div>Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800</div>
<div><i>phone</i>:  631-632-8225</div><div><i>e-mail</i>: <a href="mailto:Michael.Zingale@stonybrook.edu" target="_blank">Michael.Zingale@stonybrook.edu</a></div><div><i>web</i>: <a href="http://www.astro.sunysb.edu/mzingale" target="_blank">http://www.astro.sunysb.edu/mzingale</a></div>

</div>