Matt, does this explain why in a notebook the orientation of a volume rendering resulting from 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 <> wrote:
Hi everyone,

Here's step one:


On Fri, Jan 31, 2014 at 12:03 PM, Matthew Turk <> 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 <> 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 <> wrote:
>>> On Jan 17, 2014, at 1:35 PM, Nathan Goldbaum <>
>>> 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
>> --
>> Cameron Hummels
>> Postdoctoral Researcher
>> Steward Observatory
>> University of Arizona
>> _______________________________________________
>> yt-dev mailing list
yt-dev mailing list

Michael Zingale
Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800
phone:  631-632-8225