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 pip...@gimp.org wrote: On Sun, Aug 29, 2010 at 11:40 PM, Alan Reiner etothe...@gmail.com 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
[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
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] 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] 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
[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] 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: Meta-x ^h to popup a window of available combinations. Or Meta-x gausstab-blurenter and of course Meta-x Meta-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] 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
[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: [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
