回国要干的几件事情

1. homepage: documentation, writing
   of chapters

   
   

   1. MitAC (a framework to be filled in with detail when coming back to Canada)

      
      

      1. Wiki transcription

         
         

      2. Blog transcription

      1. Hardware/Software: lens, stage, inabilities, unuseful functions
      2. Measurement: focusing, automation, capture capability, data view
      3. Stitching
      4. Restore
      5. Fitting
      
      

   2. Label Recognition (project brief,
      paper link)

      
      

   3. Audacity (project brief, paper
      link)

      
      

   4. Remote Metadata editor

      
      

   5. Metadata formatter

      
      

   6. Breakbeater

   7. Other course projects

   8. Other interests (mastering,
      karaoke)

      
      
   
   

2. coding: music_man, breakbeater

   
   

3. reading

   
   

1. homepage: documentation, writing
   of chapters

   
   

   1. MitAC

      
      

      1. Wiki transcription

         
         

      2. Blog transcription: measurement
         

         
         
      
      

   2. Label Recognition (project brief,
      paper link)

      
      

   3. Audacity (project brief, paper
      link)

      
      

   4. Remote Metadata editor

      
      

   5. Metadata formatter

      
      

   6. Breakbeater

      
      

   7. Other interests (mastering,
      karaoke)

      
      
   
   

2. coding: music_man, breakbeater

   
   

3. reading (machine learning, algorithms)
   

   
   

回国要干的几件事情

1. homepage: documentation, writing
   of chapters

   
   

   1. MitAC

      
      

      1. Wiki transcription

         
         

      2. Blog transcription

         
         
      
      

   2. Label Recognition (project brief,
      paper link)

      
      

   3. Audacity (project brief, paper
      link)

      
      

   4. Remote Metadata editor

      
      

   5. Metadata formatter

      
      

   6. Breakbeater

      
      

   7. Other interests (mastering,
      karaoke)

      
      
   
   

2. coding: music_man, breakbeater

   
   

3. reading (machine learning, algorithms)
   

   
   

ramp intensity vs. single scan settings

1. under 1X VSS, initial intensity is better to be 13, 14 doesn't do much more and saturate the top.
2. ramp intensity gives much better bottom capture then without ramp
   

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

pyMuTag: Pilot

Done

1. Multi-page task and preview+2-level target selection
2. Object design

TODO

1. MVC with each page: M=Tagger+DirTree, V=preview, C=Notebook_page
   
2. link dir-tree, preview, tagger, and notebook
3. UI-threading with notebook
   

config update: test measurement and initial thinking

<test config>
1. backscan depth, modthresh
2. speed, intensity
- FilterIntensity0=1,85
- VSISpeed=23
--V:11, I: 52
--V:3, I:23
--V:1, I:14.5
3. specify grid files in config
- STAGEFILENAME=
4. tilt
5. automation
- AUTORUNFLAG=1
- RESETSEQUENCE=1
- USESTAGE=1
<refocusing>
1. see whether backscan accounts for measurement,
if true, then starts really low, we are still fine
- true
2. two-phase, focus stay deep below the bottom
- phase 1, use only backscan and set depth to zero; those who cannot survice this phase need refocusing in phase 2
- phase 2, from the analysis of phase 1, we refocus

<organize output opd from iteration>
- good data accumulate in a group

- bad data found -> compare with stats of the good data,

<reginal random sampling>
don't do full random, finely divide the entire surface into subrigion, then sample within each (sub dividing scheme flexible)

<python>
1. ini parser

<matlab>
0. grid division and sampling
1. opd analysis
2. output read-for-parse to python
3. read history of python

1. if starting high above,
- then we tend to miss bottom > top from above
- to get the top and hopefully the bottom again, we need to lower the lens or enlarge the depth
- matlab should
- extract all problematic FOVs,
- put them into a new grid
- make the decision whether to do a manual turret-- or simply depth++
2. matlab also need to
- to move up or down?
- no idea, unless we try twice, first down, then up
- how much for the next iteration?
- if new backscan+length > THRESH, we need to manually refocus

3. top only, if down 1*gd (groove depth), if bottom only or nothing, back up for 20um; init focus?
4. NO USE measuring initial depth, because whatever result we get, even if we ge the top, we don't konw which portino it appears along the veritical scale of our chosen depth

<grid>
1. grid should be calc through multi-parts of the whole circle, right half has larger radius!!
2. remedy code, enlarge circle!

config update: planning tree

<a tree of update history>
1 why?
- at each new update, unexpected results may come out, they may differ from the previous parent type
- this can be recursive; at each node, we can only deal with one type of error; assume after we deal with type 2, 3, 4 at itera 4, which is a result of type 2 in iter 3, we wanna go back to type 4 in iter 3.
- so, we need a tree to store the state of: parent list of error type, their state of completion (yes/no),

2 use what for a tree
- why not structure?
- because every time u run an iteration, i creates half-complete nodes, and then in next iteration, u need to go back, structure doesn't allow you to go back without a pointer.
- a matrix table
- [v_node(1);
...
v_node(i) ]
- node: [i_branch,
i_parent,
vi_child,
i_iter,
i_type,
b_done],
i_node_active
- children (x3) stay together linearly. no explicit Parent node, they are from prev 3-unit group. So 3x siblings in a row

3. when to add node?
- when updating config and generates new error group stage files, they have to be properly named to reflect the tree structure: branch, iter/tree-level, type/leaf, to avoid being overwritten by other updates or overwriting existing ones.
- depth first: add occupiors for siblings all at once, then add childrens before implementing siblings

4. how to update nodes
- when creating:
- direct: i_type, b_done
- derive: i_parent, i_iter, i_branch, (invoke parent), new subgrid filename.
- should be known when running this iteration
- unknown: vi_child (?)
- when updating:
- parent node invoked by the newly added child nodes to the tree
- parent add vi_child
[i_branch,
i_parent,
vi_child,
i_iter,
i_type,
b_done],
5. how to traverse, save, and load tree
6. how to name the output files

config update: planning and pitfalls

<Usecase config>
1. User creates original grid
2. User creates grid sample set by setting 2D downsample
3. User focuses on first random FOV.
4. User starts 1st iteration on all samples across sub-grids
5. Computer analyzes results from 4 and output 4-type classes
6. Computer puts Type-1 from this iteration to scan queue
7. For each of Type-2 ~ Type4, repeats 3~7, when new children branch out, recursively do the same, whenever the children are complete, i.e., no further Type-2~4 out, go up for parents till it seeks back to the top node, whose parent is NaN;
8. Note, there is supposed to be identifiable opds under temp folder whenever fov_verify() is called. they have to match the scan tree-traversing sequence, e.g., it's always type2->type4, and depth-first

* pitfall
- type 2 and type 3 can't miss 2+ times,
because the depth range is pretty confined: top only and
bottom only, with scan-depth being rather narrow, ensure that FOVs are pretty aligned vertically, so if one of them works, all the other in the same group should also work.
- so making a recursive structure for type2 and 3 is overkill, there will be at most only two levels.