[yt-dev] Orientation, coordinate systems

Matthew Turk matthewturk at gmail.com
Tue Apr 15 08:47:34 PDT 2014


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 at 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 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