On Wed, Nov 24, 1999 at 09:51:35PM +0100, Sven Neumann <[EMAIL PROTECTED]> 
> >         multilayer image describing an animation.
> >     If it does not exist then the multiple layers describe a single
> >         image (as usual)
> > 
> Who is supposed to set this parasite?

All plug-ins (mostly file loaders) who have this information. For example
almost all file-formats naturally know wether they store an animation or
not. xcf doesn't, and for the rest it probably doesn't matter. (it is fine
to leave this undefined).

> How can Gimp know if your image is an animation or just a weird
> multi-layer image?

Most gfx formats now this intrinsically.

> Did I miss something?

Probably not. Let's speculate on how export might behave:

image is anim?  filter handles anim?    export does
yes             yes                     do nothing
yes             no                      asks or autoconverts
no              yes                     asks or autoconverts
no              no                      do nothing
unknown         any                     asks

However, I have not proposed on how to decode that an image is _not_ an
animation. Maybe in that case we can set interframe-delay to "N/A".

The only problem I see is when a user loads multiple jpeg files and
concatenates them, but we can still chose to just leave the "animtype"
undefined (so export can skip the dialog box when an animation is saved as
an animation).

(btw it is trivial to write a plug-in that erases or sets animation

Also, this does not need to be implemenbted in export before 1.2. But we
can safely leave this half implemented in a few load-save plug-ins.

I just wanted to standardize on some future extensions to the animation

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |

Reply via email to