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