Re: [Gimp-developer] Perspective tool - preserve aspect ratio?
Maybe this is useful? http://web.archive.org/web/20091027131421/http://geocities.com/evilsnack/matrix.htm ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
The following statement of Mich's unfortunately describes most of nowadays C.S. students [1] And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. Just like the people who only know how to write java or #C code. They know how to use all the fancy classes, but they have never implemented a list or anything lowlevel themselves. I don't want people who know vala, but don't had to learn GObject. One way of viewing the issue is: Do you want to cater to the programmers you want, or the programmers you have? (With the hope of turning the latter into the former.) Nicolas Robidoux [1] research.cs.queensu.ca/~cisc422/2010f/readings/papers/whereAreTheSoftwareEngineersOfTomorrow.pdf ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] automating tasks
http://www.imagemagick.org/Usage/anim_basics/#coalesce ___ 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
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] Announcing AdaptableGIMP
Dear Dr. Terry: I find it interesting that you and your group decided to use task set instead of (solution) stack, the standard FLOSS descriptor for sets of tools tailored to a specific task. Smart move, given that the goal, I would assume, is to help everyone! Reference: http://en.wikipedia.org/wiki/Solution_stack -- Nicolas Robidoux https://www.ohloh.net/accounts/NicolasRobidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Announcing AdaptableGIMP
Dear Dr. Terry: On a more humorous note, it would appear to me that a good logo for AdaptableGIMP would be Wilber with an eye patch, suggesting that the main idea is to make only part of the interface visible (in a task dependent way). Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
Opinion: Don't waste your time and energy on the actions of dishonest internet people. There is a point to educating/warning/suing corporations (after all, some level of accountability/legal responsibility is part of their charter). Not internet ghosts. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradual zooming!
Note: I am currently working toward programming for GEGL methods which apply arbitrary transformations (affine, say) in such a way that a small change in the transformation (which are arbitrary) leads to a small change in the result. I don't know if those necessarily would be those used by the display (they are to become part of the gegl-sampler-*.c family) but if they were, this would allow any increment in zooming, with no jump in the result (although, probably, a jump in the display unless the speed is up to par). Nicolas Robidoux On Mon, Jul 19, 2010 at 6:49 PM, Bill Skaggs weska...@gmail.com wrote: It wouldn't be that hard to implement a tool that would scale in a way that feels fluid. But I question whether it is worth the effort. It's hard to see what user interaction would be easier with smooth scaling than with scaling in 10% steps. -- Bill ___ 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] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods
In light of some feedback received, me and my students will be making major changes to three of the gegl methods, so you may want to wait until the comparisons are updated. Nicolas Robidoux On Fri, Jun 4, 2010 at 2:26 PM, Nicolas Robidoux nicolas.robid...@gmail.com wrote: To illustrate the effect of the samplers when ROTATING images, I put together a comparative test. It shows the results of rotating a quite sharp image of astronauts near the space station---if I remember correctly---by 6.5 degrees with four GIMP methods, three GEGL methods and three candidate GEGL methods for which patches are provided in https://bugzilla.gnome.org/show_bug.cgi?id=619314 (The image is very sharp: I actually wonder if NASA sharpened it.) The results, named one.png to nin.png, are found in the tar archive http://web.cs.laurentian.ca/nrobidoux/misc/astronautsrotatetests.tgz To know which method was used to produce each image (and get runtimes for the GEGL methods), read the KEY text file. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods
To illustrate the effect of the samplers when ROTATING images, I put together a comparative test. It shows the results of rotating a quite sharp image of astronauts near the space station---if I remember correctly---by 6.5 degrees with four GIMP methods, three GEGL methods and three candidate GEGL methods for which patches are provided in https://bugzilla.gnome.org/show_bug.cgi?id=619314 (The image is very sharp: I actually wonder if NASA sharpened it.) The results, named one.png to nin.png, are found in the tar archive http://web.cs.laurentian.ca/nrobidoux/misc/astronautsrotatetests.tgz To know which method was used to produce each image (and get runtimes for the GEGL methods), read the KEY text file. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods
To illustrate the effect of the samplers on images from the opposite end of the spectrum (text as opposed to natural), I have put together a similar comparison with a text image created with GIMP. It shows 9.73x enlargements with two GIMP methods, three GEGL methods, and three candidate GEGL methods for which patches are provided in https://bugzilla.gnome.org/show_bug.cgi?id=619314 The enlargements, named A.png to H.png, are found in the tar archive http://web.cs.laurentian.ca/nrobidoux/misc/textenlargementtests.tgz To know which method was used to produce each image (and get runtimes for the GEGL methods), read the KEY text file. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods
I have created 6.11x enlargements with two GIMP methods, three GEGL methods, and three candidate GEGL methods for which patches are provided in https://bugzilla.gnome.org/show_bug.cgi?id=619314 The enlargements, named a.png to h.png, are found in the 15M tar archive http://web.cs.laurentian.ca/nrobidoux/misc/catenlargementtests.tgz To know which method was used to produce each image, read the KEY text file. One of the three candidate methods is very fast. The total runtime for the creation of the enlargement with upsmooth is only 15% more than with bilinear. Only one of the three candidate methods is slower than GEGL bicubic (upsharp, by 30%). Nicolas Robidoux PS Warning: the upsize, upsmooth and upsharp samplers already in GEGL are prototypes of the methods showcased in the above enlargement test. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP to be removed from Ubuntu Lucid Lynx?
http://www.omgubuntu.co.uk/2009/11/gimp-to-be-removed-lucid.html ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Save + Export proposal
An idea (especially for when GIMP moves to GEGL). Apologies if this has been suggested/shot down before. I think that the following terminology would be fairly clear to users: Save IMAGE (basically, export to a non-xcf format) Save PROJECT (save the xcf/gegl tree) Save WORKSPACE (save the current configuration of GIMP, not the xcf/gegl tree or the image: visible tools, visible non image windows etc) IMHO, this 3-pronged save option makes it pretty clear what this is about. I suggested earlier that Save workspace (like nip2) should be the non-export quick save, but eventually realized that a workspace suggests a set of easily accessible tools organized to fit a specific TYPE of project. On the other hand, Save project' suggests that all the components of the intended final image should be kept around. Save image really suggests that what you are saving is the final product, in a common image format, that is, it corresponds to exporting. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] open/save/export
(Apologies if this repeats a previous suggestion.) I am wondering if making a distinction between saving an IMAGE (which would have an export format component) saving a PROJECT (basically, saving a GEGL tree: this should be the quick save) saving a WORKSPACE (chosen set of parameters for tools, basic window configurations etc, stripped of image/input specific information) would help make things clear to users. I like saving a project because I expect users to immediately understand that a project is not an image, and consequently, a project can't be stored in jpg. On the other hand, when I have a certain type of work to be done with an image, I'd bring it to a specific workspace, which basically would provide a work context, a table with the most likely needed tools laid out in front of me with the settings I am most likely to need. Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP/GEGL panorama (360 degrees) group photos from LGM 2009
Yuval Levy [0] has produced paroramic mug shots of the GIMP/GEGL developers present at Libre Graphics Meeting 2009 in Montreal. Everything was done with with FLOSS. This is a still picture: http://www.photopla.net/hugin/090509lgm03_gimp_240st.tif This is a rotating animation: http://www.photopla.net/fspan/RCMwOTA1MDlsZ20jMDkwNTA5bGdtMDNfZ2ltcCMw Good job and thanks Yuv! nicolas [0] http://panospace.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP/GEGL panorama (360 degrees) group photos from LGM 2009
Here's Yuval Levy's account of his experience using GIMP to produce the panoramas: http://panospace.wordpress.com/2009/10/13/making-the-gimp-work-for-me/ Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
On Thu, Oct 22, 2009 at 1:50 PM, peter sikking wrote: another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone). (Warning: Foot in mouth ahead.) I have the impression that the least painful way to make GEGL fast SOON may be to build its desired API on top of VIPS. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Gegl-developer] [GSoC] Mentor Summit
I'd be happy to represent GEGL and GIMP at the GSoC 2009 Mentor Summit. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Peter: just for clarification: by workspaces you're referring to nip2 workspaces, which roughly translate to GIMP compositions, correct? Yes. (More or less, a (possibly unfinalized) tree.) (I suppose composition sounds a little more artistic ;-) Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Composition rendering time instance
Peter: The best solution i've found so far is to first save the GEGL tree to make shure the user's work is safe. After that, rendering will start, and the image window gets overlayed by a lightbox displaying the rendering progress and a button 'schedule rendering for later'. I don't think that using the word rendering in a menu will be self-explanatory for non-sophisticated users when used in a save context. I am not sure that I have a better suggestion. Save workspace vs Save image? Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Composition rendering time instance
Nicolas Robidoux writes: I am not sure that I have a better suggestion. Save workspace vs Save image? ... but it makes lots of sense that the tree be saved just before rendering unless this is overridden by the user. Nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
yahvuu writes: Another alternative is to go with lazy rendering and introduce a 'finalize image' command that optionally renders to full resolution. This way, the save/render distinction won't show up until it is really desired by the user. I like finalize image. The additional command may be required anyway as a means to reduce file size by dropping some non-destructiveness. See last image in http://gimp-brainstorm.blogspot.com/2009/04/version-control.html The way nip2/vips deals with a somewhat related issue is that when nip2 is started up, if a lot of disk space is taken up by workspaces, it asks you whether you would like to delete them. A less drastic gui would ask you whether you would like to go through workspaces and mark them for deletion, and then you could pick and choose (and only look through some of them, even) based on thumbnails, size, date of last mod. and whether the result was finalized. Nicolas Robidoux University Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Nicolas Robidoux writes: The additional command may be required anyway as a means to reduce file size by dropping some non-destructiveness. See last image in http://gimp-brainstorm.blogspot.com/2009/04/version-control.html The way nip2/vips deals with a somewhat related issue is that when nip2 is started up, if a lot of disk space is taken up by workspaces, it asks you whether you would like to delete them. A less drastic gui would ask you whether you would like to go through workspaces and mark them for deletion, and then you could pick and choose (and only look through some of them, even) based on thumbnails, size, date of last mod. and whether the result was finalized. To push the at start-up idea further: At start-up, the user could be presented with a list of unfinalized workspaces, and asked whether to finalize each, or open each. This way, the possibly time consuming rendering would be started at the beginning of a session, not at the end, unless the user explicitly asks to finalize one of the current workspaces. Alternatively, this could be done automatically at start up, in the background. (Just brainstorming here.) Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSoC] Request for Status Reports
Hello Michael: Adam and Eric are moving as expected on their respective GSoCs. Nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL GSoC Mentor would like to discuss projects at LGM 2009
Hello all: I mentor two GEGL-related GSoC projects this Summer, and would like to discuss some of my ideas about implementing the two projects with more senior developers who happen to be at LGM 2009 Montreal. I'll be in town until Sunday, and this is my priority. You may also give feedback to this list if you have some to give, and I will read it carefully. In all cases, pointers toward best implementation approach would also be appreciated. (In most cases, we can probably figure it out from the source code, but this only implies preferences and intent on the part of core developers.) Main issues: --Desired image size convention for transformations (e.g. resize) for which this matters. Option A: Corner Option B: Center Option C: User chooses between them --Abyss policies for resamplers. I am not convinced that more is necessarily better. Option A: Minimal fast and robust: Only clamp a.k.a. nearest neighbour abyss (like GPUs or VIPS) Option B: User can toggle between clamp and constant and periodic (good for textures) one source at a time. --In order for a sampler to be adaptive with respect to transformation features (its jacobian matrix, say), such information must be communicated to the sampler. Any suggestion RE: how to communicate such information to samplers? (We could start with affine transformations, in which case a constant matrix gives all the key parameters.) --Higher level nohalo/snohalo (3 and above) would be simpler to program if one could store one level of subdivision into a buffer/tile which would behave like a normal input image tile as far as the final subdivision levels go. I know this is possible to do in VIPS, which is quite similar internally to GEGL (John Cupitt has tried in the past this on other operations than resamplers). I'd like some guidance as to how to do this cleanly in GEGL. (Basically, this emulates producing a double density version of the input image, fixing the sampling coordinates so that they use a coordinate system relative to the double density image (easy), and then using standard higher level nohalo as if the double density image tile was a normal input tile. Of course, this requires abyss policies to be applied to the double density image too.) We can program things directly without such intermediate result tiles, but this quicly leads to increases in code complexity. -- I don't necessarily need to fully understand the details: this will be the job of the GSoC students. I just would like to know at least enough to properly steer them. Thanks, Nicolas Robidoux Universite Laurentienne (Wearing a blue hawaiian shirt today) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC: good job Michael
I just want to let everyone know that many organizations fell into an unintended trap having to do the Melange software used by Google to manage the application process, trap in which Michael Schumacher, our GSoC admin, did NOT fall. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC appliction scores
Dear GIMP GSoC mentors and prospective mentors. Please remember to score and comment applications. Next milestone is April 15. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC 2009
Dear Nebojsa: Suggestion: Just apply. If you see other projects of interest, apply to those too. Best fit can be sorted out later. Right now you need to officially apply. Best of luck, Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] last minute GSoC applications
Expect two excellent students from my institution to slip applications in just before the GSoC deadline. This is the last week of class here, and all the semester projects are due now. Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC applicants: apply early, and apply often
Dear prospective GSoC students: Only two days to go. Unless you are really interested in one and only one project, I suggest that you put in more than one application. Only one applicant can work on any given project. If you have more than one application, you increase your chances to come on top for one of them. Better yet: Come up with your own GIMP/GEGL project instead of relying on the ideas page. This being said: If you would be so kind so as to let us know what your favorite project is, this would increase the likelyhood that you get that one. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Hello all who put down good student UI projects. Clearly, Peter can't have his students do them all. Given this, would you consider putting them up at http://wiki.gimp.org/gimp/SummerOfCode2009ideas ? There are five days left to the application process, so some student may bite, and then it would (hopefully) get done. nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a good student UI project...
Peter: Here is a suggestion UI project for training purpose: Right now, in GEGL, you have access to the whole 2-parameter family of cubic splines for resampling, as well as bilinear. Pick three representatives, say Catmull-Rom (lots of halo), smoothing B-Splines (lots of blur) and bilinear (lots of jaggies). (Instead of bilinear you could use nohalo a.k.a. gegl-sampler-sharp.c.) If you want to stick to what's already in the Gimp you could use lanczos, cubic and bilinear. Now: Any location within a triangle defines barycentric coordinates, which in term define a blending of the three methods. Construct an interface which mimicks http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm except that instead of using it as a descriptive tool, we use it as a way of picking your blend of poison. Now, I don't know how attractive it is to ask people to pick a method by focusing on their weaknesses, but it certainly is a realistic way. Also note that this interface would allow one to drive any triad of resampling methods which can be compared and characterized in terms of the three common artifacts. Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a good student UI project...
Peter: Of course, you could also use the interface to choose between three cubic methods, which makes a lot of sense within GEGL (the jaggy one would be lagrangian bicubic). Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] google summer of code
Vincent: Do you think you could put some of your ideas for useful/interesting GSoC projects here: http://wiki.gimp.org/gimp/SummerOfCode2009ideas ? Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] About GSOC 2009
YongLi: Thank you very much for your interest. You may want to check this: https://lists.xcf.berkeley.edu/lists/gegl-developer/2009-March/000998.html as well as revisit the updated http://wiki.gimp.org/gimp/SummerOfCode2009ideas#head-c616d78ee5dc03ae28707de7fadf0b1fa8ecfb66 In summary: Unless I find a mentor (I'm looking) who is ready to guide you through the GEGL back end design and programming, a non-trivial software engineering task, or you yourself have the competence to do it on your own, you probably should find another project to apply to. Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hello Rahul:
i m a student and interested in gsoc project:Fast Adaptive Resampler
Tailored For Transformations Which Mostly Downsample
I have read the requirements properly for this project which also
includes jacobian transformation,box filtering algorithm and
bilinear resampling.But i am having some problem in relating all
these in one algorithm. Please guide me.Also I would like to know
the status of this project progress.
The programming for this project has not started. No progress is
consequently a fair description.
This would be a brand new way of doing downsampling, so I can't point
you to one algorithm.
Computing jacobian information (for an arbitrary point transformation)
approximately using finite differences is probably too ambitious. My
current opinion is that this method should only be used when the point
transformation communicates this information to the sampler. This
probably means that a point transformation (e.g., scale, rotate) needs
to have this info part of its implementation as an object. I'll need
opinions from people who know better at some point.
You need to understand exact area methods, and in particular, exact
area box filtering (basically, you understand images as being a
piecewise constant surface, with the pieces determined by the set of
points which are closer to a pixel center than any other pixel center,
and you (approximately) integrate this surface over an area associated
with the new pixel centers (determined by the point transformation).
References which may help understand what is going on are
@TechReport{Dodgson,
author = {N. A. Dodgson},
title ={Image resampling},
institution = {University of Cambridge Computer Lab.},
year = 1992,
number = {UCAM--CL--TR--261},
address = {15 JJ Thomson Avenue, Cambridge CB3 0FD, UK},
month ={Aug.}
}
and
@inproceedings{DBLP:conf/iciar/RobidouxTGT08,
author= {Nicolas Robidoux and
Adam Turcotte and
Minglun Gong and
Annie Tousignant},
title = {Fast Exact Area Image Upsampling with Natural Biquadratic
Histosplines},
pages = {85-96},
ee= {http://dx.doi.org/10.1007/978-3-540-69812-8_9},
bibsource = {DBLP, http://dblp.uni-trier.de},
crossref = {DBLP:conf/iciar/2008}
}
Also, a student and I programmed a C filter (for 8-bit ppm/pgm) which
does exact area box filtering in the very simple case of pure image
resizing. If you're still interested, we'll put this on the web.
The proposed method is none of the above. More precisely, it is a
composite method: It fits a new fast but accurate downsampling
method (related to box filtering) and bilinear together so that
Frankenstein is flexible and smoothly varying.
Note: French is my mother tongue. If you are more comfortable in
French, you can communicate with me---not this list---in
French. Obviously, English is fine too.
Best of luck,
Nicolas Robidoux
Universite Laurentienne
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hello Craig: Numerical Jacobian calculation is not so bad in terms of coding effort The issue is that, if I understand correctly, GEGL's current pure demand-driven structure means that resamplers have no information whatsoever about what other nearby locations are being resampled, and consequently there would need to be major changes to make this info available for arbitrary transformations (with, most likely, serious speed impact). Once you have it, sure, computing approximate Jacobian matrices is no big deal (provided you make sure that you stay from singularity). Hence my pragmatic choice to reserve the use of the novel (not so sure anymore that it's really new) method for tasks for which the jacobian is easy to compute and pass on. (This is the: ask people who know better part.) Does this make sense to you? Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hello Rahul: Indeed, the GSoC I suggested can be roughly described as implementing a poor man's version of the scheme Craig describes in http://adsabs.harvard.edu/abs/2004SoPh..2193D Replace circles/ellipses by parallelograms/rectangles, and notice that padding the singular values of the Jacobian to 1 is more or less equivalent to exact area box filtering with sides no less than the input image's inter-pixel distance, and one gets more or less the same thing. This being said, what I have in mind in way simpler than what Craig implemented. But if you understand Craig's paper, you probably understand what I want to do. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
This being said, what I have in mind in way simpler than what Craig implemented. But if you understand Craig's paper, you probably understand what I want to do. Actually, if I took the time to completely understand Craig's paper, I probably would understand what I want to do. ;-) Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Rahul: exact area box filtering with sides no less than the input image's inter-pixel distance This was a bit terse: Exact area box filtering with a square box with diameter equal to the inter-pixel distance is exactly bilinear interpolation. So, it's only when the sides are larger than the scheme is not bilinear. nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] An Early GSoC Purpose: Better nonlinear resampler for GEGL
Hello Jenny: Thank you very much for your interest in this project. You unfortunately picked the one project for which I have someone in mind already. (This proves your good taste!) I am double checking with this student that he wants this project as a GSoC. If so, he'll be my first choice for a variety of reasons, the main one being that he is working with me right now on nohalo level 1, hence would be able to jump right into nohalo level 2 and snohalo level 1 and 2. I'll let you know ASAP whether you should look elsewhere. (Note: all my other GSoC suggestions are wide open at this point.) Nicolas Robidoux Laurentian University Jenny writes: Hi all, I'm a student and interested in an GSoC idea: Better nonlinear resampler with built-in antialiasing (GEGL) suggested by Nicolas. http://wiki.gimp.org/gimp/SummerOfCode2009ideas I have prepared to implement this idea for days, but today I found jungle had discussed this topic in January. https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-January/021512.html. I'm wondering whether jungle is a student and want to take part in GSoC 2009 too, if so, I think I have little chance to win because jungle looks more familiar with NEDI/ICBI than me. :) Should I continue my preparation on this idea? Thanks, Jenny ___ 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] An Early GSoC Purpose: Better nonlinear resampler for GEGL
Jenny: I'm a student and interested in an GSoC idea: Better nonlinear resampler with built-in antialiasing (GEGL) suggested by Nicolas. http://wiki.gimp.org/gimp/SummerOfCode2009ideas I have someone lined up for this particular GSoC project idea, so I suggest that you put your energy into another. Best of luck, Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] An Early GSoC Purpose: Better nonlinear resampler for GEGL
Hello Jenny, It must be very helpful for me if you could suggest an idea which request familiar with image filtering algorithms. :) Thanks, Jenny Maybe Fast Adaptive Resampler Tailored For Transformations Which Mostly Downsample (GEGL) fits the bill? The prereq is understanding exact area box filtering (not a particularly deep filtering algorithm, I'll admit). The real hurdle is tweaking GEGL so that transformation information is passed on from operations which call on resamplers (or else, approximating it). That, I don't exactly know how to do, but I'm sure a kind (but busy, aren't we all?) soul within the developers' group would give us some guidance. Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] need for more GSoC project ideas
Hello all, Now is the time to add project ideas to the GIMP GSoC web site (this includes GEGL). http://wiki.gimp.org/gimp/SummerOfCode2009ideas If you were the mentor/proposer for an idea from last year which did not get done, please consider moving it to the 2009 page. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Advanced Interpolation
Bill: A quick note about gegl-sampler-sharp (a.k.a. nohalo-bilinear level 1): I just checked, and it does a pretty good job at mild downsampling. Also: I am not convinced, far from it actually, that NEDI will do better than nohalo level 1 when the enlargement ratio is moderate (no larger than about 3), and I am pretty confident that higher level nohalos will actually do better across the board. It almost certainly will be much slower. So: I am not sure it really is worth your while implementing them for GEGL, given that their aims are pretty much the same, and the means are not completely different.. (Warning: I am highly biased: I am the main designer of the nohalo method. I also stand to be corrected: nohalo is still too young for me to really know its character. Note that nohalo-bilinear level 1 used on a CG picture which is writing like---as opposed to a photograph of a natural scene---is not likely to give impressive results.) Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Advanced Interpolation
Bill: There are already two fast nonlinear resamplers implemented in GEGL: YAFR (gegl-sampler-yafr.c) and Nohalo-sharp (gegl-sampler-sharp.c). Both are a little slower than gegl-sampler-linear, but faster than gegl-sampler-bicubic. See the (informal) benchmarks at http://bugzilla.gnome.org/show_bug.cgi?id=566717 Code wise, you may want to have a look at the following: http://svn.gnome.org/viewvc/gegl/trunk/gegl/buffer/gegl-sampler-sharp.c?revision=2881view=markup This is the lowest quality/fastest version of a scheme which, at higher quality levels, should compete advantageously will NEDI in the good looks department. Nohalo-sharp is (literally as we speak!) also being implemented in vips, and on the GPU (with DirectX). A not yet implemented variant of the scheme, Nohalo-Smooth, will look smoother (duh!). YAFR (Yet Another Fast Resampler) is likely to be made obsolete by the higher level nohalos. See: http://svn.gnome.org/viewvc/gegl/trunk/gegl/buffer/gegl-sampler-yafr.c?view=markup -- I'd love manpower (GSoC?) to implement Nohalo-Smooth and/or either Nohalo at higher quality levels. (Just a wish.) Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Advanced Interpolation
Hello Bill: At some point it may a good idea to move this discussion off the list, but at this point I'll hope that those without interest in these issues are just skipping this email. -- jungle writes: Nicolas Robidoux wrote: There are already two fast nonlinear resamplers implemented in GEGL: YAFR (gegl-sampler-yafr.c) and Nohalo-sharp (gegl-sampler-sharp.c). I'm not familiar with those two resamplers. Of course, that's not saying much, because it's not my area of expertise. I should mention, however, that I consider NEDI and ICBI interpolators of a different kind than most. First of all, they are very slow compared to bicubic. Speed is not the goal. Secondly, they don't provide a value for any point in between given pixels. Rather, their purpose is to enlarge the image in question by a factor of 2 (roughly. Actually it's size*2-1). After scaling, the image can be resampled to any size desired using other methods. Both algorithms copy known (given) pixel values into a 2x enlarged grid and then fill in the gaps between pixels using certain assumptions about the statistical values of the pixels. The main benefit of both algorithms is the performance around edges. ICBI is an improvement on NEDI. Edges are much smoother and more natural than bicubic. This is how nohalo works too, The current (low quality, but highly optimized) gegl-sampler-sharp.c only subdivides once and uses bilinear as finishing scheme. Consquently, the gegl-sampler-sharp.c code may provide a good basis for an implementation of single subdivision NEDI or ICBI, one level implementations which should give good results for resamplings which only involve moderate enlargement/stretching ratios (for nohalo, it's up to about 3-6). I explain all this to try to decide if the goal of ICBI is different than nohalo, and if there would be a reason to try to code it. Is there a paper I can read on nohalo? Or examples of results that I could compare to ICBI? Nohalo-sharp and nohalo-smooth are brand new schemes (we hope: maybe we'll find that they actually are old; I have to confess that I don't know as much about them as I should). We are currently writing the first paper about them. But there should be two comparison web sites coming up soon. You can also install the current gegl svn trunk and do the testing yourself. I'll include a sample .xml file at the end of this email (adapted from something Øyvind Kolås passed on). My hunch is that, given the same subdivision level, nohalo will not straighten as much as NEDI/ICBI, but will show less fine scale artifacts and will run faster---even if programmed with the same programming skill. This being said, if you would contribute toward the programming effort involved in implementing the higher level nohalos (I would guess the main programming issues are basically the same as with implementing the higher subdivisions for NEDI and ICBI) I'd be happy to count you among the co-authors of the appropriate paper(s). If you just end up programming NEDI/ICBI---but don't touch nohalo---I'd be happy to use your code for our image resizing comparison suite (which should be on the web fairly soon). Nicolas Robidoux Universite Laurentienne/Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Advanced Interpolation
Bill: I forgot the sample xml code to test nohalo-sharp level 1: !-- sharp enlargement -- gegl gegl:scale x='16.4' y='16.4' filter='sharp'/ gegl:load path='data/PICTURE.png'/ /gegl How to use: Step 1: Put this in a file (called, say, scale16p4PICTURE.xml) in the directory YOUR_GEGL_ROOT/docs/gallery/ YOUR_GEGL_ROOT being where you installed the gegl svn trunk. For example, if you used svn co http://svn.gnome.org/svn/gegl/trunk/ gegl then YOUR_GEGL_ROOT is gegl. Step 2: Put PICTURE.png in YOUR_GEGL_ROOT/docs/gallery/data Step 3: In YOUR_GEGL_ROOT/docs/gallery/ do make clean make Step 4: Point your browser to YOUR_GEGL_ROOT/docs/gallery (Note: you may want to rm -i *.xml in gallery to remove the xml drivers which don't interest you.) nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Roadmap for 2.7 / 2.8 ?
Hello Michael: Would you be willing to write an article titled: GIMP's Wish List for 2009 or something like it? You may get more feedback from the developers if you drop road map from the formulation, because unfortunately a road map sounds like some sort of informal contract, with failure to deliver the likely outcome. GIMP's New Year Resolutions would already be better than Road Map, because everybody understands about keeping such... (I already imagine the headline when GIMP moves to GEGL: The GIMP Starts Smoking.) - May the New Year bring many good features. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] question
Hello Irina: It don't know if it would help, but there is a reasonable pdf beginner's guide in French with a free download at http://www.scribd.com/doc/7909512/Debuter-Avec-Gimp-2-6 The same group http://www.aljacom.com/~gimp/ has put together an easier to install---so they say---windows remix of the Gimp with easy to install French documentation. Maybe this can give some ideas. (Note that I don't quite understand why they felt the need to have their own documentation, but apparently the remix was motivated on the basis of easier installation. I can't judge, given that I don't use Windows.) Best of luck, Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggested dates for LGM 2009 Montreal
Hello all: I am a very peripheral gimp and gegl player, but if you are having trouble sending someone to Montreal, I almost certainly can go and deliver whatever talk you want me to. (I have family there.) Nicolas Robidoux Laurentian University/Universite Laurentienne (8 1/2 hours driving from Montreal) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] investement: suggested project
Hello Alexandre Prokoudine: Here is a suggested project for the possible investment in gimp (which includes gegl, if I understand correctly). (Note: I do not want to highjack the investment. If the following is not appropriate, just let me know, and I will back off.) It turns out that I recently discovered what should be a very good method for resampling tailored for transformations in which downsampling is a more representative occurence than upsampling. I already have experience programming within GEGL so I am comfortable with this environment (to wit, the YAFR scale method, which is meant for transformations in which upsampling is more typical of the local situation than downsampling). I do not need the money myself (I am a prof). However, if some, possibly even token, amount could be sent in the way of one particular bright student I have in mind, I suspect that he could take on the project in the framework of a Summer project in May 2009 or a masters thesis starting in September 2009---although the work could start earlier. (This student and I programmed two, fairly different, gimp image enlargment plugins, which we will put in the repository when we have merged them (currently, he's busy with courses, and I'm busy with a newborn).) What the entire project could be: 1) Program a novel resampling method. This resampling method will be at least 7 times faster than (exact area) box filtering when the downscaling ratios are high and the aspect ratio is approximately preserved, and will boil down to bilinear when locally the transformation is upsampling. In terms of blur and aliasing, it will be about halfway between nearest neighbour and (exact areaa) box filtering. 2) Program specialized, even faster, versions for for image resizing (knowing that one resizes, as opposed to performing an arbitrary transformation, affine or not, allows one to access the data efficiently and fix things so that coefficients are computed only once). 3) Explore various speed-up methods for, esp., smaller integer data types, including fixed point arithmetic and compile time basis function sampling and storage (the vips image processing package makes smart use of this). 4) Slightly different project: Program a new method tailored for typically upsampling transformations. Unlike the current YAFR, this method would be co-monotone, co-convex and continuously differentiable. In particular, unlike the current gegl YAFR, it would not add any halo to images. Downside: More expensive than the current gegl YAFR, and less sharpening. 5) Yet another possible add-on: Program a novel image sharpening method based on discrete Hodge star operators. Let me know what you think, Nicolas Robidoux Universite Laurentienne/Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
David Gowers writes: ... It is certainly possible. As Sven pointed out, we should probably first address the craziness of using interpolation routines (linear, cubic, lanczos) for downscaling. Do we even need to offer a choice of algorithym for downscaling (Box filter of appropriate size should be ok, except for None, which should be obvious.)? This is tricky because the user can downscale and upscale in one pass (eg. 150% scale on x axis, 80% on the y axis) In my opinion, here is the best way to handle this: The driver (GUI) could catch that there is a enlarge in one direction, shrink in the other, first do the enlargement with the user's selected method (keeping the other dimension fixed), then do the reduction with box filtering (keeping the other dimension fixed. It is important to perform the upsampling before the downsampling. - Alternative: The GUI could have TWO sets of choices: Upscaling method: None, linear, cubic, lanczos Downsampling method: None, linear, box (say) with only one toggle being taken into account when the same type of operation is applied in both directions (of course). Nicolas Robidoux Universite Laurentienne/Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scaling in Gimp 2.6 is much slower than in Gimp 2.4
Claus: You wrote: I don't want to say much about what type of interpolation is good for what and when, since I don't have the knowledge that for. But 2 things I'd like to comment: 1.) No more interpolation Options? David Gowers mentioned: Do we even need to offer a choice of algorithym for downscaling (Box filter of appropriate size should be ok, except for None, which should be obvious.)? I can hardly imagine not to have the choice of interpolation for downscaling. Different interpolations give different results, and sometimes you want it a bit crisper, sometimes a bit softer... 2.) Interpolation options separately for Up- and Down-Scaling? Nicolas Robidoux said, that as an alternative [to a smarter algorithm], he could imagine separate GUI Options for Up- and Down-Scaling. I think, most user will think upon that: It's a joke, isn't it? ;-) For the record: I was being totally serious. The users who happen to know that there is no simple method which does really well for both (drastic) upsampling and (drastic) downsampling may be happy to see that different methods are used for the two different cases. To reiterate: Once methods good for downsampling (like box) and upsampling (like bicubic and lanczos) are implemented, either: We make the choice for the users of which method is used (ideally using two different methods something different is done in different directions, for example, bicubic in the enlargement direction(s) and box in the shrinking direction(s) if the user chose bicubic), which more or less is what David suggested; or We choose defaults for them but make it visible that we use different methods in different directions, allowing them to modify the default choices, which is my suggestion. Implementation note: If two different methods are used, do the upsampling with the better for enlargements method first (unless you can do them both at once, but this is quite challenging programming wise). This approach is slower, but will give better results. nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Updated code for gegl-sampler-yafr
Hello all: I submitted what is probably the last yafr patch for a while. (Unless I figure out how to use Geert's patch to do more careful boundary conditions and compute pixel values past the abyss boundary, which is documented through a #define in the code.) I really believe that this is without question the best overall (interpolatory) sampler currently running under gegl (and ImageMagick for this matter). Give it a try. The scheme is quite different from the one currently in the svn, which had an early diagonal version (the current version uses horizontal and vertical differences). You can find the patch file at http://bugzilla.gnome.org/show_bug.cgi?id=552159 There are suggestions in the source code to test it and compare it to the other schemes from the gegl command. You may also find a replacement gegl/gegl/docs/gallery at the following location, which uses, with permission to use for research purposes, the great test images shown of http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm The alternative gallery.tgz, which you untar then recompile if you replace the current one with it, is found here: http://web.cs.laurentian.ca/robidoux/misc/ It will produce a web page at that location which includes timings as well as clickable thumbnails (just like the original gallery did). To the main developers: Thank you for your patience, and apologies the high bandwidth. Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Updated code for gegl-sampler-yafr
Apologies: The yafr email was meant for the gegl-developer list. Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] using C99/gcc built-in math intrinsics within GEGL on gfloats
CONTEXT: I have completely changed the gegl/buffer/gegl-sampler-yafr.c code. Before I put together the patch to the new yafr, I would like to see if I could make the code even faster by using C99/gcc built-in math intrinsics. I have not tried this yet. The method used by the updated code is different from the first generation yafr (at once softer and more pervasive; yes I know this is vague: what I mean is that the nonlinear correction is on throughout more of the image, but that its effect is never as extreme). The code also runs even faster than before: on my current vintage laptop, yafr scales up about 10% slower than gegl-sampler-linear, and about 10% faster than gegl-sampler-cubic. Regarding further speed-up: Using abs, fmin and copysign I could make my code branch-free (assuming of course that these operations are translated to assembly built-ins by the compiler on the machine on which the code is compiled). That is: the code, which right now contains no if, no for, no do and no while, would now contain no ?. I suspect that using arithmetic branching could make my code run noticeably faster. - QUESTION: - I noticed that fabs, fmin and copysign, or similar C99/gcc built-ins, are not found anywhere in the gegl source. Is there a preferred/tolerated way of using such math functions in gegl? Can I assume that gfloats are floats? Can I assume that gdoubles are doubles? Must I program with the possibility that gfloats be doubles? Must I program with the possibility that gdoubles be floats? Could gfloats or gdoubles be anything else than floats or doubles? Some ideas: Idea 0: It may be that I can use the type-generic fabs, fmin and copysign on gfloats without a speed hit. Hopefully, gcc can use the correct one based on the fact that it acts on gfloats. If not, it may be that using the double versions on gfloats is still faster than the alternatives. Idea 1: If I KNEW for a fact that gfloat = float, I could simply use fabsf, fminf, and copysignf. Idea 2: I could do the necessary parts of the computation with doubles (or gdoubles) and then use the double versions. Hopefully, this will not slow down gegl when run on hardware which is faster on floats than doubles (like some GPUs). Idea 3: Is there a smarter way, which picks the right one? Idea 4: Change compilation flags to include C99 built-ins? Idea 5: You have another idea? Idea 6: Or should I just stick to C90 gcc built-ins? Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Typo in Re: patch for scale-region.c
Sven: Apologies: In my last email, For example, if one followed this strategy to downsample to 17x9 instead of 15x9, one would first box filter down to 32x9, then apply bilinear. It should surprise no one that this may produce a fairly different picture. should have been For example, if one followed this strategy to downsample to 17x9 instead of 15x9, one would first box filter down to 32x16, then apply bilinear. It should surprise no one that this may produce a fairly different picture. Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
Hello Sven: ... To see this, create a new image, apply a standard grid on it using Filter-Render-Patterns-Grid and scale it down in one direction by a scale factor smaller than 0.5. The one pixel wide grid lines will become blurry. I don't think this is acceptable and so far the only choice we have is to apply either gimp-decimate.diff or gimp-decimate-2.diff... A cartoon of what I understand about downsampling, which may be useful when people debate the various merits of downsampling methods: There are two extremes in what most people expect from downsampling. What they expect basically depends on what the downsampling is applied to: --- Old school CG type images (e.g., Super Mario or the old Wilbur, the Gimp mascot). Then, nearest neighbour (and analogous methods) will, in most situation, do better than box filtering (and most LINEAR interpolatory methods). The reason is that the picture is made up of flat colour areas with sharp boundaries, and anything (linear) which deviates a lot from nearest neighbour will not preserve the property of begin made up of flat colour areas separated by sharp lines. For most people, blur, in this context, is more annoying than aliasing. --- Digital photographs, in which the image is usually made up of smooth colour areas with blurry boundaries, and in addition, there is noise and demosaicing artifacts. Then, in general, nearest neighbour is not acceptable, because it amplifies the noise (which is not present in CG images) and aliasing is more visually jarring than blur. In this situation, box filtering (especially its exact area variant) and analogous methods will, in most situations, do better than nearest neighbour. Consequence: Linear methods cannot make both groups of people happy. Making most people happy will require TWO (linear) downsampling methods. Alternatively, it will require having a parameter (called blur?) which, when equal 0, gives a method which is close to nearest neighbour, and when equal to 1, gives a method which is close to box filtering. I can help with this. --- Another important point which was raised is that if the image is enlarged in one direction and reduced in the other, one single method is unlikely to do well. Within the GEGL approach, it may be that such situations are better handled by upsampling first (using a good upsample method) in the upsampling direction, then feeding the result to the downsampler in the downsampling direction. That is: Don't expect one single method/plug-in to do both. In summary: To stretch in one direction and shrink in the other, first do a one direction stretch, followed by a one direction shrink. --- Also, in previous emails about this, I saw the following valid point being made: Suppose that the following strategy is followed for downsampling. To make things more explicit, I'll use specific numbers. Suppose that we want to downsample an image from dimensions 128x64 to 15x9 (original pixel dimensions are powers of two for the sake of simplicity). First, box filter down (by powers of two, a different number of times in each direction) to 16x16, then use a standard resampling method (bilinear, say) to downsample to 15x9. The point that was made was that doing things this way is not continuous, meaning that scaling factors which are almost the same will not give images which are almost the same. For example, if one followed this strategy to downsample to 17x9 instead of 15x9, one would first box filter down to 32x9, then apply bilinear. It should surprise no one that this may produce a fairly different picture. The point I want to make about this is that it is possible to fix this discontinuous behavior, as follows. Produce TWO box filtered down images. In the case of downsampling from 128x64 to 15x9, the two downsamples would be of dimensions 16x16 and 8x8. Then, downsample the 16x16 to 15x9 using, say, bilinear, and upsample the 8x8 to 15x9 using, again, bilinear, making sure that the sampling keeps the alignment of the images (I know how to do this: it is not hard). Then, blend the two images as follows: Let Theta = ((15-8)/(16-8)+(9-8)/(16-8))/2. Final image = Theta * downsample + (1-Theta) * upsample. If you think about what this does, you will realize that this satisfies the criterion that nearby downsampling factors give nearby images. (WARNING: nearest neighbour is discontinuous, so the nearby images can actually be quite different. But they will be less different than with standard nearest neighbour.) If someone wants to implement the above, I can help. - I hope someone finds the above useful when thinking about the downsampling issue. With regards, Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Regarding GEGL Bug 550569 – Su ggested replacement for Lanczos, and possibly cubic: Yet An other Fast Resampler
http://bugzilla.gnome.org/show_bug.cgi?id=550569 includes gegl C code and pointers to image enlargement test code and results for a high quality (non linear) image resampling code (Yet Another Fast Resampler). The first post contained slightly non-optimized code, the second, faster code with a bug. For this reason, use the code found in Comment #3. Main features: The new method is quite flexible: It has two parameters, like cubic splines, which I call smooth and straighten but which I think I may rename smooth and antialias (the first one primarily has to do with subpixel smoothing, the second, smoothing at a scale comparable to the distance between pixels. On the basis of limited testing on a processed digital photograph and a text like image, it appears that with the theoretically optimal values of the parameters (one of which has to be computed more precicely: complex integrals are involved in the exact computation) give excellent results. These approximate optimal values are smooth = .85 and straighten = 14.27; see the corresponding results for these values first. When substituted for the gegl-sampler-cubic.c code, scale (run from xml) runs a smidgen faster than the stock gegl cubic, and 10-15% slower than stock gegl bilinear. When smooth = 0 and straighten = 1, the method is co-convex (does not introduce kinks). When smooth = 0 and straighten = 2, the method is monotone (does not introduce halos). Monotonicity is a very good thing for the transparency channel. Although these properties do not hold when smooth is not zero, for small values of smooth they may as well hold. Note however that my optimal (strongly nonlinear) values of smooth and straighten are quite far from the no halo values. Even then, the scheme does not smooth as much as Lanczos, but introduces much less halo, and has a much crisper look in general. Comments, inquiries etc welcome. Nicolas Robidoux Laurentian University/University Laurentienne. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gegl resize script, anyone?
Hello all: Maybe I am stupid, but I have looked all over the web for a code snippet/script/howto which would be easy to adapt to allow me take an image (any standard format) as input and resizing it using, say, the gegl cubic sampler, and saving the output image in some generally readable format. I understand that gegl is not meant to be particularly script friendly, but not finding anything on the web (the examples found on the gegl web site are helpful, but not enough) is quite surprising to me. Any pointer? (What I want to do: replace the innards of the gegl cubic resampler with something the code for the simplest coconvex resampler, recompile, and see if I like the results. I have already written the suitable coconvex resampler code based on the current gegl cubic resampler one.) I am finding getting gegl to do what I want much harder than understanding its source code! nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] possble replacement(s) for Gimp Lanczos
Hello Sven and Oyvind: Have you already added the plug-ins to the GIMP plug-in registry? I will when I have rewritten the code to my satisfaction. The current versions are perfectly useable (and bug free), but I'd rather release the final versions right of the bat. At this point we are concentrating on porting more and more of the GIMP core to GEGL. It is unlikely that I will port EANBQH and IBFNBQH to GEGL, because programming them so that they can be used analogously to bilinear, bicubic and lanczos is a substancial programming project. I have looked around the GEGL code, and it is very likely that I will program a novel co-convex resampling scheme following the lanczos model found there. This will take a while. One good thing about the co-convex scheme is that the results are not overly affected by what I understand is the current GEGL abyss policy (set pixel values outside of the physical extent of the image to 0): only if the sampling point is outside of the rectangle defined by the boundary pixels will the value be negatively affected. Quick comment: If the default GEGL abyss policy was smear, this would have the following general consequence: Any linear method/filter (blur, resampling...) which is exact on constant intensity data will still be exact on constant intensity data without special handling within the filter. This does not mean that the results are the same as if the filter carefully handles the boundary, just that the dirty hack of using ghost values and then implementing the filter in a boundary independent way will not give absurd results. This has two consequences: Implementing filters can be done in two passes: first, ignore boundary issues; build in boundary handling into the filter, using the x, y, width and height information to determine the position relative to the boundary and perform appropriate branching. If speed/more compact code is desired, ignore boundary branching, confident that the results are still reasonable. This being said, changing to smear will not make the results with the co-monotone method any different, which is why I don't particularly care. The co-monotone method is not linear. I suspect that for some filters it is impossible to define an abyss policy which is equivalent to careful handling of the boundary within the filter. The ImageMagick trick of masking and normalizing the coefficients is another way of getting reasonable results (and preserving the exact on constants property), but again it only approximates careful boundary handling for most schemes. If I was to choose, I'd rather (approximately) fix things with a smear abyss policy (even though, in the particular case of my next pet scheme, it makes no difference). Thank you all for your comments, Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] possble replacement(s) for Gimp Lanczos
Someone kindly pointed out that the subject line of my last email made it likely to be caught by a filter. In case you missed it: http://web.cs.laurentian.ca/robidoux/misc/ contains the tarred and gzipped folder gimptests.tgz which contains code for four suggested plug-ins which implement possible replacements for Lanczos. The README file gives details. - Of the four, IBFNBQH (a brand new method analogous to global cubic splines, but with a slightly different variational principle and boundary conditions) is the most likely candidate to replace Lanczos. If you look at the kingfisher enlargements, you will notice that Lanczos, as currently implemented in the Gimp, produces artifacts in the top row. None of the plug-ins have such artifacts. Actually, they have been tested inside and out, qualitatively and quantitatively, on a variety of images, and are almost certainly free of bugs. Because the top row is cropped out of the enlargement of the other image, this artifact is not visible. In addition, although this is of course a matter of taste, I prefer the crispness of IBFNBQH (and EANBQH) to the slight blurriness of Lanczos. -- At this point, the plug-ins only enlarge. I imagine that in order for, say, IBFNBQH to replace Lanczos, it would have to be fixed so it can resize to arbitrary dimensions. I should be able to do this in a reasonable amount of time. David Gowers has suggested using LittleCMS (or GeGL) to linearize colour profiles during the computation. In our experience, our plug-ins produce good results when used in a gamma OBLIVIOUS way. This being said, back of the envelope computations suggest that light haloing is likely to decrease if the colour profile is properly taken into account (because sRGB has a linear component near black, dark haloing is probably not going to change much for such images; again, this is from a very rough back of the envelope reasoning). Given that GeGL will perform all the heavy lifting for the Gimp in the future, I am not sure that fixing the gamma correction at this point is really something I want to do. However, I will try to integrate profile information in the profile if it is felt that it is important. The current gamma versions of the plug-ins use naive gamma correction (and do not take into account the linear piece of sRGB). David's plan is a much better one. Let me know what you think. Nicolas Robidoux Laurentian University/Universite Laurentienne [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] possible lanczos replacement
Hello David: I notice the 'Gamma' versions of these enlargers introduce haloing around some edges, while the non-gamma versions do not (or it's too little to see). A naive conversion may be the cause of this difference. If you could utilize the profile attached to the image, and generate or load a linear one, you could use LittleCMS to do the conversion in an assuredly correct way. The main weaknesses of our methods are: --haloing (but they have less haloing than Lanczos) --aliasing (but IBFNBQH shows less, although still more than Lanczos, which is more blurry) --memory usage (an temporary int16 copy of the input image has to be created) Although I have hunches, I still do not understand perfectly how icc profiles affect enlargement artifacts. (This being said, a monotone method, like nearest neighbour, bilinear or non-interpolatory B-splines, should not be affected much by gamma obliviousness; bicubic, Lanczos, EANBQH and IBFNBQH are NOT monotone.) This is something I'll have to experiment with. Thank you for your comments, Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] proposed new enlargement methods
http://web.cs.laurentian.ca/robidoux/misc/ contains an add-on to the test http://svenfoo.org/scaletest/133-9.html done using three (preliminary versions) of image enlargement plug-ins, also included. See the README (in morescaletest.tar.gz) for slightly more details. Nicolas Robidoux Dept of Math and CS Laurentian University PS I am on holiday: Please be patient with responses and bug fixes. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] bug #464466: lanczos corner artifacts
Hello: This is not directly related to the bug, although the following provides a possible alternative to fixing the corner pixel proglems of the existing lanczos... A student of mine and I have put together a gimp plug-in which ENLARGES images using a method which is analogous to global cubic splines, that is, which gives results analogous to lanczos. The plug-in should be ready for distribution in about 1 month. Features: --two related methods can be used: the first one---exact area natural biquadratic histosplines---uses the center image size convention (like gimp and imagemagick), the other---interpolatory box filtered natural biquadratic histosplines, which is almost the same as natural cubic splines---the corner image size convention (like most image enlargement programs) --the first method is strongly sharpening, the second, less so. Both give very smooth images. --the user can specify the gamma of the input image, and the gamma of the output image. The default is 2.2 for both. --the plug-ins are fast: we are not quite done optimizing the code, but as it stands, they produce large enlargements of large images faster than the gimp built-in bicubic, and slower than the gimp buil-in bilinear. --the drawback of both methods is that they are fairly memory intensive: we have several versions around, but the most likely candidates for release requires the creation of a temporary int16 or float array with as many entries as the input image. On the plus side, we use a moderate size tile cache: gimp_tile_cache_ntiles (((nnm) ? nn : m) / gimp_tile_width () + 1); where nn is the width, in pixels of the output (enlarged) image, and m is the height, in pixels, of the input (to be enlarged) image. We would be quite happy to integrate the plug-in into the built-in gimp image resize functionality (some assistance would make this happen faster: we don't quite know how to interact directly with the gimp core). Nicolas Robidoux, Department of Mathematics and Computer Science, Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
