Thursday, November 15, 2007

Target imgs: attached, broken, threshold, blob (redefined)

<CC attaching>
39_192
43_196
28_181
17_70
14_73
6_91
3_140
1_114
310_130-138, 99-103
309_145
309_136
307_153
306_153
304_81
303_81
301_159
284_184
283_185
276_192
293_174-173
258_205
257_206
238_216
229_220
210_229
29_182

<CC broken>
305_81
304_81

<Thresh problem>
302_74
295_174
288_54
287_55
286_52
279_47
99_227
97_225
94_12
48_34

<blobs> no angular neighbor in current FOV
229_220
29_182
238_216
257_206
258_205

Thursday, October 25, 2007

CC detach, filtering

  1. dealing with remaining CC after noise removal
    1. do we re-index the obj so that the indices are an array of continuous numbers?
    2. this means to re-index each pixel in the matrix, which requires time
    3. we can use a dict to record the remaining indices in the CC map, which takes space of only 10- elems
    4. go with dict !!!!
  2. Matlab boundary detection
    1. [B,L,N,A] = bwboundaries(BW);
    2. % B = {obj, holes}
    3. N = n_obj
    4. A = [boundaries, r vs. c =  enclosing(i_obj_in_B) vs. enclosed(i_hole_in_B)]

Tuesday, October 23, 2007

top as CC or bottom as CC?

Prerequisite

  • For any edges of a CC
    • the inner edge (of shorter radius) is indexed as (1), outer (2)

Top:

  • Pros
    • more direct and intuitive for CC analysis
      • no Inf in the data range, and they are really "connected".
    • edges are valid depth data
      • when calculating depth of the groove bottom, the depth of the top is directly available.
  • Cons
    • the edges are not the boundaries of the same groove, making the forthcoming groove locating more complex.
      • to locate groove(k), we have to get CC(k+1).edge(1) and CC(k).edge(2)
      • with another orientation (e.g. 12 o'clock), it might change into CC(k+1).edge(2) and CC(k).edge(1)

Bottom

  • Pros
    • more direct and intuitive for later polar coord extraction for grooves.
      • always CC(k).edge(1), CC(k).edge(2)
  • Cons
    • the CC analysis is less intuitive, need to combine the sidewall and the bottom as a pseudo-CC.
    • no valid depth value on the edge
      • when addressing the depth of the bottom, the reference depth of the top should be derived from surrounding area. This require a branched navigation to find adjacent valid area,
        • At 10 o'clock, go from 5-10 o'clock for edge(2)
        • At 2 o'clock, go from 8-2 o'clock for edge(2)

Saturday, October 20, 2007

Friday, October 19, 2007

rewrite Matlab CC analysis

Description

  • Matlab CC analysis assumes that the image can be loaded into memory. But in our case, stitched matrix exceeds the memory limit. We cannot do a CC analysis of the grid using Matlab native function.

What I want

  • Trace the groove smoothly across FOVs without hassling at the boundary.

How I can have them

  • Mark the areas in the grid as CCs, link all CCs in all frames
    • When crossing the boundary of two adjacent frames, find the CC Y in FOV B that is the continuation of the CC X in FOV A
    • This can be a round trip, because all CCs are essentially one. So the output of this step is a chain like: Obj 1 in FOV-1, Obj 4 in FOV-2, ....., Obj 3 in FOV-2, Obj 6 in FOV-1.
    • Exceptions: a node in this chain can have several FOVs (overlaps). So the chain is actually a tree.
      • How to build the tree?
        • Global: need a head and top-down
          • Pros: conceptually easy.
          • Cons: directional, need decision making about the spread direction.
        • Local: for each FOV, find its precedents and successors
          • Pros:
          • Cons: still need to determine which FOVs are precedents / successors, even harder than global approach, because there is no "spreading" at all, so the direction is N/A.
      • What will avoid direction decision?
        • Angle, with the center coord, we can determine the angles of the entry/exit points.
  • Select one of them as a current obj of interest and trace through it, collecting radial distances and depths.
  • When I collect radial distances of the target positions, I don't have to deal with boundary again, just go with a label map
    • find all pixels with a label "i".
    • calculate the radial distances without having to care about the order of these pixels.
    • we can sort the pixels in terms of the angular order later.

Any assumptions associated with this workflow and any exceptions

What I need to deal with the exceptions and achieve the original goal

What I have

What I don't have

What I shall do next