comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Teaching an Elephant to Dance
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Teaching an Elephant to Dance [message #77561] Tue, 13 September 2011 13:49
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Paulo Penteado writes:

>
> On Sep 13, 5:07 pm, David Fanning <n...@dfanning.com> wrote:
>> Oh, dear! I discovered this morning that if you set
>> N_LEVELS to one more than the number of levels you
>> want, it will work perfectly! Now, I realize that this
>> is probably because it is broken. In IDL 8.2 it will
>> be fixed and probably won't work at all again.
>
> Is this not similar to how it always was in DG?
>
> http://groups.google.com/group/comp.lang.idl-pvwave/browse_t hread/thread/43a4757b1dcfeb1f

Well, in this case it was ONE extra level, not the
arbitrary (and variable) number it was in the DG case.
I can live with a situation that is just crazy as long
as it's not moronic. :-)

> I have not had the chance to follow this discussion closely, in part
> because of lack of time, and in part because OG has been mostly broken
> and restricted to unbearably slow software rendering since I upgraded
> my OS (http://groups.google.com/group/comp.lang.idl-pvwave/
> browse_thread/thread/3828b3d0408162e4).

I wondered where you were, Paulo. At one point I
worried this newsgroup was going to turn into a
hagiography of function graphics because of you.
But I guess you have lost some of that religion.

Maybe when the ITTVIS machines go on sale you
and I can pick up something cheap that actually
works. :-)

Cheers,

David



--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77563 is a reply to message #77561] Tue, 13 September 2011 13:38 Go to previous message
penteado is currently offline  penteado
Messages: 866
Registered: February 2018
Senior Member
Administrator
On Sep 13, 5:07 pm, David Fanning <n...@dfanning.com> wrote:
> Oh, dear! I discovered this morning that if you set
> N_LEVELS to one more than the number of levels you
> want, it will work perfectly! Now, I realize that this
> is probably because it is broken. In IDL 8.2 it will
> be fixed and probably won't work at all again.

Is this not similar to how it always was in DG?

http://groups.google.com/group/comp.lang.idl-pvwave/browse_t hread/thread/43a4757b1dcfeb1f

I have not had the chance to follow this discussion closely, in part
because of lack of time, and in part because OG has been mostly broken
and restricted to unbearably slow software rendering since I upgraded
my OS (http://groups.google.com/group/comp.lang.idl-pvwave/
browse_thread/thread/3828b3d0408162e4).
Re: Teaching an Elephant to Dance [message #77565 is a reply to message #77563] Tue, 13 September 2011 13:07 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Mark Piper writes:

> In 8.0, NG CONTOUR would automatically interpolate the indices of the
> chosen color table, just like DG CONTOUR. This was broken in 8.1. The
> workaround (which I've used above) is to use RGB_INDICES to tell CONTOUR
> to interpolate the color table indices. This is CR 62414 & it's fixed in
> 8.2.
>
>> [snip]
>> be included in the contour levels? Is so, why doesn't this
>> happen when you specify N_LEVELS?
>
> I don't know! I don't use N_LEVELS because a really good IDL
> programmer (with initials DF) taught me long ago to always calculate my
> contour levels, a corollary of Dave Stern's maxim, "know your data."

Oh, dear! I discovered this morning that if you set
N_LEVELS to one more than the number of levels you
want, it will work perfectly! Now, I realize that this
is probably because it is broken. In IDL 8.2 it will
be fixed and probably won't work at all again.

It's a topsy-turvy world in function graphics! ;-)

Cheers,

David



--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77567 is a reply to message #77565] Tue, 13 September 2011 13:01 Go to previous message
Mark Piper is currently offline  Mark Piper
Messages: 198
Registered: December 2009
Senior Member
On 9/12/2011 11:50 AM, David Fanning wrote:
>
> OK, now, you have this line of code with a comment:
>
> rgb_indices=bytscl(indgen(4))) ; this is a bug in 8.1
>
> Can you explain what this particular bug is? Or, provide
> a reference? I've come to the conclusion that this keyword
> doesn't work "correctly," but I haven't yet figured out
> what is wrong with it.

In 8.0, NG CONTOUR would automatically interpolate the indices of the
chosen color table, just like DG CONTOUR. This was broken in 8.1. The
workaround (which I've used above) is to use RGB_INDICES to tell CONTOUR
to interpolate the color table indices. This is CR 62414 & it's fixed in
8.2.

> [snip]
> be included in the contour levels? Is so, why doesn't this
> happen when you specify N_LEVELS?

I don't know! I don't use N_LEVELS because a really good IDL
programmer (with initials DF) taught me long ago to always calculate my
contour levels, a corollary of Dave Stern's maxim, "know your data."

:D <-- (that's a big smile)

mp
Re: Teaching an Elephant to Dance [message #77574 is a reply to message #77567] Tue, 13 September 2011 08:53 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
David Fanning writes:

>
> Mark Piper writes:
>
>> cb = colorbar(target=c, $
>> tickname=string(levels, format='(f4.2)'), $ ; use the levels
>> position=[0.1, 0.90, 0.9, 0.95])
>
> Even though I can't run this code because of the TICKNAME
> keyword that crashes my machine, I can see that this is
> only a cosmetic fix, not a real fix. The color bar
> is actually showing data that runs from 0.0134 to
> 0.9847, and it is dividing that range into four divisions.
> But, the divisions do not fall where we need them to fall.
> The divisions are marked at 0.2563, 0.4991, and 0.7419.
> This is so even if you *label* them 0.25, 0.50, and 0.75!
>
> If we weren't so lucky with our actual data range, we
> would see BIG differences in how the tick marks on the
> color bar and the colors themselves line up.
>
> Run this program with data defined like this, and you
> will see what I mean:
>
> data = 0.125 > Randomu(-3L,9,9) < 0.875

I think I am beginning to understand the philosophy
behind the Colorbar() function.

A color bar is not actually related to anything in the
physical world. It doesn't have anything to do, for
example, with the levels with which you fill a contour
plot, etc. In function graphics, the colorbar is *only*
associated with some specific "data". That is, the
data of a contour plot or the data of an image.

The data seldom has a direct one-to-one connection to
the range of data you want to represent in a color
bar, so I think the idea is "Why worry about it?"
The color bar simply labels itself according to the
"data" it is associated with. If that is not what
you want, change it with the TICKNAME keyword.
This, of course, puts the burden (rightly, probably)
on you to format the tick names the way you want
them to be formatted.

For me, of course, this is a big problem, because
the TICKNAME keyword crashes my machine every single
&*$%#*& time! But, maybe it doesn't crash other people's
machines and this is the way the color bar is suppose
to work.

I can see the point, I just can't see how that makes
the Colorbar() function easy to use. :-)

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77578 is a reply to message #77574] Mon, 12 September 2011 12:59 Go to previous message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
On 12 sep, 20:43, David Fanning <n...@dfanning.com> wrote:
> David Fanning writes:
>> Run this program with data defined like this, and you
>> will see what I mean:
>
>>    data = 0.125 > Randomu(-3L,9,9) < 0.875
>
> As I was taking a shower I thought, "I don't know,
> maybe I'm blowin' smoke...". Can someone who CAN
> use the TICKNAME keyword send me a picture of what
> the plot looks like with the data defined like this
> in Mark's latest program?
>
> Please send it to "david" at the usual place.
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.idlcoyote.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")

Well, the clever solution given by Mark Piper inspires me two
comments:
1) do not necessarily use /OVERPLOT for overplotting: indeed, here in
NG, the two contour plots will show up correctly by only drawing them
in the current (/CURRENT) window at the same position.
2) the COLORBAR labelling is just a trick since ticknames 0, 0.25, 0.5
etc... are forced at the computed positions 0.0134, 0.2563, etc... A
colorbar routine based on the input of an arbitrary color scale and
without any reference to an underlying image, would be simpler!
alain.
Re: Teaching an Elephant to Dance [message #77579 is a reply to message #77578] Mon, 12 September 2011 12:55 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
David Fanning writes:

> As I was taking a shower I thought, "I don't know,
> maybe I'm blowin' smoke...". Can someone who CAN
> use the TICKNAME keyword send me a picture of what
> the plot looks like with the data defined like this
> in Mark's latest program?
>
> Please send it to "david" at the usual place.

That's what I thought. No one except the Windows 97
crowd can actually use this software. :-(

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77580 is a reply to message #77579] Mon, 12 September 2011 11:43 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
David Fanning writes:

> Run this program with data defined like this, and you
> will see what I mean:
>
> data = 0.125 > Randomu(-3L,9,9) < 0.875

As I was taking a shower I thought, "I don't know,
maybe I'm blowin' smoke...". Can someone who CAN
use the TICKNAME keyword send me a picture of what
the plot looks like with the data defined like this
in Mark's latest program?

Please send it to "david" at the usual place.

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77581 is a reply to message #77580] Mon, 12 September 2011 11:18 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Mark Piper writes:

> cb = colorbar(target=c, $
> tickname=string(levels, format='(f4.2)'), $ ; use the levels
> position=[0.1, 0.90, 0.9, 0.95])

Even though I can't run this code because of the TICKNAME
keyword that crashes my machine, I can see that this is
only a cosmetic fix, not a real fix. The color bar
is actually showing data that runs from 0.0134 to
0.9847, and it is dividing that range into four divisions.
But, the divisions do not fall where we need them to fall.
The divisions are marked at 0.2563, 0.4991, and 0.7419.
This is so even if you *label* them 0.25, 0.50, and 0.75!

If we weren't so lucky with our actual data range, we
would see BIG differences in how the tick marks on the
color bar and the colors themselves line up.

Run this program with data defined like this, and you
will see what I mean:

data = 0.125 > Randomu(-3L,9,9) < 0.875

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77582 is a reply to message #77581] Mon, 12 September 2011 11:01 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
David Fanning writes:

> I do note that the fuzzy contour annotations in the upper
> right hand corner of the plot in my article have also
> gone away in this version of the program. Do you think
> that is a result of specifying the upper level as 1.0?
> Why are you making a point of specifying the upper contour
> level as the maximum value of the filled contour data? Should
> the lower and upper "bounds" of the contour data always
> be included in the contour levels? Is so, why doesn't this
> happen when you specify N_LEVELS?

Oh, I see! The fuzziness goes away because you are thinning
the number of annotations on the contour lines. The fuzziness
comes from contour annotations being written too close together
for very short lines. Is this something you plan to fix as
the default, or do you expect people to realize they have to
"thin" the number of annotations if they get fuzzy results?

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77583 is a reply to message #77582] Mon, 12 September 2011 10:50 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Mark Piper writes:

> Ack! Yes, I made a mistake. Sorry about that. Lesson: I shouldn't post
> to the newsgroup while distracted. Counting the colors with N_ELEMENTS
> was the problem.

OK, now, you have this line of code with a comment:

rgb_indices=bytscl(indgen(4))) ; this is a bug in 8.1

Can you explain what this particular bug is? Or, provide
a reference? I've come to the conclusion that this keyword
doesn't work "correctly," but I haven't yet figured out
what is wrong with it.

I do note that the fuzzy contour annotations in the upper
right hand corner of the plot in my article have also
gone away in this version of the program. Do you think
that is a result of specifying the upper level as 1.0?
Why are you making a point of specifying the upper contour
level as the maximum value of the filled contour data? Should
the lower and upper "bounds" of the contour data always
be included in the contour levels? Is so, why doesn't this
happen when you specify N_LEVELS?

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77584 is a reply to message #77583] Mon, 12 September 2011 10:25 Go to previous message
Mark Piper is currently offline  Mark Piper
Messages: 198
Registered: December 2009
Senior Member
On 9/12/2011 11:12 AM, David Fanning wrote:
> David Fanning writes:
>
>> I'll see what I can learn from that example if I remove
>> the TICKNAME keyword. :-)
>
> Ah, Mark, all I did to your code was comment out the
> TICKNAME keyword and run the program. This is the
> output I got:
>
> http://www.idlcoyote.com/misc/mark_piper_contour.png
>
> I'm pretty sure that's not what you must be seeing!
> I'm running IDL 8.1 on a Windows 7, 64-bit OS:
>
> IDL> print, !version
> { x86_64 Win32 Windows Microsoft Windows 8.1 Mar 9 2011 64 64}
>
> Any ideas?
>
> Cheers,
>
> David
>

Ack! Yes, I made a mistake. Sorry about that. Lesson: I shouldn't post
to the newsgroup while distracted. Counting the colors with N_ELEMENTS
was the problem. Here's a revised version.

mp

pro ng_discrete_colorbar1
compile_opt idl2

data = randomu(-3L, 9, 9)
levels = [0.0, 0.25, 0.5, 0.75, 1.0] ; note top level

; COLORBAR wants 256 colors, so replicate the 4 desired colors.
colors = [[!color.red], [!color.blue], [!color.green], [!color.yellow]]
step_ct = congrid(colors, 3, 256)

w = window(dimensions=[750, 400])
w.refresh, /disable

c = contour(data, $
/current, $
c_value=levels, $
/fill, $
position=[0.1, 0.1, 0.9, 0.8], $
rgb_table=step_ct, $
rgb_indices=bytscl(indgen(4))) ; this is a bug in 8.1

over = contour(data, $
/current, $
c_value=levels, $
axis_style=0, $
font_size=10, $
/c_label_show, $
/c_use_label_orientation, $
c_label_interval=0.6, $ ; thin the number of labels
position=[0.1, 0.1, 0.9, 0.8])

cb = colorbar(target=c, $
tickname=string(levels, format='(f4.2)'), $ ; use the levels
position=[0.1, 0.90, 0.9, 0.95])

w.refresh
end
Re: Teaching an Elephant to Dance [message #77586 is a reply to message #77584] Mon, 12 September 2011 10:12 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
David Fanning writes:

> I'll see what I can learn from that example if I remove
> the TICKNAME keyword. :-)

Ah, Mark, all I did to your code was comment out the
TICKNAME keyword and run the program. This is the
output I got:

http://www.idlcoyote.com/misc/mark_piper_contour.png

I'm pretty sure that's not what you must be seeing!
I'm running IDL 8.1 on a Windows 7, 64-bit OS:

IDL> print, !version
{ x86_64 Win32 Windows Microsoft Windows 8.1 Mar 9 2011 64 64}

Any ideas?

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77588 is a reply to message #77586] Mon, 12 September 2011 10:05 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Mark Piper writes:

> There's an easier way to make this plot, but you have to work with the
> fact that COLORBAR wants 256 values and is tied to the data.
>
> I've used code similar to what I posted earlier
> [ https://groups.google.com/d/msg/comp.lang.idl-pvwave/QHJmvrK ybz/WMR2aD5g0P8J],
> and I put in a few comments to show where my code differs from yours.
>
> I've tested this on my laptop (64-bit Win XP + 32-bit Linux (Ubuntu
> 10.10)) and the Tech Support Mac running Lion.

I'm going to haul my machine to Boulder and see if it
works better in the rarefied atmosphere up there.
I missed that TICKNAME keyword, and down she goes! :-(

Does no one at ITTVIS use Windows 7? (It's the latest
Windows operating system.) I'd be happy to loan you
one of my machines, if you like.

The fact that you have to "work with the fact that
COLORBAR wants 256 values and is tied to the data"
is exactly what is wrong with the COLORBAR function.
You can't make it do what you want it do to. Believe
it or not, people don't always use 256 colors. Sometimes
they use a lot less. But, I'm sure you know this.

I'll see what I can learn from that example if I remove
the TICKNAME keyword. :-)

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77589 is a reply to message #77588] Mon, 12 September 2011 09:48 Go to previous message
Mark Piper is currently offline  Mark Piper
Messages: 198
Registered: December 2009
Senior Member
On 9/11/2011 12:14 PM, David Fanning wrote:
> Folks,
>
> Because what I assumed was impossible has turned out to be
> possible, and because I don't want others to struggle
> for three days in frustration, Coyote and I have
> decided to share the secret of how to produce a simple
> contour plot using the IDL 8.1 function graphics
> commands. (The alternative, of course, would be to try to
> get rich by writing the only IDL 8.1 graphics documentation
> worth a damn, but the audience seems small to us.)
>
> You can find the article here:
>
> http://www.idlcoyote.com/ng_tips/elephant.php
>
> Cheers,
>
> David
>
>

There's an easier way to make this plot, but you have to work with the
fact that COLORBAR wants 256 values and is tied to the data.

I've used code similar to what I posted earlier
[ https://groups.google.com/d/msg/comp.lang.idl-pvwave/QHJmvrK ybz/WMR2aD5g0P8J],
and I put in a few comments to show where my code differs from yours.

I've tested this on my laptop (64-bit Win XP + 32-bit Linux (Ubuntu
10.10)) and the Tech Support Mac running Lion.

mp


pro ng_discrete_colorbar1
compile_opt idl2

data = randomu(-3L, 9, 9)
levels = [0.0, 0.25, 0.5, 0.75, 1.0] ; note top level

; COLORBAR wants 256 colors, so replicate the 4 desired colors.
colors = [[!color.red], [!color.blue], [!color.green], [!color.yellow]]
n_colors = n_elements(colors)
step_ct = congrid(colors, 3, 256)

w = window(dimensions=[750, 400])
w.refresh, /disable

c = contour(data, $
/current, $
c_value=levels, $
/fill, $
position=[0.1, 0.1, 0.9, 0.8], $
rgb_table=step_ct, $
rgb_indices=bytscl(indgen(n_colors))) ; this is a bug in 8.1

over = contour(data, $
/current, $
c_value=levels, $
axis_style=0, $
font_size=10, $
/c_label_show, $
/c_use_label_orientation, $
c_label_interval=0.6, $ ; thin the number of labels
position=[0.1, 0.1, 0.9, 0.8])

cb = colorbar(target=c, $
tickname=string(levels, format='(f4.2)'), $ ; use the levels
position=[0.1, 0.90, 0.9, 0.95])

w.refresh
end
Re: Teaching an Elephant to Dance [message #77591 is a reply to message #77589] Mon, 12 September 2011 08:35 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
alx writes:

> The "ghost" contour is one of possible workarounds. Another one would
> be to rewrite the colorbar axis by playing with TICKNAME and TICKVALUE
> keywords. But they are only workarounds: I hope that ITTVIS people
> will be able to offer a true solution !

Yes, but I'm telling you, TICKNAME buggers my machine
big time! And, EVERY time! If you had re-booted your
machine 30 times in two days, as I did, your opinion
of function graphics may be as dark as mine. ;-)

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77593 is a reply to message #77591] Mon, 12 September 2011 08:26 Go to previous message
lecacheux.alain is currently offline  lecacheux.alain
Messages: 325
Registered: January 2008
Senior Member
On 12 sep, 17:00, David Fanning <n...@dfanning.com> wrote:
> Paul van Delst writes:
>> the final NG contour plot is clearly inferior to the DG/CG original. the final label orientation (all horiz rather than
>> following the contour) is laughable. And the fact that the default is to stick in some of the labels upside-down (your
>> 4th ng plot) even more so.
>
> Well, yes, but the kicker for me is that you have
> to create a second, "ghost" contour plot to get the
> ranges on the color bar right. Unbelievable!
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")

The "ghost" contour is one of possible workarounds. Another one would
be to rewrite the colorbar axis by playing with TICKNAME and TICKVALUE
keywords. But they are only workarounds: I hope that ITTVIS people
will be able to offer a true solution !
alain.
Re: Teaching an Elephant to Dance [message #77594 is a reply to message #77593] Mon, 12 September 2011 08:00 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Paul van Delst writes:

> the final NG contour plot is clearly inferior to the DG/CG original. the final label orientation (all horiz rather than
> following the contour) is laughable. And the fact that the default is to stick in some of the labels upside-down (your
> 4th ng plot) even more so.

Well, yes, but the kicker for me is that you have
to create a second, "ghost" contour plot to get the
ranges on the color bar right. Unbelievable!

Cheers,

David



--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Re: Teaching an Elephant to Dance [message #77595 is a reply to message #77594] Mon, 12 September 2011 07:52 Go to previous message
Paul Van Delst[1] is currently offline  Paul Van Delst[1]
Messages: 1157
Registered: April 2002
Senior Member
David Fanning wrote:
> Folks,
>
> Because what I assumed was impossible has turned out to be
> possible, and because I don't want others to struggle
> for three days in frustration, Coyote and I have
> decided to share the secret of how to produce a simple
> contour plot using the IDL 8.1 function graphics
> commands. (The alternative, of course, would be to try to
> get rich by writing the only IDL 8.1 graphics documentation
> worth a damn, but the audience seems small to us.)
>
> You can find the article here:
>
> http://www.idlcoyote.com/ng_tips/elephant.php

the final NG contour plot is clearly inferior to the DG/CG original. the final label orientation (all horiz rather than
following the contour) is laughable. And the fact that the default is to stick in some of the labels upside-down (your
4th ng plot) even more so.

what i don't get is that ittvis has the code/algorithms to do this correctly (i.e. in their dg graphics codebase). why
aren't they using that? maybe it's just too hard to keep track of varying label orientations amongst the 10,000 or so
object and pointer references created when ng is invoked?

oh well.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: More Function Graphics Confusion
Next Topic: Re: Trouble exporting vector .eps file from ivolume

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:48:54 PDT 2025

Total time taken to generate the page: 0.00558 seconds