[Gimp-developer] Fractal image scaling
Good evening! Liquid scaling is beautiful technology, but differs from fractal scaling pretty much. The fractal image scaling is based upon an Fractal compression algorythm and a functional analisys. In the fractal compression algorythm we propose that our image is fixed point of contractive affine transformations. Such system of the affine transformations is called Iterated function system (IFS). We build the IFS based upon our image. Then, to get our image we should take any starting point (any image for example) and apply the IFS many times. As the result we get our image. That's interesting, that the IFS don't know about image resolution, and we can take an big resolution image as the starting point. This way of image scaling is noted by Stephen Welstead in his book Fractal and Wavelet Image Compression Techniques (Chapter 3, 3.6. Resolution independence). If it is not good approach, could you offer me another task related to image processing research field? Regards, Alexander Beloborodov. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tiny-Fu and its possible R6RS (beyond) future...
The following is a reply to an old e-mail message sent to gimp-devel that has been bit rotting for some time in my drafts folder. Andreas Posur wrote: Many thanks for contributing to G.I.M.P yw I heard lots of different complains about working with scheme for GIMP (mostly: ugly interface and unsexy) Scheme (TinyScheme/Fu and as well SIOD) are not up to date nor do they feature some stuff which is meanwhile often requested (such as) intensive (unit) testing... SIOD was old and didn't really follow existing Scheme standards. TinyScheme is meant to be tiny, or at least small, and will be seen as missing features when viewed by those used to a full-blown Scheme implementation such as Guile. There are a couple of scripts for testing Scheme implementations for compatability with R4RS and R5RS. TinyScheme can't run the R5RS tests as it doesn't support define-syntax. It does quite well running the R4RS tests when you take in to account the lack of support for things like complex numbers and big numbers. The Programming Languages Teaching Team is reshaping their version of scheme to another much less misunderstood name on Google called Racket. They will feature their implementation of R6RS Standard Thank you for the information on Racket. It looks interesting but it would be too big to include with GIMP. How difficult could it be to write at least a GIMP (Tiny-Fu I don't think we would need tinyscheme that bad, but perhaps I'm wrong) rewrite perhaps together with M. Felleisen and his crew to get this not so much convenient method to do effective scripting updated (upgraded). [snip] You will find the whole discussion here: http://list.cs.brown.edu/pipermail/plt-dev/ I don't understand what you are asking. The link to the discussion is just a link to the entire mailing list archive for PLT. If you have a direct link to the message thread I will look at it. I'm not going to dig through their archives to find the discussion you wanted me to look at. GIMP will have crucial feature changes (GEGL) with 3.0 and with Scheme/Racket we could to try to automate and enhance them for the greater good of people. PLT-Scheme coding is such much more comfortable and no it is not that power-limited... Every so often someone suggests that Script-Fu should use some more full-featured version Scheme implementation. It's fine to suggest such a thing but you have to keep a couple of things in mind. Is the proposed implementation of Scheme available for all environments that can run GIMP? How big is the implementation and can it be embedded with Script-Fu? Most of the more complete implementations of Scheme are too big and contain features not needed for basic scripting and automation of GIMP. If someone can propose additions to TinyScheme to add any needed features, or knows of a more full featured Scheme interpreter that isn't a lot bigger than TinyScheme, I would be interested to look at the proposal. For GIMP 3.0 I would like to get the changes I have planned for version 2 of Tiny-Fu in as the new Script-Fu which will make it easier to use alternative Scheme interpreters. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fractal image scaling
2011/4/1 Александр Белобородов vala...@gmail.com: Good evening! Liquid scaling is beautiful technology, but differs from fractal scaling pretty much. The fractal image scaling is based upon an Fractal compression algorythm and a functional analisys. In the fractal compression algorythm we propose that our image is fixed point of contractive affine transformations. Such system of the affine transformations is called Iterated function system (IFS). We build the IFS based upon our image. Then, to get our image we should take any starting point (any image for example) and apply the IFS many times. As the result we get our image. That's interesting, that the IFS don't know about image resolution, and we can take an big resolution image as the starting point. This way of image scaling is noted by Stephen Welstead in his book Fractal and Wavelet Image Compression Techniques (Chapter 3, 3.6. Resolution independence). If it is not good approach, could you offer me another task related to image processing research field? Regards, Alexander Beloborodov.] Hi Alexander - I myself find this idea very interesting. Certainly, a fractal scaling algorithm of some sort should find its way into GEGL. Can you elaborate a bit more, or give us a link to a digest article describing fractal scaling? In order to consider it as a project, the motivation and advantages of it should be clear to all developers, so that your project is voted up. Your e-mail above is still a bit cryptic on the capabilities of this algorithm regarding what could be available for the final user. You describe the general lines on how does, but we don't know now what it does. For example - can it scale up and down? Can it compare, visually, to the algorithms already implemented in GIMP? Does it offer at least a theoretical big advantage for the final user? (/me hopes so :-) ) Thanks, js -- __ 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] gegl build fails
On 30 March 2011 19:24, Michael J. Hammel mjham...@graphics-muse.org wrote: On Wed, 2011-03-30 at 19:10 +0200, Jon Nordby wrote: GISCAN Gegl-0.1.gir WARNING: Skipping unknown interface GeglVisitable GICOMP Gegl-0.1.gir Gegl-0.1.gir: error: Type reference 'GeglMatrix3' not found Yeah, this has been reported by other as well. I'll try to fix it now. Which distribution are you using, and what is the version of gobject-introspection? Fedora 13. Is gobject-introspection within gobject-2.0? If so: $ pkg-config --modversion gobject-2.0 2.24.1 No, the introspection toolchain is separate. Typically packaged as gobject-introspection or similar. Anyhow, does it work for you now? I pushed a fix. -- Jon Nordby - www.jonnor.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL Editor - Idea for GSoC
Hello, everybody. I have a quite simple proposal for this year GSoC: make a nice editor for GEGL pipelines. Why do we need it: because the GEGL eats XML files. GIMP could eat them too. It would introduce much greater reusability in the work of designers. Who will use it: graphic designers (who else? :p). The concept of GEGL operations is sufficiently simple to be used even by casual users. How it could be used: GIMP could show a list of GEGL XML files that can be applied to current layer. Very similar to how the filters are exposed right now. The editor itself could be located in GIMP (I would like that :) ) or as a separate program. I have been generating various content on this topic for around a year and made a few concepts. Their code is packed at stud.ics.p.lodz.pl/~mafik/prototypes.tar.bz2 (contains a few interface ideas) (bother to look only if you want to deal with lots of unfinished code). I have made a sample here: http://www.youtube.com/watch?v=sEm9M2O6xC0 (second part shows much better, what I am thinking about). There are many areas where the idea could be clarified, but the concept should be clear. Request for comment: - what do you think of the whole idea? Would it be useful or not? - should it be merged with GIMP or work standalone (or both :) )? - is Vala mature enough to use it as the main language? (I'm asking because I saw some discussions about it recently on this list) - what gui toolkit would be appropiate? GTK or Clutter? (I fell in love with clutter, but there may be reasons not to use it for such program) Other ideas: - shebang at the beginning of the GEGL XML - drop files on the script and get them processed - automatically generate GtkBuilder XML for marked parameters of GEGL operations - could be used to display filter-like dialogs of arbitrary GEGL pipelines. PS. (note to GSoC mentors) I would like to take part in this year GSoC. If you encounter my submission, take it under considerations only under this idea (if it passes, of course). -- Marek Rogalski ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
At the LGM 2009 BOF, I remember Oyvind discussing his vision of something kind of like this. Since GEGL structures its operations in tree form, what you may want to think about is that you want to display a tree in a form understandable by a user. My personal take is that there probably is a topological sort algorithm which effortlessly leads to an easy to understand description of the tree in list form. (This list could then be broken up in sublists. No doubt, Oyvind and others (including you) have better ideas. Good luck, Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
On Sat, Apr 2, 2011 at 12:00 AM, Nicolas Robidoux nicolas.robid...@gmail.com wrote: Since GEGL structures its operations in tree form, what you may want to think about is that you want to display a tree in a form understandable by a user. GEGL does not structure operations in a tree form but as a graph, the XML file format of GEGL uses a tree with clones. Both are valid options, though there are some types of graphs that might be desirable that are not possible to express as graphs. For an editor for meta-operations (like unsharp mask, dropshadow etc. a proper graph editor could be mose suited.) My personal take is that there probably is a topological sort algorithm which effortlessly leads to an easy to understand description of the tree in list form. (This list could then be broken up in sublists. GEGL already does this topological sort when saving the in memory graph structure out to the tree in XML. But that does not have to impinge on how a UI is done. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
Apologies: I meant acyclic digraph, not tree. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
On Fri, Apr 1, 2011 at 9:55 PM, Marek Rogalski mafi...@gmail.com wrote: Hello, everybody. I have a quite simple proposal for this year GSoC: make a nice editor for GEGL pipelines. Why do we need it: because the GEGL eats XML files. GIMP could eat them too. It would introduce much greater reusability in the work of designers. Who will use it: graphic designers (who else? :p). The concept of GEGL operations is sufficiently simple to be used even by casual users. How it could be used: GIMP could show a list of GEGL XML files that can be applied to current layer. Very similar to how the filters are exposed right now. The editor itself could be located in GIMP (I would like that :) ) or as a separate program. The meta-operations should be loaded from XML definitions and not defined in C, allowing such an editor to program composite filters, that effectively will replace many of the current uses of script-fu in GIMP. For instance the logo scripts and quite a few other such scripts should be possible to easily reimplement as meta-ops visually with such an editor in place. See https://bugzilla.gnome.org/show_bug.cgi?id=465743 for a bug tracking the long standing desire to load these ops from XML instead of hard-coding them in C. Request for comment: - what do you think of the whole idea? Would it be useful or not? It would defintely be useful. - should it be merged with GIMP or work standalone (or both :) )? Making it work stand-alone first is probably best, a stand alone tool would also allow easier testing of GEGL operations (GEGL used to ship with a tree based editor UI sandbox (http://pippin.gimp.org/tmp/gegl-foo/) that I removed since the code was scraped from somewhere else and rather ad-hoc.) If a good graph editor surfaces, GIMP might be interested in incorporating portions of it in some way, but it would defintely be useful on its own as well. - what gui toolkit would be appropiate? GTK or Clutter? (I fell in love with clutter, but there may be reasons not to use it for such program) If the program is stand-alone, the choice would be up to the implementor ;) Other ideas: - shebang at the beginning of the GEGL XML - drop files on the script and get them processed - automatically generate GtkBuilder XML for marked parameters of GEGL operations - could be used to display filter-like dialogs of arbitrary GEGL pipelines. Generting XML is not neccesary, both the GEGL tool in GIMP and the sandbox I linked to were generating their property editors on the fly based on inspecting the GParamSpecs. Going through GtkBuilder XML might not neccesarily be easier than building the UIs only in code. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
help me to understand. GIMP plugin authors will now be required to write their plugins in GEGL? as of what version of GIMP, if anyone knows? From: Robert Sasu sasu.rob...@gmail.com To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Wed, March 30, 2011 10:53:09 AM Subject: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations My background: I am a 1st year student of the department of Computer Science and Engineering at Polytehnical University of Bucharest. I have started to use GIMP 2 years ago. I wrote emboss, blur and sharpen tools in C and then in Octave. I wrote a program which converts images from Targa(for RGB images with colour map or without) to PPM(type 3) and back. I would also suggest to generalize the emboss plug-in by using some operators such as: Sobel, Robert Cross, Prewitt, Scharr or Costella. In case of Sobel operator we can set 3 types of normalizing (gradient x,y or magnitude) all 3 making some new effects. Code review and algorithm description (GIMP plug-ins): 1. Cubism Function cubism: Initializes the values of alpha and image type, and fills the image with the background colour, which we get from the drawable image(current image). After calculating the number of tiles of the asked rectangle the function randoms the indices and initiates the first rectangle. For each tile the starting point (x,y),height and with is randomed between certain limits, depending on the tile saturation and tile size set by the user. The rotation grad is also randomed. Then for each polygon it adds the calculated points to the structure for creating the double perspective, rotates and translates it by adding the starting points(x,y). It checks if the calculated point is between minimum and maximum and gets the closest value (CLAMP), and gets the pixel color from the source. Finally it fills with color the drawable image in the pixels within the polygon. fill_poly_color: The colour of a pixel will be calculated by looking at the backgroung image and the intersection of the polygons. Firstly calculates the distance between the 2 points of the polygon and initiates values of vector. By polygon_extent we get the minimum and maximum position of the pixels. It initiates the the values of the lines which need to be scanned and for every 2 points in the polynom it calculates the minimum and maximum of the segment. For every pixel in the polygon it calculates the colour which will be equal with the color from the source image which is in the position (x,y). x is equal with ((size_x-1)/4+min_x. In vals the function keeps if that row was reached or not. The alpha value of the pixel color is between 0.1 and 0.2, caculated by the distance between the points in the polygon. Every value we get from buf which will be equal with the color of the coloumn plus the color from the position (x,y). 2. Fractal trace Initialization: source pixel table(guchar **) gets the color values of the current picture for every column. Destination pixel table gets allocated memory. Pixel get: In function of the image type the asked pixel gets the values from source pixel table for RGBA. Pixel set: The color of a certain (position c,y) is uploaded to destination pixel table considering also the image type. Pixel get biliner: Calculates the values of the colors for the asked pixel, making median of its neighbour. The alpha value is accumulated, for the other values after accumulating the color*alpha it divides with the acumulated alpha. Mandelbrot: While the iteration number is smaller then it calculates the position of the pixels with the quadratic polynomial. The new pixel position will be the values calculated on the last iteration. Filter: For each pixel in the given rectangle the function calculates its colour value. First it calculates a position of the asked pixel by the parameters, then iterates it with the mandelbrot function. If the iterated pixel position is in within the image then its color value is calculated. Else if the position escaped to infinite then in function of the Outside type it calculates its value. In case of WRAP the color of the pixel will be equal with the pixel being at the position (px-px/width,py-py/height). At last it saves the value of the color in destination pixel table. It is written almost the same thing for the dialog-preview, the setpixel function is differing because it considers every picture to be type RGBA. Possible optimization: If the given point lies within the cardioid or in the period-2 buld we can calculate its color without appealing the mandelbrot function, without iterating, because it will never escape to infinite. Just have to verify that: q(q+(x-1/4))1/4*y^2, where q=(x-1/4)^2+y^2. Moreover the periodicity checking could also be implemented by using a little more memory. If by iterating a pixel, that pixel reaches another pixel which was calculated(iterated) before we know
