|
|
| Re: Questions about IDL 8.0 [message #73722 is a reply to message #73712] |
Wed, 24 November 2010 12:15  |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 24, 6:00 pm, Michael Galloy <mgal...@gmail.com> wrote:
> But I don't see where 'zaxis' appears at all:
>
> IDL> foreach el,s['zaxis*'] do print, el.identifier
> AXIS2
> AXIS5
> AXIS8
> AXIS11
>
> It seems like it is doing something smart, but I'm not sure exactly what
> it is. For example, 'zaxis*' matches all the axes pointing in the z
> direction:
>
> IDL> foreach el, s['zaxis*'] do el.hide = 1
Yes, the overload function is not matching by the names of the objects
(though it could), it is using igetid() to decide what is the best
match for the string given. The help on igetid() says
"You do not need to enter the exact substring of the intended
visualization object. IGETID’s matching algorithm overlooks small
formatting irregularities to return the match(es) that best fit the
given substring."
In this particular case, when igetid() sees one is searching for axes,
it determines if the string specifies a direction (from it containing
x|y|z), and if so, only returns the axes with the corresponding
direction:
IDL> s=surface(/test,axis_style=2)
IDL> foreach el,s['axis*'] do print,el.name, el.direction
Axis 0 0
Axis 1 1
Axis 2 2
Axis 3 0
Axis 4 1
Axis 5 2
Axis 6 0
Axis 7 1
Axis 8 2
Axis 9 0
Axis 10 1
Axis 11 2
IDL> foreach el,s['zaxis*'] do print,el.name, el.direction
Axis 2 2
Axis 5 2
Axis 8 2
Axis 11 2
IDL> foreach el,s['*Axis 2*'] do print,el.name, el.direction
Axis 2 2
|
|
|
|
| Re: Questions about IDL 8.0 [message #73723 is a reply to message #73722] |
Wed, 24 November 2010 12:00 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On 11/24/10 11:30 AM, Paulo Penteado wrote:
> On Nov 24, 4:02 pm, Michael Galloy<mgal...@gmail.com> wrote:
>> What are the allowable names? I see 'xaxis', 'yaxis', and 'zaxis', but
>> are there clever names for the other axes like when AXIS_STYLE=2? And
>> what exactly is that name, part of an identifier?
>
> The overloaded brackets match objects in the hierarchy through calls
> of igetid(), with some processing before and after it. So it is mostly
> up to igetid's way of finding identifiers.
>
> The matches are not necessarily of single objects:
>
> IDL> s=surface(/test,axis_style=2)
> IDL> help,s['*axis*']
> <Expression> OBJREF = Array[12]
> IDL> foreach el,s['zaxis'] do print,el.name
> Axis 2
> IDL> foreach el,s['zaxis*'] do print,el.name
> Axis 2
> Axis 5
> Axis 8
> Axis 11
But I don't see where 'zaxis' appears at all:
IDL> foreach el,s['zaxis*'] do print, el.identifier
AXIS2
AXIS5
AXIS8
AXIS11
It seems like it is doing something smart, but I'm not sure exactly what
it is. For example, 'zaxis*' matches all the axes pointing in the z
direction:
IDL> foreach el, s['zaxis*'] do el.hide = 1
Mike
--
www.michaelgalloy.com
Research Mathematician
Tech-X Corporation
|
|
|
|
| Re: Questions about IDL 8.0 [message #73725 is a reply to message #73723] |
Wed, 24 November 2010 10:30 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 24, 4:02 pm, Michael Galloy <mgal...@gmail.com> wrote:
> What are the allowable names? I see 'xaxis', 'yaxis', and 'zaxis', but
> are there clever names for the other axes like when AXIS_STYLE=2? And
> what exactly is that name, part of an identifier?
The overloaded brackets match objects in the hierarchy through calls
of igetid(), with some processing before and after it. So it is mostly
up to igetid's way of finding identifiers.
The matches are not necessarily of single objects:
IDL> s=surface(/test,axis_style=2)
IDL> help,s['*axis*']
<Expression> OBJREF = Array[12]
IDL> foreach el,s['zaxis'] do print,el.name
Axis 2
IDL> foreach el,s['zaxis*'] do print,el.name
Axis 2
Axis 5
Axis 8
Axis 11
|
|
|
|
| Re: Questions about IDL 8.0 [message #73726 is a reply to message #73725] |
Wed, 24 November 2010 10:02 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On 11/24/10 8:34 AM, Mark Piper wrote:
> On Nov 23, 4:12 pm, Paulo Penteado<pp.pente...@gmail.com> wrote:
>> On Nov 23, 8:44 pm, Leslie Sherrill<leslie.wel...@gmail.com> wrote:
>>
>>> (2) I'm trying to set up the z axis ticks and title to be at the back
>>> of the surface plot. The z axis defaults to a location right in front
>>> of the surface, and is often obscured by the data. I noticed that
>>> even the documentation examples always show that z axis in front
>>> rather than at the back of the y axis. Anyone know of a quick-fix?
>>
>> IDL> s=surface(dist(100),ztitle='Z')
>> IDL> axes=s.axes
>> IDL> foreach el,axes do if (el.title eq 'Z') then break ;find out
>> which axis is Z
>> IDL> el.hide=1 ;hide that axis
>> IDL> za=axis('Z',location=[(s.xrange)[0],(s.yrange)[1],0d0]) ;make a
>> new Z axis, at the back
>
> Here's a way to move the existing Z axis:
>
> IDL> s = surface(/test)
> IDL> (s['zaxis']).location = [0, (s.yrange)[1], 0]
What are the allowable names? I see 'xaxis', 'yaxis', and 'zaxis', but
are there clever names for the other axes like when AXIS_STYLE=2? And
what exactly is that name, part of an identifier?
Mike
--
www.michaelgalloy.com
Research Mathematician
Tech-X Corporation
|
|
|
|
| Re: Questions about IDL 8.0 [message #73727 is a reply to message #73726] |
Wed, 24 November 2010 08:19 |
lecacheux.alain
Messages: 325
Registered: January 2008
|
Senior Member |
|
|
On 24 nov, 16:56, Paulo Penteado <pp.pente...@gmail.com> wrote:
> On Nov 24, 1:34 pm, Mark Piper <mpi...@ittvis.com> wrote:
>
>> Here's a way to move the existing Z axis:
>
>> IDL> s = surface(/test)
>> IDL> (s['zaxis']).location = [0, (s.yrange)[1], 0]
>
> Thanks, that is much better than what I suggested. Because it moves
> instead of adding an axis, and selects the axis in a much better way.
This is a good example of the new possibilities, I guess, offered by
NG (i.e. a way to get complex graphics with both powerful and concise
coding). Unfortunately, a "normal" user like me cannot really discover
all them by himself, and might be tempted to continue with "old"
direct graphics or, even, to leave IDL.
We then urgently need for a complete NG documentation from ITTVIS!
alx.
|
|
|
|
| Re: Questions about IDL 8.0 [message #73729 is a reply to message #73727] |
Wed, 24 November 2010 07:56 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 24, 1:34 pm, Mark Piper <mpi...@ittvis.com> wrote:
> Here's a way to move the existing Z axis:
>
> IDL> s = surface(/test)
> IDL> (s['zaxis']).location = [0, (s.yrange)[1], 0]
Thanks, that is much better than what I suggested. Because it moves
instead of adding an axis, and selects the axis in a much better way.
|
|
|
|
| Re: Questions about IDL 8.0 [message #73732 is a reply to message #73729] |
Wed, 24 November 2010 07:34 |
Mark Piper
Messages: 198
Registered: December 2009
|
Senior Member |
|
|
On Nov 23, 4:12 pm, Paulo Penteado <pp.pente...@gmail.com> wrote:
> On Nov 23, 8:44 pm, Leslie Sherrill <leslie.wel...@gmail.com> wrote:
>
>> (2) I'm trying to set up the z axis ticks and title to be at the back
>> of the surface plot. The z axis defaults to a location right in front
>> of the surface, and is often obscured by the data. I noticed that
>> even the documentation examples always show that z axis in front
>> rather than at the back of the y axis. Anyone know of a quick-fix?
>
> IDL> s=surface(dist(100),ztitle='Z')
> IDL> axes=s.axes
> IDL> foreach el,axes do if (el.title eq 'Z') then break ;find out
> which axis is Z
> IDL> el.hide=1 ;hide that axis
> IDL> za=axis('Z',location=[(s.xrange)[0],(s.yrange)[1],0d0]) ;make a
> new Z axis, at the back
Here's a way to move the existing Z axis:
IDL> s = surface(/test)
IDL> (s['zaxis']).location = [0, (s.yrange)[1], 0]
mp
|
|
|
|
| Re: Questions about IDL 8.0 [message #73737 is a reply to message #73732] |
Tue, 23 November 2010 16:54 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> Ah, I see. CTLOAD returns a 256x3 array, because that's
> what TVLCT expects. Makes sense I guess that new graphics
> is doing everything in a contrary fashion. Why leverage
> old code when you make people write everything from
> scratch? :-)
>
> Cheers,
>
> David
>
> P.S. I guess I'll add a NG keyword to flip things around
> so I can use the program where I need it. Thanks!
I just point out that FSC_Color has the same problem
when returning a color triple. TVLCT expects a column
vector and new graphics routines (in fact, all *object
graphics* routines) require a row vector. (I had
forgotten all about this, I guess.)
Anyway, the way the problem is solved in FSC_Color's
case in that you can set the ROW keyword to get the
color triple returned as a row vector instead of as
a column vector.
IDL> aColor = FSC_Color('wheat', /Triple, /Row)
IDL> Help, aColor
ACOLOR INT = Array[3]
IDL> bColor = FSC_Color('wheat', /Triple)
IDL> Help, bColor
BCOLOR INT = Array[1, 3]
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: Questions about IDL 8.0 [message #73739 is a reply to message #73738] |
Tue, 23 November 2010 16:30 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paulo Penteado writes:
> If your question is why it works with the first table, and not the
> second, I do not have an answer. I would not expect it to work with
> either, because 3 is the second dimension.
>
> I verified that both work when I use the transpose of what ctload
> returns.
Ah, I see. CTLOAD returns a 256x3 array, because that's
what TVLCT expects. Makes sense I guess that new graphics
is doing everything in a contrary fashion. Why leverage
old code when you make people write everything from
scratch? :-)
Cheers,
David
P.S. I guess I'll add a NG keyword to flip things around
so I can use the program where I need it. Thanks!
--
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: Questions about IDL 8.0 [message #73740 is a reply to message #73739] |
Tue, 23 November 2010 16:13 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On 11/23/10 5:04 PM, Paulo Penteado wrote:
> On Nov 23, 9:27 pm, Michael Galloy<mgal...@gmail.com> wrote:
>> This should make an axis in the back instead of the front (without just
>> rotating the plot around):
>>
>> IDL> s = surface(dist(20))
>> IDL> axes = s.axes
>> IDL> axes[2].hide = 1
>
> When I wrote what I posted above, I was wondering whether it would be
> best to search for the Z, as I did, or just assume it is the third
> axis, as you did.
Yes, I'm not sure either, especially if you have a box style set of
axes. Which one exactly is axes[11]?
Mike
--
www.michaelgalloy.com
Research Mathematician
Tech-X Corporation
|
|
|
|
| Re: Questions about IDL 8.0 [message #73741 is a reply to message #73740] |
Tue, 23 November 2010 16:12 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 23, 9:52 pm, David Fanning <n...@dfanning.com> wrote:
> David Fanning writes:
>> ;*********************************************************** *********
>> file = Filepath('worldelv.dat', SUBDIRECTORY = ['examples', 'data'])
>> world = Read_Binary(file, DATA_DIMS = [360,360])
>> CTLoad, 4, /BREWER, RGB_TABLE=ct
>> img = Image(world, RGB_TABLE=ct)
>
>> CTLoad, 18, /BREWER RGB_TABLE=nct
>> img.rgb_table=nct ; to new color table
>
>> Help, ct, nct
>> END
>> ;*********************************************************** *********
>
> Oh, wait, there is a typo there! I need a comma
> after the second BREWER.
>
> CTLoad, 18, /BREWER, RGB_TABLE=nct
>
> But even when fixed, it doesn't work. :-(
If your question is why it works with the first table, and not the
second, I do not have an answer. I would not expect it to work with
either, because 3 is the second dimension.
I verified that both work when I use the transpose of what ctload
returns.
I would guess that the init method looks for the dimension with length
3, while the setproperty method just assumes it is the first.
|
|
|
|
| Re: Questions about IDL 8.0 [message #73742 is a reply to message #73741] |
Tue, 23 November 2010 16:04 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 23, 9:27 pm, Michael Galloy <mgal...@gmail.com> wrote:
> This should make an axis in the back instead of the front (without just
> rotating the plot around):
>
> IDL> s = surface(dist(20))
> IDL> axes = s.axes
> IDL> axes[2].hide = 1
When I wrote what I posted above, I was wondering whether it would be
best to search for the Z, as I did, or just assume it is the third
axis, as you did.
|
|
|
|
| Re: Questions about IDL 8.0 [message #73743 is a reply to message #73742] |
Tue, 23 November 2010 15:52 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> ;*********************************************************** *********
> file = Filepath('worldelv.dat', SUBDIRECTORY = ['examples', 'data'])
> world = Read_Binary(file, DATA_DIMS = [360,360])
> CTLoad, 4, /BREWER, RGB_TABLE=ct
> img = Image(world, RGB_TABLE=ct)
>
> CTLoad, 18, /BREWER RGB_TABLE=nct
> img.rgb_table=nct ; to new color table
>
> Help, ct, nct
> END
> ;*********************************************************** *********
Oh, wait, there is a typo there! I need a comma
after the second BREWER.
CTLoad, 18, /BREWER, RGB_TABLE=nct
But even when fixed, it doesn't work. :-(
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: Questions about IDL 8.0 [message #73744 is a reply to message #73743] |
Tue, 23 November 2010 15:45 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paulo Penteado writes:
> This works for me
>
> IDL> rt0=rebin(reform(bindgen(256),1,256),3,256) ;make up a table
> IDL> rt1=rebin(reform(reverse(bindgen(256)),1,256),3,256) ;make up
> another table
> IDL> im=image(dist(100),rgb_table=rt0) ;make an image with table rt0
> IDL> im.rgb_table=rt1 ;switch the table to rt1
Can someone explain this example for me:
;*********************************************************** *********
file = Filepath('worldelv.dat', SUBDIRECTORY = ['examples', 'data'])
world = Read_Binary(file, DATA_DIMS = [360,360])
CTLoad, 4, /BREWER, RGB_TABLE=ct
img = Image(world, RGB_TABLE=ct)
CTLoad, 18, /BREWER RGB_TABLE=nct
img.rgb_table=nct ; to new color table
Help, ct, nct
END
;*********************************************************** *********
IDL> .go
% IDLITDATAIDLPALETTE::SETDATA: Data must be a 3xN or 4xN array.
CT BYTE = Array[256, 3]
NCT BYTE = Array[256, 3]
I can load the first color table fine, but not the second,
even though they are formatted in EXACTLY the same way. :-(
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: Questions about IDL 8.0 [message #73745 is a reply to message #73744] |
Tue, 23 November 2010 15:27 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On 11/23/10 4:05 PM, Gray wrote:
> On Nov 23, 5:44 pm, Leslie Sherrill<leslie.wel...@gmail.com> wrote:
>> I have two issues with plotting in the new IDL 8.0. They seem like
>> fairly straightforward problems, but I can't seem to find a way around
>> them. I'd be grateful of any advice you can give me.
>>
>> (1) I have a widget program which is using the new IDL 8.0 graphics,
>> and I finally figured out how I can access the plot commands in other
>> widget programs. I am able to change things like axis titles, ranges,
>> etc. However, when I change the color table and attempt to do a
>> graphic.rgb_table=new_rgb_table that is associated with my new color
>> table, nothing happens. In fact, it looks like the rgb_table and
>> vert_colors commands are Init variables that cannot be re-defined
>> later in the program. However, the new documentation indicates that
>> the values are changeable. Has anyone else encountered this?
>>
>> (2) I'm trying to set up the z axis ticks and title to be at the back
>> of the surface plot. The z axis defaults to a location right in front
>> of the surface, and is often obscured by the data. I noticed that
>> even the documentation examples always show that z axis in front
>> rather than at the back of the y axis. Anyone know of a quick-fix?
>>
>> Thanks in advance,
>> Leslie Sherrill
>
> Hm. For the first one, I have no idea.
>
> For the second, you can add another Z axis with the AXIS function, but
> I see no way to suppress a single axis in the original SURFACE call.
> Are the axes in a SURFACE object themselves AXIS objects? If so, then
> being able to access their properties with surface.axis.property would
> be extremely useful.
>
This should make an axis in the back instead of the front (without just
rotating the plot around):
IDL> s = surface(dist(20))
IDL> axes = s.axes
IDL> axes[2].hide = 1
IDL> zaxis = axis('z', location=[19, 19, 0])
Mike
--
www.michaelgalloy.com
Research Mathematician
Tech-X Corporation
|
|
|
|
| Re: Questions about IDL 8.0 [message #73746 is a reply to message #73745] |
Tue, 23 November 2010 15:17 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 23, 8:44 pm, Leslie Sherrill <leslie.wel...@gmail.com> wrote:
> (1) I have a widget program which is using the new IDL 8.0 graphics,
> and I finally figured out how I can access the plot commands in other
> widget programs. I am able to change things like axis titles, ranges,
> etc. However, when I change the color table and attempt to do a
> graphic.rgb_table=new_rgb_table that is associated with my new color
> table, nothing happens. In fact, it looks like the rgb_table and
> vert_colors commands are Init variables that cannot be re-defined
> later in the program. However, the new documentation indicates that
> the values are changeable. Has anyone else encountered this?
This works for me
IDL> rt0=rebin(reform(bindgen(256),1,256),3,256) ;make up a table
IDL> rt1=rebin(reform(reverse(bindgen(256)),1,256),3,256) ;make up
another table
IDL> im=image(dist(100),rgb_table=rt0) ;make an image with table rt0
IDL> im.rgb_table=rt1 ;switch the table to rt1
|
|
|
|
| Re: Questions about IDL 8.0 [message #73747 is a reply to message #73746] |
Tue, 23 November 2010 15:12 |
penteado
Messages: 866
Registered: February 2018
|
Senior Member
Administrator |
|
|
On Nov 23, 8:44 pm, Leslie Sherrill <leslie.wel...@gmail.com> wrote:
> (2) I'm trying to set up the z axis ticks and title to be at the back
> of the surface plot. The z axis defaults to a location right in front
> of the surface, and is often obscured by the data. I noticed that
> even the documentation examples always show that z axis in front
> rather than at the back of the y axis. Anyone know of a quick-fix?
IDL> s=surface(dist(100),ztitle='Z')
IDL> axes=s.axes
IDL> foreach el,axes do if (el.title eq 'Z') then break ;find out
which axis is Z
IDL> el.hide=1 ;hide that axis
IDL> za=axis('Z',location=[(s.xrange)[0],(s.yrange)[1],0d0]) ;make a
new Z axis, at the back
|
|
|
|
| Re: Questions about IDL 8.0 [message #73748 is a reply to message #73747] |
Tue, 23 November 2010 15:05 |
Gray
Messages: 253
Registered: February 2010
|
Senior Member |
|
|
On Nov 23, 5:44 pm, Leslie Sherrill <leslie.wel...@gmail.com> wrote:
> I have two issues with plotting in the new IDL 8.0. They seem like
> fairly straightforward problems, but I can't seem to find a way around
> them. I'd be grateful of any advice you can give me.
>
> (1) I have a widget program which is using the new IDL 8.0 graphics,
> and I finally figured out how I can access the plot commands in other
> widget programs. I am able to change things like axis titles, ranges,
> etc. However, when I change the color table and attempt to do a
> graphic.rgb_table=new_rgb_table that is associated with my new color
> table, nothing happens. In fact, it looks like the rgb_table and
> vert_colors commands are Init variables that cannot be re-defined
> later in the program. However, the new documentation indicates that
> the values are changeable. Has anyone else encountered this?
>
> (2) I'm trying to set up the z axis ticks and title to be at the back
> of the surface plot. The z axis defaults to a location right in front
> of the surface, and is often obscured by the data. I noticed that
> even the documentation examples always show that z axis in front
> rather than at the back of the y axis. Anyone know of a quick-fix?
>
> Thanks in advance,
> Leslie Sherrill
Hm. For the first one, I have no idea.
For the second, you can add another Z axis with the AXIS function, but
I see no way to suppress a single axis in the original SURFACE call.
Are the axes in a SURFACE object themselves AXIS objects? If so, then
being able to access their properties with surface.axis.property would
be extremely useful.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
