bugs: Don't require client knowledge of flattened representations.
[libale.git] / bugs / issue-fe7d4be60f4124201844a23c0d70a87792494f9a.yaml
blob3608157d3b56372c4a8263762e699c9ee572ba59
1 --- !ditz.rubyforge.org,2008-03-06/issue 
2 title: Provide a means of offering rendering including frames just prior to, or clustered around, the current frame.
3 desc: |-
4   avgf provides rendering from first frames, but a generalized technique would be useful,
5   allowing for rendering from recent frames, or frames clustered around a given frame
6   (e.g., for facilitating time-salient visp rendering).
7 type: :task
8 component: libale
9 release: 
10 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
11 status: :unstarted
12 disposition: 
13 creation_time: 2009-03-21 18:14:31.509749 Z
14 references: []
16 id: fe7d4be60f4124201844a23c0d70a87792494f9a
17 log_events: 
18 - - 2009-03-21 18:14:32.286613 Z
19   - David Hilvert <dhilvert@auricle.dyndns.org>
20   - created
21   - ""
22 - - 2009-03-21 18:17:55.990551 Z
23   - David Hilvert <dhilvert@auricle.dyndns.org>
24   - commented
25   - |-
26     Note that the saturation argument appears to provide for this to some degree
27     (e.g., allowing for avgf and medianf), but that further facilities may
28     be required for things like analogous avgl and medianl, or avga
29     (avg about) and mediana (median about).
30 - - 2009-03-21 18:22:04.913045 Z
31   - David Hilvert <dhilvert@auricle.dyndns.org>
32   - commented
33   - |-
34     Note that it might be useful to make AVG/MEDIAN (etc.) independent from FIRST/LAST,
35     perhaps extending the latter group to include an ABOUT (or some such), but that the
36     details of implementation, and interaction with saturation values are not immediately
37     clear.
38 - - 2009-03-21 18:42:08.233573 Z
39   - David Hilvert <dhilvert@auricle.dyndns.org>
40   - commented
41   - |-
42     Consider that, if invariant concerns are made independent, one of the
43     concerns that might be worthwhile to make independent might be the
44     distinction between weight saturation and frame count saturation.
45 - - 2009-03-21 21:55:40.103253 Z
46   - David Hilvert <dhilvert@auricle.dyndns.org>
47   - commented
48   - |-
49     Consider that the correct approach to modifying the saturation behavior is
50     probably to separate saturation into two kinds, one that takes weight within
51     frames into account, and one that does not; the latter would naturally carry
52     over to Irani-Peleg renderers from an incremental reference, whereas the former
53     would not.  Implementation in ALE could proceed with separate invariant types
54     avgf:<x> and avgff:<x>, or some such, in order to simplify the concept
55     somewhat.
56 - - 2009-03-22 11:58:03.886135 Z
57   - David Hilvert <dhilvert@auricle.dyndns.org>
58   - commented
59   - |-
60     Note that weighted saturation might just as well be carried over from incremental
61     to Irani-Peleg renderers, both for the sake of simplicity and because there seems
62     to be no obviously better approach (aside from allowing the client to set the values
63     independently, which can be done implicitly by not propagating settings from
64     the incremental renderer to an existing renderer using this as a reference).
65 git_branch: