Re: [Gimp-developer] Re: [Gimp-user] [Fwd: Gimp interface streamlining]
Willie Sippel wrote: Check my new mockup, I've changed this. It's available at http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png . I rather like the way this is going. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 "I am NOT a nut! I am the keeper of the seven universal truths!" ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?
On Sat, 2003-09-06 at 02:35, Tor Lillqvist wrote: > OK, I tried to use a GAP's move path on a high resolution image. It > seems to require a moving image as source? If a want to use a *still* It can be a still. > image as source, does this mean I have to create n copies of the > already large image, and GAP then loads each (identical) image > separately, and extracts the zoomed-in and panned frame from it? No. You just have one source image that will be rendered to the final composite as a new layer. > Ugh. Also, the GAP's move path dialog didn't seem to have a way to set > the destination frame size directly in pixels, only hard-to-use > percentages? Yes, only in percentages. I have made a tutorial on GAP that has a description of the move path dialog at http://jimmac.musichall.cz/tutor2.php3 that you may find useful. cheers -- Jakub Steiner <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
[Gimp-developer] Screenshot plug-in status
Henrik Brix Andersen writes: > It would be nice if someone on say... win32 ;)... would have a go at > writing the missing win32 part of the select_window() function. I get the hint ;-). I'll have a look at it. Grabbing the whole screen with screenshot (without any Win32 specific code yet) was *much* slower than with winsnap. It was the image transfer phase from the plug-in to GIMP that was a lot slower. I tried to change the code to just call gimp_pixel_rgn_set_rect() once, like winsnap does, instead of calling gimp_pixel_rgn_set_row() in a loop. And it is now much speedier. Do you see any reason why this should not be done? (Maybe also call gimp_tile_cache_size(), although calling it like winsnap.c does results in black screendumps, oddly enough.) > When the win32 specific part of select_window() has been written and > committed I plan to retire the win32 specific winsnap plug-in in favor > of the new screenshot plug-in. BTW, shouldn't it be possible to write select_window() using only GDK? gdk_pointer_grab() and, hmmm, well I'll think about it. --tml (Wonder why it seems to take so long for messages to go through [EMAIL PROTECTED] Two or three days. Sobig.F?) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
Willie, Excellent! Lets hope the right folks are paying attention. Seems like a wonderful idea. It's both more functional *and* more attractive. I've always felt the stock Gimp interface was a little too weird/clumsy in it's layout. Cheers, Bowie Bowie J. Poag <[EMAIL PROTECTED]> - Original Message - From: "Willie Sippel" <[EMAIL PROTECTED]> To: "Alan Horkan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, September 03, 2003 11:18 AM Subject: Re: [Gimp-developer] Gimp interface streamlining > I already explained most of my suggestions to Joao. > I did another design, available at > http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png > > On Wed, 2003-09-03 at 18:17, Alan Horkan wrote: > > On 1 Sep 2003, Willie Sippel wrote: > > > > > Date: 01 Sep 2003 20:09:23 +0200 > > > From: Willie Sippel <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: [Gimp-developer] Gimp interface streamlining > > > > > > Hi there. > > > > > > First post, so please go easy on me ;-). > > > > > > Also Gimp always gets better and more powerful, the interface still > > > needs a lot of work. It almost looks like yet another Photoshop clone - > > > > I really dont think GIMP looks at all like Photoshop although ... > > > > > and even if Photoshop is some sort of de facto standard, it's interface > > > is pretty clumsy and inefficient. > > > > ... I agree Photoshop is far from perfect either. > > > > > 1.) Remove unnecessary buttons from the main toolbox to reduce clutter: > > > Smudge, Dodge or Burn, Blur or Sharpen, Erase, Zoom, Color Picker; > > > > I also would love for the toolbox to be customizable > > http://bugzilla.gnome.org/show_bug.cgi?id=105764 > > I don't want a customizable toolbar, but some of these tools are already > modes for paint tools, and the other mentioned tools should be the same. > > > but comletely removing the buttons as you suggest without anyway to add > > them back will likely displease many different people depending on which > > features they happen to use, personally I would miss the Zoom button. > > > > It might also be worth considering better to do like Photoshop and > > Sodipodi and have button submenus, that when you click and hold you get > > more of the related items. > > Screenshot of Adobe Photoshop toolbox submenu > > http://matrix.netsoc.tcd.ie/~horkana/dev/gnome/gimp/screenshots/photoshop/Ad obePhotoshop-clicknhold.png > > shorter link to Photoshop screenshot > > http://tardis.linux.ie/1653/matrix.netsoc.tcd.ie > > > > I know Photoshop very well, but I don't like the submenus, as they are > wasting time (click, hold, wait, look for the right option, move mouse, > release...) - this is unnecessary. Look at my new design for another way > to deal with that issue, might be more useful than a 'click and hold' > menu, and also better than my first suggestion. > > > > 5.) The Color Picker should become available when you click the > > > foreground or background color in the main toolbar, and should set the > > > respective color (set foreground when you clicked the foreground color); > > > > This is already the case in GIMP 1.2, just double click on it. > > > > OK. What about the right or middle mouse button? Check my new mock-up, > I've changed this. > > > > 6.) Add 'Alpha' to the Color Picker; > > > > Consider carefully if the more user friendly term "Transparency" should be > > used. > > > > 'A rose, by any other name...' - granted, but well - it IS alpha. And > Gimp is not Tuxpaint. But I thought about this, and this one should > remain as it is today, 'opacity' on the tool settings. Changing the > current color sliders from HSVRGB to HSVRGBA would be sufficient. > > > > 8.) Remove the giant FG/ BG preview at the bottom of the 'Colors' > > > window to make the interface more compact; > > > > There is an option to hide the brush+pattern preview, an additional option > > to hide the colours widget might be an acceptable idea (but there is > > always the matter of getting some one to write the needed code). > > > 9.) The remaining buttons on the main toolbox should be reordered: > > > Brush | Pen | Airbrush | Ink | Text | Fill | Select | Transform | Create > > > paths | Measure tools > > > > care to explain your reasoning for this reordering? > > > > I changed this one, but I think it's faster if the most common used tool > is also the first button on the list. I think 'ordered by importance' is > better as ordered random, like it seems today... > > > > 15.) Remove the brush and pattern preview from the main toolbox, because > > > it clutters the toolbox - it's redundant, anyway, because there is > > > allready a preview in the tool settings window. It might be even better > > > to also remove the pattern preview from the tool settings and show the > > > selected pattern on the color preview of the main toolbox; > > > > There is already a preference to remove it. > > Toolbox, File, Preferences... > > Interface, > > [] Display Brush, Pattern and Gr
Re: [Gimp-developer] "Ken Burns" style animation tool: standalone orplug-in?
Tor, I wrote/maintain a project that does what you're describing. In realtime, even! :) http://freshmeat.net/projects/show/?topic_id=111,112 ...Might be worth looking into for such a plug-in. I made it as modular as possible, so making a gimp plugin [out of it | for it] may not be too much of a stretch. Cheers, Bowie J. Poag <[EMAIL PROTECTED]> - Original Message - From: "Tor Lillqvist" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 03, 2003 2:54 PM Subject: [Gimp-developer] "Ken Burns" style animation tool: standalone orplug-in? > (No, I haven't seen any Ken Burns documentaries (AFAIK), but his name > comes up all the time when googling for stuff to do this kind of > animation I am talking about here. He probably is known to the > Americans on this list?) > > I have recently toyed with the thought of writing a tool to produce > (low (TV) resolution) animations (for writing to VCD or DVD, mainly) > from (high resolution) still images. I.e. if you have some > multi-megapixel image, with the tool you could produce animations > where you zoom in/out, pan the over some straight or curved path, > rotate the viewport, etc. Seems like a nice way to put a bit more > "life" into your digital image slideshows. > > (For a simple and small commercial standalone tool that does this (on > Windows), check out MovingPicture from Stage Tools, > www.stagetools.com. Demo version downloadable.) > > Would it be better to write this as a GIMP plug-in, or a standalone > tool? > > If written as a GIMP plug-in, it seems natural to use GIMP's Bezier > paths to define the path along which the "virtual camera" moves. Lots > of code saved there. As a plug-in, it would perhaps most closely > resemble the "Easter Egg" plug-ins as it isn't really a filter, > doesn't render anything into a new image, nor does is save or load > images. Hmm. > > The "Ken Burns" plug-in would need to associate more data with the > path. The path nodes would correspond to keyframes between which the > tool would interpolate zooms and camera movements. Each keyframe > would have an associated time values and "virtual camera" orientation > and size vector. (To be able to zoom or rotate without moving the > virtual camera, path nodes might have several associated keyframes.) > > The plug-in would provide a GUI to define the keyframes and their > attributes, and a preview window, but not do the actual rendering of > the animation to AVI, MPEG or whatever format itself, just output a > "recipe" that would then be used by a separate batch-oriented program > to actually render the animation. It should also be possible to load > such a saved recipe and continue working on it, of course. > > One difficult thing is how to handle the fact that it is possible that > the user edits the path while the "Ken Burns" plug-in is active and > already has fetched its data with gimp_path_get_points(). > > Should there be some way for plug-ins to register interest in getting > callbacks when paths nodes are moved/added/deleted, etc? Other > plug-ins for new kinds of functionality might similarily be interested > in getting callbacks when selections are modified, etc. Is there > currently any way for plug-ins to get asynchronous callbacks for > events like these? > > --tml > > > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?
Alan Horkan writes: > If you are particularly ambitious could it be an substantial "Animation > Tool", an interface like a standalone application but substantially > reusing the GIMP components, a sister to the GIMP if you will? (If I am > being wildly unrealistic as usual, just say so). Umm... Yes, that does sound a bit scary. I don't think GIMP's components (like the bezier path tool) are ready yet to be used in other applications. > With the slideshow features you suggest you would have quite a useful and > substantial Presentation program so long as you could through text and > arrows on top. Umm... maybe later. Layering graphics on top of the animation could/should be handled by a separate application, why cram all functionality into one. At least not initially. > > Should there be some way for plug-ins to register interest in getting > > callbacks when paths nodes are moved/added/deleted, etc? Other > i think that would be useful. Yup. Any comments from core developers? Would implementing callbacks to plug-ins be straightforward, or is there some gotcha? Or should plug-ins just poll frequently to see if a path/selection/whatever has been edited? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?
Jakub Steiner writes: > I have sucessfully done this with an existing GIMP plugin - GAP's move > path. At PAL resolution. The only problem is it needs a lot of disk > space and RAM. Hmm, didn't know GAP could do that. I don't think GAP is suitable for this. Takes way too much disk space. Or does it? OK, I tried to use a GAP's move path on a high resolution image. It seems to require a moving image as source? If a want to use a *still* image as source, does this mean I have to create n copies of the already large image, and GAP then loads each (identical) image separately, and extracts the zoomed-in and panned frame from it? Ugh. Also, the GAP's move path dialog didn't seem to have a way to set the destination frame size directly in pixels, only hard-to-use percentages? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug Week!
What do you think, should I perhaps build a fresh Win32 build of GIMP 1.3 for the bug week, and announce it on gimpwin-users? Or will we get overloaded by non-bugs like problems with installing GIMP 1.3 on Windows? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: "Ken Burns" style animation tool: standalone or plug-in?
Tor Lillqvist <[EMAIL PROTECTED]> writes: > I have recently toyed with the thought of writing a tool to produce > (low (TV) resolution) animations (for writing to VCD or DVD, mainly) > from (high resolution) still images. I.e. if you have some > multi-megapixel image, with the tool you could produce animations > where you zoom in/out, pan the over some straight or curved path, > rotate the viewport, etc. Seems like a nice way to put a bit more > "life" into your digital image slideshows. You should look at Cinellera. It does all the things you're looking for, and it saves you a quite a bit of coding in the long run. -- burton samograd [EMAIL PROTECTED] http://kruhftwerk.dyndns.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?
On Wed, 3 Sep 2003, Tor Lillqvist wrote: > Date: Wed, 3 Sep 2003 21:54:31 + > From: Tor Lillqvist <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [Gimp-developer] "Ken Burns" style animation tool: standalone or > plug-in? > I have recently toyed with the thought of writing a tool to produce > (low (TV) resolution) animations (for writing to VCD or DVD, mainly) > from (high resolution) still images. I.e. if you have some > multi-megapixel image, with the tool you could produce animations > where you zoom in/out, pan the over some straight or curved path, > rotate the viewport, etc. Seems like a nice way to put a bit more > "life" into your digital image slideshows. I have seen simple Zoom and Pan web tools written in Javascript, but are interactive tools rather than slideshows exactly. > Would it be better to write this as a GIMP plug-in, or a standalone > tool? Would it be impossible for it to be both? If you are particularly ambitious could it be an substantial "Animation Tool", an interface like a standalone application but substantially reusing the GIMP components, a sister to the GIMP if you will? (If I am being wildly unrealistic as usual, just say so). With the slideshow features you suggest you would have quite a useful and substantial Presentation program so long as you could through text and arrows on top. > If written as a GIMP plug-in, it seems natural to use GIMP's Bezier > paths to define the path along which the "virtual camera" moves. Lots > of code saved there. As a plug-in, it would perhaps most closely > resemble the "Easter Egg" plug-ins as it isn't really a filter, > doesn't render anything into a new image, nor does is save or load > images. Hmm. I dont think the ImageMap plugin fits a definition that limited. I would not let it stop you from making you add on as a GIMP plugin > The "Ken Burns" plug-in would need to associate more data with the > path. The path nodes would correspond to keyframes between which the > tool would interpolate zooms and camera movements. Each keyframe > would have an associated time values and "virtual camera" orientation > and size vector. (To be able to zoom or rotate without moving the > virtual camera, path nodes might have several associated keyframes.) > > The plug-in would provide a GUI to define the keyframes and their > attributes, and a preview window, but not do the actual rendering of > the animation to AVI, MPEG or whatever format itself, just output a > "recipe" that would then be used by a separate batch-oriented program > to actually render the animation. It should also be possible to load > such a saved recipe and continue working on it, of course. > Should there be some way for plug-ins to register interest in getting > callbacks when paths nodes are moved/added/deleted, etc? Other i think that would be useful. i was thinking about a tool i saw in anther program which allows you to place an image beside another by creating a large canvas and when you place the second image it automatically crops away any unneeded background probably a better example would be the Guillotine tool, which currently requires you to have already placed Guides on your image. with callbacks, if no guides existed you could put the cursor over the image with a Guide ready to be placed and then slice when the user places the image. > plug-ins for new kinds of functionality might similarily be interested > in getting callbacks when selections are modified, etc. Is there > currently any way for plug-ins to get asynchronous callbacks for > events like these? - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Scale Constrained
I wrote a small but useful script that will scale an image to best fit within a constrained size without affecting aspect ratio. It's a simple script, but I've found it quite useful as a component for other scripts, and thought it might be useful in GIMP at large. It's scheme right now, but I could code it in C if you would like: http://www.eskimo.com/~johnnyb/computers/multimedia/ Also on that page is a templated images script, which is really, REALLY basic at the moment, but basically allows you to easily create image-based templates (think Print Shop). Anyway, eventually I'm going to make this into something which has the ability to intelligently search for pictures to plug in, a better UI, and a UI for creating templates. However, if someone else was interested it might go a bit faster :) I thought this would be useful enough that some of the developer community might want to be involved, so I posted here. Anyway, let me know. Jon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
On Wed, 3 Sep 2003, Joao S. O. Bueno wrote: > Let's check your ideias. > One thing, from reafdign your e-mail I guess you are using 1.2 GIMP > series. A lot of what you comment has changed to the 1.3 series. To be fair from his screenshot he is clearly using some version of 1.3 http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png Sincerely Alan Horkan http://matrix.netsoc.tcd.ie/~horkana/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
> I already explained most of my suggestions to Joao. > I did another design, available at > http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png that's REALLY nice looking, and I like it, not that my opinion counts for much :) Jon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > In the GIMP, while it is not possible to make such a ssue to the right > mouse button, there could, and IMO should, be a fast keystroke > (mnemonic?) to swap BG and FG. It is great for a couple of fancy > effects to be able to quicly switch between fg/bg without moving the > cursor. Swapping FG/BG is per default bound to X (has been in 1.2 already). This is indeed an essential keybinding. > Youa re late on this. It´s possible for one to dinamically assing hot > keys to anything on the GIMP menus. Just go for it...hover the cursor > over your menu option, and press the hotkey you wnat there. > This, IMO is what make the GIMP more dinamically than Photshop and > clones band, as I mentioned above. I am sorry but I don't think you cannot assign keybindings to the layer or paint mode menus. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
On Wed, 2003-09-03 at 07:49, Joao S. O. Bueno wrote: > In the GIMP, while it is not possible to make such a ssue to the right > mouse button, there could, and IMO should, be a fast keystroke > (mnemonic?) to swap BG and FG. It is great for a couple of fancy > effects to be able to quicly switch between fg/bg without moving the > cursor. For a long time this has been bound to the 'X' key. Can't live without it. Also 'D' for resetting the colors to default is handy. cheers -- Jakub Steiner <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] Gimp interface streamlining
On Wed, 2003-09-03 at 07:49, Joao S. O. Bueno wrote: > Hi there, > > Well, A lot of things for a first post. > > Allow me to go for a first triage of your suggestions, so that the > men-in-the-power-to-do-it can focus their attention. > > First, allow e to present myself: I've joinned here about two to three > months ago, and so far an better in talking and suggesting than > contributing with the code or docs. > > But I could grasp, I think, a feeling of where the gimp is going,a nd > what people making it are after. > > Now, onto your suggestions: > > On Monday 01 September 2003 3:09 pm, Willie Sippel wrote: > > Hi there. > > > > First post, so please go easy on me ;-). > > Only reading througgh the end will tell Iif I managed to go easy. > > > > Also Gimp always gets better and more powerful, the interface still > > needs a lot of work. It almost looks like yet another Photoshop > > clone - and even if Photoshop is some sort of de facto standard, > > it's interface is pretty clumsy and inefficient. > > Funny...more oftenly people will come in and complain that it is _not_ > like photoshop. I however think that the GIMP is far less clumsy than > Photoshop/corel photopaint/Paint Shop Pro/Windows Paint and > friends,and OTOH no were near what Deluxe Paint has been in it's time > for free hand drawing. Might be more or less true, but this depends on what programs you compare Gimp to. I mostly used more professional applications like Aura, Quantel Paintbox and 5D Cyborg, and these applications are really workflow - optimised. If you compare Gimp to these tools, Gimp behaves much more like Photoshop... ;-) > > > So I thought about some interface improvements for Gimp, to make it > > look more distinguished, remove much of the clutter and unnecessary > > redundancy and improve the workflow: > > Let's check your ideias. > One thing, from reafdign your e-mail I guess you are using 1.2 GIMP > series. A lot of what you comment has changed to the 1.3 series. > Nope, 1.3.19. > > > > Gimp interface improvements: > > > > > > 1.) Remove unnecessary buttons from the main toolbox to reduce > > clutter: Smudge, Dodge or Burn, Blur or Sharpen, Erase, Zoom, Color > > Picker; > > Bad news in the "remove buttons" part. In the 1.3 series, actually, > more things have been added there, and his will not change. > > If you manage to make you point quite well, be aware that I simpathise > with the idea..and possibly...just possibly...gimp 2.2, or 3.0 can > have a completely customizable tool box. > Well, Dodge and Burn are already pretty redundant and therefore useless clutter, since these tools are also modes for the paint tools. They are much more flexible and usable as modes, 'cause you can airbrush the Burn - effect - it would be even more flexible and intuitive to do the same for Blur, Sharpen and Smudge, and remove the corresponding toolbox buttons. > > > > 2.) Remove buttons from the main menu and add the corresponding > > functions to a mode selector in the Tool Options: > > ok. Deluxe Paint would make this subselection by displaying a submenu > if the button on the main tooll palette would remain pressed for a > while. IMHO,, that would be better than a selection on the tool > options.. > It could be event better to split the toolbox in two segments, the upper segment contains the groups, the lower segment the corresponding tools. BTW, also I like DPaint, it should be our goal to improve, not mimic some other program... > > >(...) > > (*) This tool would be a great addition, and could even replace > > most other transform tools. > > 'Corner pin' is a standard tool in compositing software, it uses > > the current layer as a plane with four freely movable corners, and > > skews, rotates and scales the layer according to those corners. > > IMO, the perspective transformation does just that. Check t see if it > equivalent, and if it is not, just explain what is missing or > behaving differently. > You're right, sorry - must have missed this one. As I say, to much buttons... ;-) Would a realtime preview be doable - with a lower proxy, if necessary? > > 4.) The old eraser should be replaced with an 'Erase' - mode for > > the paint tools (Brush, Pen, Airbrush, Ink, Text, Fill), to be able > > to use e.g. the Airbrush as Eraser, this would make the interface > > less cluttered and also improves the flexibility. Same goes for the > > 'Smudge', 'Blur', 'Paint using Patterns' 'Sharpen' tools; > > Ok, here is how Deluxe Paint would deal with this: > painting with right mouse button instead of the left would use the > Background color, instead of foreground. > In the GIMP, while it is not possible to make such a ssue to the right > mouse button, there could, and IMO should, be a fast keystroke > (mnemonic?) to swap BG and FG. It is great for a couple of fancy > effects to be able to quicly switch between fg/bg without moving the > cursor. > That'
Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?
On Wed, 2003-09-03 at 23:54, Tor Lillqvist wrote: > I have recently toyed with the thought of writing a tool to produce > (low (TV) resolution) animations (for writing to VCD or DVD, mainly) > from (high resolution) still images. I.e. if you have some > multi-megapixel image, with the tool you could produce animations > where you zoom in/out, pan the over some straight or curved path, > rotate the viewport, etc. Seems like a nice way to put a bit more > "life" into your digital image slideshows. I have sucessfully done this with an existing GIMP plugin - GAP's move path. At PAL resolution. The only problem is it needs a lot of disk space and RAM. cheers -- Jakub Steiner <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
[Gimp-developer] Quickly Changing bg/fg colors
> In the GIMP, while it is not possible to make such a ssue to the right=20 > mouse button, there could, and IMO should, be a fast keystroke=20 > (mnemonic?) to swap BG and FG. It is great for a couple of fancy=20 > effects to be able to quicly switch between fg/bg without moving the=20 > cursor. You mean like the hotkey 'x'? (its in the menu /Tools/Swap colors if you want to change it to something else). Or were you wanting yet-another-modifier (control, shift, alt are already taken)? > As for the eraser tool, it is currently the only of the paint tools=20 > that paints to transparency without the need to paint on the mask.=20 Not quite - the ColorErase mode of paintbrush/airbrush/pencil/clone/ink/bucket tools will also remove alpha, though in a more selective way. > > 13.) Remove the pressure mapping options from the tool settings and > > add it to the 'Tool state' window, to remove unnecessary options > > for users without a tablet; > Better would be to think of a way of USING the pressure settings for=20 > those who do not have a tablet. Maybe the experience could be made=20 > with the mouse wheel, for instance, or a gauge dinamically controled=20 > by pressing left and right arrows while painting. I do not think that=20 > any of the tool settings is clutterd, even in 1.3 where most of them=20 > get a vertical scroll bar. I agree here that they just take up space for someone without a tablet. I don't have a device that would allow such control (anything you can come up with a mouse or keyboard is a mostly unsable hack) and I don't foresee attaching one to my computer in the near future. > > 14.) Add a pressure curve to the tool settings, to edit the > > pressure and suppress values on the fly; > Maybe you could elaborate on that. What exactly would t be? A visible=20 > calibration curve for the pressure? I think what is described is a work-around for those that don't have a pressure device - something a of 'pressure gradient' that can be applied to the stroke. Other than size and hardness, its mostly covered with the 'use color from gradient' (which should probably be renamed, since it uses Opacity too). Happy GIMPing, Seth __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface streamlining
Hi, I would appreciate if you could try to keep this discussion going on both lists. Cross-posting may mean that a few people get the posts twice but since this topic is of interest to both lists, cross-posting seems appropriate. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Making the color picker tool grab the alpha value
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > As I stated on the answer to Willie Sippel, > I liked the idea of the color picker tool to pick de alpha value of a > pixel. More specificaaly when c temporarily called using "control" > while one is using another paint tool. > The alpha value of the pixel or region picked would them set the > "opaccity" of the tool one is using in the moment. > > I even suggested this as an enhancemnet at bugzilla (bug 121331). > However, people need to like the idea for it to be done. > > So, what do you think? Should the color picker pick the alpha and set > the opacity of the current paint tool, or not? I doubt that this would be useful in general. Actually I can only imagine workflows where I would not want the color-picker to affect the tool opacity. When doing retouching you usually set the brush opacity to some lower value in order to carefully apply some color where needed. While doing this you frequently pick colors from other places in the image. In most cases these places are opaque but you definitely don't want the brush opacity to change to 100%. You want to pick up the color, not the alpha value. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-1.3.19 ./configure failure oddity
Hi, Sven Neumann <[EMAIL PROTECTED]> writes: > Jeff Trefftzs <[EMAIL PROTECTED]> writes: > > An additional effect that I have noticed only with the gimp, is that > > make crashes repeatedly during the compile. I was wondering if this > > meant I was running out of temp disk, but I still have close to 2G left > > on the root filesystem, so that isn't it; I have tried compiling with > > and without /usr/local/lib in the ld.so.conf file and both compiles > > crash (segfault) after compiling for a long time. Note that if I simply > > reissue the make command the compile picks up where it left off, and > > eventually I get a brand new gimp. > > > > Has anybody seen problems like these, and can you suggest any possible > > causes or other places to look? It's not a show-stopper, but it > > certainly has been leaving me baffled. > This sounds very much like a hardware problem. Unsufficient cooling or > corrupted memory could be the cause. It's not too unlikely that such > problems only show up when compiling a large software package such as > The GIMP. You could do some tests compiling other software such as the > kernel or XFree86. It's a long-shot, but I had exactly this problem when I was using libsafe. Disabling it for the configure and compile fixed it. Keith ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
