On Tue, Apr 15, 2014 at 9:46 AM, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
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)

Yes.  More precisely it's likely that one of the functions transposes the image to get the correct orientation while the other does not.  Matt's effort will hopefully make it so everything is oriented in a uniform manner.  It will also make it easy for us to generalize to cylindrical and spherical coordinates.

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

Here's step one:



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

Michael Zingale
Associate Professor

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

yt-dev mailing list