| Array Dimensions and WRITE_GIF [message #10642] |
Fri, 26 December 1997 00:00  |
Burkhard Prause
Messages: 6
Registered: February 1997
|
Junior Member |
|
|
Hi everybody,
a question from an occasional user:
I thought I'd use IDL to reformat several hundred tiff files into gifs.
So TIFF_READ reads every tiff image into a three dimensional array, of
dimension (3,*,*).
WRITE_GIF then gives me the error message:Must be a byte matrix.
This happens when I use my own code, the JHU tif2gif.pro, or line by
line. Since I want to process hundreds of these, using gifscreen is out
of the question, though it works for single images.
Why this is happening, I don't know - it seems to work for other people,
since the nice folks at JHU put their code out there. I'd be satisfied
to simply truncate the first dimension and write just a (1,*,*) array
into gif, but it will not accept that either.
How do I extract a truly two dimensional array from a three dimensional
one, if the "first" dimension is the one to be eliminated?
I'll be happy for any insight into this problem.
--
************************************************************ ********************
BURKHARD A. PRAUSE
DEPARTMENT OF PHYSICS
UNIVERSITY OF NOTRE DAME
NOTRE DAME, IN 46556
bprause@campra.phys.nd.edu
(219) 631-4088
Fax: (219) 6315952
************************************************************ ********************
|
|
|
|
|
|
| Re: array dimensions [message #24576 is a reply to message #10642] |
Mon, 09 April 2001 01:16  |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
"Richard G. French" wrote:
>
> David Fanning wrote:
>>> dimensions = Size(myarray, /Dimensions)
>>
>> Cheers,
>
> David is the master of keywords - I've used SIZE all these years without
> knowing that there was a /DIMENSIONS keyword. I guess the only way to
> know about these things is to read through the documentation over and
> over again and take notes on potentially useful keywords and options.
>
> Which brings me to my question - does anyone out there have a favorite
> keyword on a routine that we mere mortals might not know about, but
> which
> might make our lives much easier? Any suggestions welcome, except for
> HISTOGRAM and PLOT!
>
> Dick French
Not a favorite keyword, but a favorite tool: Get a decent system (if
you haven't one), install emacs with idlwave, run the routine-info
collection, and then you have all the keywords you never knew but
always dreamt about literally at your fingertips.
Cheers,
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
| Re: array dimensions [message #24578 is a reply to message #10642] |
Sun, 08 April 2001 20:13 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Richard G. French (rfrench@wellesley.edu) writes:
> Now that you mention SMOOTH, one of my pet peeves is that
> y=SMOOTH(array,n) gives an error message when n=1. There are lots of
> instances where the degree of smoothing is calculated on the fly,
> and one common instance is that you want no smoothing at all - i.e.
> just give me the original array, unsmoothed. I've ended up writing
> my own routine MYSMOOTH which is identical to smooth except that
> it does not barf when n=1. Perhaps this has been changed recently,
> but I don't think so. Does anyone have a good explanation for why
> n=1 does not have the expected behavior of returning the array
> unsmoothed? Or is there a keyword I have not been noticing that
> can handle this case?
Having had some modest experience these past few years
writing programs for public consumption, allow me to
make an observation or two.
I don't know how it is done in the real world, but
in my world a program idea is generated as a result
of a problem I have encountered (usually more than once)
in my own work. I come up with what I almost always
mistakenly believe is a clever idea and I code it up.
The program stays at this stage for some indeterminate
amount of time, usually until someone runs into a similar
problem and asks a question on the newsgroup. "Oh", I think,
"I have a clever solution to *that* problem. I'll clean
it up for them and offer it on my web page."
In the course of "cleaning it up", I usually discover
that my clever solution is really not as clever as I
thought it was and that it tends to work only in the
narrow confines of its original purpose. So I
make it more general. In fact, I usually try to imagine
all the ways it might be used.
Now, I am known in some circles as having a pretty
fertile imagination, but I have to admit that one of the
things that would *never* occur to me if I was writing
a SMOOTH function is that someone would use it if they
*didn't* want to smooth anything. Are you sure it would
have occurred to you?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: array dimensions [message #24580 is a reply to message #10642] |
Sun, 08 April 2001 18:29 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
web (jiali3@21cn.com) writes:
> I still remember that decomposed=0. You know before that, I change my screen
> color set frequently. And I had wasted much time to find a way to set the
> display color.
I used to fool around with it too. But it was
too much work. So I just wrote a bunch of color
tools that don't care whether color decomposition
is turned on or off and I use those. I haven't
set the color decomposition keyword (or even looked
to see what it is set to) for well over a year now. :-)
> To read the help document is too hard. Are there any good course or document
> on the web?
Programming itself is too hard. There really should
be some other way. I hear tell there is a pretty good
book around about IDL Programming, but I don't have the
time to read it, and I can't remember the author anyway.
> By the way, I have known how to draw solid arrow, but all the arrow I draw
> are ploted in 'velocity', then how to draw solid arrow? It seems that there
> is not any solid keywords there.
You will probably have to modify something like the VELOVECT
procedure. Everywhere it is using a PLOTS to draw the arrow,
you might want to substitute an ARROW, /SOLID command. It will
be a bit slower, of course, but it will probably look good.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: array dimensions [message #24582 is a reply to message #10642] |
Sun, 08 April 2001 09:11 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Francesco (francesco.spada@jrc.it) writes:
> I'm particulary interested in this keyword since I have many problem
> with colors.
>
> First of all I'm working with IDL 5.4 for win and I use WIN98 (16.8
> millions of colors (24 bit)).
>
> For fixing some color problem I use (taken from the demo of IDL, I
> don't know what they mean):
>
> device, decomposed=0
> device, bypass_translation=0
>
> When I make some contour with /fill all is all right, but when I try
> to use xinteranimate
>
> wdelete
> xinteranimate, set = [xw,yw,hrs]
> for i=0,hrs-1 do begin
> xinteranimate,frame=i,image=imgs(*,*,i)
> endfor
> xinteranimate
>
> I get completely different (and not really nice!!) colors from the
> imgs that I see before the animation.
>
> Does anyone can tell me why and what's the meaning (in a simpler way
> than that of the IDL man) of the device keyword I use?
In a simple way, DECOMPOSED=0 means don't take this number
I specify for a color and decompose it into 8-bits of red
information, and 8-bits of green information, and 8-bits
of blue information. Instead, use the number I specify as
an index into a color lookup table, and use the RGB values you
find there to specify the color I want.
You can learn a great deal about color by reading these
articles on my web page:
http://www.dfanning.com/documents/tips.html#UsingColors
Or, you could purchase my book, which only costs about
16 million lira in Italy, I think. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: array dimensions [message #24583 is a reply to message #10642] |
Sun, 08 April 2001 08:38 |
francesco.spada
Messages: 8
Registered: April 2001
|
Junior Member |
|
|
On Sat, 7 Apr 2001 19:40:17 -0600, davidf@dfanning.com (David Fanning)
wrote:
> Richard G. French (rfrench@wellesley.edu) writes:
>
>> Which brings me to my question - does anyone out there have a favorite
>> keyword on a routine that we mere mortals might not know about, but
>> which
>> might make our lives much easier?
>
> I'm inordinately fond of DECOMPOSED=0. :-)
I'm particulary interested in this keyword since I have many problem
with colors.
First of all I'm working with IDL 5.4 for win and I use WIN98 (16.8
millions of colors (24 bit)).
For fixing some color problem I use (taken from the demo of IDL, I
don't know what they mean):
device, decomposed=0
device, bypass_translation=0
When I make some contour with /fill all is all right, but when I try
to use xinteranimate
wdelete
xinteranimate, set = [xw,yw,hrs]
for i=0,hrs-1 do begin
xinteranimate,frame=i,image=imgs(*,*,i)
endfor
xinteranimate
I get completely different (and not really nice!!) colors from the
imgs that I see before the animation.
Does anyone can tell me why and what's the meaning (in a simpler way
than that of the IDL man) of the device keyword I use?
Thank you very much also for helping me with the /dimension keyword!!
Ciao
Francesco
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: array dimensions [message #24664 is a reply to message #24589] |
Mon, 09 April 2001 08:28 |
Alex Schuster
Messages: 124
Registered: February 1997
|
Senior Member |
|
|
"Richard G. French" wrote:
> David is the master of keywords - I've used SIZE all these years without
> knowing that there was a /DIMENSIONS keyword. I guess the only way to
> know about these things is to read through the documentation over and
> over again and take notes on potentially useful keywords and options.
True. And repeat that for every new version of IDL.
> Which brings me to my question - does anyone out there have a favorite
> keyword on a routine that we mere mortals might not know about, but
> which
> might make our lives much easier? Any suggestions welcome, except for
> HISTOGRAM and PLOT!
MIN() has the MAX keyword so you can compute both values in one step.
And it also allows a second parameter (I wonder why they didn't make
that a keyword) to return the (first) position the the minimum:
IDL> x = sin( findgen( 300 ) / 100 ) ; create array
IDL> print, where( x eq max( x ) )
157
; another variant
IDL> tmp = max( x, pos ) & print, pos
157
; and yet another:
IDL> print, !c
157
Alex
--
Alex Schuster Wonko@weird.cologne.de PGP Key available
alex@pet.mpin-koeln.mpg.de
|
|
|
|
| Re: array dimensions [message #24665 is a reply to message #24578] |
Mon, 09 April 2001 08:20 |
James Kuyper
Messages: 425
Registered: March 2000
|
Senior Member |
|
|
David Fanning wrote:
>
> Richard G. French (rfrench@wellesley.edu) writes:
>
>> Now that you mention SMOOTH, one of my pet peeves is that
>> y=SMOOTH(array,n) gives an error message when n=1. There are lots of
>> instances where the degree of smoothing is calculated on the fly,
>> and one common instance is that you want no smoothing at all - i.e.
>> just give me the original array, unsmoothed. I've ended up writing
>> my own routine MYSMOOTH which is identical to smooth except that
>> it does not barf when n=1. Perhaps this has been changed recently,
>> but I don't think so. Does anyone have a good explanation for why
>> n=1 does not have the expected behavior of returning the array
>> unsmoothed? Or is there a keyword I have not been noticing that
>> can handle this case?
>
> Having had some modest experience these past few years
> writing programs for public consumption, allow me to
> make an observation or two.
>
> I don't know how it is done in the real world, but
> in my world a program idea is generated as a result
> of a problem I have encountered (usually more than once)
> in my own work. I come up with what I almost always
> mistakenly believe is a clever idea and I code it up.
>
> The program stays at this stage for some indeterminate
> amount of time, usually until someone runs into a similar
> problem and asks a question on the newsgroup. "Oh", I think,
> "I have a clever solution to *that* problem. I'll clean
> it up for them and offer it on my web page."
>
> In the course of "cleaning it up", I usually discover
> that my clever solution is really not as clever as I
> thought it was and that it tends to work only in the
> narrow confines of its original purpose. So I
> make it more general. In fact, I usually try to imagine
> all the ways it might be used.
>
> Now, I am known in some circles as having a pretty
> fertile imagination, but I have to admit that one of the
> things that would *never* occur to me if I was writing
> a SMOOTH function is that someone would use it if they
> *didn't* want to smooth anything. Are you sure it would
> have occurred to you?
It would have occurred to me; part of my group's standard testing
routine is to check all boundary cases, which would have focused my
attention on n=1. One of my own design rules is to avoid interpreting
unusual values for arguments as errors unless I have to. I look for ways
to interpret them as instructions to do something unusual (but
consistent with the meaning attached to more normal values). Thus, I
don't normally treat a count of 0 as an error, but as an instruction to
process 0 of whatever is being counted; i.e., to skip processing.
|
|
|
|
| Re: array dimensions [message #24668 is a reply to message #24576] |
Mon, 09 April 2001 07:56 |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
Martin Schultz wrote:
>
> "Richard G. French" wrote:
>>
>> David Fanning wrote:
>>>> dimensions = Size(myarray, /Dimensions)
>>>
>>> Cheers,
>>
>> David is the master of keywords - I've used SIZE all these years without
>> knowing that there was a /DIMENSIONS keyword. I guess the only way to
>> know about these things is to read through the documentation over and
>> over again and take notes on potentially useful keywords and options.
>>
>> Which brings me to my question - does anyone out there have a favorite
>> keyword on a routine that we mere mortals might not know about, but
>> which
>> might make our lives much easier? Any suggestions welcome, except for
>> HISTOGRAM and PLOT!
>>
>> Dick French
>
> Not a favorite keyword, but a favorite tool: Get a decent system (if
> you haven't one), install emacs with idlwave, run the routine-info
> collection, and then you have all the keywords you never knew but
> always dreamt about literally at your fingertips.
Similar to typing "?" at the IDL prompt and getting similar info - with examples no less!
Gasp!
paulv
--
Paul van Delst A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
Ph: (301)763-8000 x7274 There shallow draughts intoxicate the brain,
Fax:(301)763-8545 And drinking largely sobers us again.
paul.vandelst@noaa.gov Alexander Pope.
|
|
|
|
| Re: array dimensions [message #24669 is a reply to message #24579] |
Mon, 09 April 2001 07:52 |
Paul van Delst
Messages: 364
Registered: March 1997
|
Senior Member |
|
|
"Richard G. French" wrote:
>
> Craig Markwardt wrote:
>
>> If you are interested in important keywords, I've found
>> SMOOTH(/EDGE_TRUNCATE) indispensable, as well as CONVOL(/CENTER). I
>> don't do *that* much time series analysis but it seems I always need
>> these keywords when I do.
>>
>
> Now that you mention SMOOTH, one of my pet peeves is that
> y=SMOOTH(array,n) gives an error message when n=1. There are lots of
> instances where the degree of smoothing is calculated on the fly,
> and one common instance is that you want no smoothing at all - i.e.
> just give me the original array, unsmoothed.
Jeez, how about:
IF ( n GT 1 ) THEN SMOOTH( array, n )
?
--
Paul van Delst A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
Ph: (301)763-8000 x7274 There shallow draughts intoxicate the brain,
Fax:(301)763-8545 And drinking largely sobers us again.
paul.vandelst@noaa.gov Alexander Pope.
|
|
|
|
| Re: array dimensions [message #24673 is a reply to message #24578] |
Mon, 09 April 2001 06:23 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
> Now, I am known in some circles as having a pretty
> fertile imagination, but I have to admit that one of the
> things that would *never* occur to me if I was writing
> a SMOOTH function is that someone would use it if they
> *didn't* want to smooth anything. Are you sure it would
> have occurred to you?
Yes, it's called the degenerate case. REBIN and REFORM can
essentially do this.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
