bugs/issue-918a69e36da1549cf255704c3b9a74a71a6f2ead.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Consider adding bayer pattern auto-detection (e.g., by checking whether extrema tend to occur on particular grids).
   3 desc: ""
   4 type: :task
   5 component: ale
   6 release:
   7 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
   8 status: :unstarted
   9 disposition:
  10 creation_time: 2009-04-01 17:33:53.774829 Z
  11 references: []
  12
  13 id: 918a69e36da1549cf255704c3b9a74a71a6f2ead
  14 log_events:
  15 - - 2009-04-01 17:33:54.360437 Z
  16   - David Hilvert <dhilvert@auricle.dyndns.org>
  17   - created
  18   - ""
  19 - - 2009-04-01 17:35:43.092157 Z
  20   - David Hilvert <dhilvert@auricle.dyndns.org>
  21   - edited title
  22   - ""
  23 - - 2009-04-01 17:39:46.363601 Z
  24   - David Hilvert <dhilvert@auricle.dyndns.org>
  25   - commented
  26   - |-
  27     For status output of (e.g., --bayer auto), consider:
  28
  29      '002.png (RGB )'*** okay (84.073183% match).
  30      '003.png (rgbg)'*** okay (90.266200% match).
  31      '004.png (gbgr)'*** okay (78.123316% match).
  32 - - 2009-04-01 17:46:49.842335 Z
  33   - David Hilvert <dhilvert@auricle.dyndns.org>
  34   - commented
  35   - |-
  36     Consider that, for detecting grayscale uninterpolated bayer patterns (e.g.,
  37     those produced by dcraw -d/-D), it could be worthwhile to check for apparent
  38     similarity within planes of candidate bayer patterns, when compared against
  39     similarity in the grayscale image generally.  Such checks would, assumedly, be
  40     performed solely on images found to be grayscale (e.g., images having all
  41     channels equal for each pixel, if no other indicator of grayness is available).
  42
  43     For distinguishing R/B, the commonest type for the given orientation might be
  44     chosen if no other marker is available (e.g., RGBG in the upright horizontal
  45     orientation is probably more common than BGRG).
  46 - - 2009-04-01 17:47:49.629116 Z
  47   - David Hilvert <dhilvert@auricle.dyndns.org>
  48   - commented
  49   - |-
  50     Note further that autodetection might be overridden by detected values from
  51     the script (e.g., based on a database within the script, or based on output
  52     from a program such as dcraw, should relevant output be available).
  53 - - 2009-04-03 14:10:05.538913 Z
  54   - David Hilvert <dhilvert@auricle.dyndns.org>
  55   - commented
  56   - |-
  57     Note that, perhaps especially in the case of a GUI, a step might be added to
  58     inquire whether a rendering looks OK, or whether red and blue values should be
  59     swapped, and that, in the case that they should be swapped, a request might
  60     be made that the user submits camera info (e.g., via EXIF) for updating the
  61     bayer pattern database, perhaps along with certain program output (e.g., for
  62     determining the assumed pattern, as well as the correct pattern).
  63 - - 2009-04-03 14:23:11.454480 Z
  64   - David Hilvert <dhilvert@auricle.dyndns.org>
  65   - commented
  66   - |-
  67     Consider that, for requesting user input regarding patterns, rather than
  68     requesting any information at the end of a run, a question might be asked at
  69     the beginning (perhaps in conjunction with an image viewer such as display),
  70     and, furthermore, that such questions should probably be limited to the case
  71     where a grayscale bayer is provided as original input.  (In particular, the
  72     case of color input and the case of raws processed by dcraw should be possible
  73     to address in the typical case with no user input [e.g., as dcraw can be called
  74     twice, once generating a color result].  For this case, however, a request
  75     could still be made that a report be submitted regarding the hardware, so that
  76     an addition could be made to the hardware database.
  77 - - 2009-04-04 18:56:15.772655 Z
  78   - David Hilvert <dhilvert@auricle.dyndns.org>
  79   - commented
  80   - |-
  81     Consider that a reasonable first implementation might be to add recognition for
  82     color inputs, either PPM or those read by ImageMagick (as this is probably the case
  83     most commonly seen, and also the case most in need of recognition).
  84 - - 2009-04-04 19:27:00.179279 Z
  85   - David Hilvert <dhilvert@auricle.dyndns.org>
  86   - commented
  87   - |-
  88     Consider that a reasonable definition of a preferred Bayer pattern might be one
  89     that explains (e.g., via a particular sort of interpolation, such as triangle)
  90     the input better than any other Bayer pattern, perhaps by some margin.  An
  91     additional constraint (e.g., such as those previously considered) might be used
  92     to determine whether a Bayer pattern is preferred over no Bayer pattern.
  93 - - 2009-04-05 09:37:11.504870 Z
  94   - David Hilvert <dhilvert@auricle.dyndns.org>
  95   - commented
  96   - |-
  97     Consider that, in the case that orientation information is not present,
  98     hardware database bayer pattern information might still be ignored in
  99     favor of autodetection (since bayer patterns may change with orientation).
 100     A weaker version of this would be to ignore the database bayer pattern
 101     in cases where orientation information is not present and the orientation
 102     is not a horizontal orientation (as observed by input resolution).
 103 git_branch: