Re: [Gimp-developer] MMX in 1.3 tree
This isn't quite ready to go yet. But thanks for the note. The default build behaviour right now is to not build the new code. Helvetix On Thu, Jul 10, 2003 at 08:36:44AM +0200, David Neary wrote: Hi, The new MMX composite code in the 1.3 tree doesn't build for me - am I the only one? My processor is a 350MHz K6-2 with mmx support, and the error says that there are a bunch (6, I think) of unknown registers in the asm (%mm0, %mm1, ...). I'm mailing this to the list because, to be quite honest, I'm not sure how many people actually look at bugzilla these days apart from Sven and Raphael. But that's another issue... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ 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] what is up to day
This is the best idea so far. Helvetix On Fri, Jun 20, 2003 at 01:47:14AM -0700, Joel Eduardo Rodriguez Ramirez wrote: dont whant to bother,..but how about an totally alphabetic release,..like picasso, vinci il mondo, maya art, gliphic insight?,,,ha,..galactic green,.. ...the number? regards Joel ___ 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: Status of MMX code in The GIMP
Last Februrary, I volunteered to help with the GIMP MMX implemetation that had been languishing and had recently started to cause problems when building the current GIMP code. This (http://oak.mysterious.org/~helvetix/practicum/gimp-composite.tgz) is release 0.0 of an extensible and customisable image compositing interface for the GIMP. This doesn't really provide any 'user visible' changes, other than the potential (and actual in this case) performance improvements. I'd like to hear feedback. What you get is this: * A general mechanism for incorporating compositing functions based upon the compositing function and the pixel formats of the inputs and the outputs of the function. * Generic implementations of the supported compositing functions as a foundation for further/future improvements. * The general mechanism allows any compositing function implementation to be replaced by a different implementation. This is particularly useful in that one can write specialised implementation of some, many, or all of the compositing functions. These specialised implementations can be written to take advantage of special CPU instructions, such as VIS, AltiVec, MMX, and so forth, and special hardware acceleration that might be available. Currently, I have an incipient set of functions implemented which use the MMX instruction set of the Pentium processor. Helvetix ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] makes it sense to add native CMYK support toGIMP?
This is more about philosophy than an actual answer to Stefan's question, but maybe there it can inspire some more thinking. This may be entirely my deficiency, but I am unclear on the general usefulness of having a native CMYK implementation. On one hand I understand that there is a perceived value of working with the four values, on the other hand I think we expose too much of the underlying guts of the colour implemetation and gamuts to the poor user already. Converting RGB to CMYK is algorithmic. Here's the generalised algorithm: c = (255 - r) * Cr m = (255 - g) * Cg y = (255 - b) * Cb k = max(c, m, y) * Cy Of course the interesting part about the algorithm are what to choose for the values of Cr, Cg, Cb, and Ck, and *unless* you have the data on the printer, the inks (lot numbers and even age), and paper, any values you arbitrarily choose would likely be wrong. A contribution here would be the development of a good colour abstraction interface. Let the user choose things like if the image is a COLOR image or a Black and White image (GRAY), with or without transparency. None of this business of values like 255 (white in 8bit rgb). Naturally there will be people who want access to the underlying knobs and switches, and that's okay. But we ought to at least put a cover over it. I think CMYK ought to be a Save As option (as appropriate). Helvetix On Sun, Jun 08, 2003 at 11:13:33AM +0200, Stefan Klein wrote: Hi all, I am a computer science student looking for a final year project. I'd love to do something in the Open Source community and I am looking around where my help might be needed. Having a little interest in graphics design and prepress, I came across GIMP and CMYK support. The little research I've done gives me the impression that over the last couple of years it's regularly been asked for and it might be an important feature to get GIMP into the pre-press world. What I'd like to know is the following: 1. Is anybody actually working on this? There were hints now and then that people are thinking about it, but I didn't find anything definite, apart from an entry Additional ColorModels on the GEGL todo list (http://developer.gimp.org/gegl-todo.html) that seems to point in that direction. 2. How important is this really? What I am talking about is native CMYK support, not just a conversion function. There was a thread on the developers-list in November 2001 (http://www.mail-archive.com/[EMAIL PROTECTED]/msg01350. html) that gives the impression that it might not be all that important and that there might be cheaper workarounds (converting when saving, spot color channels). How important is a CMYK mode for people working in prepress? 3. Any guesses on the effort to implement this? I'd appreciate it if you could answer asap, since I have to hand in my project proposals very shortly. Thanks Stefan Mit der Grupppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179 ___ 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] (gimp-image-add-layer)?
You need to say something like: (set! the-image-id (car (gimp-image-new 10 10 GRAY))) (set! the-layer-id (car (gimp-layer-new the-image-id 10 10 GRAYA_IMAGE a named layer 100 NORMAL))) (gimp-image-add-layer the-image-id the-layer-id -1) In my opinion the PDB documentation isn't helpful in this case, because the mnemonics are wrong, but paying close attention to the details will show you what went bad: The value of GRAY_IMAGE (which you're using in gimp-image-new) is 2, which corresponds to an image type of GIMP_INDEXED -- which is obviously not what you wanted. Then when you tried to add the, correctly created, layer, it complained. Helvetix On Sat, Jun 07, 2003 at 04:47:54PM -0400, Douglas Lewan wrote: All, I've just started hacking in the Gimp via scheme and clearly don't understand (gimp-image-add-layer). What I've read suggests that the following ought to get me a new layer in an image. = (set! the-image-id (car (gimp-image-new 10 10 GRAY_IMAGE))) 0 = (set! the-layer-id (car (gimp-layer-new the-image-id 10 10 GRAY_IMAGE a named layer 100 NORMAL))) 2 = (gimp-image-add-layer the-image-id the-layer-id -1) ERROR: Procedural database execution failed: (gimp_image_add_layer 0 2 -1) A procedural database execution failure suggests that something quite fundamental is going on. (It's not just me getting types or syntax confused.) Can anyone help? Can anyone tell me how I might investigate this intelligently? Thanks. -- ,Doug Douglas Lewan email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] cell: 908 7207 908 Design: The activity of preparing for a design review. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] car and cdr
It is not clear from your message if you are reporting a widely known fact, or trying to report a bug. To report bugs, go to http://bugzilla.gnome.org/ so the bugs can be tracked. But since the topic is Lisp, I will jump in. In either case, all shorthand forms of car and cdr are convenience functions for which you can extend all that you want. Generally the predefined ones do indeed stop at about 3. Helvetix On Tue, Jun 03, 2003 at 12:27:18PM +0400, Alexey V.Chaykin wrote: Command with more than 3 'd' or 'a' subcommand not work. =(cdddr '(1 2 3 4 5 6 7 8 9 10 11 12 13)) (4 5 6 7 8 9 10 11 12 13) =(cr '(1 2 3 4 5 6 7 8 9 10 11 12 13)) ERROR: unbound variable (errobj cr) --- gimp 1.2.3 ___ 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] running gimp withou't make install?
Once the linking part has been done by app/gimp-1.3, I just run gdb app/.libs/gimp-1.3 Helvetix On Sun, Jun 01, 2003 at 04:35:02PM -0700, Nathan Carl Summers wrote: On Sun, 1 Jun 2003, Joao S. O. Bueno wrote: But what I do need now is a faster way to go from edit code to running gimp. Make Install asctually eats out a lot of time on my system. Is it possible to run the gimp-1.3 binary generated from make straight, without make-installing it? Of course you can, as long as all the data is installed in the right places (which the first make install took care of for you.) How can it be done? cd app ./gimp-1.3 Rockwalrus ___ 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] Error in Script-fu !
When executing from the script-fu console, don't supply a value for the run_mode flag. Be sure to supply a number and not a string for the value of font size. Like this: (script-fu-alien-glow-logo hello 150.0 -*-utopia-bold-r-*-*-150-*-*-*-*-*-*-* '(255 0 0)) Helvetix On Wed, Feb 26, 2003 at 09:43:29PM +0100, Branko Collin wrote: On 26 Feb 2003, at 10:30, Valter Mazzola wrote: i'm executing this line in gimp 1.2.3 Script-Console , linux Mandrake 9.0 intel: = (script-fu-alien-glow-logo 0 hello 150 -*-utopia-bold-r-*-*-150-*-*-*-*-*-*-* '(255 0 0) ) the console gives: ERROR: wta(1st) to quotient (errobj hello) I don't know, it looks like it should work, but it doesn't. -- branko collin [EMAIL PROTECTED] ___ 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] Status of MMX code in The GIMP
Folks, I haven't seen anyone respond to Sven's message. But this is about the right sized thing for me to help with. So barring the advent of someone with more time, I am willing and able to take on the MMX code implementation for GIMP. My recommendation is that current development proceed without expecting the current MMX code to work. Sven, et alia, can either remove it or leave it in place as a warning to others. When I have something ready to be integrated, we can syncronise then. Hopefully, that will be before 1.4 in a reasonable amount of time. But if not, it will be just as fine post 1.4 as well as to use it with GEGL. Helvetix ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
