Re: [Gimp-developer] tiff save dialog cosmetic fix
Speaking of tiff files, is there any particular reason why the tiff plug-in doesn't support saving multiple layers as tiff pages, or is it just that noone has got around to implementing it? Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Image scrolling
Hi Glenn, This answer has nothing to do with gimp, but as the author of the GtkImageViewer widget who has dealt with a similar problem - the display of 600MB pbm images - I thought I would tell you about my solution. The solution only works for uncompressed images. I did not load the whole image into memory at all, but used the view_changed signal callback of the GtkImageViewer for fetching a rectangle of data from the disk which is then immediately displayed. Zoomed out data was created on the fly as well by reading from the disk and downscaling in one go. Even smooth scrolling worked surprisingly fast. There is a small delay as the disk is accessed, but it is a lot less annoying then the swapping and paging that will take place if you try to read the whole image at once into memory. Hope this helps. If you want to hear more about this solution, perhaps we should move the discussion to gtk-app or privately, as it has nothing to do with gimp. Regards, Dov ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patterns -- things we could do to make their manufacture much easier
Don't forget the fantastic resynthesizer plug-in as part of the tool chain for creating tilable plug-ins. It is certainly usually much better than any alpha-blending. See: http://www.logarithmic.net/pfh/resynthesizer Regards, Dov On 12/29/05, Leon Brooks <[EMAIL PROTECTED]> wrote: > On Thursday 29 December 2005 07:20, Carol Spears wrote: > > the one other thing that would make them useful as patterns is if > > they can be made tileable. there is at least one plug-in that > > does this. > > OK... having a stab at doing this "manually" for one herringbone pattern > of brick pavers now, and it ain't as easy as it looks. (-: > > This would be a really handy thing to have a dedicated tool (or at least > plugin) to do. The following comments apply to real-world objects being > converted to patterns; they may not apply to computer-generated > patterns. > > Each potential tiled texture will probably need some fisheye correction, > which Dave Hodson's "Telephoto" plugin does reasonably well -- thanks, > Joao, for reminding me that the plugin existed. This is made a little > easier by lining image features up against guides, but it's still very > much trial-and-error. Being able to do it on the main image in real-ish > time would help a lot. > > Many of them will also require "keystone" correction to make them square > (or at least symmetrical across the X and Y axes). Those which require > both would be a lot easier to deal with if both this and the fisheye > correction could be done interactively, realtime(ish) and full-scale on > a single set of sliders. > > Next, we need to isolate (crop to) a section of the subject which is > suitable for one of the algorithms below. Interactivity would help this > a lot as well, see discussion for each. > > Having made the subject basically rectangular, the next step is to make > it repeatable. There are two techniques that I've looked at so far. > > One consists of replicating the original rectangle in each direction, > flipping the image over its edge to achieve an image twice as large in > each direction but which matches exactly along the edges. > > This does not work well for asymmetrical subjects, such as those > containing text or lit predominantly from one side. > > Being able to tweak the corrections and cropping on the fly and have it > displayed as an "endless" pattern would make achieving near-perfect > results considerably easier. > > Storing a single copy of the basic pattern rather than a fourfold-larger > copy woulod be good, but would require the addition of a different > tiling mode rather than simple repetition, call it "flip-tiling" if it > doesn't already have a name. > > The other method consists of overlapping the original image with itself > and alpha-blending the edges of each copy to smooth over differences > between each edge of the image. This does not work very well if the > subject is not consistent from edge to edge, but does handle > asymmetries such as sunlight coming from one side reasonably well. > > There is already a plugin to do something like this, but it is *very* > clumsy and only works acceptably with very complicated, fine-grained > subjects, or with very near-featureless subjects. Even then, there is > rectangular meta-pattern visible at larger scales because of the > unsubtle blending at the edges of the image. > > Real-time interactivity would greatly help this mode as well. > > It would also benefit from being able to do "gradiented" corrections of > at least brightness across the subject, possibly automatically or > semi-automatically by selecting tiles along each edge and adjusting the > intensity gradient so that they are equal, then another pass to smooth > the gradient. > > Another pair of useful features would be the ability to draw the > alpha-blending border on each edge of the image freehand and/or with > beziers, and to adjust the slope (or possibly even curve) of the > blending. This would allow the operator to better duck around > anomalies. > > A final useful feature would be the ability to arbitrarily deform areas > of the subject, PowerGoo(tm)-style, in order to better match up the > edges of random/chaotic patterns like waves or gravel. > > Cheers; Leon > > -- > http://cyberknights.com.au/ Modern tools; traditional dedication > http://plug.linux.org.au/ Member, Perth Linux User Group > http://slpwa.asn.au/Member, Linux Professionals WA > http://osia.net.au/ Member, Open Source Industry Australia > http://linux.org.au/Member, Linux Australia > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Idea for data flow in gimp and or plug-ins
Hello, When reading about the ideas for the SoC, I was reminded of an idea I got when looking at a collegue showing me the L*bVi*w code development environment. By interactively dragging out various blocks with a different set of inputs and outputs and connecting these with connectors he basically created a "dataflow". In LV these are usually used for reading input from various HW sensors and displaying them in dials etc. As I was thinking about other uses for the same idea, I thought of two uses in Gimp. Either as what was mentioned on this list as "effect layers" or as an alternative way of creating scripts. The layer paridigm seems to be quite limited since it is effectively one-dimensional. I believe that creating a canvas containing effect boxes and connecting wires through which images and parameters would flow, would be an easier interface to comprehend. Sorry for these somewhat disconnected thoughts. Should I write it up more organized in bugzilla? Regards, Dov ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: [Gimp-user] Opening Photoshop Files
On Fri, Feb 08, 2002 at 12:41:42PM +0100, Sven Neumann wrote: > > yes, it will use Freetype2 but somewhat hidden behind a Pango layer. > The advantage of using Pango on top of Freetype2 is that it takes care > of all the ugly details of glyph positioning and shaping. And you get all the beautiful rendering of lots of exotic scripts! Imagine, now you will be able to render your APL programs in Gimp with comments in Chinese and Runes intermixed. 8-) This is really the way to go! Keep it up. Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Hebrew with vowel positioning has also been ported by me to ft2. See http://imagic.weizmann.ac.il/~dov/Hebrew/pango-hebrew.html http://imagic.weizmann.ac.il/~dov/freesw/paps for some screen shots and utilities. Regards, Dov On Sun, Feb 10, 2002 at 07:22:09PM +0100, Sven Neumann wrote: > Hi, > > Dov Grobgeld <[EMAIL PROTECTED]> writes: > > > > yes, it will use Freetype2 but somewhat hidden behind a Pango layer. > > > The advantage of using Pango on top of Freetype2 is that it takes care > > > of all the ugly details of glyph positioning and shaping. > > > > And you get all the beautiful rendering of lots of exotic scripts! > > Imagine, now you will be able to render your APL programs in Gimp > > with comments in Chinese and Runes intermixed. 8-) > > > > This is really the way to go! Keep it up. > > uhm, yes, that's the plan. The reality is however that PangoFT2 at the > moment has the basic shaper which works well for lots of scripts but > not so well for the more exotic ones. Then there's an arabic shaper > that's been added in the latest release and that's it. If we want all > the exotic scripts to render correctly, someone needs to port more > PangoXft shaper modules to PangoFT2. Fortunately the porting is pretty > straightforward. > > > Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Updated scheme and perl tutorials
I have just updated my Scheme and Perl tutorials for gimp scripting. The updated tutorials may be found at: http://imagic.weizmann.ac.il/~dov/gimp/perl-tut.html http://imagic.weizmann.ac.il/~dov/gimp/scheme-tut.html Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Preview widget for plugins
Though I am not very familiar with the current preview widget, it seems to me that my GtkImageViewer widget would be well suited for this task. Please have a look at: http://imagic.weizmann.ac.il/~dov/freesw/gtk/gtk-image-viewer/ Regards, Dov On Fri, Apr 05, 2002 at 08:40:39PM +0200, Maurits Rijk wrote: > Ok, this has been discussed numerous times and seems to be quite high on > the wishlist but it still doesn't really exist: a preview widget that > can be used in all (or probably most) plug-ins. > > So I've taken up this challenge and started coding, heavily based on > some work that has already been done in this area. However my approach > is slightly different: instead of coding a perfect preview widget from > the start I opted for the evolutionary approach: > > Step 1) first create a quick and dirty preview widget that really > consists of code factored out from several plugins. This code relies on > the deprecated GtkPreview widget. Main advantage of having this step is > that it doesn't involve a lot of rewriting of the existing plugin code. > This step has been succesful: I have changed the code from the max_rgb > and the plasma plugin so they now both use my new preview widget. > > Step 2) update all plugins that already have a preview. Some of them > will be easy, others might involve more rewriting or adding > functionality to the preview widget. > > Step 3) once all plugins use the same preview widget it's time to > replace the deprecated GtkPreview by another widget (GtkImage or > GtkDrawingArea). In this step the API should be well established and be > able to handle all preview needs. > > Step 4) update plugins that don't have a preview yet. > > So what's the current status? Well, I've finished step 1 and it seems to > work :) Step 2 will take quite a bit more time, but will greatly clean > up and reduce the current plugin code for all those plugins that use a > preview. I expect this to take about 2 or 3 months. Step 3 will be > relatively easy. Few evenings of hacking should be enough to do this. > And finally, step 4, will be comparable with step 2: about 2 or 3 > months. > > To sum up: before the end of the year all plugins for which this is > appropriate will have a preview, using a common preview widget. I just > hope Gimp 1.4 isn't already released before that time :) > > Any thoughts? > > Maurits > > ___ > 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] MNG support. Was: Intolerance, and development.
David, Instead of spending all this time writing your views of the world, I am sure that all on this list including you would actually think the time would be better spend actually implementing mng support for gimp. I suggest that you go about it in the following steps: 1. Extract the png plug-in file and rename in mng. 2. Change it so that it registers the .mng extension. 3. Make sure that it compiles and that it is may be used to read png files that have been renamed ".mng". 4. Get and compile the libmng library from http://www.libmng.com/ . 5. Get some mng example files. 6. Study the libmng example programs and try to implement the same scenario for getting the data into the mng plugin. At first, decide about some minimal subset of mng that you will support, e.g. one-layer that are not JNG. (This is essentially the same thing as png). 7. After succeeding in reading one-layer non-jng mng images, add support for multi-layer and mng. 8. Release and get the well deserved glory. 9. Add mng write support. 10. Release again and get more glory. 8-) Btw, is there tutorial available for image loader and writer plug-ins? Regards, Dov On Thu, Nov 28, 2002 at 08:50:51PM -0500, David Weeks wrote: > Jeez, > > Guys, perhaps it was wrong for me to do the French/American thing, but I was > drawing on historical examples. All the same, I'd not respect anyone who > didn't respect their own country. I LOVE America, as an American, and I have > MAJOR problems with much of America, just the same. > > Tolerance isn't the lack of criticism, and intolerance isn't the act of > criticism, and beyond that, some things are tolerable, and some things are > not. So let's drop the "troll" "intolerant" "ignorant" crap and deal with > information. These reactions are human nature, and responsible for the > strife in the world; just look at this list. > > Free discusion of ideas means it's all good, even the bad and the ugly, cause > that bad and ugly might be the fact that we're wrong, and someone was rude in > pointing it out. > > My problem of recent days started with a reply to a requested feature: mng > support. The response I got was that I had a lot of nerve asking someone > else to slave for me. I got that from the same who's never even HEARD of > regular expressions, and is now an active partner in the development of gimp? > Red flag folks. I also see a split between Film Gimp and gimp. More flags > of red. And there the fact that very POWERFUL people don't like us. We > don't serve them, we undermind their economic rents. > > So here's the challenge: who thinks that not knowing what regular expressions > are, or thinking that a feature request is wrong, is an indication of knowing > what you're doing as an open source developer in the GNU/Linux community? > > While this on going discussion is not a specific, tactical Q&A on code, it is > a specific discussion of what it is to work on that code, and the expectation > of that code's consumers: the GNU/Linux/Open Source community, and end-users > the world over. I'm "chop chewing" because of what I've found in this > CRITICAL application's development forum. > > Teachers correct, some learn, some cheat, others blame. Fact is, none of us > matter -- except for the users of gimp. If we care about them, then we're > not so different after all. > > David Weeks > > PS -- my deference to the French, and to Microsoft. America would be English, > were it not for aid of France, and computers would be Apple, Unix or IBM, > were it not for the aid of Microsoft. Ask those of us who were there, when a > "pop" of Unix ran $2500 a seat, and Microsoft could be had for $100. I'm > glad Richard Stallman, Linus Torvaldes(sp?), Vinton Cerf and company, and the > internet community furthered the perfection of software technology. The > strongest contribution being Freedom. > -- > You can call me at: 813-236-2009, USA > [EMAIL PROTECTED] > Shop TampaPC.com! > ___ > 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
[Gimp-developer] Re: Preview widget name
While we are at it. The two characters "Fu" to represent "A uniform
interface that allows setting parameters for the execution of a sequence
of gimp functions where each type of parameter has a fixed GUI mapping"
is much weirder, imho. And that is exposed to the user, which Prevue
would not be...
Regards,
Dov
On Wed, Apr 02, 2003 at 05:48:44PM -0600, Brian Mullin wrote:
> I do see those sorts of spellings from time to time, yes. The same thing
> with "prevu".
>
> But, to answer your question... Yes, "GimpPrevue" does look kind of
> weird. It does to me, at any rate. :)
>
> Brian Mullin
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Ernst Lippe
> Sent: Wednesday, April 02, 2003 5:24 PM
> To: Gimp-developer
> Subject: Preview widget name
>
>
> My Webster's lists prevue as a synonym for preview (to me this appears
> to be the original French root of the word).
>
> Does GimpPrevue sound very weird for native English speakers?
>
> greetings,
>
> Ernst Lippe
> ___
> 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
--
___ ___
/ o \ o \
Dov Grobgeld ( o o ) o |
The Weizmann Institute of Science, Israel \ o /o o /
"Where the tree of wisdom carries oranges" | | | |
_| |_ _| |_
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: red-eye-removal (was: Debugging?)
I just had a look at the two plug-ins for fun of it and they doing part of the problem differently, which means that the perl program looks more complicated than necessarry. The scheme plugin uses the plug-in plug-in-colors-channel-mixer to do the actual color mixing, whereas the perl plug-in accesses the pixels itself. Accessing pixels always gets dirty, because of the tile based approach of gimp. Actually, I think that Marc Lehmann's use of PDL for the job is very elegant. But I'm sure that it can be confusing to have to learn another huge sublanguage (which PDL is). So if you want to compare syntax, please compare the same approach in the different languages. I'm curious, does the python plug-in allow you to access the pixels? Regards, Dov On Mon, Jun 16, 2003 at 02:04:52AM -0400, Carol Spears wrote: > On 2003-06-15 at 2031.16 -0700, Jeff Trefftzs typed this: > > > > Debugging: you might try firing up the script-fu console in the GIMP > > and testing code snippets there. I've found this to work fairly well. > > My main problem is getting my head back into lisp space ... > > > Eeek! > > Jeff, just say no! > > all three versions of gimp i have used, 1.0 1.2 and 1.3 have a nifty > python plug-in complete with browser and console as well. > > today i read two plug-ins for red-eye removal. the script-fu just > looked like gibberish: > http://cs.uhh.hawaii.edu/~jeschke/photography/articles/gimp/RedEye2/red-eye.scm > > this one. this was the saddest thing i ever read. i never want to read > something this sad again. please. it is not the authors fault. it is > not the fault of the person who ported gimp to it. nor the gtk guy that > did it. not the original authors of this scripting language either. i > don't know why it is so sad. you have to stop making me try to read this. > mercy! > http://fmg-www.cs.ucla.edu/fmg-members/geoff/digicam/redeye > > i would like to read it written in python. it is direct and the modular > part is starting to make sense to me. it makes me angry (okay > frustrated) not sad. that is better. please someone write this in > python quick so we can compare before i forget! > > carol > > -- > The sooner you fall behind, the more time you have to catch up. > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- ___ ___ / o \ o \ Dov Grobgeld ( o o ) o | The Weizmann Institute of Science, Israel \ o /o o / "Where the tree of wisdom carries oranges" | | | | _| |_ _| |_ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] there is hope for gimp-perl-1.3 (was:red-eye-removal)
On Mon, Jun 16, 2003 at 09:57:48PM +0200, Marc A. Lehmann wrote: > > > > http://fmg-www.cs.ucla.edu/fmg-members/geoff/digicam/redeye > > Woaw, a PDL plug-in not written by me! Oh my god, I can't believe it > happened ;) Yep, though the author missed the whole point of PDL by looping over x and y. Instead of the loop the following code would have done the same thing much faster. $rbrite = $data(0,:,:)* 0.513; $gbrite = $data(1,:,:); $bbrite = $data(2,:,:)*0.19; $r = (($gbrite+$bbrite)/2/0.51)->clip(0,255)->byte; $mask = ($rbrite >= $gbrite - $threshold) & ($rbrite>=$bbrite - $threshold); $data(0,:,:) .= $mask * $r + (1-$mask)*$data(0,:,:); using the NiceSlice syntax. But it really doesn't make it any more legible... (It doesn't even look like perl...) (Btw, I wonder if you couldn't use the PDL implicit threading model to loop over the tiles implicitely... Now I'm getting carried away.) > On Mon, Jun 16, 2003 at 09:54:42AM -0400, Carol Spears <[EMAIL PROTECTED]> wrote: > > perl ported to gimp-1.3 and the plug-ins as well. > > One thing of interest is that I am currently working my way through the > Gtk2 module(s) available for perl. Apart from some things I'd really like > to have changed and settled to make use of it, this was the major obstacle > to a gimp-perl-1.3. Actually, I ported all the non-gui stuff already, which was really quite straight forward. I then started looking at perl-gtk-xs. What got me stuck is the fact that you created the various widgets by inheritance and perl-gtk-xs still doesn't support inheriting gtk widgets on the perl level. I'd be happy to send you the stuff that I have, but I really don't think that you need it. > Ok, that was a lie, the major obstacle was my lack of time, but now I > don't have any other good excuses anymore. It might still take months, but > at least I'd like to let you know that I am working on gimp-perl again, > even if it's only "getting used to the Gtk2 internals". > > (Gtk2 looks quite good already, btw..) It sure does. :-) Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions + Patch, Redo - Part 1
On Sat, Jun 28, 2003 at 12:20:26PM +0200, Jakub Steiner wrote: > On Sat, 2003-06-28 at 01:13, [EMAIL PROTECTED] wrote: > > > Then this looks like a serious issue, since this feature is probably not > > used often by advanced users, but often by beginners, while the dynamic > > shortcuts are used as quick-assign-keys by advanced users. > > The feature will be quite often used by very advanced users who run out > available shortcuts and will start using mnemomics for common functions > (there can be a lot more mnemonics than shortcuts - they are > multi-dimensional; gaussian blur could be accessed with a sequence > alt+f,b,g for example). Wouldn't it be nice if you could do: -x ^h to popup a window of available combinations. Or -x gauss-blur and of course -x -p to rerun the last plug-in. Beginner users would probably not use these combinations, but for power users emacs is the sky. ;-) Regards, Dov > [rest of email deleted] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Dicom plug-in for gimp
Hello, I have written a Dicom format plug-in for gimp. Dicom is a standard for medical apparatus and includes an image format which this plug-in partially supports for reading and writing. Here are some links about Dicom: http://medical.nema.org/ http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html I have attached the source for it to bug report #126521 . Sven wanted to have a discussion whether this plug-in should be included by default in gimp. So, the question is, do you want to improve your X-Ray images (and in the process change your name to Wilber Doe, which is the value for the "Patient name" tag of all dicom files written by the plug-in) ;-)? Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dicom plug-in for gimp
Perhaps we need a browser function for accessing a remote site with installable plug-ins, just like the "extensions" and plug-ins available in MozillaFirebird. It might also be coupled with an "update" function that retrieves the latest version of all installed plug-ins. Regards, Dov On Mon, Nov 10, 2003 at 03:39:32AM +0100, Marc A. Lehmann wrote: > On Sun, Nov 09, 2003 at 11:34:48PM +0200, Dov Grobgeld <[EMAIL PROTECTED]> wrote: > > Sven wanted to have a discussion whether this plug-in should be included > > If discussion means "wants to see some opinions", then here we go :) > > - No, it should not be included, in general. > - As long as there is no good repository for plug-ins (and my opinion is > that there isn't), it (and any other plug-ins that can be maintained > at reasonable cost(!)) should be included, as that's the best way to > ensure total user satisfaction. > > In other words: Right now, yes, but in the long run it should be a > seperately installable module, just as python or perl come with some > common modules/extensions, but not all of them. > > -- > -==- | > ==-- _ | > ---==---(_)__ __ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > | > ___ > 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] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
You will first need to install Gtk2 and all its prerequisites. ExtUtils::Depends is one of these. See the gtk2-perl home page. Regards, Dov On Sun, Mar 28, 2004 at 08:57:31AM +1000, Owen wrote: > On Sat, 27 Mar 2004 23:47:22 +0200 > [EMAIL PROTECTED] wrote: > > > I have just tested this release and updated my tutorial so that > > it works with it. You may see the result at: > > http://imagic.weizmann.ac.il/~dov/gimp/perl-tut-2.0/ . > > I downloaded from ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.0/perl/ > > but it wouldn't configure/make > > ERROR from evaluation of /home/owen/Gimp-2.0pre1/UI/Makefile.PL: Can't locate object > method "add_define" via package "ExtUtils::Depends" at ./Makefile.PL line 42 > > > In fact a grep of all modules could not locate add_define so I was wondering if that > routine has been replaced with something else? > > -- > Owen > > ___ > 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] GPU-accelerated Image Filtering w/ CUDA
Alan, You're code certainly sounds very useful, and I would love to see it open sourced. May I suggest, as was already stated, that you decide upon a license, find a name for your library, and then open a github ( http://github.com) account (or any other free hosting) where you upload the code. Whether it will be made part of gimp or not is a different issue, and I agree that you should introducing closed source dependencies for such a project is not a good idea. Btw, there is an open standard for CUDA-like operations being developed, called OpenCL, but it is not very supported yet. See: http://en.wikipedia.org/wiki/OpenCL . Pehaps you want to investigate whether there is NVIDIA support for the operations that you use, and if so, recode the algorithms in OpenCL? But again, I would do the work in a separate repository in github. Regards, Dov On Mon, Aug 30, 2010 at 01:46, Øyvind Kolås wrote: > On Sun, Aug 29, 2010 at 11:40 PM, Alan Reiner wrote: > > I forgot that CUDA is not OSS. We don't have to worry about that because > we > > only use it for in-house simulations. I only remembered it was free for > > such use. > > > > I know that similar stuff can be done with OpenGL, but that's a > completely > > different beast. There's also OpenCL but I don't know anything about > that > > either. At least those two solutions should work on both NVIDIA and > ATI, > > but I believe the code still needs to be tailored specifically for each > > architecture. > > > > As for portability, I don't see that as a concern for any of these. For > > various platforms, it would be preprocessed out. For everything else it > can > > detect and disable itself if it won't work on the resident card. > > > > I might look a little bit into the OpenGL solution to see if that's > > feasible, but my understanding is that it's more archaic and not as > > powerful. And I personally don't have a reason to learn it. Perhaps one > > day when I have time to contribute directly to an OSS project. > > Doing image processing on the GPU using OpenGL and GLSL for GIMPs next > generation engine is planned and the initial proof of concept of such > a system deeply integrated with GEGL exist in a branch of the git > repository at http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu , > The approach taken there is to implement automatic migration of tiles > between cpu and gpu. > > /Øyvind K. > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp double cursor
Here is another solution to the problem, which may or may not be similar to the method used in clone. The code certainly needs more documentation, but I hope you can figure out how to use it from the test-dovtk-lasso.c example. http://github.com/dov/dovtk-lasso Regards, Dov On Thu, Oct 28, 2010 at 12:28, Alexia Death wrote: > On Thu, Oct 28, 2010 at 12:56 PM, Levente Kovacs > wrote: > > Hi All, > > > > // sorry if this is not the right place to ask > > > > I'm in the process of customizing paint tools in Gimp for a specific > > application (more on that later), and I've hit a wall which I can't > > seem to be able to figure out. I'd appreciate any pointers. What I'd > > need at some point to be able to display a second (virtual) cursor, > > similar to how it is in the clone tool during the process of cloning > > itself, > > Here's your answer. Read the clone tool code. Specially the bits where > draw tool is used. > > > > -- > --Alexia > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
