bugs/issue-e9fed8b2d39321d520c90e584bc26f132ae355d8.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Consider merging approx and frame types (into 'frame'?), with formats {bayer} x {weighted}, and resolution for libale-{17,19}.
   3 desc: Formats would be (RGB, RGBG, BGRG, GBGR, GRGB) X (WEIGHTED, UNWEIGHTED).  (defaults?)
   4 type: :task
   5 component: libale
   6 release:
   7 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
   8 status: :closed
   9 disposition: :fixed
  10 creation_time: 2009-02-11 21:48:13.489277 Z
  11 references: []
  12
  13 id: e9fed8b2d39321d520c90e584bc26f132ae355d8
  14 log_events:
  15 - - 2009-02-11 21:48:14.138242 Z
  16   - David Hilvert <dhilvert@auricle.dyndns.org>
  17   - created
  18   - ""
  19 - - 2009-02-11 21:53:55.346332 Z
  20   - David Hilvert <dhilvert@auricle.dyndns.org>
  21   - commented
  22   - Naming such a merged data type 'image' would probably better match ALE terminology.
  23 - - 2009-02-12 10:17:57.149386 Z
  24   - David Hilvert <dhilvert@auricle.dyndns.org>
  25   - commented
  26   - |-
  27     Perhaps better than combining the types would be incorporating new formats
  28     (esp. bayer) into the approximation type; in particular, the approximation type
  29     is always linear, and hence naturally linearly accumulative, whereas the frame
  30     type is generally not, making combination of the two perhaps somewhat less than
  31     convenient.
  32
  33     One approach to combination of the types, that may obviate these concerns,
  34     would involve disallowing any accumulative operations for certain
  35     configurations (e.g., non-floating point types, non-zero black level, and
  36     non-linear gamma).
  37 - - 2009-02-12 13:15:42.775264 Z
  38   - David Hilvert <dhilvert@auricle.dyndns.org>
  39   - commented
  40   - |-
  41     One advantage to having a combined type (aside from the obvious Irani-Peleg case)
  42     would be naturally allowing loads into approximation types from client code (as this
  43     behavior would be required in any case for frame types).
  44
  45     Prominent challenges to combination of types would probably include ensuring adequate
  46     predicate checks and providing an adequate range of functions for handling each of
  47     the sub-types.
  48 - - 2009-02-12 14:44:42.686169 Z
  49   - David Hilvert <dhilvert@auricle.dyndns.org>
  50   - commented
  51   - |-
  52     Note that certain interface elements of frames (esp. bayer patterns) are analogous
  53     to patterns (esp. sub-pixel positioning and rendering) that might be eventually
  54     useful for approximation types, so that a combination might be useful for this reason
  55     also, in addition to other reasons earlier noted.
  56 - - 2009-02-12 18:28:38.872208 Z
  57   - David Hilvert <dhilvert@auricle.dyndns.org>
  58   - commented
  59   - |-
  60     One approach to resolving the predicate check problem might be to make images
  61     have strictly linear properties (black=0, linear gamma), and to introduce
  62     non-linearities as part of a transformation object operating on an image.  In
  63     this way, there would be no restrictions on operations such as accumulation,
  64     so that operations allowed for frames and approximations would become roughly
  65     equivalent.
  66 - - 2009-02-12 18:34:03.722666 Z
  67   - David Hilvert <dhilvert@auricle.dyndns.org>
  68   - commented
  69   - |-
  70     In addition to black and gamma, exposure might also be moved from frame into
  71     transformation.
  72 - - 2009-02-12 22:21:57.753142 Z
  73   - David Hilvert <dhilvert@auricle.dyndns.org>
  74   - commented
  75   - |-
  76     Note that bayer patterns (and any sub-pixel positioning) might be moved into
  77     transformation, and that the frame type might have a simpler set of varieties
  78     (perhaps between 1-channel and 3-channel types).
  79 - - 2009-02-13 12:15:27.474904 Z
  80   - David Hilvert <dhilvert@auricle.dyndns.org>
  81   - commented
  82   - |-
  83     On the topic of moving structures into transformation, PSF might also be
  84     associated with transformation (perhaps with adjustable parameters for
  85     determining frame properties, including possibly focus and shake -- although
  86     the former should probably eventually be incorporated into 3D code).
  87 - - 2009-02-16 18:11:12.360337 Z
  88   - David Hilvert <dhilvert@auricle.dyndns.org>
  89   - closed with disposition fixed
  90   - |-
  91     Types under consideration have been merged, with certain parameters migrated
  92     as suggested.  Further incorporation of parameters (e.g., PSF) would probably
  93     be appropriate.