This page is a work in progress, I'll be filling it out over the days to come.
1. Write a small introduction to yourself.
My name is Robert Bieber. I live in Bradenton, Florida, and I'm heavily interested in software and photography, which makes Darktable a particularly enticing project for me.
1. State your preferred email address.
1. If you have chosen a nick for IRC, what is it?
bieber (In general I go by some variation of my surname everywhere online)
1. Why do you want to participate in summer of code?
I'm a free software enthusiast, and this represents a great chance for me to get to contribute to free software. It's also an excellent work opportunity for the Summer, with flexible hours and location (there's not a whole lot of CS internships to be had around Bradenton) and good pay.
1. What are you studying, subject, level and school?
Computer Science, third year at UCF. When this semester is over, I'll have completed the entire degree program aside from one required upper-level course, one elective and a network security class.
1. What country are you from, at what time are you most likely to be able to join IRC?
United states, Florida to be specific. Last year I generally worked from around 1200 to 1600 my time when I woke up, and then from around 0000 to 0400 at night, which worked well because a lot of the developers I was working with were in European time zones. I could also adjust to more normal hours if that would work better for communication.
1. Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.
I'd like to try to take a week off at some point, but it's not a priority. Coding doesn't actually start until almost a month into my Summer break, so if I do go away I'll make sure to do it before then.
1. What programs/software have you worked on before?
I worked on Rockbox for last year's SOC, and I've been programming on various personal projects and school assignments since I was 10. Two Summers ago, I put together a web photo gallery in PHP as a side project. More recently I've built a simple message broadcast system, an amusing little charged particle simulator, a simple person-tracker for video (the goal is to eventually connect the whole system to a motorized pan/tilt head and have it automatically track a speaker with a video camera), and various school projects.
1. Have you developed software in a team environment before (as opposed to hacking on something on your own)?
Yes, but not as much as I'd like. I've worked on group projects for classes, and last year I worked on the Rockbox project, but I was mostly working on my own standalone application with little assistance from others.
1. Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?
I participated in Summer of Code last year for the Rockbox project. Rockbox is an alternative firmware for digital audio players which has a sophisticated theme language used to style the player. The theme language is similar to HTML with tags specifying structure and content, but in addition to doing simple formatting and value substitution there are conditional tags which display their content based on the value of other tags, and these can be nested to arbitrary depth. My task for the Summer was to create a graphical theme editor; because they were making some significant changes to the theme language around the time the Summer began, I started out by writing a parser for the theme language which is currently in use both in the theme editor and Rockbox itself. With the rest of the Summer I built a substantial GUI application in Qt that can load themes, manage them as projects, render a graphical preview of skins as they're being written, and allows some drag and drop editing of theme elements.
1. Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
I still do occasional maintenance work on my project from last year.
1. Photographic experience
1. What type of photos do you take, with what camera, in which format?
I shoot portrait, wildlife, still-life, and just about anything else I get the opportunity to shoot. I use a Canon EOS 20D, and shoot RAW unless I really can't afford to fill up the buffer too fast (really only happens when I'm shooting sports).
1. How do you organise and develop your photos?
I organize and tag with Shotwell, hoping to get everything moved over to Darktable now that there's a database transfer script available. My current workflow is Shotwell -> UFRaw -> GIMP, but I'd very much like to be able to cut UFRaw and GIMP out of the picture for simple RAW conversion, curves, levels and such.
1. Do you have a website/flickr account?
1. How proficient are you with post-production software, and which one(s) do you know?
I'm reasonably proficient with UFRaw and GIMP: I'm able to do some relatively sophisticated post-processing, from basic color correction and removal of facial blemishes up through removing and rearranging objects in scenes, compositing photos and so on. I'm not amazing, but I think I'm pretty competent.
1. Are you familiar with basic photographic data processing (demosaicing, white balance, color management)?
I have a general idea of what they are and how they work, but I haven't worked with any of those concepts in code yet.
1. If you have contributed any patches to darktable, please list them below. You can also list patches that have been submitted but not committed yet, patches that were refused or patches that have not been specifically written for GSoC. This will help us find out what your work was and how you code.
So far I've submitted a series of patches that add subject distance to the EXIF data gathered from images, puts it in the database, and shows it in the image EXIF info window and loads it automatically in the lens correction plugin. These patches have been accepted and committed to the master repository.
I also recently made a pair of patches that allow a user to select between RGB and Lab view for the color picker. I haven't received any feedback about these patches yet.
1. Communication skills
1. Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.
I'm a native speaker, I speak and write fluent English.
1. What spoken languages are you fluent in?
Only English, I'm afraid.
1. Are you good at interacting with other people?
I believe so.
1. Do you give constructive advice (both as a photographer and as a coder)?
I always do my best to.
1. Do you receive advice well (both as a photographer and as a coder)?
Yes, I always appreciate good advice.
1. Are you good at sorting useful criticisms from useless ones?
1. How autonomous are you when developing? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want?
Somewhere in between. I always try to get a solid set of requirements before I start working on something intensively, but I'm not afraid to make a proof of concept ahead of time or take a chance on some implementation details I might have to change later, if I don't have anything else to do with the time.
1. Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?
I've opted for several smaller tasks, including some from the suggestions list and some of my own design. From the Wiki, I picked rewriting the keyboard accelerator system and removing the libglade dependency by hard-coding the UI initialization code. The keyboard shortcut is my main focus among the two.
1. If you have invented your own project, please describe the project and the scope.
In addition to the two tasks I've picked from the Wiki, I have two of my own. The first is a revamp of the color picking tool. While the specific interface is still being discussed, the two key points of my modifications will be to make the sampling interface more intuitive and to display the samples in a better way, allowing the user to view the sample in different color spaces and to see the point as a line on histogram and curve displays.
My other enhancement will be the addition of a levels view to the curves adjustment plugin. This will allow the user to view a histogram and set the image black, white, and gray points in the same way as GIMP's interface.
1. Why did you choose this project?
I picked my two original projects because they're features that I would very much like to see implemented and use myself. I picked the two from the wiki because they're changes that members of the community seem to desire and that represent interesting challenges to me.
1. Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".
I don't have any vacations or absences planned yet for the Summer, and if I do decide to take a vacation I'll do it before coding begins. This is my estimated timeline. With any luck, I'll be able to stay ahead of schedule on most if not all of these tasks, which will leave me with plenty of time to deal with unexpected issues in the other tasks, and hopefully to tackle some other UI related tasks at the end of the Summer. In particular, I would like to work on getting Darktable to compile with Gtk+ 3.
1. Removing libglade dependence: 4 weeks (May 23-June 13)
I want to do this task first and allocate it the greatest amount of time because it should give me a good feel for both Darktable and GTK. Both will be important for my subsequent tasks, so I want to spend the time upfront to get used to the systems I'll be working with.
1. Rewriting the keyboard accelerator system: 3 weeks (June 13-July 4)
I'll aim for about one week to build the accelerator dialog box, one week to design and implement the functions for registering keyboard accelerators, and one week to replace all the keyboard accelerators in the interface with the new version.
1. Replacing the color picker tool: 3 weeks (July 4 - July 25)
I'll try to spend the first week redesigning the actual color picking interface. In the second week I'll create an interface to allow access to color samples from all the modules in the darkroom view and get color samples displaying as bars on histogram and curves controls. In the third week I'll investigate and experiment with alternative methods for handling color samples in the GUI. There's been a lot of discussion about how this should be done, so I'd like to devote some time to working out a solution that most of the community will be happy with.
1. Adding a levels control to the Tone Curve module: 3 weeks (July 25 - August 15)
I'll spend one week designing and implementing a modified histogram control with the ability to set white, black, and gray levels, and perhaps the ability to add extra user-defined points as well. In the second week, I'll get this control implemented into the tone curve module with a pair of radio-style pushbuttons to switch back and forth between the two views, and implement call-backs for the levels control to modify the curve as necessary to implement the levels set on it. The third week can be spent working on the integration between the two controls.
1. Include as much technical detail about your implementation as you can.
1. Removing the libglade dependency. The initial loading of the glade file will need to be replaced with code that creates all the widgets currently in the glade file using manual calls to GTK functions. Of course I'll need to store pointers to the important containers in the darktable_t struct for access from all the different functions that will need to work with them. Henrik Andersson has posted a suggested design here, and I intend to more or less follow this guide.
1. Rewriting the keyboard accelerator system. Currently, modules which need keyboard accelerators call the appropriate GTK functions to manually register them themselves. What I propose is a central data structure accessible through darktable_t that will store all the currently needed keyboard accelerators. A module needing an accelerator will call a function, something along the lines of dt_gui_request_accelerator(char* name, char* description, sequence default_sequence, int level). The name and description arguments are self-explanatory. The default_key argument will specify the key sequence (I don't know what particular data type GTK uses for key sequences yet) that the module desires for its default, and the level argument will specify the level at which the accelerator should operate (global, canvas, module, etc.).
Once an accelerator is installed in the data structure, an actual accelerator will be registered to correspond to it. The user will also be able to use a central shortcuts dialog box to override the default key sequences for the registered accelerators. Overridden defaults will be stored in gconf so that they can be reloaded every time the application starts back up.
1. Replacing the color picker tool. I still need to learn more about Darktable's internals to be entirely sure how to implement this (completing my first task should help a lot with that). My general plan is that the picker tool should expose its sample data through a semi-global interface to all the different modules running in the darkroom view. This way individual modules will be able to query at will for current sample data: for instance, the white balance module will be able to fetch the current sample from the color picker to determine the neutral point, rather than needing its own color selection.
1. Levels adjustment tool. While I haven't worked with GTK yet, I know from the examples in /src/dtgtk/ that it's possible to define custom controls based on existing ones. I'll create a new version of the existing histogram control with sliders at the bottom (similar to those currently on the base curve control) used to set the white, black, and gray point. I may also offer the ability for the user to add new sliders representing different intensity points as well. This control will be an alternate view in the tone curve plugin, and any changes made on it will automatically be translated into a corresponding curve and set on the curve control.
I hope to gain experience (particularly working with GTK, as it will be nice to have some experience with both major UI libraries) and produce some code that I'll be able to use myself. It is also an excellent opportunity for Summer employment, and a great chance to meet interesting people with similar interests.
1. What do you expect to gain from this project?
- git (used for all commits)
1. What would make you stay in the darktable community after the conclusion of GSoC?
Nothing in particular necessary, Darktable is an interesting enough project that I see myself sticking around for a long time.
1. Practical considerations
1. Are you familiar with any of the following tools or languages?
I'm familiar with using git for basic commit/push, branching, merging and rebasing. Not a master of it yet, but I can use it well enough.
- C99 (language used for all the normal source code)
Very familiar. I've been writing C and C++ for years, and C in particular is the language I feel most confident with.
I've used SQL before, but not SQLite specifically. From what little work I've done on Darktable already I feel confident with SQLite, at least as much as I'll need to use to work on Darktable.
I haven't done any intensive parallel or GPU programming before, I'll have to get used to both of these libraries.
So far, only as much as I've encountered modifying Darktable. I've used other GUI libraries extensively, and don't anticipate any trouble with getting used to GTK.
- SSE intrinsics/optimized programming
No experience with this yet, it's something I'll have to learn.
I have used CMake, although not a whole lot.
1. Which tools do you normally use for development? Why do you use them?
So far working on Darktable I've been using QtCreator because it gives me autocomplete, symbol following, whole-project search, and similar tools that help with getting used to a large codebase, and compiling from the command-line. For smaller projects I usually just stick to Emacs.
1. What programming languages are you fluent in?
C, C++, PHP. I'm kind of a novice in Haskell and Ruby as well.
1. Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably only add this number in the application for you submit to Google since the info in the wiki is available in public. We will not make any use of your number unless some case of "there is no way to contact you" does arise!
No problem at all, I'll include my number in the GSOC application.