Orientation, coordinate systems
Hi all, I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items. -Matt
Hi Matt,
Can you expand on the context here? I don't think I know exactly what
you're referring to.
Britton
On Fri, Jan 17, 2014 at 5:11 PM, Matthew Turk
Hi all,
I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Ditto.
On Jan 17, 2014, at 12:53 PM, Britton Smith
Hi Matt,
Can you expand on the context here? I don't think I know exactly what you're referring to.
Britton
On Fri, Jan 17, 2014 at 5:11 PM, Matthew Turk
wrote: Hi all, I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items.
-Matt _______________________________________________ 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
Yes, sorry. The common criticism is that it's not a right-handed
coordinate system, and that the Orientation class is not used
everywhere.
On Fri, Jan 17, 2014 at 12:54 PM, John ZuHone
Ditto.
On Jan 17, 2014, at 12:53 PM, Britton Smith
wrote: Hi Matt,
Can you expand on the context here? I don't think I know exactly what you're referring to.
Britton
On Fri, Jan 17, 2014 at 5:11 PM, Matthew Turk
wrote: Hi all,
I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items.
-Matt _______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I imagine this still leaves a number of people in the dark. Unless I
misunderstand, my issue was that slices and projections do not follow the
right hand rule, in that the following should be true:
slice_axis image_x image_y
##########################
x y z
y z x
z x y
slice_axis image_x image_y
##########################
x y z
y x z
z x y
I guess it's really just viewing along the y axis, but it does lead to
having to do some work-arounds here and there. I would be in favor of
fixing this issue.
On Fri, Jan 17, 2014 at 6:11 PM, Matthew Turk
Yes, sorry. The common criticism is that it's not a right-handed coordinate system, and that the Orientation class is not used everywhere.
On Fri, Jan 17, 2014 at 12:54 PM, John ZuHone
wrote: Ditto.
On Jan 17, 2014, at 12:53 PM, Britton Smith
wrote: Hi Matt,
Can you expand on the context here? I don't think I know exactly what you're referring to.
Britton
On Fri, Jan 17, 2014 at 5:11 PM, Matthew Turk
wrote: Hi all,
I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items.
-Matt _______________________________________________ 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
_______________________________________________ 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
I would also like to see this fixed.
It would also be nice to see volume renderings, off-axis projections and
cutting planes align with the plot coordinate axes when the normal vector
is aligned with one of the coordinate axes.
I think the orientation class is already used everywhere where it would be
appropriate. Matt, can you clarify a bit what you mean by "not used
everywhere"?
On Fri, Jan 17, 2014 at 10:24 AM, Britton Smith
I imagine this still leaves a number of people in the dark. Unless I misunderstand, my issue was that slices and projections do not follow the right hand rule, in that the following should be true: slice_axis image_x image_y ########################## x y z y z x z x y
slice_axis image_x image_y ########################## x y z y x z z x y
I guess it's really just viewing along the y axis, but it does lead to having to do some work-arounds here and there. I would be in favor of fixing this issue.
On Fri, Jan 17, 2014 at 6:11 PM, Matthew Turk
wrote: Yes, sorry. The common criticism is that it's not a right-handed coordinate system, and that the Orientation class is not used everywhere.
On Fri, Jan 17, 2014 at 12:54 PM, John ZuHone
wrote: Ditto.
On Jan 17, 2014, at 12:53 PM, Britton Smith
wrote: Hi Matt,
Can you expand on the context here? I don't think I know exactly what you're referring to.
Britton
On Fri, Jan 17, 2014 at 5:11 PM, Matthew Turk
wrote: Hi all,
I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items.
-Matt _______________________________________________ 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
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Fri, Jan 17, 2014 at 10:28 AM, Nathan Goldbaum
I would also like to see this fixed.
It would also be nice to see volume renderings, off-axis projections and cutting planes align with the plot coordinate axes when the normal vector is aligned with one of the coordinate axes.
Sorry, I meant to say "align with the data coordinate axes". 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. Of course there will be some differences because of the different underlying data selection, but at least the plots should be aligned.
I think the orientation class is already used everywhere where it would be appropriate. Matt, can you clarify a bit what you mean by "not used everywhere"?
On Fri, Jan 17, 2014 at 10:24 AM, Britton Smith
wrote: I imagine this still leaves a number of people in the dark. Unless I misunderstand, my issue was that slices and projections do not follow the right hand rule, in that the following should be true: slice_axis image_x image_y ########################## x y z y z x z x y
slice_axis image_x image_y ########################## x y z y x z z x y
I guess it's really just viewing along the y axis, but it does lead to having to do some work-arounds here and there. I would be in favor of fixing this issue.
On Fri, Jan 17, 2014 at 6:11 PM, Matthew Turk
wrote: Yes, sorry. The common criticism is that it's not a right-handed coordinate system, and that the Orientation class is not used everywhere.
On Fri, Jan 17, 2014 at 12:54 PM, John ZuHone
wrote: Ditto.
On Jan 17, 2014, at 12:53 PM, Britton Smith
wrote: Hi Matt,
Can you expand on the context here? I don't think I know exactly what you're referring to.
Britton
On Fri, Jan 17, 2014 at 5:11 PM, Matthew Turk
wrote: Hi all,
I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items.
-Matt _______________________________________________ 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
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Jan 17, 2014, at 1:35 PM, Nathan Goldbaum
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.
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
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
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
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
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
Hi everyone,
Here's step one:
https://bitbucket.org/yt_analysis/yt/pull-request/821/abstract-out-all-axis-...
-Matt
On Fri, Jan 31, 2014 at 12:03 PM, Matthew Turk
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 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
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
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
On Tue, Apr 15, 2014 at 9:46 AM, Michael Zingale < michael.zingale@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
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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
On Fri, Jan 31, 2014 at 12:03 PM, Matthew Turk
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
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
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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (6)
-
Britton Smith
-
Cameron Hummels
-
John ZuHone
-
Matthew Turk
-
Michael Zingale
-
Nathan Goldbaum