From dhilvert at gmail.com Fri Apr 4 20:34:43 2008 From: dhilvert at gmail.com (David Hilvert) Date: Fri Apr 4 20:35:05 2008 Subject: [ale] 0.9.x release plans Message-ID: <20080404223443.314f4658.dhilvert@gmail.com> 0.9.0 will probably soon be released, with the following changes, already roughly complete in the git repository: * Miscellaneous bugfixes * Optional backing store for (large) images * Multiple alignments per frame, as suggested by Rob Stewart Because of limited testing and possible performance issues with multi-alignment, the new code will probably be added as a testing branch, with 0.8.11 remaining the stable branch. Following the 0.9.0 release, the next 0.9 minor releases will probably look something like: 0.9.1 -- Enhancements to --visp stream processing for video 0.9.2 -- Enhancements to 3D scene reconstruction and rendering The order of these could be reversed, but I've placed --visp first because others seem to have used it more than the 3D code, and because it doesn't have the constraint of requiring a change in camera position to generate valid results. From gmaxwell at gmail.com Fri Apr 4 21:03:26 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Fri Apr 4 21:03:36 2008 Subject: [ale] 0.9.x release plans In-Reply-To: <20080404223443.314f4658.dhilvert@gmail.com> References: <20080404223443.314f4658.dhilvert@gmail.com> Message-ID: On Fri, Apr 4, 2008 at 11:34 PM, David Hilvert wrote: > 0.9.0 will probably soon be released, with the following changes, already > roughly complete in the git repository: > > * Miscellaneous bugfixes > * Optional backing store for (large) images > * Multiple alignments per frame, as suggested by Rob Stewart [snip] I've been following the changes in darcs and saw the multiple alignment stuff but I wasn't entirely clear about what it is supposed to do. Care to expand on it? From dhilvert at gmail.com Fri Apr 4 21:52:37 2008 From: dhilvert at gmail.com (David Hilvert) Date: Fri Apr 4 21:52:51 2008 Subject: [ale] 0.9.x release plans In-Reply-To: References: <20080404223443.314f4658.dhilvert@gmail.com> Message-ID: <20080404235237.1a0cc451.dhilvert@gmail.com> On Sat, 5 Apr 2008 00:03:26 -0400 "Gregory Maxwell" wrote: > On Fri, Apr 4, 2008 at 11:34 PM, David Hilvert wrote: > > 0.9.0 will probably soon be released, with the following changes, already > > roughly complete in the git repository: > > > > * Miscellaneous bugfixes > > * Optional backing store for (large) images > > * Multiple alignments per frame, as suggested by Rob Stewart > [snip] > > I've been following the changes in darcs and saw the multiple > alignment stuff but I wasn't entirely clear about what it is supposed > to do. > > Care to expand on it? The simplest case that it should solve (and does, in limited tests so far) is local mis-registration in sets of frames having small amounts of local movement in some scene area (e.g., due to a non-static scene, change in perspective, or poor lens). Alignment proceeds by breaking the reference frame into progressively smaller pieces, and aligning on each of these pieces. Then, at each pixel in the domain of the forward and inverse maps, one such alignment is selected (e.g., by best error). This approach isn't powerful enough to handle the general --visp or 3D case, but it may be useful as a pre-processor of sorts, since it generates more detailed information about a scene than does Euclidean or projective single-alignment. The current default minimum dimension for subdivision of the reference frame is 10 pixels, but this will probably be increased to 100 pixels prior to release. There are also some things left to code in initialization of transformations and in status display. From dhilvert at gmail.com Sun Apr 6 13:18:30 2008 From: dhilvert at gmail.com (David Hilvert) Date: Sun Apr 6 13:18:48 2008 Subject: [ale] Different-exposure tests fail with multi-alignment Message-ID: <20080406151830.674c94ac.dhilvert@gmail.com> Using multiple alignments per frame with differently-exposed frames seems to break in some cases with current code. This may be resolved in a follow-up release after 0.9.0, probably by accommodating multiple exposures per frame (varying by region), something that would probably be useful to have anyway. From dhilvert at gmail.com Mon Apr 14 15:00:11 2008 From: dhilvert at gmail.com (David Hilvert) Date: Mon Apr 14 15:00:35 2008 Subject: [ale] More on performance and 0.9.0 release plan. Message-ID: <20080414170011.adcb3811.dhilvert@gmail.com> Further testing seems to suggest that performance issues earlier noted in development code may be cache related, and that these may be resolvable by modifying the code generating per-pixel alignment maps so that alignments within small regions (e.g., 10 pixels by 10 pixels) are assigned the most frequently occurring best transformation within the region for those pixels where individual best has similar error (e.g., a difference in error of less than 10-50% or so), hence perhaps reducing the frequency of alignment changes when iterating over the image (as during rendering). As it appears that this approach might be most easily tested after localized tonal registration is finished, these changes may be implemented as one or more follow-up releases, with 0.9.0 based on current code (with its attendant performance and alignment issues). As noted earlier, 0.9.0 will probably be released as a testing branch, so that major problems with 0.8.11 can be fixed on a separate, stable, branch, without involving any less stable code. From dhilvert at gmail.com Mon Apr 14 15:32:45 2008 From: dhilvert at gmail.com (David Hilvert) Date: Mon Apr 14 15:33:04 2008 Subject: [ale] Re: Strange grid appearing on image... In-Reply-To: <4339717E.5080005@groupboard.com> References: <4339717E.5080005@groupboard.com> Message-ID: <20080414173245.55abc485.dhilvert@gmail.com> On Tue, 27 Sep 2005 17:21:18 +0100 Rob Stewart wrote: > Hi David. > I don't think it is an interference pattern. > > I did image manipulation a long time ago and got the same kind of > artifacts. > > The algorithm I initially used would look at each pixel in the > 'supplemental' frame and then calculate where it would go. This meant > that as the supplemental frame was scanned (a pixel at a time) there > would be gaps as the calculations for the destination pixel position > were rounded up (or down). ALE should probably have a bug-tracking system, to make it easier to track things like this; I just noticed this bug report again while sifting through posts for changelog updates for 0.9.0. In any case, this pattern may have been a consequence of a bug in Irani-Peleg code fixed on 31 Oct 2006, and hence fixed in current 0.8.11 and 0.9.0 code. (The bug produced artifacts looking very much like interference patterns.) From dhilvert at gmail.com Mon Apr 14 17:41:43 2008 From: dhilvert at gmail.com (David Hilvert) Date: Mon Apr 14 17:42:03 2008 Subject: [ale] 0.9.0 Message-ID: <20080414194143.d8f5831a.dhilvert@gmail.com> Testing release 0.9.0 is now available for download. URLs: http://auricle.dyndns.org/ALE/download/ale-0.9.0.tar.gz http://auricle.dyndns.org/ALE/download/ale-0_9_0-win32.zip Overview: This testing release allows multiple alignments per input frame, and adds an option for specifying resident sizes for loaded images, allowing more efficient management of backing stores. The current stable branch may offer more reliable performance and results. Changelog: o Add skeletal web documentation to the documentation tree, in doc/web, and revise this to consolidate more information on the front page. o Implement an alignment technique allowing multiple alignments for a single frame. Handling parts of a frame separately to resolve alignment issues (but using match thresholding to discard regions instead of using multiple alignments) was suggested by Rob Stewart. o Add --resident parameter, allowing explicit allocation of backing store for (e.g., large) image data structures. o Check for NaN in linearization and unlinearization in exposure_default, as a possible fix for a segmentation fault reported by Bret Towe.