Stitching: microscope scan path vs. DP

Microscope goes col-by-col, then row-by-row.
So we have less horizontal drifts than vertical ones.
So we can use greedy on horizontal and DP on vertical.

Stitching: image alignment major failure

We used "Greedy" method that only align newly introduced images with the ones already in place, regardless images that haven't been put in the array.

In our case, 690 rows of images, one-pixel vertical error per row will cause an accumulated vertical error as large as one FOV!!

DP is necessary.

FOV chain

Chain start has to be found.

Start with lowest FOV (assume disc is placed in normal position):
[r_grid_max, c_grid_mid]

For each CC in FOV, try to load gridcc_next recursively;
If c_grid_next == c_grid, we found a valid start, which leads to its inner neighbor successfuly.
If c_grid_next not found, then we reached a deadend,
move to [r_grid_max-1, c_grid_mid]

sting removal: w/z not robust at all

give up on sting removal

w/z not robust.

and in/out pairing up should move to stitching-main

Interview: Tell me about yourself

Tell me about yourself (2 minutes)

1. About myself, I have professional and personal tracks.
2. I have been doing image and audio related research and development for the past 7 years.
3. Actual
   Experence: My most recent experience has been doing an innovative
   multi-disciplinary research that involves optics, image recognition and
   digital audio signal processing. 
4. What I gained: I've developed good R&D methodology, organized research and programming styles.
1. Research content: This work is unique; it requires to deal with a programmable white-light interferometer microscope, which involves mechanics and optics, and with millions of images that contain grooves at micrometer-to-nanometer level;
   all of them need to be recorgnized in the image domain yet eventually
   interpreted in the audio sense. This is the kind of work that needs
   both patience and imagination, which are both my strength. I gained
   interesting signal processing experience in connecting both domains.
1. My
   other strength is in R&D methodology: From various experience of
   working with new problems that involves massive data with little
   reference to resort to, I have cultivated an organized and cautious
   research behavior and programming style that works pretty well with
   exploration of ideas and constant evolution in algorithm implementation.
1. In a procedural research, I strive to do a depth-first style to try moving forward
   towards the end result in the early stage of research, and skip little
   bumps as fast as possible until a skeleton workflow is built up.
2. Then
   as the whole problem gets better understood during the course, I would
   then work on each step of the workflow or adapt the workflow according
   to any new surprises. 
3. For recorgnition problems, I would start
   with creating a meaningful and precise data
   visualization that helps me verify any change that my real work
   makes, and I use incremental tests on my extremely large datasets for
   any new idea or step in a workflow; 
4. To
   ensure any failure during long experiment running time, I have detailed
   temporary data storage and retrieval schemes, so even a power failure
   wouldn't cost me too much.
5. My coding style makes such
   evolutionary processes easier by using systematic naming conventions,
   template-functional design pattern, and I would tidy things up whenever
   new functions come into the whole system with necessary code
   refactoring. As a result, my main client routinesseldom change.
6. I respect performance optimization in coding but I use them only after I have better understanding of the problem.
5. I
   have pretty good sense of presenting ideas, work, and very considerate
   about applying various design principles to my presentation more
   comprehensible and efficient.
6. I'm strong in independent problem-solving.
7. In
   various research projects and extra-curriculum work, I've also worked
   in teams, as a member and the coordinator as well. People often find me
   an easy-going and cooperative person.
8. When having to meet dealines, I'm very flexible and adaptible in my R&D approach;
   if brute-force works better in such a situation I would just use it.
   When the automation of the microscope wasn't working well, I manually
   scanned 700 images to meet the deadline.
9. What I'm looking for now is a challeging project that's more widely applicable, using my experience, knowledge and skills, and I'd like to join a strong team and have a positive impact on the R&D process.

Interview Memo: high level construction

Prepared topics

1. Myself: experience, training, knowledge, soft skills, not in CV
   
2. Past project: Handel, Webcast, Music Tech projects (screenshot, code samples)
   
3. Research: content, method, value
   
4. Company
   

Bottom line

1. Maybe I can't answer all question. But I can answer those that are not supposed to be failed.
2. I'm supposed to know my own research inside out.
   
3. Confidence
4. Decisive
5. don't lead the interview, let them guide you.

bottom 1D: sidewall based thinning

Problem

1. broken bottom
2. get the real 1D ones
3. simple features: median radius, lowest points, not satisfactory

Analysis

1. bottom = "lowest sidewall tip band"
2. from outer band to inner band, the extreme radial positions are sidewalls for sure?
3. If there is just one point, then no sidewall to analyze.
4. The acquired band is usually 2D, tangentially thick layered. So extracted 1D should be a vector instead of one single point.
5. Then the real 1D point, should be picked from the vector according to p-to-line dist.
6. #4 does the radial picking, #5 does tangential picking
7. Need to check the z-contour of bottom: under various resolution, they show certain trail of stylus tip across band, though extremely noisy.
   
8. cannot assume all bottom points are distributed across the groove center.
9. so we have to make sure which of them belong to which side of the walls.
10. ASSUMPTION: the 1D point is among the detected points.
    
    

Implementation

1. find center by in/out edge.
2. divide 2d band into in/out wall groups.
3. linear fitting on both sides,
   
4. find the cross as the center.
5. if one sidewall is missing, assume its delta_r/z with prev is proportional with the edges'.
   

New tertiary build: accumulated error in finding outer-edge pair

Problem

1. Line-equation algo introduces error.
2. This error accumulates along the iteration, if we start search from each (prev+1) location
3. Error is due to the "min-dist" scheme, which ignores the actual numerical tangential error.
   

Solution

1. There has to be limitation in tangential error.
2. What would be the threshold?

Major analysis

1. Outer/inner edges are noise signal.
2. We expect that they should be 1v1 relationship, while in reality they are not due to stings and other noises.
3. Tangential Redundancy: should be defined as "if two inner points find a common outer pair, then one of them is redundant."
4. In Case #3, preserve only the 1st inner point along the tangential direction.
5. Since inner signal has bigger tangential density, we need to remove inner-edge redundancy first.
6. Bottom has the most redundancy because it is the most 2D-ish among the tertiary edges.
7. Too strict line-equation would miss out bottom band completely.
8. Too loose line-equation would carry neighbor and select wrong band.
9. Bottom has to be found through 2D measure.
   
10. We need to try the sidewall-tip idea in 1D, and ensure no redundancy in the other 1D.
11. Bottom tangential redundancy can be removed by assuming bottom depends on both edges.
    
12. W2Z Reference should use "majority" instead of "mean".

Implementation

1. Do regular tertiary search based on inner edge.
2. Do redundancy check against outer-edge along the way instead of a pre-step.
3. After inner/outer pair determined, find bottom band with inner/outer line-equation.
4. For bottom, when using minimum point-to-line distance measure, should discard redundant result (pick the first non-overlap point from sorted distance list).
   

tertiary: bottom from in/out pair

Problem

1. line-equation: dist from bottom to in/disc-center line diverse. hard to threshold.
2. pair azimuth range lock: too narrow to catch anything

Solution

1. in-center line equation: with flexible CLOSENESS threshold
2. include previous point into the search process (only way to work)
   

update_neighbor: some new ccs are found having bottom

Cause

• a few noises recognized as bottom,
  
• they exist in ho area, i.e., not contained by any CC
  

Solution

• in btm_indexed_by_container(), remove noise btm, and redo cc_analysis for btm.
  

Pictures to take with microscope

1. grid
2. bottom with jags
3. 11X acquired image

bottom 1D from 2D: linear slope problematic

the prev linear slope algo needs to have both sidewalls to work.
if one side wall portion is missing then there is no way to find the true stylus tip

audio alignment: edge , bottom

linear interpolation to get same azimuths at the overlap between prev and cur FOV.CC.win.edge.
get dr, dz,
apply to cur FOV
merge cur with main thread

image alignment redesign

Used simpler and straightforward design to update FOV locations.
Dealt with too-large views when trying to display them; divide and conquer, currently only 2-piece display

image stitching revisit

Problem

1. inter-FOV z diff is always present.
2. align them in image domain or audio ?

Analysis

1. If z un-aligned in image, later update_neighbor() filtering will transfer wrong z values to neighbor-FOVs that don't align with the focus-FOV.
2. Stitching in image registration gives rough result that's visually satisfied.
3. Stitching in audio registration yields aurally satisfied refined stitching.
   

remove sidewall imp

1. for each bottom_thread(cc), 
2. - for each overlap_pair,
3. - - get median_a of each btm
4. - - get edges(a) from line_equation()
   
5. - - get valley-center(a) from edges(a)
6. - - get delta_r(center, median_a)
7. - - sidewall.append(bigger delta)
8. remove sidewalls and re-cc-analysis
9. for each bottom_thread(cc)
10. - for each non_overlap_pair,
11. - - #3-5
12. - - get delta_r(center, median_a) / width(a)
    
13. - - sidewall.append(delta > THRESH)
14. remove sidewalls and re-cc-analysis
15. update edge(3)
    

remove sidewall

Problem

1. Sidewall may not overlap with anything or slightly overlaps if there is no bottom in center area.

Solution

1. using center valley as reference, check out 1) for overlapped pairs, which one is closer to the center; 2) for non overlapped bottoms, threshold them with off-center ratio.
   

Presentation: lab meeting

Top level

1. Post scan: Workflow
2. Mechanics and physics
3. Sampling
   
4. Note: explain why, how, and why again.
   

Post-scan

1. Workflow:
   
   
   
   1. FOV alignment (2D, 3D),
      
   2. Polar coordinate system
      
   3. Segmentation: extracting tertiary glyphs: groove spacing area, groove valley, and groove bottom.
   4. Filtering: blobs from dirt and thresholding error from, e.g., damaged groove spacing.
   5. Restoring grooves: detaching, reattaching, sidewall removal, sting removal
      
   6. Groove edge extraction
      
   7. Groove unwrapping (windowing)
      
   8. Groove bottom thinning
      
   9. Resampling and fitting
      
   10. Stitching
       
   11. counter-EQ (optional)
       
   12. Stereo decoding and audio output.
       

Mechanics and Physics

1. VOS
   
2. Depth irregularity and Coarse-to-fine vertical scanning parameter derivation.
3. Resampling dillema.
4. Bottom capturing: Ramp intensity
5. Stage drift and counter-strategy.
   

tertiary build-up + sting removal bug fix

tertiary is needed twice.

1. 1. sting removal
2. 2. bottom thinning
3. so, need a function
4. [vaa_pair, ca_vaa_btm] = tertiary(vaa_in, vaa_btm, vaa_out, common_range)

Sting removal fix

1. previously we use inner-bottom, outer-bottom pair without pairing up inner/outer,
   
2. this is wrong.
3. first, removal angular redundancy,
   
4. then, built tertiary,
5. finally, remove sting via w2z verification.

small blobs percentage

2825/3223 = 87.65%

bottom 1d from 2d

Problem

1. radial thinning disregard neighboring azimuths and creates choppy line
2. tangential thinning tends to drift apart, i.e., deviate from the ideal center of groove bottom

Solution

1. somehow combine the two: weighted average of the two results.

Analysis

1. what we do NOT want to see: a locally(at its own azimuth) optimized btm-pos that disintegrates from its context.
   
1. 1D-btm(a) deviates to the back or front (tangential error): goes behind the previous point or beyond the next point.
2. 1D-btm(a) deviates to the left or right (radial error): causes w/z to fluctuate (stylus shape distorted).
   
2. what we want the 1D-btm(a) to provide: 
1. a(i) > a(i-1)
2. abs(r(i)-r(i-1))<e, e.g. 2pixels
   
3. dr_btm is similar to dr_in, dr_out
4. abs(w2z(i) - w2z(i-1)) < e

Imp

1. #1 elem: 1D-btm(1) is chosen according to any of : 1) lowest, 2) middle, 3) equal w/z for in/out.
2. #2+ elems:
   1. vp = closest_to_line(e_in(a), e_out(a))
   2. vpp = find(vp(a)>a(i-1))
   3. p = min(abs(r(a) - r(a-1))) or
      
   4. p = P * min( (w2z_out(a) - w2z_out(a-1)) / w2z_out(a-1) ) + Q * min(.... w2z_in....)
      
   
   

thresholding: cc analysis

200 * wavelength(82.5415nm) = 15um

This corresponds to our measured min-depth of grooves.

Previously, we used a histogram and try to find the population drop, based on the fact that bottom is thin and thus contains much less points than top. And tried to refine this value by applying a depth difference thresholding.

This method fails at noisy depth data and the changing depth of grooves, where bottom can be fairly close to some part of the top. And when top depths vary, they scatter into different histogram bins with huge population difference, making thresholding based on population very hard.

Failed methods and params

1. rg_ratio_population_drop: values does not matter much
2. delta_z: essential
3. z_peak: most population, actual peak, bin_thresh+1
4. thresh = mean/median (z_peak, z_btm)

The above data didn't prove robust.
thresh = z_most_popular - magic_thresh, i.e., 15um.

CC analysis: based on bad-data first (thresholding not robust)

Problem

1. thresholding not robust, a overly hi-thresh tends to bring top-edges to the ground -> bottom.

Solution

1. find bad data (Inf) first, what's inside of it are bottoms, the rest of the FOV are tops.

Imp

1. good data <= 1, bad <=0,
   
2. CC analysis, 
3. get bad-contained CCs -> bottom
   

detach: sidewall-faked bottom causes false-alarm

Analysis

1. If no holes in b/w the two btm-chains of a CC are found, mark this as non-attached CC
   

sting removal

Problem

1. sting removal tends to ruin non-attached/broken FOVs.
   

Solution

1. only apply the sting removal to attached/broken FOVs.
2. for other FOVs, only apply radial-redundancy removal.
   

bottom 1D from 2D wrong!

X: 1D bottom azimuth positions
Y: their index in original bottom 2D band

What's wrong here?

1. Some consecutive azimuths have same bottom 2D points (overlapped). They should have been monotonously increasing indices.
2. Instead, this curve means we will have "blur" problem if not angularly resampling/filtering carefully.
3. This also means, bottom thinning is problematic. Neither deepest-rule nor median-radius-rule would give us smooth continuous bottom trace.
   

How to solve this

1. resampling over each azimuth, if the tertiary has any overlap with the previous, it has to be discarded or adjusted to pair up other points.
2. we need to delay the fix? verify whether this fix will significantly improve sound quality?

Webcast survey brainstorm

Question categories

1. About the user: Location, Age, ....
   
2. Getting start with webcast: How did you find webcast....
   
3. How do you use webcast: where...
   
4. What do you think of webcast: speed, sound quality, ...
5. Other comments

Candidate questions

About you

1. Which country are you usually in when listening to the webcast?
2. How old are you?
3. Are you (a McGill students, faculty, or staff, or alumni, family or friend of a performer in volved in the concerts being webcast by us)?
   

Getting started with the webcast, as a user:

1. How did you hear about our webcast?
2. Did you find the webcast service user-friendly?
3. Are you satisfied with the network connection and streaming speed?
   
4. Are you satisfied with the sound quality of our webcast? If not, give what is in your mind.
   
5. Did you like the concerts that we selected?
6. The concerts being webcast are all by McGill musicians. Which specific McGill musicians would you like to be webcast?
   
7. Did you like the hosting, interviewing, and other non-music content in some programs? Did they help you gain a better experience of the program?
8. In some programs there was not much hosting and interviewing, would you like us to add more?
   

Getting started with the webcast, as a non-user:

1. If you have not heard about the webcast, would you be interested in trying it? Why?
2. If not, why?

Publicity and on-demand service

1. Via which of the following ways do you prefer to receive our webcast announcement?
2. If you are interested in a concert, do you prefer listening to the on-site webcast or downloading concert recording later?
   
3. If the recording of a concert being webcast will be available for downloading later, would you still like to listen to the webcast?
4. What media format and quality specification do you prefer as downloadable audio?
   

Other comments

1. How do you like our webcast in general?
   
2. Please tell us what could be done to improve our webcast service.

Plans

What do we have now

1. code, except for RIAA EQ
2. no doc
3. no presentation
4. no report

Work to do

1. documentation, report, presentation.
2. test existing code, may need more fitting
3. scanning two albums (jazz, classical)
   
4. coding on my personal software: tagger, breakbeat
   
5. chuck
   

Readings

1. microsound
2. art of listening
   
3. linux tutorials
4. computer networks
   

Other activities

1. prepare CVs for interns
2. start translating
3. canadian news
   
4. french
   

What should stop

1. unrelated news: like the chinese ones.
2. kanichi should definitely stop except for exercise.
   

resample for windows

Problem

1. each window should start fitting at an azimuth that is consistently spaced from the prev window.
2. this spacing is determined by samplerate and initial azimuth in Win(1).
3. so Win(i) should always know where Win(1).va(1) is.

Solution

1. Win(1).va(1) should be saved somewhere.
2. Condition 1: Win(i).a_start = Win(1).va(1) + N * a_per_samp.
3. Condition 2: Win(i).a_start >= Win(i).va(1) + LEN_WIN
   

need to keep the disc rect coords even after unwrapping

used for pairing in bottom-1D-to-2D

window-based calibration

1. Resulting 3 threads from stitching and unwrapping are not calibrated, i.e., each window of a different thread will have different
2. inner/outer edge + bottom of Win(i) need to be calibrated so that they all start/end at the comparable azimuth.
   

calibrate edge windows

Problem

1. Later fitting needs to apply to window instead of entire main thread
2. final stitching requires no overlap in the fitted data
3. can we leave the window as it is, fit each window, and merge them afterwards?
   
4. NO, it's different from fit the entire main thread; the data used to fit Win(i+1), thought having an ov-FOV, is not necessarily the same as those used for Win(i).
5. The last sample to be interpolated in Win(i), has to use the following WIN_HALF samples, so the last sample is not the last sample in the tail-FOV of the win; same for the 1st sample of Win(i+1).
6. WIN_HALF could change depending on our tests.

Solution

1. All windows have to be calibrated, based on previous window's calibration.
2. we don't throw away window data, we just define interpolation boundaries, based on fitting window size.
   

phase unwrapping in win

two conditions

1. if Win(i)'s last FOV has gap, then convert the gap to the Win(i+1), and apply phase unwrapping to all azimuths > aa_gap
2. if Win(i).FOV is not the last FOV of the window, then apply normal unwrapping to all Win(i+k). 

NOTE: no two gaps in the same Win

multi-piece hard windowing vs. phase unwrapping vs. resampling

Problem

1. no way to apply simple phase unwrapping to main thread, because it's broken into individual files, and has to be loaded one at a time.
2. accumulated 2*pi unwrapping
   

Analysis

1. when stitching, we save data based on FOV count; have 1 FOV overlap
2. after stitching, do a thorough truncating for all window files, so that the window-based resampling can start at an integer multiple of sampling period, and consecutive window file will have no resampling overlap.
   1. Prev window-file 1: truncate at the 1st resample node (RN) bound of the ov-FOV. NOTE: resample pos is an interpolation point, does not exist in data, so we need a true data bound, i.e., the lowest point that's greater than the resample window that bounds the RN.
   2. Suc window-file 2: truncate at the 2nd RN bound of the ov-FOV
      
   
   
3. when resampling, we resample each window file.
   
4. window file should be larger than a processing window for polyfit.
5. when final concatenating, do beginning-alignment, discard overlap.
   
6. for unwrapping,  data needed: i_window_file; count_revolution;
7. for resampling, data needed: sample rate/period in angles, resample window-size
   

hard windowing

we can't just load main thread all the time.
from the hard stitching on, there has to be a hard windowing technique to save
the main thread back to pieces in favor of later audio resampling.

only after resampling can we FINALLY stitch all data into single main thread and make it sound.

stitch overlap simplified

Don't have to average between ov-FOVs, just pick our next focus-FOV and truncate (for top edge) or merge (for bottom 2D band) the suc-FOV and the main thread

Tom's Visit

1. Reinstalling Vision solved the init problem
2. Bottom improvement: hi-mag filter in both intensity window and the option dialog improves the scanning a lot!
3. Auto-scan stops within a specified scanning depth when obtained-pixel reaches a ratio of the FOV.
4. Auto-scan generates very noisy data.
   
5. 5X * 2 does not equal 10X; the 2X factor is a magnification of the FOV in 2D; it does not improve the optical capability at all.
6. Hardware: loosening 4 screws + tuning 2 handles against the PSI mirror to make sure the center fringe does not move when tiling or focusing
7. Hardware: tuning another two handles at the top against the stitching result aligns the stitching.
8. Fiducials can be used to calibrate drift
9. Post-processing with just tilt-only
10. Getting bottom by tilting is not recommended, because the recovered data could be from the sidewall as opposed to real bottom

Vision installation

1. download 4 files
2. install from install.exe in 775-296_(Vision_v3.60).zip, all default.
3. then 775-297
4. then 775-298
5. then v3.6cu5
6. copy config , kikaida.cfg, wyko.ini, in config/ folder; devices/services.cfg
   

detect attached-CC: bottom-based improved

1. bottoms are pre-tagged with CC containers
2. for each CC, get the bottoms segs and chain them up
3. NOTE: sum(span_a_btm) > span_cc does not always work, when bottom is seriously broken.
   

CC containers

theory

1. a CC can have only one container CC.
   

detach: when to calc bottom CC-ownership?

bottom ownership can be calced by line-equation

1. in mi_btm, select the point at median_a of a bottom, get line-equation of it
2. in mi_cc, get all points on the line, find the radially closest point to the median_a btm point, the "cc" is the owner.
   

Final: right way of folder structure

Problem

1. for each subprocess, the cpd_load contains different content, and the cellarray size is different for each process. 
2. loading process is always non-linear and requires specific loading folders.
   

Solution

1. if the all folders stay ordered in the cpd_load, then when trying to load stuff, we can trace back to the previous stage and in each folder, there are only updated FOVs.
   

retach/detach: folder version control or not?

Problem

1. Counter-intuitive settings in folder structure.
2. Not fully tested, so don't know what quirks it may give.

Argument

1. Why introducing folder version control? 
2. Cons: files are scattered into different folders and hard for the successive processes to load the folders.
   

Solution

1. For each FOV, if no .dat exists in attach/detach folder, first copy from filter_blob, then start from attach with overwriting.

Workflow recorganization in favor of sting removal

Problem

1. Sting removal involves more pre-processing than expected,
   
2. it needs to be broken down into more parent processes

Solution: new workflow

1. edge detection
2. clear edge angular redundancy
3. bottom fix (an optional set of bottom data, in addition to the original raw edge):
   
4. sting removal

Detail

1. what's the diff b/w lateral (r-wise) and vertical (z-wise) data?
   
2. from the fig., lateral top edges imply the linearity of the bottom seg in 2D.
3. however, since top edges are flat, there is no indication of the undulation of the bottom from viewing the top.
4. if only we can trust the width and use w/z ratio to fix it...., but for sting removal, we can't trust it.
   
5. we won't trust the sting segs, but we can trust most segs along the groove.
   
6. from angular redundancy test, we know roughly where the stings are.
   
7. to think out of the box, if stings are gone, we can fix the z data by using w/z;
8. before this can happen, we can't trust w/z as a condition but a question.
9. so the bottom fix should take two steps,
   
10. before sting removal, simply do lateral fix, i.e., much like groove retaching, retach the bottoms in the sense of CC angular link.
11. after sting removal, and the main-thread construction, we fix the depth by further w/z-based method.
    

sting removal: main steps

1. condition: no angular redundancy
2. connect bottom segs: 1) if short gap, linear linkage; 2) if long gap, seg the gap and do multi-seg linkage.
   
3. check w/z

Final: angular redundancy

1. Has to be done.
2. cannot be perfectly done.
3. hard sampling is still by far the best method, as opposed to radius-line-distance based free clustering.
4. usually there shouldn't be any missed out points, if we select the entired region bounded by the rough diff(va_edge) detection.
   
5. some missed out points have to be fixed during the next step: sting removal based on w/z.
   

can't do the one-shot sting removal

1. One shot requires correct op/ed angles, i.e., both on the edge thread not the sting thread, which is not guaranteed to be correct.
2. worse, if on same edge, there are 2+ clusters, it's hard to determine the op/ed of each cluster and fix them one by one.
   

New idea: sting removal, one shot!

After finding the overly dense angular seg,
if we can determine that it is a sting, we flatten it by using the hole connection method directly.

what ruined hard angular-sampling?

In the effort of clearing angular redundancy, hard sampling tends to mis-cluster, i.e., some points on the stings are missed out and become self-contained clusters, so that they would stay alive after the sting removal.

The problem is the sting-thread points and the non-sting-thread point (real edge) have different angular spacing. So that an overly refined hard sampling could cut into a theoretical angular group and split the edge and the sting, yet we want them to stay together so that we can measure the sting against the edge in the same group. If the sting is missed out, then there will be nothing to remove.

angluar redundancy: point-to-line distance dilemma

Problem

1. If the idea of "common radius" is defined by mutual distance among multi-multi evaluation, the overlapping nature of the rectangular pixel tesselation will make the common radius group grow excessively thick.
2. meaning point-by-point + line equation based grouping is likely to cluster the whole set of points
   

Solution

1. grouping should not work on the multi-multi assumption.
   
2. at each azimuth, there should be a reference point, against which all the other points' p2l-distances are calculated.
   
3. an angular group is defined by the innermost/outermost point on that common radius
4. dilemma: hard-coded angular quantization tends to mis-cluster; soft-quantization by multi-multi free clustering clusters everything
   

angular redundancy problem

Problem

• Angular grouping methods, incl. diff histogram and angular frames, are not robust.

The proper solution

• draw explicit radius line and take all points that fall on the line
  

various experience

1. previous filtering didn't always apply z-update, which may create Inf/NaN problem when the 2D image looks alright.
2. naming for assembler index containers should make the index-level explicit! always!
3. constantly refactor repetitive small code blocks with function extraction
   

Plan on sting removal

1. use w/z ratio filter
2. a process to verify multi-inner/bottom/outer units at the same azimuth. use the extreme points
3. at depth-less portion, check width vs. mean_width, if, e.g., w<0.5*mean_w or w>2*mean_w.
4. at offensive azimuth, r_new = r_mean, rc_new = rect_from_polar([r_new, a_old]), depth_new = depth_nearby, collect the offensive rect coords
   
5. fill the new holes caused by revising edges.
   
6. get new data into sotrage.
   

[sting removal] Proof of advantage of using w/z as oppose to w

std(w/z) = 0.0057 ~ 0.0124
std(w) = 1.6771 ~ 2.5518

edge detection: benchmark

sideband vs. old

16 sec vs. 30 sec.

edge detection: noise

before edge detection, there are small noise along the edge that are not removed by the intra-CC ho removal process.

However, these noises are connected to the holes, not stand-alone objects.
So better leave them alone for now.

pitfall of sideband method

this method supposed that the edge is perpendicular to the radius.
if the edge is slanted across the cross-section, then sidebands miss the middle area.

solution

1. after creating sideband, check the rect-bbox of middle-band to see if it contains non-zero points (valley), if so, extend the sidebands to fullband.
   

advantage of CC analysis

Tag/index all objects in the FOV,
in later edge detection, this helps to use non-pixel edge detection method, more accurate than the canonical method.

why ho-based and CC-based methods perform differently?

• CC-based = Intra-groove: Because in CC, the outer/inner edge undulate in a parallel way
• Ho-based = Inter-groove: Between CCs, undulation is arbitrary, making the groove spacing more versatile so that hard to make division by radius.
  

hole-based raw edge extraction

1. calc ho / CC centroids
   
2. sort hos and CCs radially
3. for each ho, find its sandwich wrap CC; one of them could be missing, 
4. fast windowing-based algo:
   1. angularly windowing a hole, based on a time param for the window size
   2. in each window, extract two side-bands and only do 8-neighbor edge search to the side-bands
   3. in low-level search, by checking existence of CC nb-pixel and the CC index, do inner/outer division
      
   
   

meditation: edge division

Problem

1. hole-based edge detection has the advantage of finding the true depth-present edge(top edges)
   
2. but the shape of the holes are more versatile in that there are inwards stings that cause problems in inner/outer edge division, e.g. no easy reference radius to look at even at a very narrow azimuth window.
3. the wrong division (incorporate extraneous blobs) will cause a sting if we sample that azimuth and take only the outermost/innermost point.

Dilemma

1. we want to interpolate based on a continuous edge array
2. but the array contains wrong data (stings)
3. to remove the wrong data, we need to do angular-sampling to evaluate the edge
4. this sampling would be a downsampling and could cause blur.

Question

1. do we wanna downsample at first to get the resampled-edge or thereafter?

Answer

1. whichever helps us preserve the resolution....
2. then it should be after the raw edge extracted.
3. so during sting-removal, for normal edge data, we keep them all (more than sampled data), but only exclude detected stings among the sampled data.

Raw edge detection

1. CC-based or hole-based?
2. CC-based: simple and straightforward to implement but not physically reasonable, no real depth data at the lateral position, need interpolation.
3. hole-based: physically reasonable, but hard to implement when it comes to inner/outer division, because more susceptible to CC-stings.

Solution

1. CC-based: after raw edge detection, get depth from neighbor hole-points (radius extrapolation), need interpolation; ring shaped part needs to look at wider adjacency.
2. Hole-based: after raw edge detection, do a CC-HO band division; for each hole edge point, look at its 8-neighbor and find the dominant CC index and assign it to the CC as either inner/outer edge depending on the band-division.(NO INTERPOLATION INVOLVED)
   

inner/outer edge division (2)

Problem

1. random division point is not robust, outer/inner distance is too variable

Solution

1. what's robust is the fact that, the division points on outer edge and inner edge are farther apart than consecutive points within outer/inner group

Implementation

1. sort the angular seg radially and take diff(vr),
   
2. find the max diff(vr) and divide.
   

Inner/outer edge division

Problem

1. old method: look at an edge point-of-interest; find its angular peers; see if among the peers, inner-more points exceed outer-more points compared to this POI, true-> this an outer point
2. this one is too rough to handle situations where there are significant angular overlap among such angular groove, then the number stats will be messed up instead of clear-cut 1-on-1 inner/outer pair.

Solution

1. angular analysis: still take angular groups; at each azimuth, find in the original top area a random non-edge point, all points outer-more are outer edge, and inner-more are inner edge.
   

sting removal: steps

1. get raw edges
2. angular division: get w/z ratios.inner + outer
   
3. check current CC w/z ratios
4. * find offensive azimuth and show them
   
5. find offensive azimuth and assign a value corresponding to the median ratio
   

Today: start on refining groove detaching

A few things to try

1. A global fixing or local fixing of ho-linkage only?
2. stats of width/depth
3. 
   

restore: post-processing remove-holes should be done separately

...to all FOVs scattered in different tags,

and assemble them to the same output folder

detach: sting-removal should return log: sting/edge percentage.

detach: btm-ho-btm sandwich

Problem

1. Rule: r_btm_inner < r_ho < r_btm_outer is not robust, either parallel bottom can be missing, or global radius relationship can defy this assumption.

Solution

1. find inter-centroid radial distance between ho and btm's, take the nearest two btm's as the wrap.
   

Redesign saving/loading

Problem

1. recursive process on filtering attached/detached FOVs requires non-destructive saving
2. currently we have only one output folder, one loading folder for each type of base data
3. FOVs that are iterated 3 times can't start with the same folder as those that are done 2 times.
4. Non-processed and processed files (output figs) blend together and hart to check.
5. 2D/depth data are not fully synchronized after filtering.
   

Solution

1. at the beginning of an iteration, load the tag file from the same place to retrieve iteration number; at the end of every iteration, update the tag file with an increment in the iteration number.
2. all output folders are named with the iteration number, and loading is done with the correct folder.
3. each process has its own tag series, e.g., stitch-blob-1, stitch-small-2, attach-1, broken-2....
   
4. non-processed FOVs does not output fig/img!!!
5. loading process should be stupid, load() doesn't have to know how to compose the folder names.
6. i_round: current round to be saved; i_round_prev = i_round-1: prev round to be loaded.
7. 
   

[detach] nb-FOVs: bad about chain reaction on nb-FOVs

it is destructive in that it only performs "adding points" (set stuff to be zero, i.e., holes), but never recovering from the added points.

[failed] use bottom to bound holes

can't just simply use bottom/holes bbox to narrow down hole chains....
has to be done with an angular iteration to make sure at each azimuth the bbox fits

Attached Grooves: new algo by bottom detection

1. basis: an attached groove must have bottom in the CC area; it must have 2+ bottom threads in there.
2. difficulty: bottom threads might be intermittent, hence the true number of bottom threads is hard to get; hough-based method is not flexible enough to adapt to all shapes of bottoms.
3. solution: find number of bottom threads; find holes between each one of them and chain them up in order.
4. detection procedure:
   1. get bottom-only image
      
   2. bottom-CC analysis
   3. bottom-CC angular grouping
   4. check bottom-groove-CC ownership: which bottom belongs to which groove.
      
   5. those who owns 1+ bottoms are attached.
   6. enlist those who owns 0 bottoms.
      
5. detaching:
   1. make sure bottom is there in the gap
   2. along with each bottom associated with the gap, get the promising top edge points that ensure a constant groove width.
      
6. deteching procedure: (discarded)
   
   1. find chains of holes, and the intact bounding top edges
   2. collect angular widths by holes and its opposite edges, each hole has inner/outer pair of track widths
      
   3. from inner "tracks" to outer ones, collect bounding nodes for filler areas, by checking the width consistency against the other "intact" edge; the filled hole boundary track will become the reference for the next adjacent track.
      1. for chain_holes, filter out noises (off-center)
      2. sort holes by angular ranges
      3. the filling order will be, both ends of the attached groove first, i.e., innermost and outermost.
         
      4. for each azimuth in gap, search for its opposite edge point across the bottom, by azimuth; if no edge point available, e.g., track in the middle, look for bottom instead, and apply half-width.
         
      5. against mean width (or half-width) of pair widths on the side, calc the polar pos of the filler boundary point; polar-to-rect conversion.
      6. after a pair of boundary is done, make the second thread the reference edge for the next track's first thread.
         
   4. remove any ho in the filler area defined by the bounding points.
   
   
7. cosmetic filler is hard to be done here, e.g., if the missing filler point is near FOV boundary, it is hard to collect reference points if opposite edge is outside of the FOV.
8. but we have few choices but to do it here, because it only makes sense to do this bold "data filling" while we know which FOV to fix; in other words, we cannot run the filler process over the entire unwrapped thread or pure edge data without distroting the entire audio signal;
   
9. the best place to insert this sting-removal step is after raw edge detection, and we only work on FOVs that contained attached grooves. This way, we don't have to deal with lots of "holes" and figure out their sides and "opposite" points; the dusty texture would have been removed by the coarse detaching procedure.
10. the FOVs that need to be registered include the ones that contain attached grooves, and those around them that share overlaps in the filler area.
11. sting-removal procedure:
    1. for each registered attached groove, get the raw edges
    2. needs experiment: get the median ratio of half-width to depth, or width to depth, of current CC or all CCs; ignore those azimuths without bottom
       
    3. Statistics: for each azimuth of inner/outer, collect ratio = bottom-edge width / depth; if no bottom is available there, skip; this "unavailability" includes the situation where source edge point is at an azimuth that is beyond the angular range of the bottom, e.g., near FOV boundary. WHY? because in its overlap neighbor, this will be solved nicely and then we get back here to fill in the points.
       
    4. take median ratio; set a threshold based on median ratio as the numerical reference for the FOV.
    5. for each azimuth of inner/outer, measure their ratio against the reference, if it's too big (too wide because of the sting), try to find the closer point that makes it as wide as the median, take it as a node.
    6. Thin gap remedy for missing bottom: if missing bottom at the place, take edge-to-edge width and angularly closest bottom r/z as the imaginary bottom, from the contrived bottom position, extrapolate both edges through median ratio.
       
    7. after collecting all new nodes of the FOV, for each holes in inverted-CC analysis, fill holes; save them back into "filter_attach"; redo CC analysis + edge detection.
       
    8. finally, get nb-FOVs' corresponding points, and fill them as well; redo CC analysis + edge detection for nb-FOV.
       
    9. Side track: in coarse detaching phase, always try starting from the result folder to see if a modification from neighbor FOV has happened, and the current detaching will happen on top of that result.
    10. Side track: if there are any non-attaching-caused stings, after edge detection, they will be spread and change the topology of the 1D edge. So edge has to be sampled before array-length calibration. NOTE: if calibration is done based on angle range discrepancy, no need to do an extra resample before bottom-1D-from-2D.
        
    
    

Reconsider groove edge as the representation of audio waveform

Summary

• Previously we decided to collect all pixel-level edges of CCs as our raw database of extracted audio. We hope that resampling and fitting could give us a safely downsampled version of hi-fidelity audio signal.
• However, there is a fundamental flaw in this approach. By using any low-level edge detection, there is bound to be noise mixed in. Here noise means any pixel that is not representative of audio signal. These noisy pixels, when getting into our process chain, would hardly be removable. See Detail.
• A possible better way of audio extraction from groove edges would be to perform a fairly dense angular sampling in the beginning instead of trying to perform traditional edge detection; then downsample the result at an audio rate during the fitting process.

Detail

• See the image below, it can be observed that pixel edges sometimes overlap along the radial direction relative to the disc center; but only the outermost (for outer edge) or the innermost (for inner edge) should count as signal, and all the others are noises.
  
• Unfortunately, there is no way to distinguish them unless we do a filtering based on angular sampling right after edge detection.
  
• Without such filtering, they will be considered as data for the successive fitting process, which is bound to lead to problematic result.
  
• The high level explanation of this is that 1) the input image offers a much higher sampling rate than the output audio rate. 2) traditional image edge detection is a 2D processing, yet our desired edge detection is essentially a process of creating a special 1D database, which has its semantics.
• As a result of the above two factors, low-level edge detection will incorporate 2D edges that share no semantic meaning with our application; before such 2D data get unwrapped into 1D audio undulation, they need to be filtered out.
• Because this filtering still requires an angular sampling, it would be better to completely give up on the edge detection and do such angular sampling instead.

Edge merging: what could be wrong

What happened?

• somewhere, there is a radius discrepancy
• it happened at only one boundary among two

What happened?

• CCs are valleys; so edges of a CC are Infs;
  
• they need to be extended one pixel, or, re-extracted from the "holes"

What else happened?

• Wrong edges from nb attached CCs.
• Detaching function should take care of nb-FOVs by filling the necessary points in overlaps

When and how to extract bottom?

• If we do it in individual FOVs, then if one top edge is missing, the missing bottom radius can't be obtained through top edges -> has to remain NaN;
• If we do it in main-thread, then how do we trace back to what's inside the valley?
• Conclusion: In individual FOV, at least get the radial position of the missing points
  

Go back: edge

Currently: edge = all detected pixel edges
Risk: Some of them are on the same theoretical angular position, so the extracted edge is distorted (extended, spread out)
Solution:

• Don't take every point;
• Make our sampling a 2-phase process:
  
• Phase 1: the edge extraction uses a strict pixel-precision sampling, i.e., the angular sampling rate is limited to 1-pixel wide, so that at each pixel angular position, no two points exist in our edge array.
• Phase 2: audio re-sampling

Plan: don't do this until we hear the sound.

FOV chain

What should we do

• make sure it's correct for all FOV.CC.edge's

Test Design

1. For all FOV.CC.edge's in a FOV, show all nb-FOV.CC.edge, and next focus-FOV.CC.edge
   
2. For all ...., show consolidated edge

Need to do next

1. bottom r/z, NaN case
   

FOV chain, edge/bottom extraction, attach/broken

What do we have

1. FOV chain not fully tested
2. edge extraction problematic
3. bottom extraction not implemented
4. attach / broken not fully tested

What is the most important

1. FOV chain

How to achieve the most-important goal?

1. CC-edge exit points should be correct -> edge extraction....
2. does edge extraction need correct attach/broken treatment? -> not everywhere
   

test flock

1. Awesome
1. fantastic
2. just what I need
2. let's do something together.
   

回国准备

回国要带

1. 礼物
1. 游戏
2. 口红
3. 药
4. 洗脚水
5. 加拿大硬币
6. 计步器
7. 爵士节program
8. Ubuntu盘子
2. 衣物
1. t-shirt
2. 老头衫, 内裤 * 10
3. 飞机上: 长袖衬衣, 牛仔裤, 长袜子
4. 好坏皮带
5. pillow
6. 大纪元报纸
7. 钥匙
8. 淘汰衣物
3. Electronics
1. laptop
2. mouse
3. sennheiser headphone/mic
4. Dell accessories
5. 充电器
6. razor + recharger
7. camera + recharger
8. watch
9. sunglass * 2
10. mp3 player * 2
11. usb hub
4. 学习用品
1. audible design
2. machine learning
3. modern recording techniques

回国前要收拾

1. 洗衣服
2. 钱物
3. 桌子:音箱
4. 书架:耳机,话筒
5. 床铺:床单
6. 衣柜
7. laoptop, 硬盘, camera, mp3

回国后要做

1. 修皮带, 墨镜
2. 体检, 预防针
3. 买维生素
4. 买西装

1. k

• 1
• 2

• ---

  
  

d1
2

[attached CC] link holes

5204816697

<link holes>
1, edge detection
- later find true ho points at the same angular pos with the hit edge points.
2. start from angular extremes, find smallest angular pie to hit on the edge of the opposite ho
3. determine clockwiseness
- cross boundary pair: ho(i).bound.r > ho(i+1).bound.r
- here, a(i) should start facing outer circle, move counterclockwise
4. the reason to do a shape-preserving connection:
- if postpone this to a later CC-based approach, i.e., fix CC later instead of fixing holes now, we'll have to search for the problematic position, but with the chain of hos we got, we knew their positions immediately, so now is better than later
5. branch out connection method by size of gap
- gap is bigger than ho size, don't search

回国要干的几件事情

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.

piece-wise spline

what we are trying to do

• split the angular edges into equal-size windows and perform spline in each local window
• in each window, there should be resample points
• all windows should have same number of samples -&gt; time windows
• we should test on window size, and overlap ratio
  

3X speed scanning

generates jaggy edges

Auto mashup

1. read tags
2. detect passages
3. bpm detection
4. audio mixing
5. auto level adjust
6. auto groove generation

case

1. percussion: generate drum N'bass sequence
2. groove instruments: find 1 or 2+ bpm-matches in 1 or 2+ non-Electronica recordings, e.g., guitar solo or riff, cut them off properly to form a loop, possibly using Metadata tags for searching.
3. repeat #2 to lots of other recordings, e.g., ambient recordings, find spectral balance between selected tracks.
4. level adjust to avoid clipping and imbalanced EQ.
5. mix down

max angular sampling (write-up outline)

our scan line (radius) may fall between pixels, then in the sense of NN,

1. starting with a reference point A
2. evenly sample
3. can't predict the shape of the edge, so consider the worst case: the next edge point can be within one of the 8-neighbors.
4. which one of the 8-nb, determined by the orientation of the radius, position of the anchor point.

Angular sampling rate selection

- sampling in a non perpendicular direction to the FOV dims.

- EVEN sampling
- then the neighbored samples are not supposed to overlap angularly
- also, the neighbored samples should be a real edge point, i.e., in the radial direction, no other same CC point exists.

- if SR too big, lose point -> in between "neighboring" points there are other edge points.

- sampling rate should come from audio sampling rate

 

Right way to do

• extract all edges
• sample edges according to the audio rate, and (r, a) parameters, variable rate across radii

angular sampling

• if we take all points between [a1, a2], we get a thick stripe, that way, lower SR always leads to more data, and by taking the head and tail of the group, we won't necessarily get the rightly spaced edge points.
• right way:
• don't take the [a1, a2], but use [a1-e, a1+e], e is the tunable offset.
• e << (a2-a1)/2;
• e = ratio * angle_per_sample.
• e should make the angular group thin enough,
• ratio should be adaptive, by looking at the width of the angular group, should be

individual FOV sound extraction

what do we have

• a few new FOVs
• different sizes from [640, 480]
• stage pos for center, in mm's
• old code to deal with stitching, saving each temp results
• old code to trace grooves in individual FOVs, with input data from stitching results

where are we going

• use audio extraction on new sine waves

what do we not have

• stitching data, bbox, trc_vertex, etc.
• an intuitive

what to do

• create new project repository
• use an individual process to create "stitching data" (centered coords)

Webcast metadata

<webcast>
make it simple
1 - layout of list
2 - workflow of listening
3 - workflow of tagging

3. workflow of tagging
- mp3 files -> server
- manual input:
  single entries: time, place, concert title
  matrix: title, composer, performer (instr) (omit allowed)

intelligent: blank strip

Webcast overall

<webcasting sites>
template
talk to alain
mcgill information service center
- possible using mcgill content management (CMS) API/component, instead of creating myself
- cosmetic features

make sure services that they ask for

after talking with CMS, know how much coding i have to do

user stats (who, where, when downloaded)

Music Manager ver 0.1.0

<re-arrange music according to date>

chrono list
add new stuff to their genre list
- rescan through metadata

-------------------

so that new releases stands out

input: folder
output: m2u list, renamed folders

1. all new music goes to 'my music'
2. when needed to be moved to USB, a folder named after the "creation date" is created (if it does not exist), and all albums got on the same date get in, accurate to month
3. 'monthly' and 'dayly' m3u lists are created to the 'my playlists', rescan
4. related genre playlists are updated

Tagging program

What do we have

• Mutagen fully working
• Questionable Tags clarified
• Metadata INI file developed

What are we trying to get

• Program running on Music server to tag everything

What are we not sure of?

• Whether Mutagen works on Music server or not?
• What tags to use to make info in the limited fields provided by Winamp, iTunes look good
• INI parser to get all info out

What do we do

• quick remote test of Mutagen
• list all tags:values in use
• finish parser

Detail

• "track number" is explicit, because it can be error-prone and annoying to rearrange lines
• "conductor" is unseen at this point, so fill it in as performer, can be rearranged later because we have the role filled in.
• the human editor is responsible for using correct characters for various fields (encoding)
• "performer", "composer" etc can be multi-value, use ', ' to separate; use ';' to separate fields
• mark any field without data 'N/A'
• UTF8 with BOM will mess up the first char '[' in the first row
• in ini parser, all strings have to be explicitly unicoded into UTF-8

Plan - Winter 2008

Most urgent (having to be done)

1. MItAC: sound, in two months (8 weeks)
2. Martha's course
3. Catherine's job opportunity
4. Toastmaster
5. Creating or mixing an album (Jan ~ May, 20 weeks)

Important (Long term)

1. Sound recording
1. MUSR-300
2. Martha's classes
3. Mixing listening and practice
4. Recording assistance
2. Personal software
1. Beat factory (breakbeater extension)
2. Audacity auto-labeling or audio feature visualization
3. Reading in music psychology
4. Reading in machine learning (sparse model)
5. Reading in MIR/ICMC/DAFx
6. News, global and local
7. Reading of computer science book collections
8. Writing
9. Using DAWs to create music
10. Science Applets
11. Exercise

Only emotionally important

1. Blogging
2. Google reader
3. Japanese
4. Music genre-based collection and listening
5. Videos
6. My novel
7. MSN chatting
8. Parties

Daily time distribution (24 hours, all in hours)

1. sleep (including noon nap): 7
2. eat: 2
1. Breakfast: 7:30~8:00am
2. Lunch: 12:00pm
3. Dinner: 6:00pm
3. MItAC
1. Before sound out: 7-8
2. After: 3-4 (including writing)
4. Catherine's job preparation:
1. Before submission: 2
2. After submission: 1
5. Toastmaster: 1~2 *
6. Mixing listening, practicing and writing: 1
7. Reading 3~5: 1
8. News: 0.5
9. Japanese, blogging, and others: 1

Weekly activities

1. Exercise: twice; 0.5/session
1. Tuesday
2. Friday
2. TA: Martha's course: 120+class; 4/week
1. grading on weekends
2. class attendance