Showing posts with label gimp. Show all posts
Showing posts with label gimp. Show all posts

Wednesday, March 12, 2014

Activity, Preparing to LGM 2014

*Shaking off the dust*

It's been quite a while since I last posted here. Some will smile at the sight of this post, especially those who know why I was absent (a state which should change until October this year).

Not too far ago, I was invited to the Libre Graphics Meeting of 2014; one of the largest (if not the largest) annual gatherings of users and developers of Open-Source tools and programs for graphics. After having to turn down the invitation once or twice before due to problematic dates, this year I managed to arrange a "vacation" in the relevant dates and I'll actually be going!

Yesterday I finished all of the arrangements (including setting up ubuntu dual-boot on my laptop, which turned out to be way easier than I thought), and I can start thinking about LGM itself. It's going to be the first time I attend a real convention like this, and the fact that this first time is abroad and far from home does add it's share to my excitement :)

The program sounds very interesting and with a potential to cover many topics which I never had the chance to learn (such as color management and font design). Also meeting people whom I talked to by IRC in the last 4 years but never met in practice should be one of the greatest parts in LGM fromy my point of view.

So, before I depart, it's time for some thanks. The first of them is to the GIMP family - the people who always care, help and greet you with a smile after you were missing for some time. The second thank is to you - the (usually anonymous) supporters of GIMP; donations you make to GIMP, help also to reimbruse the traveling expenses to developer gatherings like LGM.

So, I'll see you there,
~ Barak

Wednesday, May 15, 2013

GIMP GSoC 2011 - Seamless Cloning Project - Technical Overview & Status

Recently, I was asked by email to help with the status of my GSoC (2011!) project. So before I say anything about that, let me explain a few things about my current situation.

For those of you who didn't figure it out already from the lack of activity on this website (and the lack of my activity on the web in general), due to my current real-life situation, I barely have any free time except for those few precious hours in the weekend in which I try to run my own life.

This means that my open-source activity went to a level which is not enough to do anything which requires long sessions (*cough* coding new stuff *cough*), and only translations of open source software are being kept in progress (very slowly, but they are being worked on and I'll commit them when I have enough material).

Now that I said that, and now that you know why I'm rather unresponsive by email/comments to this site, let us begin a technical overview of the project status. Note that this was originally written as an email, so I'll sometimes write as if I'm addressing someone specific in a conversation, and sometimes I talk in general (3rd person). Please ignore this inconsistency...

Technical Overview & Status

Proposal
Unfortunately, I failed to find the original proposal. However, you can find the proposal which I recorded in the GIMP wiki. The proposal is located here.

Papers
I'm listing them here, it will become clearer once you see the modules listing.

Modules
The project is divided into 3 main modules
  • A library for creating fine triangular meshes - poly2tri-c
    • The first part of this library is a C port of a library for creating Constrained Delaunay Triangulations, which are basically "nice" triangulations of existing outlines with/without holes.
      The original library is poly2tri, and the C port I wrote can be found in poly2tri-c's repository under the poly2tri-c/p2t folder
    • The second part of this library is an implementation of the Delaunay Terminator algorithm for what we call a Delaunay Refinement.
      • Delaunay Triangulations are triangulations which are considered "nice", meaning that most triangles are more or less of equal size, without too big or too small angles.
      • Delaunay refinement is the process of taking a Constrained Delaunay Triangulation (which is not exactly Delaunay due to constraints such as outline that must be respected) and refining it by inserting more and more points. The process terminates when the resulting triangulation is almost Delaunay.
      • The implementation of the algorithm above was made from scratch and in fact was the biggest part of the GSoC project (the assumption was that there was an existing open source library to do this. Apparently it wasn't so...)
      • My implementation can be found in poly2tri-c's repository under the poly2tri-c/refine folder
    • The third and final part of this library is an implementation of a triangular mesh render. The render basically takes a mesh created from the refinement process, a buffer to fill and a vertex-to-color function, and creates an image of the mesh in the specified resolution and size.
      • This is another implementation from zero, although quite trivial and could probably be made more efficient
      • The original article used OpenGL to do this rendering, resulting an ultra-fast renderer. Since the project was done when GIMP/GEGL were in an unclear state regarding usage of graphics hardware acceleration, it was done on the CPU purely which is much slower (yet still almost interactive - less than a second for rendering regular objects)
      • My implementation can be found in poly2tri-c's repository under the poly2tri-c/render folder

  • The second part of the project is a GEGL operation for doing the actual seamless-cloning operation.
    • In brief, here is a description of the process (needed to understand the state of the code):
      • Do a heavy preprocessing step for creating a fine triangular mesh from the outline of the pasted area
      • Now, for each render attempt, compute the color differences between the edges of the paste and the background image, and use the previously created mesh to interpolate the differences in the colors along the entire area of the pasted image. Add the interpolated color differences on-top of the paste and you get a seamless pasting!
    • The GEGL implementation of the operation can be found under gegl/operations/common/seamless-clone (in the soc-2011-seamless-clone branch):
      • Files beginning with sc-* are part of a "shared library" with the code required to do seamless cloning
        • This library is used using the GeglScContext object (sc-context.h) which manages a seamless cloning operation for a specified buffer to use as a paste.
        • GeglScContext implements smart logic to notice when a paste doesn't change between rendering sessions (i.e. calls to the process function) in order to avoid re-doing the heavy preprocessing step
        • Ideally, GIMP would use this "seamless cloning library" to implement seamless cloning with an internal op that does not need to do this check over and over, since the paste can't change when moving it on the canvas in the GIMP UI. However, currently gimp uses the GEGL op which is described below in a rather dumb way...
        • This library even exposes a pkg-config file to be easily linked against later...
      • seamless-clone.c implements gegl:seamless-clone - A simple seamless cloning operation using the above library.
      • seamless-clone-compose.c implements gegl:seamless-clone-compose - A simple meta-op for GEGL that composes the seamless paste above a given background...
    • Finally, in order to have the triangulation algorithm included, a copy of poly2tri-c is included under the libs directory of GEGL. This is since poly2tri-c has no package that can be installed and it was asked for so that developers won't need to download additional source code from more locations. This is not a desired situation, yet I'm unaware of any package owners for various Linux distributions which would be willing to help with distributing poly2tri-c as it's own package. If any such developer would be found, send them to me and I'll give them any access/help to the repositories (and I'll do any code modifications needed)

  • A GIMP tool using the seamless cloning GEGL op
    • The tool is a bit buggy in terms of refreshing the canvas (sometimes, artifacts are left when dragging the paste)
    • Additionally, it is inefficient since it doesn't use the library directly and so it does the check of whether the paste buffer changes each time
    • I'm not sure whether the errors regarding non-continuous pastes (with holes and/or composed of several unconnected parts) do find themselves into the GIMP UI in a proper way...

GIMP/GEGL TODO
  • Make GIMP check for the presence of the seamless cloning operation on the startup of the tool
  • Make GIMP use the library directly (and check for it's presence on compilation time)
  • Conditional OpenGL for doing the rendering of the triangular mesh!
    • Implementing the OpenGL rendering in poly2tri-c should be very easy for anyone knowing OpenGL. I'll do it if GIMP/GEGL accepts OpenGL (not OpenCL! That's different!) into the pipeline
  • Fix the described bugs in the GIMP tool UI

Poly2tri-C TODO
  • Code cleanup, prepare for distribution (I'll do that - it requires less coding then the GIMP stuff and does not require a long coding session - so I can do it on my short available time periods)

Saturday, July 7, 2012

Trying all my GSoC projects (seamless clone, triangulation)

It's about time I post this. My work is actually useable enough (I even received my first bug report by email recently) so it's the time to explain how to use this.

In this post I will explain you how to compile Poly2tri-C (the triangulation and mesh generation library), how to compile GEGL with the seamless cloning operation and GIMP with the seamless clone tool.

Ready? Then let us begin!

Saturday, March 31, 2012

Very big steps towards finishing post GSoC (2011) work

It works!

An outline and it's refinement

If you have been tracking my blog, you saw that I was struggling in the last few weeks to implement a constrained delaunay refinement algorithm. It took ages, as I always encountered lack of available materials and/or programming bugs. But I'm here to say that it works now!
This implementation is in C# (easier to prototype algorithms than in C), and I will convert it to C later for usage with GIMP and the rest of the project. It's based on a paper by Jonathan Shewchuk: Delaunay Refinement Algorithms for Triangular Mesh Generation.

Now, what about the GEGL side of the project?
As you may have all heard, GIMP is progressing onwards to use GEGL as it's image processing core. My seamless clone tool is not different - it was written as a GEGL operation (meaning you can use it outside of GIMP, in your own programs!). The GEGL operation has received lots of work this week, including:
  • Working in tiles instead of whole at once (reduces memory usage and makes it scalable for images as large as supported by GEGL)
  • Bug Fixing and Compiler calming (making the warnings disappear)
  • Removing code duplication
The op is pretty much done now! I will need to use the new triangulation algorithm (as mentioned above), but it should be transparent to the rest of the code.

Now, what about the GIMP side of the project?
Other than a bit nicer looking GUI for tuning some settings, it's already done since the summer.

Remaining TODO:
  • Make the GEGL operation handle blank images to paste and images with very thin (1 pixel wide) areas. Also make it handle holes (I would probably warn about these and refuse to paste).
  • Port the triangulation algorithm to C
    • Also finally make it a standalone package...
  • Improve a bit the GIMP user interface for the tool
  • Bonuses:
    • Implement an OpenGL and/or a OpenCL (I'm unfamiliar with openCL, and this op is actually very easy with OpenGL) version of the seamless clone operations, to speed things up even more.
    • Code optimizations....
That's it for now. I'm off to bed...

Friday, February 10, 2012

Post-GSoC work, End(?) of University

I have done the seamless cloning project for GIMP and finished it in August. So, you may ask, why on earth is it not integrated yet? The answer is short and simple - last university semester combined with real life. But, I'm not here to bring excuses, I'm here to bring results:
  • On Thursday I had my last university exam (Computational Complexity). Unless I fail, and I hope I don't, I finished university!
  • In the last two weeks of university, I had more and more free time so I began working again on my GSoC project. The current things that are waiting to happen are:
    • Fix the triangulation refinement implementation. For those who are not familiar with the algorithm behind the scene, the algorithm itself is based on interpolation of image differences in a triangular mesh. Therfor, it is a critical part.
      The algorithm currently would get stuck in an infinite loop of refining the triangulation, even though it was gauranteed to stop (meaning an implementation bug). I think I just fixed it now (now as in 5 minutes ago), more on this below.
    • Make the algorithm iterate over tiles inside of allocating a big chunk of memory, and thus limiting the maximal image size for the algorithm.
    • Fix memory leaks (there are several known leaks, and hopefully none unknown).
    • Improve a small glitch on the borders of the image.
    • Optimize the speed!
    • Get it reviewed, and merge back to master.
  • Being free of university, and free from other work (I have a day work on which I don't work "after-hours"), I'm now free from chores on evenings (if I get home at sane hours) and weekends. For the first time in the last 3.5 years, I really have free time with nothing on my mind. So don't worry, I'll get into GIMP :D
Now, before I get into details on my GSoC bug, a short "what's going on?".
  • Last time I left the geometry library, I was completly stuck with no idea what was the bug.
  • When I got to it again, I decided to re-write it in a language which is more type-safe (no pointer bugs), with less memory issues (garbage collection), and much easier to debug (no offense, but gdb isn't always ideal). Eventually I chose C# (and not Java, my favorite language) in order to learn a bit.
  • I have been spending my free time between the exams, in the last two weekends, to re-write the library. The re-write was something like "look at the code and write it in a different language". Almost no structural changes or anything, so that I'll keep synced with the source.
  • And then I found the bug...
Now for the bug, which made me like C much less than I did before:

// Relevant type declarations:
typedef enum
{
  INCIRCLE_ON,
  INCIRCLE_INSIDE,
  INCIRCLE_OUTSIDE
} P2tRInCircle;

// Types from GLib
typedef int  gint;
typedef gint gboolean;

// The function I called
P2tRInCircle p2tr_math_incircle (P2tRPoint* a,
                                 P2tRPoint* b,
                                 P2tRPoint* c,
                                 P2tRPoint* d);

// Somewhere in the code, in the function that I knew that
// was deeply related to the problem:
gboolean inside = p2tr_math_incircle (p, a, q, b);

if (inside)
  {
    ...
  }

I don't even feel like explaining this. It is so trivial (and if not, go learn C!) Other than feeling stupid silly for falling on such a bug for days of debugging, I don't have anything else I can say... So, with all the dislike of some people to high level languages, I like type safety. It saved my here simply since this code, when converted directly to C#, didn't compile and produce an error instead!

So, Hurray for C#, Hurray for end of University (hopefully) at least untill second degree, and just some other random hapiness. And don't worry, I'm not gone yet :)

Edit: More silly bugs found. I'm starting to like re-writing stuff - way better than debugging...
Edit 2 (February 11th, 2012): The geometry library works, at least in C#. Now it's time to re-implement in C.

Monday, September 5, 2011

Video demo of my GSoC project


[If you are reading this from RSS, you may not be able to see the video. Click here to see it]

Monday, August 29, 2011

[GSoC-2011] Final Results and How to Try

I am very glad to announce that I now officially passed the Google-Summer-of-Code 2011 :) The email from Google arrived in the last few days, and the official Google announcements on the GSoC results (of all projects) are supposed to be published tomorrow.

S/He is eyeing you :)
Sources: background, paste
Now, it’s time to publish the instructions on how to get and try it for the people who want to test it. There are some known bugs, and probably some unknown bugs, so be warned.

Compilation and Set-Up Instructions
  1. You should know how to build of GIMP and GEGL from Git. A partially outdated guide is available here, and some things are explained in more depth here.
  2. Instead of building the GEGL master (main) branch, switch to the soc-2011-seamless-clone branch. You can do this by running git checkout soc-2011-seamless-clone. Compile it with the regular flags – nothing special is needed.
  3. After building the updated version of GEGL, it’s time to build the updated version of GIMP. Switch to the soc-2011-seamless-clone2 branch, and build it.
  4. Before running GIMP, you must set the environment variable p2t_refine_steps to some number defining the maximal amount of points to be used in the mesh (in plain English, more should theoretically produce better result). I know this is annoying, I will get rid of it as soon as I finish debugging a certain code part. The typical number I use is 500 for pastes of around 200x200 pixels, and you should probably increase it if you wish to work on large pastes. If you are using the bash terminal, do export p2t_refine_steps=500 (and change the number as you wish)
  5. Run GIMP.
Usage Instructions

Basically, you can just try copying a part, selecting the Seamless Clone tool (Shift+L) and clicking anywhere on the image to start the tool’s interaction. Click Enter to apply the final result. If this doesn’t work (and/or crash), then the instructions below are for you.
  1. Run Gimp :)
  2. Open the image that you wish to use as the background, and open the image you wish to paste into the background. Copy the part you want to paste. Note that opacity of that part will be treated as if it was binary – parts under 50% opacity will be removed, parts of more than 50% opacity will be completely opaque. The shape can be any shape, as long as it follows the following rules:
    1. It must not have holes (Temporary limitation)
    2. It must be continuous, i.e. composed of only one part (Temporary(?) limitation)
    3. It must not have any long thin areas (Temporary(!) limitation).
      This means that if you have any area which is 1 pixel wide and is 3 pixels long or more (i.e. a thin spike), it will crash. Solution for this was already devised, I just need to code it. Select the Seamless-Clone Tool (Either by clicking the second tool on the toolbox that has the same icon as the move tool, or by doing Shift+L).
  3. Click anywhere on the canvas while the background layer is active. The paste will be centered on the cursor, and so the cursor should be in a place where the entire paste is inside the background boundaries (both inside the rectangle defining the layer, and inside an area where all the background below it is opaque). This limitation will be enforced by the User Interface later.
  4. Move the paste by clicking on it, dragging and releasing. If you move it slow enough (which actually shouldn’t be so slow), you’ll see the preview updating while you are moving.
  5. Click Enter to Apply the effect.
Known Bugs
  • All the above mentioned crashes and bugs :)
  • Due to not yet complete memory management, the tool leaks memory from it’s preprocessing.
  • Converting to tile-based processing is NOT 100% done, so it may crash on large pastes. Don’t ask me how large since I didn’t try anything more than 300x300 on my machine.
Other TODO’s
  • Integrate the tool with the help system
  • Test better the interaction when the the active image/display/drawable are switched during the interaction of the tool.
  • Get a decent tool icon. Anyone with ideas for the visual metaphor to be used by a seamless paste tool, is more than welcome to leave them here as comments! I do design icons, but I don’t have an idea for this one.

Monday, August 15, 2011

GSoC 2011 - (Almost) Final results and thanks!

The end of Google Summer of Code 2011 is near, and I have failed to post enough updates on my blog. But that does not mean one bit that I failed to make progress. I'm proud to present you with my results:

Result, using my GIMP tool :D
The image to paste (source)
The image to paste into (source)
Licensed under Creative Commons Attribution-Share Alike 3.0 Unported

My tool allows you to move the paste on the image and see it update according to it's environment, so that it will paste seamlessly. It's not real-time yet, since I recompute some values that should be cached everytime, but most work to enable caching is done, and I hope to reach that before the final deadline. (Even if it won't be before the deadline, I will do it even after GSoC ends).

This is also the time to thanks all the people who made this possible:
  • The authors of the Coordinates for Seamless Cloning article, who developed this algorithm.
  • Prof. Daniel Cohen-Or, the professor who taught me computer graphics at the university, and helped me understanding the article (he is also one of the article authors).
  • My GSoC mentor, Michael Natterer (aka mitch), who agreed to mentor me and assisted me when I was stuck.
  • Mason Green, the original author of the poly2tri library, which was heavily used in the project for computing interpolation meshes. I would have never reached the project deadline without his amazing library.
  • Prof. Jonathan Richard Shewchuk, who developed some of the geometrical algorithms that were used in this project.
  • Finally, special thanks to all the great guys on the GIMP and GEGL irc who helped a lot - mitch, Bat`O, pippin, Alexia_Death, Mikachu, and more.

Friday, May 27, 2011

The end is near, and so is the beginning

Pictures from Yehuda Poliker's Concert on the
Student-Day, and a picture of my GSoC kit. Cellphone
pictures, so low quality :P
There is a feeling of an end in the air. The end of university, another chapter in my life. Yesterday I took part in the Student Day party at our university - there were amazing concerts by fantastic artists, including Yehuda Poliker, Monica Sex, Hadag Nachash and more. The Student Day is a known symbol of the end of the year, which happens 2-3 weeks before the end of the semester. The fact that is practically my last year as a student (I will have one last course left for the next semester, but that doesn't really count) does start to get in, and I am gradually getting used to this.

This week was also the official beginning of the Google Summer of Code coding period! After getting my cool GSoC kit (see the picture) 2 days ago I really felt that I'm a part of this great project - many thanks to google for organizing this! Anyway, I almost finished porting poly2tri to C. Once this is done, I can start coding my project. The milestones for my project are:
  1. Port poly2tri to C (from C++), a library for generating Constrained Delaunay triangulations for given polygons.
  2. Implement Chew's Second Algorithm to create adaptive meshes from CDT's*
  3. Implement code to create polygons from Black/White (1-bit) channels (The edges where the color differs should be described by polygons)*
  4. Combine all these to create an adaptive mesh from a Black/White channel (which symbolizes a selection area)
  5. Create a triangle mesh renderer with color interpolation between vertices (actually, Cairo may be able to do this!)*
  6. Implement the Mean-Value-Coordinate cloning, using these above, as a GEGL operation*
  7. Add some GUI and put it as a GIMP tool
Marked with * are the steps that would require the actual work, most other steps should hopefully be trivial. But again, hopes and reallity don't necessarily agree :) When I applied for this GSoC I knew there was code to do adaptive mesh generation from polygon outlines. It's only too bad that none of the code to do this is small and in a GPL compatiable license :(

I hope to finish everything untill step 4 (and parts of 5 if I'll be able to use Cairo) untill the midterm, but I can't really set the midterm goals yet since I haven't started to seriously code yet because there is still a university semester going on for the next week or two.

To all students out there, good luck in the exam period! And for the GSoC students, good luck with the projects! :D

Tuesday, April 26, 2011

I’m doing a Google Summer of Code!

My application for a Google Summer of Code project for GIMP was accepted! =D
After being around the development team for a year or so (and hanging around the IRC even more), and after I couldn’t apply last year for technical reasons, this year I will get my chance.

Here is the initial description of the project, taken from my project page:

The project I intend to implement is something called Adaptive Cloning (aka Seamless cloning). Basically, the idea is that cloning parts from one image to another usually does not end well. This is because of different exposure/white-balance settings, or simply because of different lighting conditions.

The idea is to implement an algorithm which would allow to copy a part from one image, and paste it seamlessly into the other; the pasted area will be blended to fit the destination image locally. There are several techniques to do that, and the most known one is called poisson image cloning. The problem with most of these algorithms is that they are expensive (computation-wise) and are not suitable for interactive editing and previewing, unless you use hardware acceleration.

The suggested technique for my project is based on an article from Siggraph 2009 (includes demos and videos), which shows realtime performance (both on the GPU and the CPU*). The user would paste a some area from the clipboard and will then be able to "blend it in" according to it's environment.

I'm open for any suggestions regarding usability, ui integration, or anything which relates to the project. Feedback will be more than welcome!

* Note that I'm not sure for which sizes on the CPU it preforms on realtime, but it's still much more cheap computation-wise than most other techniques and a small lag of few seconds is something which should be acceptable for this sort of workflow.

GIMP has 5 projects for this GSoC – if all these projects succeed, GIMP will gain a major boost in it’s capabilities. This year’s projects are:

I would also like to congratulate Blender (formally, The Blender Foundation) for an astonishing amount of 17 GSoC projects! If there is any project who can do anything with 17 students, it’s Blender. Congrats also for Inkscape for 4 GSoC projects.

Good luck to my fellow GSoC students, especially the GIMP (and Blender) students. I hope I will finish my project – I already learned from Bat`O last year that it is feasible to code something like this ;)

The list of all accepted projects for all organizations for this year’s GSoC can be found here.

Small Help Wanted

I searched without success for a small GPL compatible library for generating quality triangular meshes (example) from a given outline (probably a quality constrained Delaunay triangulations / conforming Delaunay triangulation) - I need this for my project. I haven’t found any library that is both small and GPL compatible. If anyone knows any such library, please tell me - it will save me lots of work and guarantee less bugs in the final result.

Edit: It seems as if poly2tri may do the job of creating a CDT (Constrained Delaunay Triangulation), and on that I can apply Chew's second algorithm. This is not optimal, but it is feasible since creating the CDT was probably the hard pard. If anyone finds something better, I will still be glad to knkow!

Friday, March 18, 2011

GIMP was accepted to GSoC 2011

GIMP was accepted to Google Summer of Code 2011!


Congrats also for Inkscape, Blender, Scribus for making it to GSoC 2011! For the full list of projects, see GSoC 2011 participating projects.

Tuesday, March 1, 2011

First GIMP Developer Meeting - A success!

I worked hard to arrange it, but it paid off - We had a serious gimp developer meeting, with most developers attending it :)

Thee meeting page, including the agenda and log can be found at:
http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Feb_2011

Some of the decided actions in the meeting:
  1. schumaml and LightningIsMyName fix wgo?
    wgo is a shortcut for the GIMP main website - we need it to have auto-updates again
  2. Alexia and mitch take care of redirecting wiki.gimp.org
    We need to make the domain point back at a working wiki, the original one died of spam and Alexia Death has a new working one here
  3. Enselic makes a draft of a GIMP roadmap and sends to gimp-developer
    Let's get some priorities!
  4. everybody subscribe to bug mail and TRIAGE BUGS
    We get toooooo many bug reports, we need to start filtering them
  5. mitch, make a development release soon
    Yes - that's right! GIMP 2.7.2! Now we just need to define soon :P
  6. LightningIsMyName takes care of next meeting
    Hehe. I'll do that with pleasure :)
  7. setting pages on the wiki to discuss changes in different topics
    Too many changes are done solo and may not be agreed upon by everyone - this is because of lack of places to show plans
  8. LightningIsMyName gets a list of projects on the wiki by tomorrow, developers review the ideas by email or by commenting on the wiki. Saturday (March 5th, 2011) is hard dead line for finalizing the project list!We want to get to GSoC, so we must have a list of projects ASAP! I'm going to work on this and try to get this done tomorrow night
  9. all devs PM/Email LightningIsMyName username and email
    Yeah, so if you are a GIMP dev and you don't have an account for the wiki yet, tell me!

Next meeting: March 14 2011 10:00 PM CET (GMT+1)

If you want to influence GIMP development, and/or contribute, come and attend the next meeting. Just note that the agenda will be decided by email several days ahead, on the developer mailing list - so submit your ideas there. You can also jump to irc://irc.gimp.org/#gimp and people will help you there if you want to help the GIMP project.

Monday, February 28, 2011

GIMP Developer Meeting

Today (February 28th, 2011), at 10pm CET a meeting of GIMP developers is scheduled on the GIMP developer IRC.

Agenda:
  • GSoC 2011 - ORG Application deadline is in 11 days!
  • Bug fixing priorities
  • Future development?
  • Make an official wiki working again (i.e. make wiki.gimp.org pointing at it)! Can be done either by making http://gimp-wiki.who.ee/ the official wiki, or potentially using some other available servers (will be discussed in depth on the meeting)
  • Make a roadmap on the official wiki
  • Try and decide on clear release policy for beta builds - I personally would like to see more recent beta releases, and the last one was 7 months ago!
  • Anything else? =)
If you want to discuss GIMP's future, GSoC this year, and just listen, please come. We will meet on irc://irc.gimp.org/#gimp (Users without IRC client can connect using this link).

Edit: The wrong time was displayed - it's february 28th, not the 27th

Sunday, January 30, 2011

Compiling (Pre-Packaged) GIMP on Windows!

Finally, after all the promises, I'm proud to announce that I finished the Guide for compililng (a pre-packaged version) GIMP on windows! The technique is using MSYS and MinGW, and without Cygwin - which means it's a native windows build!

What does it mean Pre-Packaged? It means a source package that you download from the website, and not the latest one from the version control system (Git in GIMP's case). Pre-Packeged version are not exactly the same you get from Git, and they passed an additional step that makes the compilation a bit easier. The additional steps for compiling the Git versions will be posted (hopefully) later this week.

On which version was this tested? On GIMP 2.7.1

The guide can be found here.
Update - fixed a small mistake which caused some stuff to be extracted to the wrong place.

Friday, January 14, 2011

A very complete guide about compiling GIMP (Linux)

I have just published a very very detailed guide about compiling GIMP from source, with explanations of what does each step mean (instead of just giving commands for people to follow like dummies). You can find it here.

Corrections/Suggestions/Comments will be happily accepted!

Update (15 Jan, 2011): Added instructions about updating your build

Wednesday, December 15, 2010

Writing a Raytracer, and some other random thoughts

I always wanted to write a raytracer, and theoretically I knew enough math and programming to do it for a long time. Yet, I didn't write one before - this is because I thought it would be a gigantic project. Well, I'm gald to tell you that at least a basic ray tracer is not too big!


The picture above is from a half-done ray tracer which I'm implementing during a course in computer graphics (which I'm taking now). I have documented the math that I needed, along with annoying bugs that I had (and I'm sure that at least some of these are common bugs).

When I finish this project in the following weeks, I intend to publish these documents. Currently I have:
  • A list of things which can cause annoying bugs, which are related to how ray tracers should work.
  • A document explaining many common 3D calculations (instead of taking these for granted, like we did in class).
I may publish more documentation about writing a ray tracer when I'm done - but this is just quick update about what I'm currently working on.

During writing the raytracer, I saw the influence of choosing the right programming language. We started with C++ and after we had memory leak that we failed to trace (even with valgrind and friends) we migrated to java (in which you have to work very hard to leak memory) - since it was the begining and converting the code was quicker than fixing the leak.

The debate about programming languages made me wonder - when GIMP 2.8 is finally out (and I'll start working on gimp again in the next weeks - I had too many things to do lately), and the writing of GIMP 3.0 starts, should we keep using C?

C is OK, as long as you know what you are doing, unlike C++ in which you can still make things crash even if you *think* you know what you are doing. I would really like to see GIMP in a higher level programming language, but it seems as if Java and C# are out of the question (patents, political/idiological reasons, ...). About a month ago, someone introduced me to Vala - a new OOP programming language, which works very nicely with the GNOME libraries, and it's translated to C code so that it works on most platforms.

I wonder if it's possible to convert the code gradually to Vala - and have the C code integrate with the converted Vala code. It is theoretically possible (I think, since Vala translates into C), I just wonder if it's practical, and what would other developers think about this idea.

Also, is Vala mature enough? And more importantly, Is Vala known enough? I did find several projects that use it, but when I tried to check how many people know it (asked fellow students in the university labs - sounds like the right place to ask) most people said they never heard about it.

Edit: See the comments below for a discussion for/against languages such as javascript/python/perl

Saturday, November 6, 2010

New GEGL operation!

Hello,

As I mentioned, I started working on some gegl operations, and I'm glad to announnce my first official gegl operation - whirl and pinch! This operation is a port of the known gimp plugin to gegl (since eventually every gimp plugin will have to be ported).

How to install it (linux users):
  1. Copy the file operations/workshop/whirl-pinch.c (from inside gegl's source tree) into ~/.local/gegl-0.1/plug-ins/
  2. Make sure your enviroment contains gegl's build dependancies
  3. Type 'make' inside ~/.local/gegl-0.1/plug-ins/

Now, you will be able to access the operation inside gimp (using the "GEGL Operation" tool) and get a live on-canvas preview of it!

Whirl and pinch gegl op!
"Whirl and Pinch" live on canvas!
BTW - last night I closed 6 gimp bugs :)

Thursday, September 2, 2010

Update - Multicolored text is now supported in GIMP

Thanks to Michael Natterer (mitch) who had some time to do some cleaning to my patch, and integrate his patch to allow true rendering of color for text (instead of rendering an alpha mask) GIMP now supports multicolored text :D

Go test it from the latest source and report bugs if you find some ;-)

Saturday, August 28, 2010

GIMP can now export PDF's!

Hello!

After some work, I'm proud to say that GIMP can now export PDF's using my new cairo-based pdf export plugin!
Go check it out - it's in the main source repository in the master branch :D

Comments and feedback are more than welcome - you have until 2.8 to affect how this plugin will work and which features it will have. Currently, it has:

  • Support for multiple pages using multiple images using File->Create->Multiple-Paged PDF...
  • Support for exporting text as text!!
  • Support for resolutions

And it has the following optimizaiton options:

  • Replace rectangles of a single color with a vector shape. This can dramatically decrease the file size (think of all the single-colored background layers that are now saved as vector instead as bitmap)
  • Remove the alpha channel of layers where it's unused, to decrease the file size
  • Discard layers which are not visible or are100% transparent
  • Can either apply layer masks (to decrease the file size) or keep them (better quality pdf, bigger file size)

Happy Gimping!

Edit: Updated the post with details on the plugin

Tuesday, August 10, 2010

Some updates + Feedback Needed

As I said in my previous post, I'm a bit inactive due to the tests which I had in university. After finishing Logics for Computer Science, tomorrow I have my last test - the dreaded Calculus 2...

So starting tomorrow noon (it's night here right now), I'm back on full time GIMP coding! Here is what I'm up to, and reasons for some delays:

Multicolored Text Layers
On their way - no real reason for a delay, I just need to fix some (hopefully) easy bugs :-)

Where is the PDF plugin which you promised?
A new API is being introduced into GIMP - an api for accessing layers, channels, masks and paths - all as GimpItem objects. I want this api to be finished before I'm done, so I'll write the code once.
Also, it's currently impossible for plugins to access the layers inside layer groups - instead they get one layer which is a merged version of all the group. This means that text as text will be ruined if it's inside a group, so I'll wait a while to see if there is any chance it will be fixed before I continue.
Finally,it's probably better to finish implementing the multicolored text patch, so I'll be able to test the pdf plugin when it's already integrated =)

Angular Guides - Feedback Needed
Before you get excited, don't. I'm checking the option of adding support for guides with arbitrary angles inside GIMP (instead of only horizontal and vertical like now). I'm in doubt this is going to happen soon - I had a day to play with the code a bit, but nothing more.
Someone (mitch if I remember right) suggested to implement the new guides system as paths; You can currently snap to the active path as if it was a guide (View->Snap to active Path) - that's a less commonly known feature. Anyway, Implementing it this way will possibly allow us to add things like isometric/polar grids and other snapping shape we can imagine. So even if this sounds harder, it's worth a check.

Here is where I need your feedback on:
  • What kinds/shapes of guides/grids would you like to see in GIMP?
  • Do we need guide groups (for enabling/disabling many guides at once)?
  • Other guide related requests?
I don't promise anything yet, but if I'll know what I'm aiming for before I begin, it might help :-)

Usability of GIMP's menus - Feedback Needed
Finally, there have been a discussion on the usability of the GIMP menus. There were discussions about adding searchboxes to search GIMP's menus (since these can get cluttered if having many plugins).

Here is where I need your feedback on:
  • Would you like to be able to categorize your plugins? Or maybe tag them and browse by tags?
  • Do you need to be able to edit the categorization of an existing plugin (if such categorization exists)?
  • How would you like to search for a plugins/built-in functions? What should appear next to the description of each action/plugin?

I'll raise some of the suggestions on the discussions in the mailing list or the developer's IRC. We need your feedback! If we want to make GIMP better for the users, we better hear them =)