active layers (was: Onion Skinning for GIMP/GAP)
On Fri, 10 Nov 2000, "wolfgang hofer" <[EMAIL PROTECTED]> wrote:
> For painting Animations it can be useful
> to see the previous or next frame(s)
> more or less transparent.
>
> Here are 2 Variants A) and B) how to implement such features in GIMP.
[...]
> B) OnionLayer is a new 'special' layertype,
>known to the GIMP core app.
>GIMP offers a PDB Interface
>
>- gimp_image_add_onionlayer(image_id, src_image_id,
>OnionPosition,
>OnionRevers,
>OnionOpacity,
>OnionMode)
>
>(do we need a special PDB interface for remove ?)
>
>GIMP should display the OnionLayer like any other Layer,
>but set to ReadOnly. (if possible)
>
>The Display of image_id colud be updated on
>every change of src_image_id
>as long as src_image_id is valid.
[...]
This looks very similar to the concept of "active layers" or "shadow
layers" that I explained some time ago on this list. Other proposals
have been discussed as well, using different or similar names ("action
layers", "plug-in layers") and doing different or similar things, so
it is a bit difficult to remember what each proposal is about (because
the similar names are confusing but the underlying concepts are
sometimes different). The concept that I am refering to is the
following:
- You could add an "active layer" to an image. This layer takes as
parameters the name of a PDB function, plus some other parameters
such as references to other layers or layer groups (the layer groups
are planned for 2.0, I think).
- The references to other layers can be relative (N layers above or
below the current one) or absolute (layer number X in the stack).
- The "active layer" cannot be edited by the user.
- The layer shown or hidden, its opacity can be changed like a normal
layer, and it can be moved up or down in the stack (as long as the
contstraints of the relative references are respected).
- When you create the layer or whenever one of the referenced layers
changes, the PDB function associated with the "active layer" is run
(taking its input from the other layers) and the result is stored in
the tiles of the "active layer".
- It is possible to disable the automatic updating of the "active
layer" and to switch to manual updates for performance reasons.
Originally, I was thinking about using layer references inside the
current image only, because then you can save all parameters of the
active layer into the XCF file and they would have no dependencies on
other files.
But your proposal for "onion layers" looks like a natural extension of
this concept, if you allow an "active layer" to reference some layers
in another image. These layers with external dependencies could not
be saved in the XCF file (or we would have to come up with a very
clever mechanism for maintaining the dependencies between images) but
that would be enough for what you want to do with them. In this case,
the PDB function would be a simple copy of the referenced layer.
There are some plans to implement something like this for 2.0, so we
could start thinking about the details as soon as 1.2 is out.
-Raphael
Onion Skinning for GIMP/GAP
Hi,
On Fri, Nov 03, 2000 at 06:49:53PM -0800, thus said Caroline Dahllof:
>
> Yeah, I thought about adding it the fg image as a layer to the bg image
> but I thought that there would be a nicer way of doing it. WHat I am
> trying to do is onion skinning. Users want to see two images displayed in
> the same display. They want to be able to offset these images. They use
> this for cloning.
>
> Thanks,
For painting Animations it can be useful
to see the previous or next frame(s)
more or less transparent.
Here are 2 Variants A) and B) how to implement such features in GIMP.
A) The OnionSkin Layer(s) has
NO special Meaning to the GIMP core Application.
GAP creates them optional as normal Layers
in the current frame image, using a special Name
and/or Parasite to identify them.
1) automatic creation of onion_layer(s)
is done on evry GAP-controlled load image
Operation, but only if Parameter
OnionLayersAutomatic is TRUE
(as video/goto/next .
and most of the other video menu actions)
2) per explicite User request
(via KeyShortcut or video/onion/CREATE
a new gap-plugin gap_set_onion)
Before every GAP-controlled save image
and before onion_layer creation
the Onion Layers are removed from the frame.
If the user saves the current frame explicite
the Onion Layer(s) goes into the diskfile.
!! This may be a fatal Problem only
for frameformat that cannot handle layers -- like jpeg --
the original frame is merged with its onion layer,
A new GAP PlugIn implements a Dialog for the Parameters,
and explicite Funtions to Turn OnionLayers ON (CREATE) or OFF (REMOVE).
video/onion/CREATE
video/onion/REMOVE
video/onion/Parameters
Parameters for OnionLayers:
- Number of Onion Layers
- OnionLayersAutomatic TRUE/FALSE
per layer:
- OnionPosition in the Layerstack
- OnionRevers TRUE/FALSE (TRUE: Position 0 == on top, FALSE: Position 0 is on
Botttom)
- OnionOpacity 0.0 upto 100.0 %
(how to calculate source framenumber)
- OnionMode FLATTEN | MERGE_VISIBBLE_LAYERS
(how GAP creates the onion Layer)
- OnionFrameDelta 1,2,3.. or -1,-2,-3 ..
alternative to OnionFrameDelta you can specify
to use any other image (that is opened in the gimp)
The Parameters are stored in the GAP Video Info File .vin
B) OnionLayer is a new 'special' layertype,
known to the GIMP core app.
GIMP offers a PDB Interface
- gimp_image_add_onionlayer(image_id, src_image_id,
OnionPosition,
OnionRevers,
OnionOpacity,
OnionMode)
(do we need a special PDB interface for remove ?)
GIMP should display the OnionLayer like any other Layer,
but set to ReadOnly. (if possible)
The Display of image_id colud be updated on
every change of src_image_id
as long as src_image_id is valid.
When src_image_id is closed,
the onion layer should stay as it is.
This is important for GAP, because
usually the previous frame is not open
at the same time, and moving to the next
frame keeps the same image_id.
When GAP loads a new/next frame
GAP renders a temporary image containing
just the onion layers, and adds the onion_layers
to the new current frame. Then the temporary image
is close.
L&C dialog:
- the onion layer can be moved in the layerstack,
set visible/invisible and opacity values
- should be marked somehow
(similar to floating sel we could use
a Special Icon)
- can be deleted
- can be copied (the resulting copy should be a normal layer)
- but can not be moved. (or linked for groped moves)
(the fixed to position 0/0,
maybe we just ignore its position values when displayed)
GIMP sould never save onion layers !!
(the layerlist provided to file_save Plugins
should not contain onion_layer id's,
maybe gimp has a seperate list of OnionLayers,
L&C Dialog has to mix Layers from
both Layer List and OnionLayer List)
These Ideas are NOT complete concepts,
and need some more time to think about it.
Further Things to think about are:
- It is to late to implement this for the gimp 1.2 release.
- I don't know if there will be a 1.3 release ?
- Don't know if GIMP 2.0 adds animation features
to the core and makes GAP obsolete in the future ?
Wolgang Hofer <[EMAIL PROTECTED]>
Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com
Re: GAP
On Mon, Dec 13, 1999 at 02:19:16PM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > Well, much as I agree that providing essential features from GimpPerl is > not the most desirable solution (sorry Marc) No, there are simple pratcical reasons for that. For every feature you provide you have to think about the additional value against the additional dependencies. Some things (that are implemented in perl) would not significantly lower the number of dependencies when done in another language. gap-vcr could be done in gap without any additional dependencies, however. So it's obvious what is better. > erm "Plan to throw one away, you will anyway" and all that. Yepp. (I was under the impression that gap was no longer nmaintained anyway, but that was wrong). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: GAP
On Mon, Dec 13, 1999 at 09:59:53AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > would need some good thoughts and probably even the redesign of some core > menus are hacked up Sven, I appreciate your comment on my plug-in. Have you looked at it? I do not consider it "being hacked up" thanks a lot and please go on valueing the work of others that low. > in a scripting language that is not supported on all systems. That scripting language is supported on many MORE systems than java and gimp together, mind you? The interface to it, if you meant to say that, is supported on all systems except win32 (which would require makefile changes at most I presume). Come on Sven, this is FUD. > Great, now we have two ways to access the GAP (Actually, we have over 20 ways or so...) I think the current interface is indeed hacked up (on the PDB level), btw. (for example it isn't even possible to adjust the brightness with filter all layers, at leats not with additional, really disgusting hacks). However, I consider it short-minded to think that a simple addition of a vcr console to gap would fix all the internal problems of that plug-in (that should have been written in perl anyway, where it is *way* easier to implement the very simple functionality of the gap plug-in family in a more correct way). > Doesn't that really make it much more useful and intuitive for the > average GIMP user. I think the gimp-user is the last one to tell the different between gtk+ and gtk+. It would be really intuitive for the user if Filter all Layers (for example) wouldn't be limited to c and perl plug-ins. I will happily remove my hack once gap is fixed. This has happened before and I didn't cry to be superceded. It has also happened a lot more times, however, that people announced these-and-those improvements and never did it (Hello Sven, btw!). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: GAP
Disclaimer: I don't use GAP, though perhaps I should learn now... On Mon, Dec 13, 1999 at 09:59:53AM +0100, Sven Neumann wrote: > Oh, how much do I love when new features that would be really useful but > would need some good thoughts and probably even the redesign of some core > menus are hacked up in a scripting language that is not supported on all > systems. Well, much as I agree that providing essential features from GimpPerl is not the most desirable solution (sorry Marc) it DOES give us a way to try stuff out quickly, or at least it does for the apparently significant portion of Gimp's user community who have GimpPerl + PerlGtk. Presumably tigert now has some insight into what is good or bad about the hack from Marc, and that helps make the polished version better, erm "Plan to throw one away, you will anyway" and all that. Nick.
Re: GAP
Hi, Tigert wrote: > Well there is now the gimp/plug-ins/perl/examples/gap-vcr in cvs that is > implemented in gnome-perl. It is very basic, but it somewhat works. Oh, how much do I love when new features that would be really useful but would need some good thoughts and probably even the redesign of some core menus are hacked up in a scripting language that is not supported on all systems. Great, now we have two ways to access the GAP. Doesn't that really make it much more useful and intuitive for the average GIMP user. I'd say: Drop this (probably nice) hack and wait for the changes Wolfgang just announced. Salut, Sven
Re: GAP VCR-GUI
There are already Plans for a NaviagtorDialog Window for the GAP, to provide a better GUI for some of the GAP basic functions. The Navigator Window has Buttons like a "VCR Console". [ |<< ] [ < ] [ > ] [ >>| ] There will be a Listbox with a scrollbar. (similar to the Layers and Channels Dialog) The Items in the Listbox are Thumbnail Icons of the AnimFrames and a label that shows the frame Number (0001) and another Label that shows the frame starttime (min:sec:msec) For the Thumbnails I will use the Icons in the .xvpics Subdirectory. (Therefore most GAP functions must be extended to update the .xvpics/frame_0001.xcf icons as well) A doubleclick on a Thumbnail takes you to the selected AnimFrame. (the GAP Goto function) A single Click will select the frame (ctrl, and shift to select additional frames or framerange) There will be Widgets with Spinbuttons where you can enter a global framerate and a timezoom. With the timezoom you can adjust what you'll see in the Listbox. timezoom==1 shows: frame_0001 frame_0002 frame_0003 ... timezoom==10 shows: frame_0001 frame_0011 frame_0021 ... Further Buttons [ S ] Select All Frames [ X ] Delete selected Frame(s) [ C ] Duplicate selected Frame(s) [ U ] Update Thumbnails Playback: A Playback Button could call - Video|Frames To Image (for the selected frames) and then: - Filters|Animation|Animation Playback on the generated Image It'll take some time to implement the navigator ... (do not expect the GAP navigator in gimp 1.2) Yours Wolfgang Hofer, <[EMAIL PROTECTED]> (Author of GAP) HotBot - Search smarter. http://www.hotbot.com
Re: GAP
On Sun, Dec 12, 1999 at 01:47:11PM +0100, Sven Neumann wrote: > > > > I have thought of this for a while now, but now I decided to put it into > > ascii form... > > > > Would it be possible to implement a "VCR Console" for GAP plugins? > > I think it would be very useful and from what I understand it might > > even be easy? > > > > Something with [ |<< ] [ < ] [ > ] [ >>| ] and maybe even > > play facility (trigger "next frame" in every ms or > > something?) > > > > Thoughts? I think it would improve the usability a lot.. > > > > Yes, me too!! ;-) > > Actually the reason I've put GAP into CVS was that I think it is a very > useful extension to The GIMP that needs a more comfortable GUI. My hope > was that someone would take this as an interesting project to work on... > > IMHO the GAP should be implemented ( GUI-wise ) as a seperate tool. There > could be one menu entry to start the GAP console that comes with a VCR > interface to switch frames and a whole bunch of possible actions (more or > less the Video-Menu we have now). An approach like this would make working > on animations more easy and at the same time hide the animation stuff from > the main GIMP interface where it confuses the user who wants to do still > image manipulation. > > Having said that, I must admit that I don't have the time to work on this, > but probably someone else feels choosen?? Well there is now the gimp/plug-ins/perl/examples/gap-vcr in cvs that is implemented in gnome-perl. It is very basic, but it somewhat works. It was something like 15 minutes after I asked in #gimp and Marc had this :) Tig -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: GAP
> > I have thought of this for a while now, but now I decided to put it into > ascii form... > > Would it be possible to implement a "VCR Console" for GAP plugins? > I think it would be very useful and from what I understand it might > even be easy? > > Something with [ |<< ] [ < ] [ > ] [ >>| ] and maybe even > play facility (trigger "next frame" in every ms or > something?) > > Thoughts? I think it would improve the usability a lot.. > Yes, me too!! ;-) Actually the reason I've put GAP into CVS was that I think it is a very useful extension to The GIMP that needs a more comfortable GUI. My hope was that someone would take this as an interesting project to work on... IMHO the GAP should be implemented ( GUI-wise ) as a seperate tool. There could be one menu entry to start the GAP console that comes with a VCR interface to switch frames and a whole bunch of possible actions (more or less the Video-Menu we have now). An approach like this would make working on animations more easy and at the same time hide the animation stuff from the main GIMP interface where it confuses the user who wants to do still image manipulation. Having said that, I must admit that I don't have the time to work on this, but probably someone else feels choosen?? Salut, Sven
Re: GAP
On Fri, Dec 10, 1999 at 12:56:14PM -0800, Tuomas Kuosmanen wrote: > Would it be possible to implement a "VCR Console" for GAP plugins? > I think it would be very useful and from what I understand it might > even be easy? > > Something with [ |<< ] [ < ] [ > ] [ >>| ] and maybe even > play facility (trigger "next frame" in every ms or > something?) Wouldn't Filters/Anim/Play Animations do about this? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
GAP
I have thought of this for a while now, but now I decided to put it into ascii form... Would it be possible to implement a "VCR Console" for GAP plugins? I think it would be very useful and from what I understand it might even be easy? Something with [ |<< ] [ < ] [ > ] [ >>| ] and maybe even play facility (trigger "next frame" in every ms or something?) Thoughts? I think it would improve the usability a lot.. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
