[yt-dev] Orientation, coordinate systems

[Matthew Turk]

Hi Mike,

This PR doesn't, but the next set will.  The reason write_png gives
different results is that the PNG wrapper takes things in a different
ordering than matplotlib does.  Here's the trello card tracking fixes
to righthandedness:

https://trello.com/c/ec3szrn5/7-fix-righthandedness

Basically, unifying how everything is referenced and called will
solidify when axes mean what.

-Matt

On Tue, Apr 15, 2014 at 12:46 PM, 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)
>
>
> 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
>