comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: IDL 5.4. Neato. NOT.
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: IDL 5.4. Neato. NOT. [message #22237] Mon, 30 October 2000 06:04 Go to next message
Paul van Delst is currently offline  Paul van Delst
Messages: 364
Registered: March 1997
Senior Member
"Joseph B. Gurman" wrote:
>
> In article <39F9F19A.7912306D@ncep.noaa.gov>, Paul van Delst
> <pvandelst@ncep.noaa.gov> wrote:
>
>> p.s. FWIW, I applaud RSI for not caving and paying license fees for the
>> LZW/GIF stuff.
>
> Without any real details of the terms and conditions, I can't concur.

I made that statement somewhat based on my rather isolated and insulated usage of IDL but
mostly on principle (I reckon Unisys pulled a fast and dirty one) rather than real world
economies such as affects Joseph Gurman and Co. After reading his summary, it could be
quite a soul- (and budget-) destroying job having to convert a bunch of code to input and
output different image formats (despite Dennis Boccippio's suggested solution).

Maybe a better solution would have been for RSI/Kodak to offer licenses just for that
capability, e.g. you pay extra $$ and you get sent an extra "FEATURE" line for your
license.dat for LZW/GIF stuff. I have that option for my (unix based) Fortran/C/C++
compilers (i.e. extra $$, access to more compilers).

So, at the risk of it seeming I change my mind more than my underpants, I guess I agree
with Joseph Gurman.

Having said all that, I have never used IDL's ability to create GIF output mostly because
I think the text looks really crappy (although I recognise there are ways to improve the
look of the text output...not enough for my liking though). I create PS output and then
use Unix utilities (which are free or site licensed) to convert the PS->GIF. For cases
where I have done this on a semi-regular basis, I have run IDL within a shell script so
folding in the convert process was trivial (read: No SPAWN use). This, of course, isn't a
solution for Windows based (or Mac?) users.

paulv

p.s. My comments above are not to be confused with those for whom I currently work. Me
just peon.

--
Paul van Delst Ph: (301) 763-8000 x7274
CIMSS @ NOAA/NCEP Fax: (301) 763-8545
Rm.202, 5200 Auth Rd. Email: pvandelst@ncep.noaa.gov
Camp Springs MD 20746
Re: IDL 5.4. Neato. NOT. [message #22241 is a reply to message #22237] Sun, 29 October 2000 09:28 Go to previous messageGo to next message
Joseph B. Gurman is currently offline  Joseph B. Gurman
Messages: 31
Registered: April 2000
Member
In article <djboccip-6E662E.07013329102000@news2.mco.bellsouth.net>,
"Dennis J. Boccippio" <djboccip@bellsouth.net> wrote:

> Posting from home so as to forego the possibility that _our_ ODIN vendor
> will lose my post. In partial response to Joseph's issue (4) below:
>
> Q: Will 5.4's non-support of LZW (specifically, WRITE_GIF) balk at _any_
> routine named 'WRITE_GIF'? It strikes me that we, in theory, should be
> able to replace the built-in WRITE_GIF with our own code which, e.g.,
> calls WRITE_PNG, and then spawns a Unix process which converts the PNG
> to GIF using 3rd party tools, or an Applescript that calls
> GraphicConverter to do the same (I'm pretty sure GC is scriptable).
> Sorry, Windows folks, no idea how this would be done on that platform...
>
> Anyway, if this were possible, it'd be a one-time fix (for the write
> routines at least, although presumably the same could be done for
> reading) rather than a huge amount of code retooling...
>
> - Dennis Boccippio
>
> ( PS - can confirm that Mac GC is scriptable... I note the following
> entry in its AppleScript Dictionary:
>
> save reference [in alias] as [list of types, including GIF] makeCopy
> boolean
>
> On Un*x, the 'convert' command comes along with a package that I've
> forgotten - ImageMagick, or libppm, or something...)

That sounds like a good plan, and another reason we would be staying
with 5.3 for a while --- to test the new and old "WRITE_GIF" and
"READ_GIF" side by side for a while to see how close to indetical
results one could get before then trying to test the new one with 5.4.

I notice that the Mac OS QuickTime viewer no longer exports as GIF,
so I wonder how AppleScript is able to do so....

In any case, I'm certain there are ways to work around this, but in
the real world, any such implementation takes people's time, which means
money. In this case, money that Kodak will not be getting. Seems
shortsighted as a business decision to me --- but once again, we don't
have enough, er, insight into the process to know what Unisys demanded.
Re: IDL 5.4. Neato. NOT. [message #22242 is a reply to message #22241] Sun, 29 October 2000 04:01 Go to previous messageGo to next message
Dennis J. Boccippio is currently offline  Dennis J. Boccippio
Messages: 6
Registered: July 2000
Junior Member
Posting from home so as to forego the possibility that _our_ ODIN vendor
will lose my post. In partial response to Joseph's issue (4) below:

Q: Will 5.4's non-support of LZW (specifically, WRITE_GIF) balk at _any_
routine named 'WRITE_GIF'? It strikes me that we, in theory, should be
able to replace the built-in WRITE_GIF with our own code which, e.g.,
calls WRITE_PNG, and then spawns a Unix process which converts the PNG
to GIF using 3rd party tools, or an Applescript that calls
GraphicConverter to do the same (I'm pretty sure GC is scriptable).
Sorry, Windows folks, no idea how this would be done on that platform...

Anyway, if this were possible, it'd be a one-time fix (for the write
routines at least, although presumably the same could be done for
reading) rather than a huge amount of code retooling...

- Dennis Boccippio

( PS - can confirm that Mac GC is scriptable... I note the following
entry in its AppleScript Dictionary:

save reference [in alias] as [list of types, including GIF] makeCopy
boolean

On Un*x, the 'convert' command comes along with a package that I've
forgotten - ImageMagick, or libppm, or something...)




In article <gurman-AE7196.23033928102000@news.crosslink.net>, "Joseph
B. Gurman" <gurman@ari.net> wrote:

> In article <39F9F19A.7912306D@ncep.noaa.gov>, Paul van Delst
> <pvandelst@ncep.noaa.gov> wrote:
>
>> p.s. FWIW, I applaud RSI for not caving and paying license fees for the
>> LZW/GIF stuff.
>
> Without any real details of the terms and conditions, I can't concur.
>
> Thanks to the Goddard news non-server, in turn thanks to our magnificent
> ODIN contractor, my original rant on this subject didn't get posted, but
> I will summarize.
>
> 1. If it doesn't require divulging company-proprietary information, we
> would all like to hear how nisys classified IDL and how much a luicense
> would have cost the end user.
>
> 2. It would be really nice if Kodak/RSI management would realize that a
> fair fraction of IDL licenses are used to create Web content every day,
> and that usage is mor eimportant to those licensees than swanky, new
> programming features.
>
> 3. Aforesaid licensees will pay for additional, Web-friendly features
> such as QuickTime and yes, even GIF support. There is no reason why the
> functionalities couldn't have been offered as separately licensed
> products, as the wavelet kit is, no matter how expensive (the wavelet
> kit certainly isn't cheap). That way, those who need them could decide
> --- rather than Kodak --- whether to pay for them or not.
>
> 4. Some of those licensees have hundreds of modules that read and write
> GIFS. Is it worth changing them all? Without knowledge of the Unisys/RSI
> negotiations, we can't really tell.
>
> 5. This is such a major issue for us that we will be in no hurry to
> upgrade to 5.4, and as a result, probably no hurry to purchase software
> maintenance. IMHO, this means a loss of revenue stream for Kodak/RSI.
> How big a loss, I can't tell. We have ~ 20 licenses.
>
> 6. All of the above is said without regard to the superiority of PNG
> and/or any other graphic interchange format (real or supposed) over GIF,
> merely obn the basis of investment in existing code and the
> Web-accessing world's level of comfort with GIFs.
>
> Any software vendor that abandons its user base on a major item such
> as this can't expect loyalty. Given David Stern's personal relationship
> with many of his longstanding customers, RSI is going to have a hard
> time convincing me that this issue isn't what prompted David to sell to
> Kodak.
>
> Joe Gurman
Re: IDL 5.4. Neato. NOT. [message #22303 is a reply to message #22242] Thu, 02 November 2000 06:53 Go to previous message
colinr is currently offline  colinr
Messages: 30
Registered: July 1999
Member
On Sun, 29 Oct 2000 07:01:33 -0500,
Dennis J. Boccippio <djboccip@bellsouth.net> wrote:
> Posting from home so as to forego the possibility that _our_ ODIN vendor
> will lose my post. In partial response to Joseph's issue (4) below:
>
> Q: Will 5.4's non-support of LZW (specifically, WRITE_GIF) balk at _any_
> routine named 'WRITE_GIF'?

> On Un*x, the 'convert' command comes along with a package that I've
> forgotten - ImageMagick, or libppm, or something...)

Yes, ImageMagick.

pro write_gif,filename,image,_extra=e
write_bmp,'./temp.bmp',image,_extra=e
spawn,'convert temp.bmp '+filename
spawn,'rm temp.bmp'
end

is a quick and dirty fix for me. Of course what's needed is a routine which
will identify one's system, hunt down a suitable conversion routine, and
use that.

--
Colin Rosenthal
Astrophysics Institute
University of Oslo
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: looking for a compile_opt option
Next Topic: Re: IDLWAVE fontlock / fontify weirdness in Xemacs

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:50:29 PDT 2025

Total time taken to generate the page: 0.00770 seconds