Re: [yt-dev] Orientation, coordinate systems

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 wrote:

Hi everyone,

Here's step one:

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

-Matt

...

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

On Fri, Jan 31, 2014 at 12:03 PM, Matthew Turk wrote: 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 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