[yt-users] question about transfer function colorbar
Michael Zingale
michael.zingale at stonybrook.edu
Fri May 23 08:45:56 PDT 2014
FYI, here's a simple script that shows this -- with the fix noted earlier,
the tick labels are right. I suspect that this same bug is in the other
transferfunction's plot methods, so I'll wait until I have a chance to look
over things before submitting a patch.
import pylab
import numpy as np
from yt.mods import *
import yt.visualization.volume_rendering.api
use_log = False
fig = pylab.figure(facecolor="black")
vals = [-1.e7, -5.e6, 5.e6, 1.e7]
sigma = 0.1*max(abs(np.array(vals)))
mi = min(vals)
ma = max(vals)
if use_log:
mi, ma = np.log10(mi), np.log10(ma)
tf = yt.visualization.volume_rendering.api.ColorTransferFunction((mi, ma))
for v in vals:
if (use_log):
tf.sample_colormap(math.log10(v), sigma**2)
else:
tf.sample_colormap(v, sigma**2) #, alpha=0.2)
tf.vert_cbar()
pylab.savefig("test_cbar.png", facecolor=fig.get_facecolor())
On Fri, May 23, 2014 at 11:06 AM, Michael Zingale <
michael.zingale at stonybrook.edu> wrote:
> Sam, I looked at this in more detail. The transfer function is setting
> things up correctly. As best as I can tell, the issue is in the vert_cbar
> routine. In particular, since the transfer function uses linspace, which
> by default has endpoint=True, when we convert from indices into x values,
> we should divide by self.alpha.x.size-1 instead of self.alpha.x.size.
> i.e., if I change the one line:
>
> val = x * (self.alpha.x[-1] - self.alpha.x[0]) /
> (self.alpha.x.size) + self.alpha.x[0]
>
> to
>
> val = x * (self.alpha.x[-1] - self.alpha.x[0]) /
> (self.alpha.x.size-1) + self.alpha.x[0]
>
> then I get the expected behavior.
>
> I am a little confused as well why we do add the "+1"
> in np.floor(self.alpha.x[-1]) + 1, 1) when defining xticks as well -- I
> imagine that's a good thing if your are working with logs, but for my
> purpose, where x ranges from -1.e7 to 1.e7, this doesn't seem needed, but I
> can live with that.
>
> Thoughts?
>
>
>
> On Thu, May 22, 2014 at 8:32 AM, Michael Zingale <
> michael.zingale at stonybrook.edu> wrote:
>
>> I haven't explored this in any detail yet (still dealing with the end of
>> the semester here)
>>
>>
>> On Wed, May 21, 2014 at 8:38 PM, Sam Skillman <samskillman at gmail.com>wrote:
>>
>>> Hi Michael,
>>>
>>> That looks like a bug to me. I'll take a look at it in more detail
>>> tomorrow. If you have a fix that works, let us know...
>>>
>>> Sam
>>>
>>>
>>> On Wed, May 21, 2014 at 8:17 AM, Michael Zingale <
>>> michael.zingale at stonybrook.edu> wrote:
>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>
--
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/20140523/51c7039c/attachment.html>
More information about the yt-users
mailing list