[yt-dev] Orientation, coordinate systems

[Nathan Goldbaum]

On Tue, Apr 15, 2014 at 9:46 AM, Michael Zingale <
michael.zingale at 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 at gmail.com>wrote:
>
>> 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
>> >>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at 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 at stonybrook.edu
> *web*: http://www.astro.sunysb.edu/mzingale
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140415/c7276b8a/attachment.html>