SoC2009 Seth Berrier

From PanoTools.org Wiki
(Difference between revisions)
Jump to: navigation, search
(Added information about the first project proposal.)
(Simple Masking & Bracketed/HDR Exposure Stacks: updates to text of proposal.)
Line 1: Line 1:
 
==Simple Masking & Bracketed/HDR Exposure Stacks==
 
==Simple Masking & Bracketed/HDR Exposure Stacks==
Panoramas are by their nature vast offering a wide view of the world and the world, unfortunately, if full of things that move.  These moving things (animals, well-meaning family members and friends, cars and airplanes) inevitably step into your frame an the most inopportune moments and show up in only one of the overlapping source images.  For this reason above all else masking out pixels is a vital step in the pano creation process.  Much of the Hugin family of tools is already setup to support this and only a small amount of extra editing is necessary after remapping the images and before blending.  But it is not trivial and it is high time this extra step was eliminated.
+
Panoramas are, by their nature, vast offering a wide view of the world; and the world, unfortunately, is full of things that move.  These moving things (animals, well-meaning family members and friends, cars and airplanes) inevitably step into your frame an the most inopportune moments and show up in only one of the overlapping source images.  For this reason above all else, masking out pixels is a vital step in the panoramic creation process.  Much of the Hugin family of tools is already setup to support this and only a small amount of extra editing is necessary after remapping the images and before blending.  But it is not trivial and it is high time this extra step was eliminated.
  
Simple tools that allow drawing into the image's alpha channel would suffice for masking out these artifacts. I propose extending the panoramic previewer to enable this type of editing.  Registering each source image as a separate layer and allowing the user to mask out pixels from each individual layer would provide considerable flexibility for this and other future, simple photo-editing tasks.  A layer-based editing interface like this would eliminate the need to fire up Photoshop or GIMP and strong-arm the stitching process except in the most unusual of circumstances.
+
Simple tools that allow drawing into the image's alpha channel would suffice for masking out these artifacts. I propose extending the panoramic previewer to enable this type of editing.  Registering each source image as a separate layer and allowing the user to mask out pixels from each individual layer would provide considerable flexibility for this and other simple photo editing tasks.  A layer-based editing interface like this would eliminate the need to fire up Photoshop or GIMP and strong-arm the stitching process except in the most unusual of circumstances.
  
This also creates implications for bracketed image stacks and HDR exposure sequences.  The presence of an anomaly in a single exposure of a sequence of exposures will cause ghosting when and LDR sequence is combined to make an HDR.  While automatic techniques exist for removing this ghosting it seems prudent to give the user tools to intervene when the automatic techniques fail.  The simple masking interface proposed above seems ideally suited to this.  By making out the anomaly from the exposure in question a user can simply remove the extraneous data in the camera's response curve at the cost of lower sampling at the point in the dynamic range of the scene. As such, I also propose adding the ability to group images into stacks of related exposures so that they are treated as such throughout the Hugin interface.  This work would be parallel to the work on layered masking and together make a single proposal for the 2009 Google Summer of Code.
+
This also creates implications for bracketed image stacks and HDR exposure sequences.  The presence of an anomaly in a single exposure of a sequence of exposures will cause ghosting when an LDR sequence is combined to make an HDR.  While automatic techniques exist for removing this ghosting it seems prudent to give the user tools to intervene when the automatic techniques fail.  The simple masking interface proposed above seems ideally suited to this.  By masking out the anomaly from the exposure in question a user can simply remove the extraneous data in the camera's response curve at the cost of lower sampling of the dynamic range of the scene at that specific point.
 +
 
 +
As such, I also propose adding the ability to group images into stacks of related exposures so that they are treated as such throughout the Hugin interface.  Beyond masking out artifacts in exposure sequences, awareness of related exposures allows other stages in the stitching process to work more intelligently.  For example, aligning a stack of exposures that frame the exact same scene is a process that can be fully automated and has been in many other tools.  It does not require the interaction necessary for stitching adjacent images.  Furthermore, comparing control points across exposure levels is conceptually incorrect and avoiding this requires knowledge of which images are stacked and which are adjacent.  All of this is initially contingent on Hugin supporting the grouping of images into exposure stacks and this initial framework is what I propose developing along-side of the simple masking interface.  These two tasks together make a single proposal for the 2009 Google Summer of Code.

Revision as of 19:13, 2 April 2009

Simple Masking & Bracketed/HDR Exposure Stacks

Panoramas are, by their nature, vast offering a wide view of the world; and the world, unfortunately, is full of things that move. These moving things (animals, well-meaning family members and friends, cars and airplanes) inevitably step into your frame an the most inopportune moments and show up in only one of the overlapping source images. For this reason above all else, masking out pixels is a vital step in the panoramic creation process. Much of the Hugin family of tools is already setup to support this and only a small amount of extra editing is necessary after remapping the images and before blending. But it is not trivial and it is high time this extra step was eliminated.

Simple tools that allow drawing into the image's alpha channel would suffice for masking out these artifacts. I propose extending the panoramic previewer to enable this type of editing. Registering each source image as a separate layer and allowing the user to mask out pixels from each individual layer would provide considerable flexibility for this and other simple photo editing tasks. A layer-based editing interface like this would eliminate the need to fire up Photoshop or GIMP and strong-arm the stitching process except in the most unusual of circumstances.

This also creates implications for bracketed image stacks and HDR exposure sequences. The presence of an anomaly in a single exposure of a sequence of exposures will cause ghosting when an LDR sequence is combined to make an HDR. While automatic techniques exist for removing this ghosting it seems prudent to give the user tools to intervene when the automatic techniques fail. The simple masking interface proposed above seems ideally suited to this. By masking out the anomaly from the exposure in question a user can simply remove the extraneous data in the camera's response curve at the cost of lower sampling of the dynamic range of the scene at that specific point.

As such, I also propose adding the ability to group images into stacks of related exposures so that they are treated as such throughout the Hugin interface. Beyond masking out artifacts in exposure sequences, awareness of related exposures allows other stages in the stitching process to work more intelligently. For example, aligning a stack of exposures that frame the exact same scene is a process that can be fully automated and has been in many other tools. It does not require the interaction necessary for stitching adjacent images. Furthermore, comparing control points across exposure levels is conceptually incorrect and avoiding this requires knowledge of which images are stacked and which are adjacent. All of this is initially contingent on Hugin supporting the grouping of images into exposure stacks and this initial framework is what I propose developing along-side of the simple masking interface. These two tasks together make a single proposal for the 2009 Google Summer of Code.

Personal tools
Namespaces

Variants
Actions
Navigation
tools
Tools