| Passing Image Data :) [message #27327] |
Fri, 19 October 2001 12:43  |
Logan Lindquist
Messages: 50
Registered: October 2001
|
Member |
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Since everyone was so helpful last time, I figured
I'd give this another shot. I read in the [Mr. Fanning's IDL PT 1st ed.] that it
is better to use Struct's ( info = { imageData:imageData} ) to pass common
program information between pro/functions rather than the IDL 'common' keyword.
Well I am having problems doing that. I would like to make it so it doesn't
matter what type[2, 3, or 4 dimensional] of image I pass between
pro/functions. I might try making a image data variable for each type,
but that seems redundant. My original thinking was to make a dummy ByteArr and
then resize it, if need be, but that didn't work. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I tried several different variable initializations,
even making it so that it was the same as the returned image and it still gives
me an error saying that the expressions are not the same. I think I am just
going to rewrite it so that the image data is passed using the common
keyword. Does the common keyword make a pointer? Do I have to release this
from memory, or does IDL handle that? Now that I think of it, that might be
better, cause it would be faster if I could just create one instance of the
image data in memory rather than copying and pasting it between parts of
the program. So I guess what the question really is, What is the quickest
[best] way to pass image data of varying dimensions between program
components? </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks Very Much,</FONT></DIV>
<DIV><FONT face=Arial size=2>Logan Lindquist</FONT></DIV></BODY></HTML>
|
|
|
|
|
|
| Re: Passing Image Data :) [message #27412 is a reply to message #27327] |
Fri, 19 October 2001 15:16  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Logan Lindquist (llindqusit@mrdoc.cc) writes:
> Of course by no way did I attempt to dimean your honorific. I am sure you
> worked hard [paid very little so you could practice writing long papers
> while hopefully not having to grade a lot of tests or teach a lot of entry
> level courses] to obtain the title of Dr., instead of recieving an honory
> [free] one from a university that is more concerned with marketing itself.
> :)
I don't know why everyone is rushing to my
defense. I was just happy not to be addressed
as "Hey Bro" like the kids on the tennis team
tended to do until I set them straight.
> I would have the company order your new book in addition to the book by Liam
> E. Gumley, but I would rather wait a bit and buy it/them for myself. That
> way I get to keep it/them. You could however set aside one of those spiral
> bound student versions. I am in class until Dec. of this year, even if it
> doesn't relate to IDL. Guess I better put that in my budget before then, if
> I want the discount. :) That way, everyone, including your wife will
> satisfied with the transaction.
I'll tell you what. I was making a couple of changes
to the book (the whole CELL_FILL with filled contours
on map projections fiasco) and I decided to have the
boys mock me up a book using the "file prep" tool
they have now. This is an Adobe Acrobat knock-off,
but they assure me it is the "way it's done now".
I was dubious. I *like* PostScript!
Sure enough, the book looked great *except* around
certain italicized words. There the spacing got a little
close and it made it look like I hadn't run a spell checker
on the book. (I have. *Thousands* of times!) It looks
wonderful otherwise, but I'm too anal to allow a book
with even a few word run-ons out the door. So I've got
this book...
I put your name and a "half-off" sticker on it. Let
me know.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: Passing Image Data :) [message #27416 is a reply to message #27327] |
Fri, 19 October 2001 14:38 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Pavel A. Romashkin (pavel.romashkin@noaa.gov) writes:
> I would not get too carried away here. If you use
>
> widget_control, TLB, /realize, /managed
>
> then that widget program (as well as other launched the same way) runs
> just fine and events are processed properly, but no other older program
> that does use Xmanager can work properly: its event queue gets stopped.
> So, if you let go of Xmanager, drop it altogether (I did).
Oh, sorry. I thought we were talking about the future
here, where everything runs on Windows machines and
all code must be re-written for each software
upgrade. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: Passing Image Data :) [message #27421 is a reply to message #27327] |
Fri, 19 October 2001 13:30 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Pavel A. Romashkin (pavel.romashkin@noaa.gov) writes:
> Secondly, It is obviously the time to write that object (not OG!) book,
> David! Who wants nowdays the Info structure as a pointer? The whole
> widget program should be an object, and the GUI needs to be its property
> - then everything will be right there when you need it :-)
Pavel, I'm telling you, my office is clean, the yard
is mowed, the bills are paid. All I have to do now
is sharpen these damn pencils ... and ... write.
But you are right, info structures are completely in
the past. I haven't used one in a long, long time.
Cheers,
David
P.S. Let's just say I'm working on the chapter now
that expands on your tip (I think it was your tip)
that the XMANAGER is completely extraneous. Now
*that* is going to blow some minds! :-)
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Passing Image Data :) [message #27425 is a reply to message #27327] |
Tue, 23 October 2001 17:19 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> I did hear he died of lead poisoning after he
> got caught by one of his patients husbands.
That sounds like him, alright. But I hear
the Mac enthusiasts got to him first, and
he didn't have much left for the ladies.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
|
|
| Re: Passing Image Data :) [message #27431 is a reply to message #27327] |
Tue, 23 October 2001 16:05 |
Andrew Cool
Messages: 219
Registered: January 1996
|
Senior Member |
|
|
OK Guys,
I'd better quote my source...
"The Oxford Miniguide to English Usuage" 1991 ISBN 0-19-869127-0
Page 3, Abbreviations
"It is usual to indicate an abbreviation by placing a point (fullstop)
after it, e.g.
H.G. Wells, five miles S. (=south), B.Litt.
However, no point is necessary:
1. With a sequence of capitals alone, e.g. BBC, CNN
2. With the numerical abbreviations 1st,2cd, etc.
3. C,F (of termperature), chemical symbols, measures of length, weight,
time, etc. in
scientific and technical use.
4. Dr, Revd, Mr, Mrs, Ms, Mme, Mlle, St, p (=penny or pence)"
This guide to English was also published in the United States by Oxford
University Press,
New York.
What say we all compromise and call him "Doc Fanning" instead?
Andrew
PS : Just goes to show that not even New Zealanders speaka the Queen's
lingo...
------------------------------------------------------------ ---------
Andrew D. Cool .->-.
Electromagnetics & Propagation Group `-<-'
Surveillance Systems Division Transmitted on
Defence Science & Technology Organisation 100% recycled
PO Box 1500, Salisbury electrons
South Australia 5108
Phone : 061 8 8259 5740 Fax : 061 8 8259 6673
Email : andrew.cool@dsto.defence.gov.au
------------------------------------------------------------ ---------
David Fanning wrote:
>
> Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
>
>> And you shouldn't believe everything you read in it.
>
> Alas, you don't have to remind me of *this*! :-)
>
>> So, Dr. Fanning, I am afraid this authority does not support Andrew and me.
>> However, it is, as I said, an American authority. Perhaps the "no period [I
>> mean full stop] when omitting letters from the middle of an abbreviation"
>> rule applies in British English, as opposed to American English. I am sure I
>> remember learning it in school. I could ask my school-age children, but I
>> don't think they learn *anything* in school these days...I better stop here
>> before I lapse completely into impotent pedantic curmudgeonry.
>
> My more authoritarian _The Chicago Manual of Style_, 13th Ed. Revised,
> although American, has this to say about punctuating abbreviations:
>
> 1. In British practice, a distinction is made between a true
> abbreviation, in which the end of the word is lopped off (vol., Inc.,
> diam.), and a suspension, in which the interior of the word is
> removed (Mr., dept., acct.). It is usual in Britain to spell the
> latter class without periods. This logical practice shows few
> sighs of catching on in America, however.
>
> I might add, in passing, that those Brits also have the
> nasty habit of spelling COLOR as COLOUR.
>
> Cheers,
>
> David
> --
> David W. Fanning, Ph.D.
> Fanning Software Consulting
> Phone: 970-221-0438, E-mail: david@dfanning.com
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Toll-Free IDL Book Orders: 1-888-461-0155
--
------------------------------------------------------------ ---------
Andrew D. Cool .->-.
Electromagnetics & Propagation Group `-<-'
Surveillance Systems Division Transmitted on
Defence Science & Technology Organisation 100% recycled
PO Box 1500, Salisbury electrons
South Australia 5108
Phone : 061 8 8259 5740 Fax : 061 8 8259 6673
Email : andrew.cool@dsto.defence.gov.au
------------------------------------------------------------ ---------
|
|
|
|
| Re: Passing Image Data :) [message #27432 is a reply to message #27327] |
Tue, 23 October 2001 14:57 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> And you shouldn't believe everything you read in it.
Alas, you don't have to remind me of *this*! :-)
> So, Dr. Fanning, I am afraid this authority does not support Andrew and me.
> However, it is, as I said, an American authority. Perhaps the "no period [I
> mean full stop] when omitting letters from the middle of an abbreviation"
> rule applies in British English, as opposed to American English. I am sure I
> remember learning it in school. I could ask my school-age children, but I
> don't think they learn *anything* in school these days...I better stop here
> before I lapse completely into impotent pedantic curmudgeonry.
My more authoritarian _The Chicago Manual of Style_, 13th Ed. Revised,
although American, has this to say about punctuating abbreviations:
1. In British practice, a distinction is made between a true
abbreviation, in which the end of the word is lopped off (vol., Inc.,
diam.), and a suspension, in which the interior of the word is
removed (Mr., dept., acct.). It is usual in Britain to spell the
latter class without periods. This logical practice shows few
sighs of catching on in America, however.
I might add, in passing, that those Brits also have the
nasty habit of spelling COLOR as COLOUR.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Passing Image Data :) [message #27433 is a reply to message #27327] |
Tue, 23 October 2001 14:33 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
From: "David Fanning" <david@dfanning.com>
> Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
>
>> I think the idea is that the period is required only when the
abbreviation
>> removes something from the *end* of the word. Since the abbreviation
"Dr"
>> ends with the same letter as "Doctor", no period is required.
>
> Really!?
>
> That's why I like this newsgroup. I learn something
> new every day. :-)
And you shouldn't believe everything you read in it.
Having publicly pontificated on punctuation of abbreviations, I thought I
should look for some support. For historical reasons, the only style manual
in my office I have is an American one, viz. "Webster's American Style
Manual" (1985). On p 95 it says:
1. A period follows most abbreviations that are formed by omitting all but
the first few letters of a word, eg. bull. for bulletin, bro. for brother,
fig. for figure, Fr. for French.
2. A period follows most abbreviations that are formed by omitting letters
from the middle of a word, eg. secy. for secretary, mfg. for manufacturing,
agcy. for agency, Mr. for Mister.
3. [various others less relevant]
So, Dr. Fanning, I am afraid this authority does not support Andrew and me.
However, it is, as I said, an American authority. Perhaps the "no period [I
mean full stop] when omitting letters from the middle of an abbreviation"
rule applies in British English, as opposed to American English. I am sure I
remember learning it in school. I could ask my school-age children, but I
don't think they learn *anything* in school these days...I better stop here
before I lapse completely into impotent pedantic curmudgeonry.
Cheers, bro.
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield
National Institute for Water and Atmospheric Research
--
Posted from clam.niwa.cri.nz [202.36.29.1]
via Mailgate.ORG Server - http://www.Mailgate.ORG
|
|
|
|
| Re: Passing Image Data :) [message #27434 is a reply to message #27327] |
Tue, 23 October 2001 14:28 |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
Now, this is getting pretty hot. Who can look up an ANSI or at least
IEEE standard on how to do this correctly?
Pavel
Mark Hadfield wrote:
>
> From: "Logan Lindquist" <llindqusit@mrdoc.cc>
>> I thought Dr. had an period after it because it is an abbreviation of
>> doctor?
>
> I think the idea is that the period is required only when the abbreviation
> removes something from the *end* of the word. Since the abbreviation "Dr"
> ends with the same letter as "Doctor", no period is required.e
|
|
|
|
| Re: Passing Image Data :) [message #27436 is a reply to message #27327] |
Tue, 23 October 2001 14:29 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
Logan Lindquist wrote:
>
> Dr(.) Fanning,
> [I thought Dr. had an period after it because it is an abbrevation of
> doctor? I do not know what Andrew Cool is talking about.]
>
>> What you want in your info structure image field is a pointer
>> to the image:
>>
>> info= { image:Ptr_New(myimage), ...}
>
> I am wondering if you could clear up a couple of things about pointers in
> IDL. How come myimage does not have to be defined during initalization? Does
> the statement above create space in memory for a variable of indefinite
> size? It seems to operate this way., where the data in memory is allocated
> once the data has to be stored to the pointer array. Maybe I am
> understanding pointers incorrectly.
>
> 1.. The Pointer is created - a variable that 'points' to space in RAM
> reserved for a variable of indefinate size.
> 2.. The data is read into RAM during the read_image.pro.
> 3.. The Pointer then needs to store the image data for future reference.
> This is done by '*info.image = newimage'. Where newimage is the image data
> in RAM.
> 4.. Is the data then copied into the space originally allocated for it or
> does it simply change it's reference so as to point to the location in RAM
> where the image data was read into?
>
>> *info.image = newimage
>>
>> IDL takes care of all the memory management for you. You don't
>> have to worry about it.
>
Please (re)read David's excellent synopsis of what IDL pointers really
are: access points for otherwise normal IDL variables which live on a
global heap. As far as the memory allocation for pointers, you have to
worry about it only as much as you have to worry about memory allocation
for normal IDL variables (i.e., not too much). Example:
IDL> a=fltarr(1000)
IDL> a=5
where did all that memory for the vector go? The ocean floor? Who
knows.... IDL took care of it for us.
For saving memory and speeding pointer assignments, look to the NO_COPY
keyword for ptr_new, e.g.:
IDL> info.image=ptr_new(newimage,/NO_COPY)
which causes newimage to be undefined, and simply transforms it into a
pointer heap variable, now referenced by info.image.
The equivalent normal-variable operation would be:
IDL> image=temporary(newimage)
which also results in leaving newimage undefined. You could obviously
also do something like:
IDL> *info.image=temporary(newimage)
to mix the two technologies. All work exactly the same way.
One caveat: IDL manages memory for individual variables (normal or
heap) quite nicely. It does *not* ensure that heap variables which are
no longer referenced are freed: you must do this yourself. Note the
subtle distinction: data attached to individual variables is book-kept;
the collection of variables on the heap is not book-kept.
One more point. Objects variables are really just pointers into a
special heap (called, remarkably, the "object heap"), and have the same
bookkeeping issues as pointers. The only difference is, they can hold
only one type of data, and have special assignment, access, and method
invocation syntax. From a memory management point of view, however,
they are identical: you can strand unreferenced object variables on the
heap just as well as you can pointers variables.
JD
|
|
|
|
| Re: Passing Image Data :) [message #27438 is a reply to message #27327] |
Tue, 23 October 2001 14:00 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
> I think the idea is that the period is required only when the abbreviation
> removes something from the *end* of the word. Since the abbreviation "Dr"
> ends with the same letter as "Doctor", no period is required.
Really!?
That's why I like this newsgroup. I learn something
new every day. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: Passing Image Data :) [message #27440 is a reply to message #27327] |
Tue, 23 October 2001 13:39 |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
David Fanning wrote:
>
> sinThe point is, even
> if you knew how it was done there is nothing you can do in
> your code to affect how it is done, so there really is no
> point in worrying about it.
David has just revealed to us why is his code so vastly superior to any
other this NG has ever seen, and why his business is booming. He just
concentrates on making it work using what's available, not on thinking
how it would work if something that in fact is not present was made available.
Good lesson to all of us here who ask too many questions about Why RSI
does something that is does.
Cheers,
Pavel
|
|
|
|
| Re: Passing Image Data :) [message #27441 is a reply to message #27327] |
Tue, 23 October 2001 13:18 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Logan Lindquist (llindqusit@mrdoc.cc) writes:
> Dr(.) Fanning,
> [I thought Dr. had an period after it because it is an abbrevation of
> doctor? I do not know what Andrew Cool is talking about.]
Please, "Hey, Bro" is fine. :-)
>> What you want in your info structure image field is a pointer
>> to the image:
>>
>> info= { image:Ptr_New(myimage), ...}
>
> I am wondering if you could clear up a couple of things about pointers in
> IDL. How come myimage does not have to be defined during initalization? Does
> the statement above create space in memory for a variable of indefinite
> size? It seems to operate this way., where the data in memory is allocated
> once the data has to be stored to the pointer array. Maybe I am
> understanding pointers incorrectly.
Well, it might *seem* to operate this way, and
in fact there is no real harm *thinking* it operates
this way, but the facts are slightly more complicated.
In truth, it operates just like this:
IDL> a = reallybigdata
IDL> a = reallylittledata
That is to say, pointers use IDL's normal ability
to allocate memory on the fly and change the type
and structure of IDL variables on a whim.
Where you are probably going wrong is thinking that
IDL pointers are anything at all like C pointers. They
are not. In fact, the only thing that is even remotely
similar about them is their name. :-)
Pointers in IDL are simply normal variables that exist in
a globally accessible area of memory that IDL itself
manages. Nothing more or less. The fact that they
are globally accessible gives them properties that
are useful to us. Namely, we can have multiple program
modules accessing large amounts of data just by carrying
around a light-weight token that you can easily think
of as a secret decoder ring. If you know the code, you
can see the data. Simple as that.
In fact, if you know the code, you can change the data
encrypted by the code. IDL itself will take care of
all the messy details of how this is done. (CIA
special ops, is what I hear.)
> 1.. The Pointer is created - a variable that 'points' to space in RAM
> reserved for a variable of indefinate size.
No, it actually points to a variable of a very defined
size: the size of the variable it points to. If you
don't know how big the data is going to be, or it you
don't yet have a variable to store there, but you still
want a valid pointer, you can make the pointer point to
an "undefined" variable. Undefined variables are perfectly
legitimate variables in IDL:
IDL> ptr = Ptr_New(/Allocate_Heap)
IDL> HELP, *ptr
<PtrHeapVar110> UNDEFINED = <Undefined>
IDL> Print, Ptr_Valid(Ptr)
1
> 2.. The data is read into RAM during the read_image.pro.
Yes.
> 3.. The Pointer then needs to store the image data for future reference.
> This is done by '*info.image = newimage'. Where newimage is the image data
> in RAM.
Yes,
IDL> *ptr = newimage
Now the pointer points to a defined variable that is
a defined size. IDL itself has managed all the memory
allocation, etc. for you.
> 4.. Is the data then copied into the space originally allocated for it or
> does it simply change it's reference so as to point to the location in RAM
> where the image data was read into?
Uh, I don't know. And frankly, I don't even want to know.
It's fast, so I suspect the image data itself doesn't move.
I prefer to think of it being done with smoke and mirrors,
since it seems more mysterious that way. The point is, even
if you knew how it was done there is nothing you can do in
your code to affect how it is done, so there really is no
point in worrying about it.
> I went back and reviewed how pointers are treated in C++. I was wondering if
> I made my Struct a pointer, could I access memebers of Struct's using the
> '->'?
Don't ever review anything in C or C++ if you want
to know about IDL. It will just confuse the daylights
out of you. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Passing Image Data :) [message #27442 is a reply to message #27327] |
Tue, 23 October 2001 13:04 |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
Logan Lindquist wrote:
>
> I went back and reviewed how pointers are treated in C++. I was wondering if
> I made my Struct a pointer, could I access memebers of Struct's using the
> '->'?
I wouldn't go so far. IDL makes it simple for you to use pointers, as it
takes care of allocating and deallocating memory when you dereference a
pointer or change its value.
p = ptr_new() ; Make a null pointer (IDL, not C!)
p = ptr_new(fltarr(100)); Place something in it
; or
p = ptr_new(/allocate_heap) ; Same thing but is a valid pointer
*p = fltarr(1000) ; Replace contents.
ptr_free, p ; Make sure nothing stays in memory when done
This is basically all there is. Of course Gurus may have more creative
uses for them :)
-> operator in IDL is used to invoke object methods.
Cheers,
Pavel
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
