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() 

(I see gravity going sideways instead of vertically in one of my plots)


On Tue, Apr 15, 2014 at 11:47 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi everyone,

Here's step one:

https://bitbucket.org/yt_analysis/yt/pull-request/821/abstract-out-all-axis-information/diff

-Matt

On Fri, Jan 31, 2014 at 12:03 PM, Matthew Turk <matthewturk@gmail.com> wrote:
> Hi all,
>
> On the hangout today we talked about this and I did some digging into
> how yt manages arrays, and how this comes out in matplotlib.
> Basically, there are two things going on.
>
> One is: what do we want our pixel coordinates to be?  When dealing
> with images, typically [0,0] is the upper left of the *image*.  This
> is also what yt does -- except, it corresponds to the origin in the
> coordinate system.  Basically, our origin corresponds to the origin,
> but in images, this is y-axis flipped.
>
> Fortunately, matplotlib handles this gracefully with an origin=
> keyword.  You can state that origin='lower', which flips the y-axis of
> the image, thus putting 0,0 at the bottom left.  This works if you
> only care about using matplotlib to plot things -- but if you want to
> take your image buffer somewhere else and save it, it's now opposite
> what you'd get out of matplotlib.
>
> And thus we enter into the issue of the volume rendering, which we
> typically save out using a direct png writer, which by default will
> flip the axes and write it out.  But I'm wondering what the right
> approach is.  I see two options:
>
>  * Fix the way we pixelize images so that the *lower left* matches the
> origin of the coordinate system.  We would no longer use
> origin='lower' in our matplotlib calls.
>  * Use origin='lower' everywhere, and assume that FRBs and whatnot
> will be correctly pixelized by the individual getting them back out.
>
> I am inclined toward the first option, but because it's invasive and
> actually changes the way our images are generated, I wanted to get a
> feeling from the group.  We're now breaking convention somewhat, and
> our integer and coordinate system values won't match up in the y axis
> anymore.
>
> -Matt
>
> On Fri, Jan 17, 2014 at 1:45 PM, Cameron Hummels <chummels@gmail.com> wrote:
>> I agree with Nathan.  I filed a bug to this effect a few weeks ago
>> demonstrating that one gets different orientations (transposes) out of the
>> volume rendering infrastructure than out of the Projection infrastructure
>> with the same inputs.  This is very confusing and I think should be
>> remedied.  Good call, Matt.
>>
>>
>> On Fri, Jan 17, 2014 at 11:38 AM, John ZuHone <jzuhone@gmail.com> wrote:
>>>
>>> On Jan 17, 2014, at 1:35 PM, Nathan Goldbaum <nathan12343@gmail.com>
>>> wrote:
>>>
>>> To clarify further: I'd ideally like to see these two function calls
>>> produce identical plots:
>>>
>>> ProjectionPlot(pf, 2, 'Density')
>>> OffAxisProjectionPlot(pf, [0,0,1], 'Density')
>>>
>>> without having to specify a north_vector by hand for the second plot.
>>>
>>>
>>> This is my biggest reason for wanting to see this fixed.
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev@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@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
_______________________________________________
yt-dev mailing list
yt-dev@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@stonybrook.edu
web: http://www.astro.sunysb.edu/mzingale