[yt-dev] Orientation, coordinate systems

Matthew Turk matthewturk at gmail.com
Fri Jan 31 09:03:11 PST 2014


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 at 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 at gmail.com> wrote:
>>
>> On Jan 17, 2014, at 1:35 PM, Nathan Goldbaum <nathan12343 at 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 at 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 at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list