[yt-users] question about transfer function colorbar

Michael Zingale michael.zingale at stonybrook.edu
Wed May 21 08:17:54 PDT 2014


I looked at this some more.  It is this line in vert_cbar that adds the
odd-valued colorbar label:

xticks = np.append(visible[-1], xticks)

in particular, that adds the "255" value into the xticks array.
 Interestingly, xticks has a 256 value with the correct x_format() behavior
(mapping to 1.e7, the upper limit of my transfer function), but that is
ignored, since it is outside of the bounds of the color bar.

So the question then is why when I setup a transfer function via:

    tf =  yt.visualization.volume_rendering.api.ColorTransferFunction((mi,
ma))

with mi = -1.e7 and ma = 1.e7, does it map -1.e7 into index 0 in the
palette and 1.e7 into 256 in the palette, instead of 255?


On Sun, May 11, 2014 at 6:03 PM, Michael Zingale <
michael.zingale at stonybrook.edu> wrote:

> I poked around that code earlier but didn't see anything odd.  I'll look
> some more at it tomorrow.
>
>
> On Sat, May 10, 2014 at 11:31 AM, Chris Malone <chris.m.malone at gmail.com>wrote:
>
>> Hi Mike,
>>
>> The number that is getting set (~9.92e6) is just one bin off from the
>> maximum value (you have a range of 2e7 and the default is 256 bins).  The
>> code that displays the colorbar, as best I can tell, occurs when you call
>> save_annotated.  This method eventually calls
>> ColorTransferFunction.vert_cbar where the ticks and limits are applied to
>> the colorbar axes object.
>>
>> Looking over the logic in that code, it is not immediately obvious to me
>> why the index is off.  I suspect is has something to do with how the
>> `visible` variable is defined, but I'd need to play with a dataset and some
>> print statements...
>>
>> Chris
>>
>>
>> On Wed, May 7, 2014 at 8:17 PM, Michael Zingale <
>> michael.zingale at stonybrook.edu> wrote:
>>
>>> I'm trying to show the transfer function on a volume render.  Plotting a
>>> velocity component, I set the transfer function with 4 Gaussians all with
>>> the same width.  The range of the transfer function is -1.e7 to 1.e7, but
>>> for some reason, when output, the upper label in the colorbar is not 1.e7
>>> but a bit lower (9.92e6).  I am not sure where the code is that draws this,
>>> and I am confused why it is not setting the tick at 1.e7. It gets the
>>> bottom tick right.
>>> Here's an image:
>>>
>>> http://bender.astro.sunysb.edu/random/test_0000.png
>>>
>>> and the script:
>>>
>>> http://bender.astro.sunysb.edu/random/vol_rotate.py
>>>
>>> any pointers are appreciated.
>>>
>>> Mike
>>> --
>>> 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-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-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
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20140521/23d586f9/attachment.htm>


More information about the yt-users mailing list