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? 


We could then append on things like x-axis, y-axis, optionally things like field names, and who knows what else?  For example:

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