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@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 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@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@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@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

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 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@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@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

...

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@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@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@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

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@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@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 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@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@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@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@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@stonybrook.edu > *web*: http://www.astro.sunysb.edu/mzingale > > _______________________________________________ > yt-users mailing list > yt-users@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org > >

_______________________________________________ yt-users mailing list yt-users@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@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@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@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@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@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale