[yt-dev] Fwd: [yt_analysis/yt] annotate_image (issue #430)

Sat Sep 29 15:41:46 PDT 2012

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 at 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 at 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 at 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-adding-an-extra-attribute-to-ndarray
>>>
>>> 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/2225815c19a844c9974838543f09e267.ipynb
>>>
>>> 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 at 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 at bitbucket.org>
>>>> Date: Fri, Sep 28, 2012 at 7:32 AM
>>>> Subject: [yt_analysis/yt] annotate_image (issue #430)
>>>> To: matthewturk at 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 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20120929/96898cf8/attachment.html>