Hi all, We got an anonymous bug today. My guess is this is related to the transpose in write_image. -Matt ---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com --- you can reply above this line --- New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image Anonymous: Text is transposed with annotate_image. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.
Hi all, So one of the main reasons why this is so messy, IMO, is that we don't have a self-describing image. All we have is a numpy array. Would it worthwhile to do something like create an ImageArray, which subclasses numpy ndarray? http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-... We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else? For example: http://nbviewer.ipython.org/url/hub.yt-project.org/notebooks/2225815c19a844c... This would significantly help manage the rendering output since we lose info about the image as soon as we lose the camera. We could additionally write a thin layer to save these images out in hdf5, looping over the info dictionary for attributes. Thoughts? Sam On Fri, Sep 28, 2012 at 1:00 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi all,
We got an anonymous bug today. My guess is this is related to the transpose in write_image.
-Matt
---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com
--- you can reply above this line ---
New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Sam and Matt, My preference would be to make some kind of wrapper for the camera that acts like a FixedResolutionBuffer object. I mocked up something very similar for the OffAxisProjectionPlot which seems to work pretty well. In turn, it would then be pretty easy to mock of a VolumeRenderingPlot (which doesn't necessarily have to be based on plot window) to make fancy, annotated matplotlib plots based on images returned from the volume renderer. However, if someone wanted to just deal with bitmaps but still annotate them, a fix for this specific problem would be take the transpose out of write_bitmap and instead have it happen in the cython code that generates the image array in the first place or immediately after in camera.snapshot(). I'm not sure whether what Sam is envisioning would necessarily fix the issue with the transposed text since the image would still be written out with write_bitmap. Cheers, Nathan On Sep 28, 2012, at 12:30 PM, Sam Skillman wrote:
Hi all,
So one of the main reasons why this is so messy, IMO, is that we don't have a self-describing image. All we have is a numpy array. Would it worthwhile to do something like create an ImageArray, which subclasses numpy ndarray?
http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-...
We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else? For example: http://nbviewer.ipython.org/url/hub.yt-project.org/notebooks/2225815c19a844c...
This would significantly help manage the rendering output since we lose info about the image as soon as we lose the camera. We could additionally write a thin layer to save these images out in hdf5, looping over the info dictionary for attributes.
Thoughts?
Sam
On Fri, Sep 28, 2012 at 1:00 PM, Matthew Turk <matthewturk@gmail.com> wrote: Hi all,
We got an anonymous bug today. My guess is this is related to the transpose in write_image.
-Matt
---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com
--- you can reply above this line ---
New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. _______________________________________________ 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
Hi all, So I got a bit ambitious and tried this idea of an ImageArray out, and so far I really like it. It is in my fork, and here are the differences: https://bitbucket.org/samskillman/yt/compare/2c5e5476cd58..yt_analysis/yt:yt With that in place, I can do the following: http://paste.yt-project.org/show/2738/ This produces these images: http://i.imgur.com/gdwYJ.png and http://i.imgur.com/tADlk.png And spits out this for the keys/values for the ImageArray.info: Ray casting100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00 fields ['x'] normal_vector [ 0.15205718 0.91234311 -0.38014296] north_vector [ 0.06249512 0.37497071 0.92492774] dataset /media/zz3/scratch/skillman/test_data/DD1701 width (1.5, 1.5, 1.5) east_vector [-0.98639392 0.16439899 0. ] type rendering This does all of the transposing and y-axis flipping that is necessary to get back the images that you'd expect. Anyways, I think I really like it, and I'm happy to PR this in, but even if you guys don't like it I'm going to use it...a lot. It does touch a bunch of the cameras, so some testing should be done. Nathan: I think this will help push it in the right direction since it will give the necessary information to the image object returned from the camera. A thin wrapper that adds on TFs and such would be great! Cheers, Sam On Fri, Sep 28, 2012 at 4:43 PM, Nathan Goldbaum <nathan12343@gmail.com>wrote:
Hi Sam and Matt,
My preference would be to make some kind of wrapper for the camera that acts like a FixedResolutionBuffer object. I mocked up something very similar for the OffAxisProjectionPlot which seems to work pretty well.
In turn, it would then be pretty easy to mock of a VolumeRenderingPlot (which doesn't necessarily have to be based on plot window) to make fancy, annotated matplotlib plots based on images returned from the volume renderer.
However, if someone wanted to just deal with bitmaps but still annotate them, a fix for this specific problem would be take the transpose out of write_bitmap and instead have it happen in the cython code that generates the image array in the first place or immediately after in camera.snapshot(). I'm not sure whether what Sam is envisioning would necessarily fix the issue with the transposed text since the image would still be written out with write_bitmap.
Cheers,
Nathan
On Sep 28, 2012, at 12:30 PM, Sam Skillman wrote:
Hi all,
So one of the main reasons why this is so messy, IMO, is that we don't have a self-describing image. All we have is a numpy array. Would it worthwhile to do something like create an ImageArray, which subclasses numpy ndarray?
http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-...
We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else? For example:
http://nbviewer.ipython.org/url/hub.yt-project.org/notebooks/2225815c19a844c...
This would significantly help manage the rendering output since we lose info about the image as soon as we lose the camera. We could additionally write a thin layer to save these images out in hdf5, looping over the info dictionary for attributes.
Thoughts?
Sam
On Fri, Sep 28, 2012 at 1:00 PM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
We got an anonymous bug today. My guess is this is related to the transpose in write_image.
-Matt
---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com
--- you can reply above this line ---
New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. _______________________________________________ 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
This is actually pretty awesome, I'd love to see it in more places. FRBs should return ImageArrays. This will also allow us to refactor plot window and git rid of a lot of the logic that tries to figure out the image coordinate system. +1 on pulling this in to yt_analysis/yt -Nathan On Sep 28, 2012, at 4:04 PM, Sam Skillman wrote:
Hi all,
So I got a bit ambitious and tried this idea of an ImageArray out, and so far I really like it. It is in my fork, and here are the differences:
https://bitbucket.org/samskillman/yt/compare/2c5e5476cd58..yt_analysis/yt:yt
With that in place, I can do the following:
http://paste.yt-project.org/show/2738/
This produces these images: http://i.imgur.com/gdwYJ.png and http://i.imgur.com/tADlk.png
And spits out this for the keys/values for the ImageArray.info: Ray casting100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00 fields ['x'] normal_vector [ 0.15205718 0.91234311 -0.38014296] north_vector [ 0.06249512 0.37497071 0.92492774] dataset /media/zz3/scratch/skillman/test_data/DD1701 width (1.5, 1.5, 1.5) east_vector [-0.98639392 0.16439899 0. ] type rendering
This does all of the transposing and y-axis flipping that is necessary to get back the images that you'd expect.
Anyways, I think I really like it, and I'm happy to PR this in, but even if you guys don't like it I'm going to use it...a lot. It does touch a bunch of the cameras, so some testing should be done.
Nathan: I think this will help push it in the right direction since it will give the necessary information to the image object returned from the camera. A thin wrapper that adds on TFs and such would be great!
Cheers, Sam
On Fri, Sep 28, 2012 at 4:43 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: Hi Sam and Matt,
My preference would be to make some kind of wrapper for the camera that acts like a FixedResolutionBuffer object. I mocked up something very similar for the OffAxisProjectionPlot which seems to work pretty well.
In turn, it would then be pretty easy to mock of a VolumeRenderingPlot (which doesn't necessarily have to be based on plot window) to make fancy, annotated matplotlib plots based on images returned from the volume renderer.
However, if someone wanted to just deal with bitmaps but still annotate them, a fix for this specific problem would be take the transpose out of write_bitmap and instead have it happen in the cython code that generates the image array in the first place or immediately after in camera.snapshot(). I'm not sure whether what Sam is envisioning would necessarily fix the issue with the transposed text since the image would still be written out with write_bitmap.
Cheers,
Nathan
On Sep 28, 2012, at 12:30 PM, Sam Skillman wrote:
Hi all,
So one of the main reasons why this is so messy, IMO, is that we don't have a self-describing image. All we have is a numpy array. Would it worthwhile to do something like create an ImageArray, which subclasses numpy ndarray?
http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-...
We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else? For example: http://nbviewer.ipython.org/url/hub.yt-project.org/notebooks/2225815c19a844c...
This would significantly help manage the rendering output since we lose info about the image as soon as we lose the camera. We could additionally write a thin layer to save these images out in hdf5, looping over the info dictionary for attributes.
Thoughts?
Sam
On Fri, Sep 28, 2012 at 1:00 PM, Matthew Turk <matthewturk@gmail.com> wrote: Hi all,
We got an anonymous bug today. My guess is this is related to the transpose in write_image.
-Matt
---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com
--- you can reply above this line ---
New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. _______________________________________________ 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
Hi Sam, Is this a step closer to adding in a colorbar-type legend for the transfer function used in the volume rendering? From G.S. On Fri, Sep 28, 2012 at 4:04 PM, Sam Skillman <samskillman@gmail.com> wrote:
Hi all,
So I got a bit ambitious and tried this idea of an ImageArray out, and so far I really like it. It is in my fork, and here are the differences:
https://bitbucket.org/samskillman/yt/compare/2c5e5476cd58..yt_analysis/yt:yt
With that in place, I can do the following:
http://paste.yt-project.org/show/2738/
This produces these images: http://i.imgur.com/gdwYJ.png and http://i.imgur.com/tADlk.png
And spits out this for the keys/values for the ImageArray.info: Ray casting100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00 fields ['x'] normal_vector [ 0.15205718 0.91234311 -0.38014296] north_vector [ 0.06249512 0.37497071 0.92492774] dataset /media/zz3/scratch/skillman/test_data/DD1701 width (1.5, 1.5, 1.5) east_vector [-0.98639392 0.16439899 0. ] type rendering
This does all of the transposing and y-axis flipping that is necessary to get back the images that you'd expect.
Anyways, I think I really like it, and I'm happy to PR this in, but even if you guys don't like it I'm going to use it...a lot. It does touch a bunch of the cameras, so some testing should be done.
Nathan: I think this will help push it in the right direction since it will give the necessary information to the image object returned from the camera. A thin wrapper that adds on TFs and such would be great!
Cheers, Sam
On Fri, Sep 28, 2012 at 4:43 PM, Nathan Goldbaum <nathan12343@gmail.com>wrote:
Hi Sam and Matt,
My preference would be to make some kind of wrapper for the camera that acts like a FixedResolutionBuffer object. I mocked up something very similar for the OffAxisProjectionPlot which seems to work pretty well.
In turn, it would then be pretty easy to mock of a VolumeRenderingPlot (which doesn't necessarily have to be based on plot window) to make fancy, annotated matplotlib plots based on images returned from the volume renderer.
However, if someone wanted to just deal with bitmaps but still annotate them, a fix for this specific problem would be take the transpose out of write_bitmap and instead have it happen in the cython code that generates the image array in the first place or immediately after in camera.snapshot(). I'm not sure whether what Sam is envisioning would necessarily fix the issue with the transposed text since the image would still be written out with write_bitmap.
Cheers,
Nathan
On Sep 28, 2012, at 12:30 PM, Sam Skillman wrote:
Hi all,
So one of the main reasons why this is so messy, IMO, is that we don't have a self-describing image. All we have is a numpy array. Would it worthwhile to do something like create an ImageArray, which subclasses numpy ndarray?
http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-...
We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else? For example:
http://nbviewer.ipython.org/url/hub.yt-project.org/notebooks/2225815c19a844c...
This would significantly help manage the rendering output since we lose info about the image as soon as we lose the camera. We could additionally write a thin layer to save these images out in hdf5, looping over the info dictionary for attributes.
Thoughts?
Sam
On Fri, Sep 28, 2012 at 1:00 PM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
We got an anonymous bug today. My guess is this is related to the transpose in write_image.
-Matt
---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com
--- you can reply above this line ---
New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. _______________________________________________ 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
Hi Geoffrey, A little bit. We could in principle attach the tf to the ImageArray. This would make keeping track of the TF used a bit easier. Sam On Sat, Sep 29, 2012 at 12:59 PM, Geoffrey So <gsiisg@gmail.com> wrote:
Hi Sam,
Is this a step closer to adding in a colorbar-type legend for the transfer function used in the volume rendering?
From G.S.
On Fri, Sep 28, 2012 at 4:04 PM, Sam Skillman <samskillman@gmail.com>wrote:
Hi all,
So I got a bit ambitious and tried this idea of an ImageArray out, and so far I really like it. It is in my fork, and here are the differences:
https://bitbucket.org/samskillman/yt/compare/2c5e5476cd58..yt_analysis/yt:yt
With that in place, I can do the following:
http://paste.yt-project.org/show/2738/
This produces these images: http://i.imgur.com/gdwYJ.png and http://i.imgur.com/tADlk.png
And spits out this for the keys/values for the ImageArray.info: Ray casting100% ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00 fields ['x'] normal_vector [ 0.15205718 0.91234311 -0.38014296] north_vector [ 0.06249512 0.37497071 0.92492774] dataset /media/zz3/scratch/skillman/test_data/DD1701 width (1.5, 1.5, 1.5) east_vector [-0.98639392 0.16439899 0. ] type rendering
This does all of the transposing and y-axis flipping that is necessary to get back the images that you'd expect.
Anyways, I think I really like it, and I'm happy to PR this in, but even if you guys don't like it I'm going to use it...a lot. It does touch a bunch of the cameras, so some testing should be done.
Nathan: I think this will help push it in the right direction since it will give the necessary information to the image object returned from the camera. A thin wrapper that adds on TFs and such would be great!
Cheers, Sam
On Fri, Sep 28, 2012 at 4:43 PM, Nathan Goldbaum <nathan12343@gmail.com>wrote:
Hi Sam and Matt,
My preference would be to make some kind of wrapper for the camera that acts like a FixedResolutionBuffer object. I mocked up something very similar for the OffAxisProjectionPlot which seems to work pretty well.
In turn, it would then be pretty easy to mock of a VolumeRenderingPlot (which doesn't necessarily have to be based on plot window) to make fancy, annotated matplotlib plots based on images returned from the volume renderer.
However, if someone wanted to just deal with bitmaps but still annotate them, a fix for this specific problem would be take the transpose out of write_bitmap and instead have it happen in the cython code that generates the image array in the first place or immediately after in camera.snapshot(). I'm not sure whether what Sam is envisioning would necessarily fix the issue with the transposed text since the image would still be written out with write_bitmap.
Cheers,
Nathan
On Sep 28, 2012, at 12:30 PM, Sam Skillman wrote:
Hi all,
So one of the main reasons why this is so messy, IMO, is that we don't have a self-describing image. All we have is a numpy array. Would it worthwhile to do something like create an ImageArray, which subclasses numpy ndarray?
http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-...
We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else? For example:
http://nbviewer.ipython.org/url/hub.yt-project.org/notebooks/2225815c19a844c...
This would significantly help manage the rendering output since we lose info about the image as soon as we lose the camera. We could additionally write a thin layer to save these images out in hdf5, looping over the info dictionary for attributes.
Thoughts?
Sam
On Fri, Sep 28, 2012 at 1:00 PM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi all,
We got an anonymous bug today. My guess is this is related to the transpose in write_image.
-Matt
---------- Forwarded message ---------- From: Anonymous <issues-reply@bitbucket.org> Date: Fri, Sep 28, 2012 at 7:32 AM Subject: [yt_analysis/yt] annotate_image (issue #430) To: matthewturk@gmail.com
--- you can reply above this line ---
New issue 430: annotate_image https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. _______________________________________________ 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
participants (4)
-
Geoffrey So -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman