History: Notes on detaching

Note: 2008-6-23
<ich meeting>
1. webpage highest prioty
2. connect and search holes, keep tips, without contour
3. one center measurement each session
4. stitching on drifted results
5. ITS&T
6. ask engineers about bottom capture (send pic)

Note: 2008-6-19
<scan config update>
1. specify start-cell when creating .stg.
2. tree building
- when child filder is done, it's parent folder should be labeled as done, too.


Note: 2008-6-14
<rethink detach>
1. goal:
- split a hole-filled CC into two that are obviously separate to human, given the visual cue of large area of holes.
2. basic idea
- merge major holes so that the CC portions on both side of such a hole-string are consequently isolated.
- merge ~= connect, cuz "merge" aims to form a continuous and thick sector of specific boundary-like shape, instead of wild connection
3. two types of holes
- sector holes: visually aligned under similar radius
- noises: wild holes that are either far from the mainstream sector holes or though near enough, too angularly overlapped with major holes to contribute on its own.
- here "angularly overlap" = A can be projected onto B without changing B's angular shape

4. problem
- how many grooves are in this mixture?
- how many lines of holes
- mixture width
- how to group holes in terms of the number of grooves?
- rule out noises, why?
- they split wrong part
- if they are there, any ways to get around? ignore or merge -> if too far from mainstream, can't merge, then ignore.

5. thought on 4:
- if we know there is only one mainstream (2 grooves), then we can define "angularly overlap" easily, and rule out any outliers against the mainstream
- this requires accurate estimate of width -> taking out max_w_ho width when calc w_grv
- a hole can belong to onlly one sector
- first group, then merge, there will be several container CCs in the group
- for each hole, it's revo successor should be defined with its size in mind, i.e., no hard thresh on radial distance, but weighted with the hole-of-interest's size -> small hole -> small tolerance of radius error, the search should happen at the interface, i.e., the cut.
- the above thinking suggests that we are creating the mainstream sector in a gradual linked list fashion instead of a global parameter (radius)
- angular sort -> pick a valid angular successor

6. practical
- inner hole decision: boolean "=" -> abs(diff)<epsilon
- search boundary overlap -> radially overlap -> region growth
-

7. filter: remove angularly overlapped small CCs
- angular contained
- [a, b], vs. [1, 2; 6, 9; 15, 90]

8. old thoughts of linking holes
disp('% sort the holes angularly')
disp('% get link anchor angular pos, in pairs, and the thickness at the pos')
disp('% from anchor to anchor, make the range of pixels as thick as at thicker anchor angle')

9. new thoughts on linking
- polar angular search: for both ends,
- find a point as the origin,
- start with the norm direction,
- scan through the whole plane counter/clockwise to find first hit as the bounding points of the other end;

10. just enough!
disp('% get link anchor angular pos, in pairs, as the angular extreme points')
disp('% dual-way polar scan for true polygon anchors')
disp('% connect inner anchor and outer anchor pairs')
disp('% take new ho as a CC and find its own inner "hos", fill them')
disp('% from anchor to anchor, make the range of pixels as thick as at thicker anchor angle')
11. fill polar range
- only 50% success rate at most
- new noises need to be removed
- porous structure can't be connected easily and still undermine CC ananlysis
- can porousness be detected and solved globally?
12. debug
- current problem: small gap not linked; link stength not consistent; porous stucture may give thin width
- current obstacle in code: too long for loop, hard to avoid naming override
- what to do: focus on 1 FOV,
- possible effort:
- deal with porous structure
- simple link with enough strength
- complex link with boundary emcompassing and hole filling
13. chain hole span
- combined span eats large hos and preserve earlier small member hos
14. tree method -> simplified
- v_ho = sort_by_thickness(ho)
- for each ho
- vi = find(overlap in whole chain)
- for each parent





Note: 2008-6-7
<select and merge holes>
1. end goal
- classify hole revolutions
- create seamless and a sufficiently thick "single" hole for each revolution
- can have outliers, but they should never affect the CC analysis to generate attached CCs

2. histogram hole radius rg, get rid of small holes that branch out the main hole revolution