Re: IDL & iTools used as post-processor for other commercial software [message #50399] |
Tue, 03 October 2006 08:38  |
news.qwest.net
Messages: 137 Registered: September 2005
|
Senior Member |
|
|
My 2�
I (personally in my academic work) find no need for interactive graphics.
I always use main level scripts and direct graphics to create postscript
files.
These scripts read in the data, do the necessary processing, and create the
final manuscript-ready portable scalable postscript graphics file.
There are a couple of reasons for this:
1) It is reproducible. I will need to adjust the figure and perhaps
modifiy the analysis in the future. Basically I will get reviews
from a journal that suggests some minor change, and I can
implement it instantly. Another example, I actually had some boob
of a reviewer state that one of my figures was not possible (it was
too clean and nice of a result). My scathing response included the
entire package of code and data that would have let the reviewer
create the figure. (You like apples? How do you like those apples?!?
I am still seething over that one.)
1a) try to reproduce a figure from an interactive 12 hour long odyssey
of tweak and toggle. I think I can mathematically prove that each resulting
figure is unique. Applying the 3rd Law of Publications "the most difficult
figure to reproduce will be the one requiring modification", then it could
be
a problem. :(
2) simple yet powerful. Ok, direct graphics may seem a bit complicated
to newbies, with the thousands of keywords etc. But if you have had some
experience you can pretty much do anything you want. And since 99% of
my code is cut-and-pasted from previous code, development of a final
figure is very rapid.
3) quasi-interactive. I actually think I can update the image faster with
the script/direct-graphics approach than I can in Itools. In WinXP,
just type in the modifications in the editor, a subconcious CTRL-S
CTRL-R CTRL-F5 F5 (I had to look it up, since the memory of those
keys is stored in my hands) and it is done.
4) I have a large suite of functions to do exactly what I want,
and I have not been motivated to port them to Itools, or to find out if such
a thing is possible. One example is all my julian day manipulation functions
(combined with xtickformat, xrange, etc).
5) woof woof snore.... i'm an old dog. :)
Cheers,
bob
|
|
|
Re: IDL & iTools used as post-processor for other commercial software [message #50401 is a reply to message #50399] |
Tue, 03 October 2006 07:56   |
mvukovic
Messages: 63 Registered: July 1998
|
Member |
|
|
Kenneth P. Bowman wrote:
> In article <452189d6$1_2@marge.ic.sunysb.edu>,
> Benjamin Hornberger <benjamin.hornberger@stonybrook.edu> wrote:
>
>> To add some support for the poor guys at ITTVIS: I fully back Mirko's
>> statement -- not perfect but miles ahead of direct graphics commands to
>> quickly create a graphic, do some *interactive* adjustments, add
>> annotations, print directly from the screen (with page preview!), and
>> save it in an editable form.
>>
>> The lack of acceptance for iTools in this group sometimes sounds to me
>> like the "can't teach an old dog new tricks" problem :-). Ok, everybody
>> has their own preferences, but I recommend everybody to give it a try.
>
> Actually, I am finding the iTools to be quite handy, but I can't say I
> love them (yet). They are very cool for doing 3-D interactive graphics.
>
> Off the top of my head, here is my current list of gotchas with iTools:
>
> 1. Despite several tries, I have never been able to produce any usable
> PostScript graphics from an iTool (either to a printer or a file). My
> only option is to capture really big bitmap files. Yuck. This is OK
> for giving talks, but not for published graphics. This is still a deal
> breaker, in my opinion.
>
I don't use post-script anymore since I started using iTools. They
produce decent (not as perfect) output for inclusion in other
documents. And that was the main reason why I used post-script before
> 2. Manipulating iTools programmatically is not too hard. What is hard
> is figuring what it is *possible* to do. I find myself doing
> trial-and-error pattern matching on the list of iTool IDs in the iTool
> hierarchy hoping that I am looking for the right keyword. The keywords
> often don't match the labels in the parameter lists.
I have not ventured there yet.
>
> 3. Many things are still obscure. If you start out with iMap, you can
> specify the GRID_UNITS keyword. But if you want to add a map to an
> existing iTool and do things in degrees? I'm still at the bottom of the
> learning curve on that one.
>
> 4. If my z-coordinate decreases upward (e.g., atmospheric pressure), I
> have to add a light at the *bottom* of the display in order to light the
> *top* of an isosurface. I suppose there is some logic to this based on
> the direction of the normals to the surface, but it is not user friendly.
>
> Cheers, Ken Bowman
I like the fact that in iTools the data is stored with the plot. So,
if weeks later, I want to tweak the plot, I open the file, and the data
is there.
What I miss in IDL (and what is present in spreadsheets) is the fact
that once I quit the IDL session, the whole history of how I went from
raw data to the plot is gone.
While I dislike Excel and the likes, they combine the raw data, the
processing and the output all in one file. In this day of cheap disk
space, all the extra stored stuff is not too bad. Of course, there are
data sets that are just too huge for such type of processing.
I think an environment like VIP (I have never used it), combined with
iTool-type-plots would fit the bill of an integrated data processing
environment.
Mirko
|
|
|
Re: IDL & iTools used as post-processor for other commercial software [message #50406 is a reply to message #50401] |
Mon, 02 October 2006 19:19   |
Kenneth P. Bowman
Messages: 585 Registered: May 2000
|
Senior Member |
|
|
In article <452189d6$1_2@marge.ic.sunysb.edu>,
Benjamin Hornberger <benjamin.hornberger@stonybrook.edu> wrote:
> To add some support for the poor guys at ITTVIS: I fully back Mirko's
> statement -- not perfect but miles ahead of direct graphics commands to
> quickly create a graphic, do some *interactive* adjustments, add
> annotations, print directly from the screen (with page preview!), and
> save it in an editable form.
>
> The lack of acceptance for iTools in this group sometimes sounds to me
> like the "can't teach an old dog new tricks" problem :-). Ok, everybody
> has their own preferences, but I recommend everybody to give it a try.
Actually, I am finding the iTools to be quite handy, but I can't say I
love them (yet). They are very cool for doing 3-D interactive graphics.
Off the top of my head, here is my current list of gotchas with iTools:
1. Despite several tries, I have never been able to produce any usable
PostScript graphics from an iTool (either to a printer or a file). My
only option is to capture really big bitmap files. Yuck. This is OK
for giving talks, but not for published graphics. This is still a deal
breaker, in my opinion.
2. Manipulating iTools programmatically is not too hard. What is hard
is figuring what it is *possible* to do. I find myself doing
trial-and-error pattern matching on the list of iTool IDs in the iTool
hierarchy hoping that I am looking for the right keyword. The keywords
often don't match the labels in the parameter lists.
3. Many things are still obscure. If you start out with iMap, you can
specify the GRID_UNITS keyword. But if you want to add a map to an
existing iTool and do things in degrees? I'm still at the bottom of the
learning curve on that one.
4. If my z-coordinate decreases upward (e.g., atmospheric pressure), I
have to add a light at the *bottom* of the display in order to light the
*top* of an isosurface. I suppose there is some logic to this based on
the direction of the normals to the surface, but it is not user friendly.
Cheers, Ken Bowman
|
|
|
|
|
|
|
Re: IDL & iTools used as post-processor for other commercial software [message #50411 is a reply to message #50410] |
Mon, 02 October 2006 15:39   |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Benjamin Hornberger writes:
> The lack of acceptance for iTools in this group sometimes sounds to me
> like the "can't teach an old dog new tricks" problem :-).
Oh, dear. THAT touched a nerve!
I wrote a reply, but I've deleted it. God knows I
don't want to set this newsgroup on fire. Let's just
say you and I are going to have to agree to disagree
about why iTools seem to lack acceptance. :-)
I do think you will find, however, if you search
the archives of this newsgroup, that the three or four
astronomers using widgets today are doing so only
because of my unrelenting efforts to push this new
and innovative technology.
Cheers,
David
P.S. I agree with you, though, that people should try
them. That's the only way to form your own opinion.
--
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: IDL & iTools used as post-processor for other commercial software [message #50413 is a reply to message #50411] |
Mon, 02 October 2006 14:51   |
Benjamin Hornberger
Messages: 258 Registered: March 2004
|
Senior Member |
|
|
David Fanning wrote:
> Mirko writes:
>
>
>> if you google mirko love itools you will see a total of three posts so
>> far. They are not perfect, but for me they do an awsome job of
>> creating a graphic that I can export, and bring up at a later date to
>> edit some more.
>
>
> I have been wondering for some time who the target audience
> for iTools was. I am *really* glad to know there is someone
> out there!
>
> Cheers,
>
> David
>
> P.S. Please don't take some ONE literally. I'm always
> getting in trouble with ITTVIS for the most innocuous
> statements. :-(
>
To add some support for the poor guys at ITTVIS: I fully back Mirko's
statement -- not perfect but miles ahead of direct graphics commands to
quickly create a graphic, do some *interactive* adjustments, add
annotations, print directly from the screen (with page preview!), and
save it in an editable form.
The lack of acceptance for iTools in this group sometimes sounds to me
like the "can't teach an old dog new tricks" problem :-). Ok, everybody
has their own preferences, but I recommend everybody to give it a try.
Benjamin
|
|
|
|
|
|
Re: IDL & iTools used as post-processor for other commercial software [message #50450 is a reply to message #50422] |
Mon, 02 October 2006 06:01   |
mvukovic
Messages: 63 Registered: July 1998
|
Member |
|
|
Robbie wrote:
> Dear Mirko,
>
> I think that ITTVIS do not favour direct graphics because they look
> clunky (not anti-aliased). In fact, all IDL widgets look clunky. Even
> bitmap buttons look clunky! They don't have time to fix it, and don't
> want to risk breaking old code.
>
> Sorry for the little outburst, but perhaps ITTVIS should ship FFT
> glasses with future versions of IDL to solve this problem once and for
> all.
>
> In the meantime, there are some anti-aliased versions of direct
> graphics procedures written by Tobin Munsat.
>
> http://www.ittvis.com/codebank/search.asp?search=newsub& product=IDL
>
> Robbie
Naively speaking, I would think it would be rather simple to use a
better rendering engine for DGs. And the fancy anti-aliased OG's (that
I use through iTools), may look nice on the screen, but produce
disjointed plots when printed out.
Still, I do not complain. I love using iTools.
And my original point was the surprise of seeing iTools in a non-ITTVIS
commercial application.
Cheers,
Mirko
|
|
|
|
Re: IDL & iTools used as post-processor for other commercial software [message #50529 is a reply to message #50399] |
Wed, 04 October 2006 08:51  |
MarioIncandenza
Messages: 231 Registered: February 2005
|
Senior Member |
|
|
Comparing Mirko and Bob's viewpoints does show a remarkable degree of
convergence in what is possible with the two approaches. The idea that
you might be able to meet the requirements of a peer-reviewed
profession with an interactive tool is pretty impressive, honestly. The
cornerstone of these requirements is that any graphic produced can be
re-generated on-demand starting from the data in a relatively raw form,
or using different data. Bob's scripts contain the entire process,
which I think is probably pretty typical for scientific users. My own
scripts generally start with loading data (often several hundred MB).
Does iTools have a mechanism (or perhaps, could one be built in) to
keep the code used to distill from the "original" input datasets down
to the numbers for the plot? With this feature, you truly could go from
having a script associated with every plot to having an iTool. This
might actually be an improvement over a script-based process, although
I don't know if it would get me to switch. Since everything I do
graphically is 96% recycled code, the cost-benefit calculation is
pretty tight.
But anyway, even the suggestion that an interactive tool can produce
acceptable, reproducible on-demand results I find very encouraging. I
know too many people who have turned away from science because a) "if I
wanted to be a programmer, I'd have studied programming," or b) "if all
I'm doing is programming, why don't I just get paid for it?"
--Edward H.
|
|
|