User:James Legg

This is the Google Summer of Code 2009 project proposal page for James Legg. In the 2008 Summer of Code I wrote the Hugin Fast Preview window

Enfuse / Enblend Gimp Plugins

I would like to create Enfuse / Enblend Gimp plugins so that people can blend image layers with minimal visible seams directly in the GNU Image manipulation program.

Previously, a user would have to export each layer as a separate file and blend them on the command line. After the project's completion, a user should be able to have the same functionality directly in the Gimp. This would have the advantages of speed of use, as it removes several steps for the user; the ability to use Enblend and Enfuse in Gimp scripts; and the ability to consider blending like any other operation in the Gimp, with features such as undo, redo, and repeat last effect. A user interface will be created that allows the user to pick the options that are currently command line arguments. To demonstrate the plugins, I will create scripts that:

1. 'enfuses' exposure stacks
2. 'enfuses' focus stacks
3. makes any texture a seamless image, similar the "Make seamless" plugin, however it will use Enblend to reduce visible seams.

If time allows, I could also create a Gimp plugins to do the job of nona and align_image_stack (with layered, unblended output, as the Gimp does not support high dynamic range images). Then I would create scripts for aligning and blending focus stacks or exposure stacks directly in the Gimp.

This project is based on this project suggestion

I have picked this idea as it would be useful for panoramic photography and seamless texture creation, both of which I do myself. I use Hugin and the Gimp, and such a plugin will be very useful for me as well as others.

I will work full time for the majority of Summer of Code. However, my final exams are at the beginning of June, so I intend to be revising for them, instead of coding, for the first three weeks. I will also need to take a couple of days off for my graduation and a family event.

This is a rough estimation as to how I spend the time:

• Weeks 1-3: revision (not coding).
• Week 4: Create the user interface for the Enblend and Enfuse plugins.
• Week 5: Write the part of the plugins that gets the required image information (e.g. image format, sizes of layers) from the Gimp, rather than a file.
• Weeks 6-10: Modify Enblend so that the source of the image data can be from the Gimp, and not just a file, and the result can be written back to the Gimp rather than written to a file.
• Weeks 11-13: Testing, bug fixing, and enhancements.

Alternative suggestions

Here are other projects I would be happy to work on:

Bracketing Panorama Model

I will add row, column, and bracket fields to the images.

They should be set automatically after alignment. However, if there is any confusion, the user may set them manually: either individually on the images tab, or in a new layout tab. This tab will allow the user to specify something like "I was shooting with 3 bracketed images per direction, my rows span a full 360 degrees, I have 7 rows spanning 180 degrees. They are 3 rows of 14 positions, 2 rows of 6, and a single angle zenith and nadir row. Oh, and I shot in that direction twice since someone walked across the shot, so don't count those!". There is a possibility of taking the intended positions as they are given and showing a fast preview so the user is aware their settings are working quickly.

Alignment can then be done optionally per stack, or with the stacks intact as required. Also the rows can grouped together if wanted.

The previews will be modified so that there is an option to show only images in one bracket without manually picking the numbers.

The makefiles will be modified to merge the brackets based on this information, and to enblend each row together, then enblend the rows as a separate step if wanted. The interface to control what is given as output can be altered depending on the bracketing information. For example, if only focal distance changes between images in the stacks, "Create focus blended panorama" will be the most prominent option. If exposure varies greatly between images in the stacks "Create high dynamic range panorama" and "Create exposure blended panorama" will be the most prominent options. If there is only 1 image per stack and similar settings across the panorama, "Create low dynamic range panorama" will be the most prominent.

GLSL shaders in the Fast Preview

For a computer to support the OpenGL Shading Language (GLSL), the graphics hardware must conform to OpenGL 2.0 or greater, or support the GL_ARB_fragment_program and GL_ARB_vertex_program extensions. Shaders can be written which are compiled by the graphics driver, and run on graphics hardware. They are highly parallisable, as the code is run independently on each vertex in an object, or each pixel in the output depending on the type of shader. We can specify values in Hugin to be passed to shader per vertex, or for the entire scene.

This would be ideal for photometric correction, which is currently poor in the fast preview. We can also support high dynamic range images, and write code to map hdr information to a ldr image for display.

Hugin could check if the OpenGL shading language is supported, and if it is offer more features and replace some functionality.

I propose to enable HDR display, an entire panorama difference mode, and real-time full photometric correction in the fast preview for hardware supporting the OpenGL shading language. I will also write a remapper that uses a GLSL vertex program to perform the remapping, and compare it with the non-GLSL originals. I do not have particularly "high end" graphics hardware to test it on, though I have a new machine and it supports GLSL, so the performance may vary widely to systems other than my own. (My graphics chipset is an Intel 965GM.) An option will be present in the preferences to use this remapper if supported.

Unlike the nona GPU branch, the shaders that remap positions should not be compiled for every image, as this would be slow during updates. Instead, modifiable parameters will be passed to the shader from Hugin. Once a shader is compiled, it can be reused with different parameters.