| GIF again..... [message #23077] |
Fri, 05 January 2001 14:14  |
Richard French
Messages: 173
Registered: December 2000
|
Senior Member |
|
|
After 5.4 came out, there were a lot of posts about the disappearance
of the GIF writer and reader routines. Can any of you experts tell me
about the legality of using shareware C code that reads and writes
GIF files, originally used as part of the XV program that displays
lots of image types on UNIX boxes? The idea would be to write
wrapper routines that could call WriteGIF and ReadGIF in the XV
code so that GIF writing and reading could be restored in IDL.
These routines are in the pub/xv subdirectory of
ftp.cis.upenn.edu
If this is not legal, does it mean that XV is not legal,
either, even if you pay the registration fee?
Has anyone come up with a legal scheme under UNIX to
read and write GIF files? If you have to pay a license fee, does
anyone know what the fee would be for a single user?
Thanks for any hints on workarounds.
Dick French
|
|
|
|
| Re: GIF again..... [message #23161 is a reply to message #23077] |
Mon, 08 January 2001 02:13  |
wmconnolley
Messages: 106
Registered: November 2000
|
Senior Member |
|
|
Richard G. French <rfrench@wellesley.edu> wrote:
> JD Smith wrote:
> That imagemagick site looks terrific - thanks for the tip.
> I am happy to discontinue creating gifs, but I have about
> 1000 gifs I've made already that I would like to be able to read!
Well, I had the same problem and produced:
PRO READ_GIF, FILE, IMAGE, R, G, B, MULTIPLE=mult, CLOSE=close
; WMC kludge
if (!version.release eq '5.4') then begin
print,'Version is 5.4 so faking read_gif with png''s'
base=basename(file)
spawn,'convert gif:'+file+' png:/tmp/'+base
image=read_png('/tmp/'+base,r,g,b)
spawn,'rm /tmp/'+base
return
endif
; Now continue on into the standard read_gif as written by IDL...
This uses the "convert" program from ImageMagick. Its rather kludgey
(not even safe for multi-users and will gratuitously fail in 5.5) and
also somewhat slow but works OK for now...
-W.
|
|
|
|
| Re: GIF again..... [message #23173 is a reply to message #23077] |
Fri, 05 January 2001 17:23 |
Jeff Guerber
Messages: 41
Registered: July 2000
|
Member |
|
|
Dick,
xv's current home is http://www.trilon.com/xv/. I seem to recall
seeing something there (although I can't find it now) indicating that GIF
licensing is the reason there hasn't been a complete, new version of xv
since 3.10a in 1994! (I am not a lawyer, so I'll refrain from taking this
any further. Actually, I always thought that it was only _writing_ GIFs
that was illegal; but, as I said, IANAL.) We're looking into working
around the lack of GIF support in IDL by using PNG (which was developed by
the W3C itself) instead :-).
(The Web site does have a number of patches you can apply to the 3.10a
sources; my system manager recently rebuilt our copy with the patches, and
they seem to work great. Not that it helps for what you want to do.)
Usual disclamers apply: IANAL, I don't speak for NASA or Raytheon,
etc. etc.
Jeff Guerber
On Fri, 5 Jan 2001, Richard G. French wrote:
> After 5.4 came out, there were a lot of posts about the disappearance
> of the GIF writer and reader routines. Can any of you experts tell me
> about the legality of using shareware C code that reads and writes
> GIF files, originally used as part of the XV program that displays
> lots of image types on UNIX boxes? The idea would be to write
> wrapper routines that could call WriteGIF and ReadGIF in the XV
> code so that GIF writing and reading could be restored in IDL.
>
> These routines are in the pub/xv subdirectory of
> ftp.cis.upenn.edu
>
> If this is not legal, does it mean that XV is not legal,
> either, even if you pay the registration fee?
>
> Has anyone come up with a legal scheme under UNIX to
> read and write GIF files? If you have to pay a license fee, does
> anyone know what the fee would be for a single user?
> Thanks for any hints on workarounds.
> Dick French
|
|
|
|
| Re: gif again [message #32323 is a reply to message #23077] |
Wed, 02 October 2002 17:22 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Reimar Bauer <R.Bauer@fz-juelich.de> writes:
> Hi
>
> you are seeing I am very interested in doing as simple as possible a set
> of animations.
>
> Yesterday someone tolds me thats it is possible to have uncompressed
> gif. Did someone know if rsi would implement this kind of format again
> in this mode.
>
> My slow motion animation of about 20 to 100 images would be best stored
> in gif. Because in difference to the other formats I can set a wait time
> to each frame. It looks like that's an uncompressed gif is smaller as a
> compressed mpeg multiplied the frames by 24.
It is possible to take the idl_gif DLM from previous versions of IDL,
and copy it into place in your current installation. In some cases,
that will work.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: gif again [message #32337 is a reply to message #23077] |
Wed, 02 October 2002 09:24 |
Stein Vidar Hagfors H[1]
Messages: 56
Registered: February 2000
|
Member |
|
|
Reimar Bauer <R.Bauer@fz-juelich.de> writes:
> Hi
>
> you are seeing I am very interested in doing as simple as possible a
> set of animations.
>
> Yesterday someone tolds me thats it is possible to have uncompressed
> gif. Did someone know if rsi would implement this kind of format again
> in this mode.
>
> My slow motion animation of about 20 to 100 images would be best
> stored in gif. Because in difference to the other formats I can set a
> wait time to each frame. It looks like that's an uncompressed gif is
> smaller as a compressed mpeg multiplied the frames by 24.
If you can use the unix program mpeg_encode (e.g. version 1.5),
instead of IDL's "one-size-fits-all" MPEG cruncher, you don't have to
live with the huge files created by multiplying the frames. The key is
to encode all "extra" frames as a difference frame from the previous
one; since the difference is nothing, almost no space is needed.
In fact, I have a shell script that uses mpeg_play & mpeg_encode
together to "expand" a too-fast-playing mpeg by any (integer) factor,
without even having the original frames.
--
------------------------------------------------------------ --------------
Stein Vidar Hagfors Haugan
ESA SOHO SOC/European Space Agency Science Operations Coordinator for SOHO
NASA Goddard Space Flight Center, Email: shaugan@esa.nascom.nasa.gov
Mail Code 682.3, Bld. 26, Room G-1, Tel.: 1-301-286-9028/240-354-6066
Greenbelt, Maryland 20771, USA. Fax: 1-301-286-0264
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
