Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Re: IDL & iTools used as post-processor for other commercial software
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
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
In article <1159794079.042385.226170@b28g2000cwb.googlegroups.com>, mvukovic@nycap.rr.com wrote: > Still, I do not complain. I love using iTools. We should make a note in the Archive of Notable comp.lang.idl-pvwave Events. I think this is the first time that I have heard anyone say that they LOVE iTools. ;-) Ken Bowman
Kenneth Bowman wrote: > In article <1159794079.042385.226170@b28g2000cwb.googlegroups.com>, > mvukovic@nycap.rr.com wrote: > >> Still, I do not complain. I love using iTools. > > We should make a note in the Archive of Notable comp.lang.idl-pvwave Events. I > think this is the first time that I have heard anyone say that they LOVE iTools. > > ;-) > > Ken Bowman 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. :-) Mirko
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. :-( -- 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.")
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
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.")
David Fanning wrote: > 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. :-) > Oh, dear. I knew I was entering dangerous terrain writing that! Let me emphasize I was trying to make a joke. By the way, I learned that saying (not being a native English speaker) from my advisor when I tried to explain that one should use user values to store data in widget programs rather than common blocks. Cheers, Benjamin
Benjamin Hornberger writes: > Oh, dear. I knew I was entering dangerous terrain writing that! Let me > emphasize I was trying to make a joke. Well, I figured as much. I know better than to take newsgroup articles personally, but after all the effort I put into teaching people how to do innovative things on this newsgroup, being called a Luddite did manage to push a button. Please don't pass this thread on to my youngest or my life will be a complete mess. :-) 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.")
I would tend to agree that the argument that "iTools is too complicated" is a bit flawed. iTools is much simpler than the implementations of interactive UIs in other computer langauges. I'd prefer to argue that "it is too complicated to apply iTools to my problem". There is a subtle difference in the wording, but I think it is a better way to view our difficulty with iTools. We all have very individual needs, and I cannot see how iTools can be the magic bullet for all of them. iTools is just an API, it's not an entire computer language. I'd like to see ITTVIS develop other visualisation APIs which work with Object Graphics. I'd particularily like to see an API with a highly efficient message passing system and the ability to build visualisation applications from the ground up.
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
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
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
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.