Re: [Gimp-developer] GSoC 2011 Porting GIMP plugins to GEGL operations
On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman m...@banu.com wrote: Hi Sourav On Tue, Mar 29, 2011 at 12:36:04AM +0530, sourav de wrote: Hi, I am a 2nd year student of the department of Computer Science and Engineering at Indian Institute of Technology, Kharagpur ,and I am interested in the plugin for cartoonization of an image in GIMP. I gather you want to modify the cartoon plug-in in GIMP? The plug-in porting task that you have mentioned in the subject is to directly port GIMP plug-ins to GEGL ops. No modification of functionality is necessary. It is described here: http://gimp-wiki.who.ee/index.php?title=Hacking:GSoC_2011/Ideas#Porting_GIMP_plugins_to_GEGL_operations It is not a task of porting only 1 plug-in, but about 6-10 plug-ins per student. 1 plug-in is a very easy task and will not be sufficiently long for a full summer's work. To apply for this task, please present the items mentioned on the linked wiki page. However, if you wish to modify the cartoon plug-in, that sounds interesting too. It can be a different task. Can you describe what is lacking in the current approach in the GIMP plug-in? What is the algorithm that you plan to use ? You say you are doing a project on algorithmic art.. have you published anything on the methods you wish to use in this cartoon plug-in? Are you using any other published works? Note that we _may_ accomodate more tasks if they are of a high quality and we are satisfied with how the student presents it. Mukund Thank you sir, for your comments, I'll come up with the presentation of those plug-ins mentioned in the wiki page and algorithm for the cartoonization plug-in soon. And for the project on algorithmic art, I took this project in my current semester, I'll have to take the course Computer Graphics in my next semester to complete the project. So far I haven't yet publish any paper. -- Sourav De 2nd Year Student Department of Computer Science and Engineering IIT KHARAGPUR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC Introduction
Hi, I am a 3rd year engineering student at Netaji Subhas Institute of Technology,New Delhi. Although i am not a Computer Science student, my interests lie in programming especially in the field of UI development. So far i hv contributed some code for the Paint Activity in the Sugar Desktop Environment for OLPC. This has given my some idea of working of a GTK/GDK drawing Application.I hv implemented the patches for the invert color functionality and aspect ratio mode for selection tool using a constraint key among some other work for the Paint Activity. https://dev.laptop.org/attachment/ticket/3705/0001-Fixed-aspect-ratio-mode-for-Shape-tools-OLPC-3705.patch http://dev.laptop.org/attachment/ticket/2495/0001-Added-Invert-Color-Effect-to-Paint-Activity-OLPC-249.patch i can code both in C and Python. i want to implement the Unified Transformation Tool for GIMP by participating in GSoC .I hv gone through the specification of project. I think its a cool idea and i can picture it how it will work as mentioned in the specs. I hv compiled the git and will be looking for some easy bugs to fix to get started. If anyone can point me where to start off, it would be a great help.I have already started learning GTK+ in depth. Regards, Ayush ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Hello, no organized meeting log this time, for various reasons, however I'm attaching below the list of decided actions in the meeting, along with some other off-topic points that were discussed: ** GSoC Student Applications ** Core developers sign up as mentors (for GSoC) schumaml: Write mail about application is open, and required skills, and required code example ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). For UI, porting widgets to GtkBuilder is an option (and then we'll use Glade and UI xml files), but any action on the UI is postponed until we get 3.0 out! ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. ** bringing UI crew to LGM ** Will be discussed with mitch and schumaml on the financial aspect (using gimp funds) when the team is fully assembled (parts of it are already assembled - hurray for guiguru and congrats for the new team memebers!) ** Resource management for 2.8 ** One member of the new UI team (lead by guiguru) will take care of that ** Offtopic ** Seems as if most GIMP team can't attend LGM this year, but there may be a GIMP village in the Chaos Communication Camp (http://events.ccc.de/2010/08/10/chaos-communication-camp-2011/) as most developers want/plan to attend it. UI team members will start hanging on IRC once the team is assembled. Many developers suggested help in setting them up with build environments and every other thing they need. This will happen soon, so be nice to the new guys ;) ~LightningIsMyname ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/29 LightningIsMyName lightningismyn...@gmail.com: ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). Hi, Unfortunately I couldn't attend the meeting and affect the outcome of the discussion, but I still want to comment on it: GObject C boilerplate is a general productivity problem not bound to any specific kind of code, it doesn't make sense to treat core and UI code differently. Regarding code generators: that's basically how we will use Vala, I don't see why e.g. turbine would be better to use for this. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 2011-03-29 14:09, LightningIsMyName wrote: ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. So you set the quality slider to 95 to ensure files will be big, but set sampling to 2x1 to ensure the image quality will be poor? I don't see the sense in this. Also the JPEG export plug-in has had a stored default for years. What are you trying to add? Note that if the source file is JPEG the plug-in offers similar settings to the originating file by default. You can still click load defaults to override it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/29/2011 02:45 PM, Martin Nordholts wrote: 2011/3/29 LightningIsMyNamelightningismyn...@gmail.com: ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). Hi, Unfortunately I couldn't attend the meeting and affect the outcome of the discussion, but I still want to comment on it: GObject C boilerplate is a general productivity problem not bound to any specific kind of code, it doesn't make sense to treat core and UI code differently. Right, it doesn't make sense to make a difference here. And the summary doesn't quite reflect the result of the discussion. Regarding productivity: I don't know how you measure more productive on a scale from zero to zero. There is simply not much contribution currently, and blaming GObject for that is lame, and attempting a fix where you earlier put the blame is activism. As I said before, let's please work on our public interface, That maybe has the potential of attracting new developers. I already gave the reasons why I think adding another language won't. Regarding code generators: that's basically how we will use Vala, I don't see why e.g. turbine would be better to use for this. Turbine is a comfortable replacement for: - copy existing class with SameNumberOfWords - do s/OldName/NewName/ and s/old_name/new_name/ - remove junk - skeleton done Vala is a programming language and *not* a code generator. You also don't consider gcc a code generator because it has some internal representation in between C and machine code. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Question about colour
I did a little experiment last night, creating two rectangles, one of hue = 240, saturation = 90%, and value = 90%, the other differing only in saturation, = 50%, i.e., reducing saturation by 40%. Then, from the Hue/Lightness/Saturation dialogue, I increased the saturation of a selection in the less-saturated rectangle by 40, thinking the colours would then match. They don't. In fact, /no/ adjustment of saturation from that dialogue will make the colours match and, further, adjustment of the saturation also affects the colour value. Adjusting colours that differ only in value (which I assume is the same as what's called lightness in the H/L/S dialogue) yields similarly unexpected results: it was possible, using value adjustment alone, to adjust a colour with an HSV triplet of [240 90 50] to [240 90 90], but only by increasing Lightness by 61 rather than the expected 40 (or perhaps the at least somewhat intuitive 80, the percentage increase of 90 over 50). I confess I don't understand colour, but is my understanding even poorer than I thought? Or is this an area in which GIMP needs a bit of work? (The utterly prosaic background of this question is that my wife runs an eBay business for which I am the reluctant photographer. Frequently, I take multiple pictures of the same object, under the same lighting, differing sometimes only in the distance of the object from the light. The resultant colours in the photographs are frequently significantly different and I use GIMP to try to make them match. This is remarkably difficult to do and if I ever get the time I may undertake to write something for GIMP to make this easier.) (And I won't even comment on the near-impossibility of getting the image colours to perceptually match the in situ colours...) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about colour
I confess I don't understand colour, but is my understanding even poorer than I thought? Or is this an area in which GIMP needs a bit of work? I don't think HSV and HSL are the same colourspace: http://en.wikipedia.org/wiki/HSL_and_HSV Frequently, I take multiple pictures of the same object, under the same lighting, differing sometimes only in the distance of the object from the light. The resultant colours in the photographs are frequently significantly different and I use GIMP to try to make them match. This is remarkably difficult to do and if I ever get the time I may undertake to write something for GIMP to make this easier.) You can try my histogram match script: http://ffaat.pointclark.net/blog/archives/162-Gimp-Script-Histogram-Match.html -Rob A ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about colour
Hi Chris, On 29 March 2011 16:28, Chris Moller mol...@mollerware.com wrote: (The utterly prosaic background of this question is that my wife runs an eBay business for which I am the reluctant photographer. Frequently, I take multiple pictures of the same object, under the same lighting, differing sometimes only in the distance of the object from the light. The resultant colours in the photographs are frequently significantly different and I use GIMP to try to make them match. This is remarkably difficult to do and if I ever get the time I may undertake to write something for GIMP to make this easier.) (And I won't even comment on the near-impossibility of getting the image colours to perceptually match the in situ colours...) I've actually done some work on this. My package (only tangentially related to gimp) includes a colour calibration button, there's a description of the process on the website: http://www.vips.ecs.soton.ac.uk/index.php?title=Colour_calibration_with_nip2 The idea is that you take a photo including a colour standard (I use the Macbeth). Then select the chart in the photo and click calibrate to have it calculate a transform from your camera colour to sRGB. You can then use that transform to colour-correct other images. Macbeth have a mini macbeth now that has the same colour patches, but is a much more reasonable size. John ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 3/29/11, Michael Natterer wrote: As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. The wiki transition seems to be stuck as well. What exactly has to be done? The news is what I already take care of. What else has to be done apart from that? Alexandre Prokoudine http://libregraphicsworld.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 - GEGL: Make OpenGL branch use OpenCL
On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira victormath...@gmail.com wrote: Hello everyone. My name is Victor Oliveira. I'm a master's student at the School of Electrical and Computer Engineering - University of Campinas, Brazil. I work with Image Processing and Machine Learning and I've been using GPUs (CUDA) in my work since 2009. More recently, we've migrated our projects to OpenCL, which has given me more experience with GPU programming. I have a strong background in C/C++ and Python. Also, I've been using GEGL for some time in my projects. I noticed a while ago that there is a branch [http://git.gnome.org/browse/gegl/tree?h=gsoc2009-gpu] that wasn't merged in GEGL's main tree. If I understood it correctly, this specific branch is able to do pixelwise operations using OpenGL shaders and automatic memory management beetween the cpu and gpu. My idea is to use this memory management scheme to allow gegl operations with OpenCL. I've already presented this idea in #gegl without further details and I'd like to discuss it here. If moving to OpenCL, (and if OpenCL needs separately managed memory; which I think it does) basing it on the existing unmerged GPU branch would be the best plan moving forward. The general gist of the work that was done in the previous gsoc was to extend GeglBuffer with the ability to have a separate, internal backend/cache of gpu side tiles, that have their own revision; when tiles are requested either on the gpu or cpu side, migration is done automatically to ensure that the newest version is used. This management scheme was succesfully implemented for GLSL based shaders and proof of concept implementations of some point operations were done. Repeating the things that were done in this gsoc for OpenCL should not take as long as it did for the original GPU branch since a lot of the issues would already be solved. If core color correction, compositing ops and gaussian blur have vfuncs for GPU side processing; many simpler compositions would be possible to do fully on the GPU - while compositions with some cpu based ops would do the migration back and forth as needed (with incurred performance impact). Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). One thing that could be interesting to do is to make it possible to turn on a runtime flag that tests the OpenCL paths against the cpu paths when running GEGLs test suite, thus ensuring that the results are really interchangeable. The first step would be adapting the existing code and re-implementing the pixelwise operations in OpenCL. Meanwhile, we have to remember that OpenCL can be compiled to run in the cpu also, so we don't need to make memory transfers in this case. I do not know enough details about OpenCL and its data buffers to asses how this best would be done. Though it would be interesting to see how the code generated compares with the existing cpu code; if fully free software toolchains for OpenCL (perhaps using LLVM) emerges, it could be interesting to use OpenCL as the officially encouraged way of implementing GEGL ops. /Øyvind K - GEGL maintainer -- «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] GIMP Developer Meeting #3 - March 28, 2011
On 03/29/2011 06:54 PM, Alexandre Prokoudine wrote: On 3/29/11, Michael Natterer wrote: As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) - Website updates - News - Wiki - Blogs - Maybe we should have a GIMP blog aggregator? - More frequent developer releases (my fault, I know) The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. I think Jimmac is pretty busy, so maybe somebody should pick up the work. Also, I don't think we absolutely need a new website, just a few people who can trigger website updates after something has been pushed to git, at least as long as auto-updates are broken. I'll poke Sven about that. The wiki transition seems to be stuck as well. What exactly has to be done? I'm in contact with Shawn, and the DNS entry should point to Alexia's wiki soon. The news is what I already take care of. That much appreciated :) What else has to be done apart from that? Whatever people are capable and wanting to do :) Everybody involved with the project is invited to join the effort. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 3/29/11, Michael Natterer wrote: On 03/29/2011 06:54 PM, Alexandre Prokoudine wrote: On 3/29/11, Michael Natterer wrote: As I said before, let's please work on our public interface Let's try to outline what exactly needs doing, eh? :) - Website updates I think I could add recent books, including the one from Packt. - News - Wiki Discussed above and below - Blogs - Maybe we should have a GIMP blog aggregator? We used to have layers.gimp.org exactly for that, but it's gone. I think we can reuse infrastructure from graphicsplanet.org that Mukund and me maintain. Any suggestions on URL? Maybe simply blogs.gimp.org? - More frequent developer releases (my fault, I know) Since you insist :D The new website is stuck in the middle mostly because AFAIK Jimmac was busy all the time with GNOME 3 which is finally soon to be out, so maybe Jakub will have more spare time to finish this now. I think Jimmac is pretty busy, so maybe somebody should pick up the work. Also, I don't think we absolutely need a new website, just a few people who can trigger website updates after something has been pushed to git, at least as long as auto-updates are broken. I'll poke Sven about that. Can't this be automated? The wiki transition seems to be stuck as well. What exactly has to be done? I'm in contact with Shawn, and the DNS entry should point to Alexia's wiki soon. Cool Alexandre Prokoudine http://libregraphicsworld.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 - GEGL: Make OpenGL branch use OpenCL
On Tue, Mar 29, 2011 at 2:36 PM, Øyvind Kolås pip...@gimp.org wrote: On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira victormath...@gmail.com wrote: Hello everyone. My name is Victor Oliveira. I'm a master's student at the School of Electrical and Computer Engineering - University of Campinas, Brazil. I work with Image Processing and Machine Learning and I've been using GPUs (CUDA) in my work since 2009. More recently, we've migrated our projects to OpenCL, which has given me more experience with GPU programming. I have a strong background in C/C++ and Python. Also, I've been using GEGL for some time in my projects. I noticed a while ago that there is a branch [http://git.gnome.org/browse/gegl/tree?h=gsoc2009-gpu] that wasn't merged in GEGL's main tree. If I understood it correctly, this specific branch is able to do pixelwise operations using OpenGL shaders and automatic memory management beetween the cpu and gpu. My idea is to use this memory management scheme to allow gegl operations with OpenCL. I've already presented this idea in #gegl without further details and I'd like to discuss it here. If moving to OpenCL, (and if OpenCL needs separately managed memory; which I think it does) basing it on the existing unmerged GPU branch would be the best plan moving forward. The general gist of the work that was done in the previous gsoc was to extend GeglBuffer with the ability to have a separate, internal backend/cache of gpu side tiles, that have their own revision; when tiles are requested either on the gpu or cpu side, migration is done automatically to ensure that the newest version is used. This management scheme was succesfully implemented for GLSL based shaders and proof of concept implementations of some point operations were done. Repeating the things that were done in this gsoc for OpenCL should not take as long as it did for the original GPU branch since a lot of the issues would already be solved. If core color correction, compositing ops and gaussian blur have vfuncs for GPU side processing; many simpler compositions would be possible to do fully on the GPU - while compositions with some cpu based ops would do the migration back and forth as needed (with incurred performance impact). Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). One thing that could be interesting to do is to make it possible to turn on a runtime flag that tests the OpenCL paths against the cpu paths when running GEGLs test suite, thus ensuring that the results are really interchangeable. Maybe we can also use this to benchmark plug-ins and see if the speedup of using OpenCL is greater than the overhead during buffer migrations. The first step would be adapting the existing code and re-implementing the pixelwise operations in OpenCL. Meanwhile, we have to remember that OpenCL can be compiled to run in the cpu also, so we don't need to make memory transfers in this case. I do not know enough details about OpenCL and its data buffers to asses how this best would be done. Though it would be interesting to see how the code generated compares with the existing cpu code; if fully free software toolchains for OpenCL (perhaps using LLVM) emerges, it could be interesting to use OpenCL as the officially encouraged way of implementing GEGL ops. This is a nice topic. A (sufficient smart :) compiler probably is able to generate optimized code for OpenCL in an easier way than C. OpenCL language is naturally data-parallel, which allows vector instructions, for example. So what are the next steps then? Do i have to write a more formal proposal? /Øyvind K - GEGL maintainer -- «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
On Tue, Mar 29, 2011 at 1:15 PM, sourav de souravde1...@gmail.com wrote: On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman m...@banu.com wrote: Hi Sourav On Tue, Mar 29, 2011 at 12:36:04AM +0530, sourav de wrote: Hi, I am a 2nd year student of the department of Computer Science and Engineering at Indian Institute of Technology, Kharagpur ,and I am interested in the plugin for cartoonization of an image in GIMP. I gather you want to modify the cartoon plug-in in GIMP? The plug-in porting task that you have mentioned in the subject is to directly port GIMP plug-ins to GEGL ops. No modification of functionality is necessary. It is described here: http://gimp-wiki.who.ee/index.php?title=Hacking:GSoC_2011/Ideas#Porting_GIMP_plugins_to_GEGL_operations It is not a task of porting only 1 plug-in, but about 6-10 plug-ins per student. 1 plug-in is a very easy task and will not be sufficiently long for a full summer's work. To apply for this task, please present the items mentioned on the linked wiki page. However, if you wish to modify the cartoon plug-in, that sounds interesting too. It can be a different task. Can you describe what is lacking in the current approach in the GIMP plug-in? What is the algorithm that you plan to use ? You say you are doing a project on algorithmic art.. have you published anything on the methods you wish to use in this cartoon plug-in? Are you using any other published works? Note that we _may_ accomodate more tasks if they are of a high quality and we are satisfied with how the student presents it. Mukund Thank you sir, for your comments, I'll come up with the presentation of those plug-ins mentioned in the wiki page and algorithm for the cartoonization plug-in soon. And for the project on algorithmic art, I took this project in my current semester, I'll have to take the course Computer Graphics in my next semester to complete the project. So far I haven't yet publish any paper. -- Sourav De 2nd Year Student Department of Computer Science and Engineering IIT KHARAGPUR I wrote the code review for gaussian blur as it given here http://git.gnome.org/browse/gegl/tree/operations/common/gaussian-blur.c But I'm not familiar with writing code review and algorithmic description. Here goes my code review. ---code review starts here Gaussian blur operation code review: 1. function-1 : static void iir_young_find_constants (gfloat sigma,gdouble *B,gdouble *b) a. the variable sigma is to avoid unexpected ringing at tile boundaries of an image. b. there exists a variable q, whose value must be remained in between 0 - 1.5, and according to the value of sigma there are two procedures to calculate the value of q. c. lastly it sets the value of the variables b[0] to b[3] and B, and then returns. 2. function-2 : static inline void iir_young_blur_1D (gfloat * buf,gint offset,gint delta_offset,gdouble B,gdouble *b,gfloat * w,gint w_len) a. this function blurrifies an image one dimensionally. b. wlen is the length of the 1d array w passed. c. here an image would be blurrified in two steps, applying forward and backward filter for each pixel, a local variable wcount counts the number of pixels each time. d. the filter would be applied to the image according to the passed array w. 3. function-3 : static void iir_young_hor_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect,gdouble B,gdouble *b) a. this function blurrifies an image horizontally. b. first it creates an one dimensional array buf whose length is height*width*4, where height and width is height and width of the source image rectangle. c. then it creates another one dimensional array w with the length of the width of the source image. d. after then it fills the values of buf array according to the source image in RaGaBaA format. e. then it applies the iir_young_blur_1D function to the newly generated ractangles. f. lastly it stores the change in a destination array and returns. 4. function-4 : static void iir_young_ver_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect,gdouble B, gdouble *b) a. this function blurrifies an image vertically. b. first it creates an one dimensional array buf whose length is height*width*4, where height and width is height and width of the source image rectangle. c. then it creates another one dimensional array w with the length of the height of the source image. d. after then it fills the values of buf array according to the source image in RaGaBaA format. e. then it applies the iir_young_blur_1D function to the newly generated ractangles. f. lastly it stores the change in a destination array and returns. 5. function-5 : static gint fir_calc_convolve_matrix_length (gdouble sigma) a. depending upon the value of sigma it returns an integer which partially determines the width and height of the
[Gimp-developer] GSOC 2011 - EXIF data viewer and editor
Hi, I'm Noremac. I'm currently a CS grad student at BYU working in the image processing lab here on campus. My thesis is going to be focused on extracting information (OCR) from non-document images. I worked in the corporate world for a few years before coming back to get my masters. I've been wanting to get involved with GIMP and this seems to be a good time to do it. For my project I propose creating an EXIF/xmp viewer/editor. I feel that this would be very beneficial as I once struggled to find something such as the geotagging information. All I have now is a command line program (exif) or a library to get the info in code (libexif). An easy interface integrated into an image editing application makes sense. This information is becoming much more common as well due to the increasing popularity of mobile devices with cameras. The current solutions I've found are not intuitive and really not available to the common user. I am very interested in feedback on this since I'm coming in new to GIMP. Of course, I'm also interested in a mentor. I originally had been considering proposing a project in regards to computer vision (along the lines of my thesis). If the previous proposal falls though I wish to propose a project for a GEGL plugin to extract text from an image. Thoughts on this? Thanks, Noremac ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 2011-03-29 14:09, LightningIsMyName wrote: ** Default JPEG Quality (quickie, not a real topic) ** Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is not something that will happen for 2.8. So you set the quality slider to 95 to ensure files will be big, but set sampling to 2x1 to ensure the image quality will be poor? I don't see the sense in this. Also the JPEG export plug-in has had a stored default for years. What are you trying to add? Note that if the source file is JPEG the plug-in offers similar settings to the originating file by default. You can still click load defaults to override it. I did a couple of quick tests with an image with photos and design elements (type and areas with solid fill) and I got better results both in overall quality and file size using 1x1 and smaller quality factors than using worse subsampling and higher quality factors. In my test the best relationship between quality and filesize was using quality=92, subsampling=1x1 and floating point for the DCT method. The resulting file was smaller than the ones I exported with quality set in 95 and 2x1 or 2x2 for subsampling. with 1x1 subsampling and quality set in 90 the edge artifacts in type and solid fill areas became visible but the edges were sharp as in the original. The photo didn't show any noticeable compression artifacts. That's completely different with 2x1 and 2x2 subsamplings. All the edges became softer and when the quality factor is high enough to avoid compression artifacts the resulting file is larger than when 1x1 was used. So I'd suggest a different default quality setting for jpg: 92 / 1x1 / floating point. If file size matters (the size gain isn't too significative, but still), a quality factor of 90 will still give considerably better quality than the current defaults. and add a hack to save defaults (using something like the PNG plugin does, or something more elegant) I don't understand what's missing in the current implementation. I could change my defaults and store the new configuration as default through the advanced options of the jpeg export plugin (in 2.6.x) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC 2011 - EXIF data viewer and editor
On 3/30/11, Cameron Christiansen wrote: For my project I propose creating an EXIF/xmp viewer/editor. http://git.gnome.org/browse/gimp/tree/plug-ins/metadata/ Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On 3/29/11, Øyvind Kolås wrote: Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). As much as I like OpenCL, this part of implementation is going to be hairy, because to build an app that uses OpenCL one needs binary ATi drivers, binary NVidia drivers or Gallium 3D. Or you would have to keep a local copy of respective headers (or write your own ones). You can imagine the kind of fun that packagers will have. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
Hi! This is a question I haven't though. Well, I think your second option is feasible. OpenCL headers are freely (as in freedom) distributed in the khronos group page (http://www.khronos.org/registry/cl/). We just have to hope vendors follow this specification. Of course, we still need proprietary drivers (libOpenCL.so) in the runtime until there is an open-source implementation. But I don't know if this is a problem. bye! On Tue, Mar 29, 2011 at 6:33 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 3/29/11, Øyvind Kolås wrote: Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). As much as I like OpenCL, this part of implementation is going to be hairy, because to build an app that uses OpenCL one needs binary ATi drivers, binary NVidia drivers or Gallium 3D. Or you would have to keep a local copy of respective headers (or write your own ones). You can imagine the kind of fun that packagers will have. Alexandre Prokoudine http://libregraphicsworld.org ___ 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] gegl build fails
I've been having some problems building from git recently. Today I tried to figure out why. I use simple scripts to update the trees and then build them. BABL builds fine. GEGL fails here: make[3]: Entering directory `/home/mjhammel/src/graphics/gimp/git/gegl/gegl' CC gegl-c.lo CC gegl-config.lo CC gegl-cpuaccel.lo CC gegl-dot.lo CC gegl-dot-visitor.lo CC gegl-init.lo CC gegl-instrument.lo CC gegl-utils.lo CC gegl-lookup.lo CC gegl-xml.lo CC gegl-matrix.lo CCLD libgegl-0.1.la GISCAN Gegl-0.1.gir Couldn't find include 'Babl-0.1.gir' (search path: ['.', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0']) make[3]: *** [Gegl-0.1.gir] Error 1 The commands to build it were as follows: export LD_LIBRARY_PATH=/usr/local/gimpgit/lib:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=/usr/local/gimpgit/lib/pkgconfig/: $PKG_CONFIG_PATH ./autogen.sh -prefix=/usr/local/gimpgit make These are the same command used to build BABL. The missing file is in the proper place: mjhammel(tty6)$ find /usr/local/gimpgit -name Babl-0.1.gir /usr/local/gimpgit/share/gir-1.0/Babl-0.1.gir Am I missing something new related to building GEGL from git? Seems I'm not telling GEGL about the install dir correctly. Thanks. -- Michael J. Hammel mjham...@graphics-muse.org ___ 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 Tue, Mar 29, 2011 at 09:21:28PM -0600, Michael J. Hammel wrote: The commands to build it were as follows: export LD_LIBRARY_PATH=/usr/local/gimpgit/lib:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=/usr/local/gimpgit/lib/pkgconfig/: export XDG_DATA_DIRS=/usr/local/gimpgit/share/ Mukund pgpnZyIiZlnia.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
