Beinan's Work Log

Plot of groove center and width and derivatives

2010-07-28T22:47:00.001-07:00

Each plot below contains two sub-plots of the entire view of the data and a portion of it.

Silence+Sine signal

raw CenterRadius: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/c.png
raw width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/w.png
CenterRadius - width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/c-w.png
CenterRadius + width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/c+w.png
derivative of (CenterRadius - width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/d(c-w).png
derivative of (CenterRadius + width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/d(c+w).png
derivative of CenterRadius: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/dc.png
derivative of width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/dw.png
deriv(CenterRadius) - deriv(width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/dc-dw.png
deriv(CenterRadius) + deriv(width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/sine/dc+dw.png

Musical signal

raw CenterRadius: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/c.png
raw width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/w.png
CenterRadius - width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/c-w.png
CenterRadius + width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/c+w.png
derivative of (CenterRadius - width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/d(c-w).png
derivative of (CenterRadius + width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/d(c+w).png
derivative of CenterRadius: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/dc.png
derivative of width: http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/dw.png
deriv(CenterRadius) - deriv(width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/dc-dw.png
deriv(CenterRadius) + deriv(width): http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/music/dc+dw.png

True stereo samples

2010-07-27T22:02:00.001-07:00

Summary

Double checked the stereo signal rendering:

Left channel = CenterRadius - Width

Right channel = CenterRadius + Width

Silence + sine

http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/stereo_silence_sine_riaa.wav

Music

http://kakyoism.webhop.net/~kakyo/0.report/49.stereo/stereo_music_riaa.wav

BTW:

kakyo writes as　華僑 in Japanese, meaning "overseas Chinese".

Stereo vs. Groove shape

2010-07-27T05:54:00.001-07:00

The music and sine wave extracted last time are stereo signals, but only the lateral information was used. Depths were discarded. To incorporate depth info, however, the bottom data are in question.

Remember that previously we discussed about the fact that grooves in practice are "U" shaped instead of "V" shaped, so that there is no immediate 1-unit-wide bottom to use in order to derive groove depths. In other words, to be able to measure groove depth, we need to thin the bottom so that it is 1-pixel wide. This is an un-reported problem before. A few options are there:

Use pure image processing thinning (our current solution)
At a groove cross-section, use the bottom point closest to the center of the cross-section.
At a groove cross-section, use the bottom point that is deepest.

These options will introduce inevitable noise because they don't consider the fact that the cutting stylus creates some correlation between the groove lateral and vertical shape parameters such as width and depth, the ratio between bottom-to-inner-edge width and bottom-to-outer-edge width, etc. If an inappropriate bottom thinning strategy is used, the overall vertical groove info may not correlate well with the lateral info and won't yield good stereo audio.

We now call top edges "ridges".

To make sure that depth information is good enough to use together with the lateral info, the requirement includes

Along the entire groove, the ratios between bottom-to-inner-ridge widths and bottom-to-outer-ridge-widths should be consistent, e.g., at any part of the groove, the ratio remains close to 0.98. Bottom should not be sometimes closer to inner ridge and other times outer ridge.
Along the entire groove, the ratios between the groove widths and depths (diff-z between ridges and bottom) should be consistent.

Currently I'm doing tests on groove shapes with raw undulation (not resampled) and resampled /fitted undulations. The tests are not over yet but the preliminary results are not so good. The thinned bottoms apparently contain a lot of noises that fail to meet the above requirements. I'll finished the tests for results from all the thinning strategies listed above and give a thorough report.

Sidewall slopes can provide stereo info. However, since the grooves are U-shaped (also according to Nasce's thesis) and sidewalls are missing with WLI, it is also hard to estimate the sidewall slopes with the tiny portion of the bottom, although I haven't tried.

New outline for dissertaion Chapter 1 and 2

2010-07-24T20:19:00.001-07:00

Summary

Previously I felt it too awkward to avoid talking about surface metrology or phonograph recording characterisitcs during the narratives of the "related works" section in Chapter 1. After reconsidering the flow of narration, I think it would be better to keep Chapter 1 very brief and makes it only talk about research objectives and the chapter outline of the rest of the dissertation. Then reserve the true meat of the related works to Chapter 2 as literature review. It would be necessary, of course, to mention that other OAR approaches exist and the general pros of the OAR family. We then do not talk about anything further, including cons, or any more detail of the common characterisitcs of OAR as we do now.

The new outline of Chapter 1 and 2.

Chater 1

General background: One sentence definition of phonograph, the trend of digitization, and the rise of OAR, and its advantages (largely the same as the first three paragraphs that we have now)
Research objectives: (using general terms without touching technical detail)
1. Focus on stereo disc phonograph recordings.
2. Study a specific non-contact surface metrology approach: white-light interferometry (WLI), which acquires the 3D surface information of disc recordings and save it as images.
3. Implement image processing chain to extract audio information from the surface images.
4. Evaluate the resulting audio quality.
Research contributions:
- First to focus on stereo recordings with WLI.
Outline of the rest of the chapters

Chaper 2

Phonograph recording technology (Focus on stereo disc recordings)
Surface metrology (Focus on non-contact methods: ray-tracing, optical microscopy, confocal microscopy, WLI)
Existing OAR approaches
1. with ray-tracing (history of laser turntable that's already written)
2. with 2D imaging (Stotzer)
3. with confocal (Haber and McBride)
4. with optical microscopy (Tian)

Center correction for the music sample

2010-07-17T15:43:00.001-07:00

Summary
The same center correction process reported last time is performed on the music sample. Although the wavelet differentiation still introduces DC offsets to the signal, the pitch fluctuation is largely removed.

Before center correction:
http://kakyoism.webhop.net/~kakyo/0.report/47.center/audio_mitac_stereo_v2_algo23_RIAA.wav

After center correction:
http://kakyoism.webhop.net/~kakyo/0.report/47.center/audio_mitac_stereo_v2_setup28-cca1-r3484-a0.12pi.wav

Plan
Try to fully automate the process in a coarse-to-fine way, using both magnitude and phase information of the resulting audio from each Monte Carlo center shift

Coarse correction: Using the audio resulting from the non-corrected center info as a reference, if we sample the new center angularly with a fixed shifting radius, depending on where the Monte-Carlo test center is, some of the samples will show themselves as out-of-phase from the reference signal, while others will be in-phase; When corrected audio results from various angular positions are uniformly out-of-phase or in-phase, we know that the position of corresponding Monte-Carlo center is far from the true center. Then by sampling in the radial dimension, we search a critical point where angular sampling gives us a mix of out-of-phase and in-phase results. The sampling resolution in this step can be very low, i.e., just a few samples will get us to the critical Monte-Carlo center.
Fine correction: We then try taking Monte-Carlo around the critical center with a higher resolution in angular and radial dimensions, and minimize the low-end spectral energy from the magnitude response of the audio results.

Disc center correction to remove wow pitch fluctuation

2010-07-13T04:52:00.001-07:00

Summary
A simple iterative center correction procedure is used:

Assume that the current disc center is off from the true center. Randomly choose N center shifts in polar coordinates: Select R radii; for each radius, evenly sampling the angle range from 0 to 2*pi. E.g., radius = 1000 : 3000 (pixels), angle = 0 : pi/8 : 2*pi.
Apply the N shifts individually to the extracted groove undulation polar coordinates and redo fitting, downsampling, differentiation, and finally outputting the audio.
Examine the low-end energies (0~50Hz) of the N audio results. Find a saddle point in the sorted N energies. The shift radii, whose resulting energies that are adjacent to the saddle point, are chosen as the fine range for the next iteration.
Keep refining the shift radius range until a satisfying minimum low-end-energy is reached.
If no saddle point is found, then repeat #1~4 until a limit on the iteration count is reached.
If through #1~4 a saddle point is found, but the radius already stabilizes so that no low-end energy change is introduced over the iterations, then change the angles to try to continue fine-tune the low-end-energy.
Repeat #1~6 until the wow pitch fluctuation is lowered to undetectable.

The result is at
http://kakyoism.webhop.net/~kakyo/0.report/47.center/audio_mitac_stereo_v2_cca3-rc3.684402e+02-3.014367e+03.wav

The corresponding center shift correction:
radius: 3.0368mm (about 4.75 FOVs)
angle: 0.1216*pi

Plan:
Use a spiral equation to fit the Cartesian coordinates in the beginning the image processing and see if the wow can be lowered before any center correction attempts.

Archimedean spiral!!

2010-06-29T21:19:00.001-07:00

Summary

Record grooves are made mathematically with Archimedean spiral.

Quote from Wikipedia
http://en.wikipedia.org/wiki/Archimedean_spiral

"The Archimedean spiral has a plethora of real-world applications. Scroll compressors, made from two interleaved
Archimedean spirals of the same size, are used for compressing liquids
and gases.^[1]
The coils of watch
balance springs and the grooves of very early gramophone records form Archimedean spirals, making the
grooves evenly spaced and maximizing the amount of music that could be
fit onto the record (although this was later changed to allow better
sound quality)"

--Penndorf, Ron. "Early Development of the LP". http://ronpenndorf.com/journalofrecordedmusic5.html. Retrieved 2005-11-25.. See the passage on Variable
Groove.

What we can learn from the above:

The equation in polar coordinates:

The inter-revolution groove spacing: 2*pi*b.

So theoretically with this a priori we can estimate the center of the grooves, without physically measuring the center like we did before with the center-hole or lead-out grooves.

To correct systematic errors in cutting devices, we may need some gradient-descent in the end but it would be much easier than trying to converge to the "imaginary center" blindly.

Test suites
To test this idea, we can do a test suite
1. Check the inter-revolution spacing of many grooves for the mean and variance. We can treat the distance between the edges or bottoms as the target distance. If the variance and mean together show a constant inter-groove spacing, we can go on. Otherwise we need to rethink about the mathematical abstraction. One issue with this idea is the chicken-vs-egg problem. When we test the groove spacing we need to resort to polar coordinates that we already have.

2. Estimate the spiral parameters (a, and b) and eventually the center.

3. Update all groove polar coordinates of our scanned data with the new center and check output signal quality.

Optionally, we can do another test suite:
Generate a sinewave based on Archimedean spiral and see if we can reproduce the low-frequency modulation in the end. And then try to estimate the original center from the wrong signal.

Previously we've confirmed that generated sinewave around a perfect circle can be modified to generate the same modulation by shifting the center.

Better smoothing

2010-06-28T23:19:00.001-07:00

Summary

Using piece-wise polynomial fit on the raw groove edge undulation then using a wavelet differentiator shows better smoothing result than any other combinations we tried before, e.g., moving-average on undulation then differentiation.

The local result on same signal segment shown last week
http://kakyoism.webhop.net/~kakyo/0.report/46.smooth/wavelet_smooth.png

Audio (Sinewave)
http://kakyoism.webhop.net/~kakyo/0.report/46.smooth/audio_mitac_stereo_v2_algo23_NORIAA.wav

It's not clear yet how exactly a wavelet differentiator smoothed the noisy signal out, but it works much better than moving-averaing on raw signal (radii of the groove edges). From the literature I read about, wavelet differentiators have reputations for better noise reduction performance.

I also got what delta-sigma modulation roughly does. It uses pulses (bit-stream) with fixed-voltage and pulse-width, but vary the pulse-spacing, e.g., use denser pulses for weaker signal. By "oversampling", i.e., extremely dense bit-stream, the weaker signal gets a smaller quantization noise than using vertical quantization.

Assuming that our scanned 1kHz sinewave groove undulation is encoded by delta-sigma undulation, and the noise level is one pixel, then because peak-to-dip duration contains about 200 points under 10X magnification (1um/pixel resolution), then the DNR = 20log10(200/1) ~= 46dB. If the noise level is 0.5 pixel, then DNR ~= 52dB.

The reported analog 78RPM systems have 30 ~ 40dB DNR; LP systems
have around 60dB.
Stotzer's system provides about 19dB DNR for
78rpm and 16dB for LP.

Plan
Start working on center-correction to remove the low-frequency modulation.

Dissertation Chapter 1 outline

2010-06-16T20:55:00.000-07:00

In order not to waste any time on writing unapproved content in detail, I'd like to have a mid-level outline of my dissertation chapters before diving into the actual writing. I hope that I can have an idea whether the following structure and points make sense and make adjustments at the mid-level. Once this list is confirmed, I'll start expanding these ideas into real text.

Chapter 1 The McGill Image to Audio Conversion Project

1.1 Introduction

Phonograph recording/playback technology in one sentence.
Social background and significance of creating the technology of
the dissertation: Records are dying and need to be preserved;
international authorities and communities care about this. Quote
Langnois project proposal.
Digital archiving as the major solution to problem introduced in
#2: Pros (reliability; mature technology) and cons(Time cost; quality
issues).
Origin of the MItAC project: idea; rough procedure. Briefly mention optical audio reconstruction efforts.
Advantages learned from the above rough procedure: Contact-less; capability to restore damaged records.
Advantages summarized in bullet list.
Objectives derived from the advantage list, each objective seeks to explore and elaborate one or more advantages.
Briefly mention the hardware (closely related to the advantages).
Indicate that the dissertation mainly deals with which objectives.
The significance of the dissertation (To elaborate the thesis proposal): First in the world to deal with stereo LPs, with white-light interferometry (WLI) and using 3D groove profile.

1.2 Objectives of the thesis

Because the use of the specific imaging system (WLI microscope)
is unprecedented, the objectives include describing hardware system and
how it is applied to replace phonography. As a result we'll also talk
about phonography in next chapter.
Theoretical perspectives on system limitations, resolution, sampling rate, dynamic range, etc.
Image processing algorithms: stitching; groove extraction; noise reduction and restoration.
The high-level objectives of the audio extraction tasks:
reconstruct a stereo test signal (silence + sine wave, and a music
signal) at a quality/time trade-off scanning resolution.

1.3 Related works

Existing efforts to optically reconstruct audio: Laser turntable
(several models), Haber, Stotzer, Tian, (optional: McBride), with high
level categorization: Optical stylus, 2D digital imaging, 3D method.
Core image processing techniques: connected-component-analysis, edge detection.

1.4 Summary of dissertation

chapter-by-chapter description, each in one sentence.

Results of various smoothing methods and interpolation

2010-06-15T05:39:00.000-07:00

Summary

Various smoothing and resampling methods were tried.
Haber's piece-wise polynomial shows the smoothest fitted undulation.
None of the tried methods can yield smooth differentiated signal (radial velocity). This may be due to the off-center problem, e.g., the segment of sine wave shown below are all slanted due to the wrong radius, leading to differentiation errors.

Dynamic Range

2010-06-10T20:06:00.000-07:00

Dynamic Range

What is dynamic range? Dynamic Range(DNR) measures the ratio between the greatest un-distorted signal and the smallest detectable signal which is usually the average noise level, usually in dB. In the analog-to-digital conversion system. The noise is often assumed to be quantization noise. Since the quantization noise corresponds to a level of integer 1, 16bit CD's dynamic range is about 20log10(2^16 / 1) ~= 96dB.
In the case of LP, DNR is related to peak velocity of the turn-table. According to this [[book chapter|http://www.st-andrews.ac.uk/~www_pa/Scots_Guide/iandm/part12/page2.html]], "An output signal is produced which is proportional to the instantaneous radial velocity of the stylus. The signal is recorded in the shape of the groove surfaces, or ‘walls’". The radial velocity of the stylus v(t) = dx(t)/dt + dr/dt ~= kdx(t)/dt, where dr/dt is a constant rate of stylus moving inwards in a spiral towards the disc center, and x(t) the radial displacement from the center of the groove's silence position. In the case of sine wave as reference signal, whose level is proportional to the electric voltage, x(t) = A sin(2*pi*f*t). The velocity is then dx(t)/dt = 2*pi*f*A*cos(2*pi*f*t). The peak velocity corresponds to the highest signal level.
In our testLP case, where peak velocity is 7cm/sec, frequency is 1kHz, signal level at 0dB, the peak spatial amplitude is then A_peak = 7 / (2*pi*1000Hz) ~= 11.14um.
In the context of equivalent quantization error in a analog turntable, let delta_x represent the smallest stylus movement step that can generate electric signal difference. Then DNR = 20log10(2*A_peak / delta_x).
In our scanned images, under 10x magnification, where spatial resolution about 1um/pixel, the signal peak amplitude corresponds to about 27.5 pixels. If quantization error is 1 pixel, then DNR = 20log10(2 * 11.14 / 1) ~= 27dB. If quantization error is taken as 0.5 pixel, then DNR = 33 dB. Our signal actually contains greater noise (> 1 pixel fluctuation) just by taking into account the stings introduced by dusts. If delta_x = 3 pixel, then DNR ~= 17dB.
The reported analog 78RPM systems have 30 ~ 40dB DNR; LP systems have around 60dB.
Stotzer's system provides about 19dB DNR for 78rpm and 16dB for LP.

Noise reduction

Moving average may not be the right way to smooth out LP signal.
Moving average take into account every edge points under our resolution. Given the noisy nature of local undulation, from my trying of 3~10pixel window moving average, the resulting signal was still noisy.
If we imagine the way stylus moves, the contact surface of stylus with the groove edge is of a certain linear width, denoted as W corresponding to, say N points. As the stylus move across the groove, only the innermost edge points Pi, Pi+k, i+k < N. will get into contact with the stylus surface, while all the others are ignored. So the averaging here is not a moving average of every points across the contact dimension of the stylus.

Plan

Our DNR is pretty low although close to Stotzer's system. So maybe we should lower our expectation under 10X magnification about the signal-noise ratio. We can also measure the theoretical DNR of the music signal we have as a side note.
Try smoothing undulation with the stylus-inspired scheme.

Dyanmic range and quantization error

2010-06-05T12:09:00.001-07:00

Previously we confirmed that the pitch fluctuation in the output audio was due to center estimation errors.

Tried a couple of low-pass filtering and moving average before
resampling the signal, none of which can effectively remove noise
without degrading audio quality. This brought to my mind that maybe the
theoretical dynamic range (DNR) and signal-noise-ratio (SNR) of the
signals scanned under 10x magnification was never enough in the first
place.

I'll research into this problem and report in the next blog update.

Confirmed that center estimation error can cause the pitch fluctuation similar to what we heard.

2010-05-31T17:48:00.000-07:00

Summary

In order to confirm that center error can cause the pitch fluctuation that is present in our previous extracted audio signals, a simulation is done to reproduce the problem using a generated sine wave.

Simulation steps

In this simulation we assume that the grooves are in perfect circles instead of spirals.
Create a 1kHz sinewave of which the duration equals one revolution of LP signal (1.8 seconds), at the estimated sampling rate from our scanned raw images (1MHz).
On top of the sinewave, add a DC offset to the signal to simulate introducing the average radius of the revolution to the entire signal. The radius used here is 13.2cm. The spatial dynamic range of the sinewave used here is 0.027mm (according to the stats of our test sine wave).
Resample the signal at 48kHz and differentiate. The output, the clean signal, is here: http://kakyoism.webhop.net/~kakyo/0.report/44.center_error_sim/sine_input_48khz.wav
Now, if we shift the center by 3mm x 1mm, and then repeat #4, the output signal is here: http://kakyoism.webhop.net/~kakyo/0.report/44.center_error_sim/sine_center_shift_48kHz.wav.

Synopsis

As we can see/hear in the results, the output signal from the shifted center shares the same qualitative feature with the sine wave extracted from the scanned images.

Plan

Do another simulation to reproduce the crackles based on a generated sinewave in the similar manner.

RIAA EQ improves audio

2010-05-29T20:13:00.001-07:00

Audio result using spline differentiation:
The music sample without RIAA EQ reproduction filter:
http://kakyoism.webhop.net/~kakyo/0.report/43.RIAA_EQ/audio_mitac_stereo_v2_algo7_music.wav

The music sample processed with RIAA EQ reproduction filter:
http://kakyoism.webhop.net/~kakyo/0.report/43.RIAA_EQ/audio_mitac_stereo_v2_algo14_RIAA.wav

Audio result using wavelet differentiation
The music sample generated with wavelet differentiation after resampling, without RIAA EQ:
http://kakyoism.webhop.net/~kakyo/0.report/43.RIAA_EQ/audio_mitac_stereo_v2_algo15.wav

The signal generated with RIAA EQ
http://kakyoism.webhop.net/~kakyo/0.report/43.RIAA_EQ/audio_mitac_stereo_v2_algo15_RIAA.wav

Signals above are all resampled to 48kHz.

As we can notice, the crackle noise is not reduced using spline differentiation, but the musical signal's spectral balance is restored after applying RIAA reproduction EQ. Using wavelet differentiation is somehow similar to apply a low-pass filtering (the non-EQ'ed version), after applying the RIAA reproduction filter, the output signal's spectral balance can be heard as not restored, still sounds like low-passed.

Summary
Wavelet differentiation offers better crackle-noise reduction, but it is unknown yet how to counteract its strong low-pass effect.

Other differentiation methods are more susceptible to crackle noise (local signal noise) but maintain the spectral balance.

Question

Which way do we go: wavelet or regular differentiation?
Can we derive the equivalent filter spec that the wavelet differentiation introduces?

Audio rendering from undulation

2010-05-24T15:19:00.000-07:00

Summary

Previously we focused on extracting audio from the 2D groove undulation of a 1kHz sinewave, i.e., the radius of the groove edges to the disc center, and found that

The data contains lots of noises.
The signal do not appear to be fluctuating around the horizonal
axis, i.e., not centered to the 0-DC component. It includes a
time-varying DC offset that brings the entire signalup above or down below horizontal asis.
The resulting sine signal has periodically varying pitch around the expected 1kHz component.

The processing steps involved for extracting audio from undulation (order unclear)

Resampling the undulation at a fixed lower sampling rate
Differentiation against time
Possible filtering
Stereo decoding

We had theories about the above problems that

The noise may be from extracted groove undulation under the
extremely high resolution. The imperfect local groove shape then gets
amplified by differentiation. In other words, they are likely ignored
when played with the phonograph stylus.
#1.1 and 1.3 may be from the error in disc center estimation which caused the periodic fluctuation in the group envelope of the extracted undulation.

A few questions about the above problems were not addressed

What are the noises? Are they gaussian or signal-related? Are
they from the slight (1-2 pixels) discontinuity at the boundaries of
stitched FOVs or just signal-related?
How would DC offset applied to an audio signal affect its perceived pitches?
Can we find a model of the center estimate error and counteract the error by imposing a compensation based on this model?

We decided to address #3.1 first and leave the pitch-fluctuation aside till later.
Last week, the order of the steps listed in #2 and the parameters setup of each individual step were investigated. Some questions from #4 were answered:

The noises are not white noises and sound like crackles. From
filtering tests, they are signal-related broad band noises that can
cover the entire audible bandwidth.The noises can be reproduced by extracting a small subset of undulations (1 or 2 FOVs) and repeat them.
The noises cannot be suppresed by using simple moving-average
filtering alone, before or after the signal gets resampled or
differentiated.
The visible time-varying DC offset we saw previously, which
shows itself as a snake across the 3-second sinewave group amplitude,
was introducedby the wavelet differentiator that I used all along, not by the center estimate error. The DC offset itself doesn't
cause the pitch fluctuation, although the fluctuation should still be
caused by center estimation error. It's just that the big snake we saw
is not the visual representation of the audible signal frequency
fluctuation.
When using numerical differentiation by definition (dy/dx), there is no DC offset.

The crackle noises can be suppressed by using the same wavelet-based differentiator before resampling, but
due to some bugs the output audio is at a wrong sampling rate and
longer -than-expected signal (3 sec => 24 sec), which I need to
figure out how.

Details

Tried a few combinations of the processing sequence in Summary #2. The only combination that can remove the crackes is as described in #7. See Details #2.2
Tried differentiation by definition and a couple of models under the wavelet framework.

Differentiation by definition does not introduce DC offset, but is susceptible to noise and contains pitch fluctuation. [See figure below].

Global audio signal view: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/diff_by_def_after_resample_global.png
A portion of the same signal: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/diff_by_def_after_resample.png
Audio (48kHz): http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/audio_mitac_stereo_v2_algo7.wav
Stick in a lowpass before resampling does not help suppress
the noise (tried cut-off frequency at 2kHz). The differentiation still
amplifies them to the audible degree.

According to papers such as this one, wavelet differentiator offers better noise suppression among existing numerical differentiators, especially under low SNR. [See result below]

Global audio signal view: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/diff_by_wavelet_before_resample_global.png
A portion of the same signal: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/diff_by_wavelet_before_resample.png
Audio (48kHz): http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/audio_mitac_stereo_v2_algo12.wav
Audio (384kHz): http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/audio_mitac_stereo_v2_algo12-384khz.wav

Tried #2 on the music signal

With differentiation by definition, Audio (48kHz), no sampling rate error, DC offset, but with pitch fluctuation and noises: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/audio_mitac_stereo_v2_algo7_music.wav
With wavelet differentiation, Audio (48kHz): sampling rate error: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/audio_mitac_stereo_v2_algo12_music.wav
With wavelet differentiation, Audio (144kHz): sampling rate error after trial and error, the signal length is the closest to the expected: http://kakyoism.webhop.net/~kakyo/0.report/42.audio_diff/audio_mitac_stereo_v2_algo12_music-144khz.wav

Tried resampling with linear and polynomial interpolation. Doesn't make an audible difference.
Tried zero-phase and regular low-pass filtering. Zero-phase filtering introduce DC-offset, regular low-pass filtering is very unstable.
Tried moving average filtering in time-domain. Doesn't help unless we use wavelet differentiator before resampling.

Plan

I haven't found how to fix he visible DC offset and the sampling rate error introduced by the wavelet differentiator.
The quality and side-effect of numerical differentiation are said to be
highly problem specific. So I'll dig into the numerical differentiatora little deeper with basic tests and also check out the Stotzer's solution. In a week, I should be able to get it right.

Problem with resample and differentiation

2010-05-11T02:30:00.001-07:00

Previously differentiated groove undulation of sine wave look good, however,
the entire differentiated signal shows low-frequency radius modulation and reflects in the resulting sound.

Audio (left, right channel by inner/outer differentiated radius)

http://kakyoism.webhop.net/~kakyo/0.report/41.wrong_diff/audio_mitac_stereo_v2.wav

Plot of left channel stereo (Silence), not scaled according to the right
x-y size ratio

http://kakyoism.webhop.net/~kakyo/0.report/41.wrong_diff/diff_silence.png

Plot of right channel stereo (1kHz Sine), not scaled according to the
right
x-y size ratio

Warning: This may not make much sense to eyes, just as a reference

http://kakyoism.webhop.net/~kakyo/0.report/41.wrong_diff/diff_sine.png

There are two possible causes:
1. This differentiation was done with Order 1 (every neighboring samples). There could be local errors here and there. But this doesn't explain well the fact that the error shows an overall trend of a low-frequency component.
2. The cause can be the disc center estimation error, which leads to the periodic error curve in the polar coordinates of the grooves. Haber tried to solve the similar problem by modelling the disc center with a sine-based center correction function. I may need to try that. However, this means to spend about 1-2 days on each try because the coordinates and groove edges are going to be regenerated. We need to think of better ways.

The clicks in the signal can be seen in the plotted differentiated signal. They can probably be filtered out with an additional low-pass filter. But I will delay this step until I solve the problem above.

Differentiation result after removing stings

2010-05-04T06:49:00.000-07:00

Our sting removal algorithm resulted in improved sine signal after flattening and differentiation.

Previous result:
http://kakyoism.webhop.net/~kakyo/0.report/37.flatten_sine/undudiff_radius_arc-fov632-368-3-2-fov631-369-4-2.png

Result after removing stings
http://kakyoism.webhop.net/~kakyo/0.report/40.flatten_nosting/nosting-undu-fov632-368-3-2_631-369-4-2_diff.png

FOVs involved

Sting removal solution

2010-04-27T00:05:00.001-07:00

Previously we found that irregular groove edges would cause significant distortion in the differentiation phase of audio extraction. They therefore have to be cleaned up beforehand.
About 12 algorithms were tried, and a relatively good-enough solution was found.
Basic idea: Detect radius differences that represent skewing of groove shape symmetry, which is derived from stylus shape, and then shift the offensive edge points towards the direction that would restore the symmetry.
Fact: Radius differences of edge series measured at a distance corresponds to the location of the "stings". An optimal difference interval can be found, which ensures that the stings show sufficient distinction in the FOV-local edge series. Under our current settings (10X magnification), 10-point-interval makes the sting location most obvious. Intervals smaller or greater than 10 show less promises. See figures below:
1. Groove edge with a convex sting: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/edge-sting-r669-c245-i1-e2.png
2. Radius difference at interval 3: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/radiusdiff-fov669-245-1-2_difforder-3.png
3. Interval 5: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/radiusdiff-fov669-245-1-2_difforder-5.png
4. Interval 7: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/radiusdiff-fov669-245-1-2_difforder-7.png
5. Interval 10: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/radiusdiff-fov669-245-1-2_difforder-10.png
6. Interval 15: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/radiusdiff-fov669-245-1-2_difforder-15.png
7. Interval 20: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/radiusdiff-fov669-245-1-2_difforder-20.png
8. As seen in the above figures, intervals below 10 give less obvious radius difference for stings, yet those higher than 10 start to show great difference across the signal range. 10 gives the best signal-to-noise ratio.
According to my experiement, it is rather difficult to to wipe off all the stings in one pass along a groove edge series. After a lot of trial-and-errors, the final solution is a recursive algorithm contains three major step:
1. Remove any overlapped pixels at each azimuth.
2. Detect stings by measuring radius difference a large azimuthal interval (default to 10 points), treat the detected locations of significant radius discontinuity as stings, recursively remove the front one and remeasure until no new stings are detected.
3. Perform post-processing radius-diff at interval 1 to smooth out possible remaining edge irregularities.
About #5.2, look at the edges as flattened 1D signal. Because the start and/or end of the target diff interval usually lie somewhere in the middle of the sting-part of the signal but not exactly the opening or the closing point so that we don't know , we then adjust the edge point's radius so that the updated radius diff at the same interval gets down to the median level of the groove in the FOV, that is, to "wipe it flat". Note, we also linearly flatten the points within the interval when the slope is detected.
Because each detected interval correspondes to a radius ramp. In order to minimize the difference in such an interval, it's necessary to have a reference point and shift the other points against the reference point. However, both convex and concave irregularities can be seen in the edge. The relation between reference and target and the shifting direction thus can become quite complicated. We thus introduce the groove shape, i.e., the symmetry nature of its left/right half, as heauristics on the shifting of edge points for restoring the grooves. Assume the left/right half of the groove cross-section are of a constant ratio across a local range and a sting tends to distort such a symmetry. Then any shifting that can reduce the distortion to the symmetry is good. Note that this only serves as a sanity check after a shifting iteration, not main heuristics, because this feature relies on three noisy signal: inner edge, outer edge and the bottom, and thus less accurate than the radius difference of either edge.
We also make sure we don't re-visit what's alrady processed.
Example of sting and fixed groove edges
Another example
Another example
Another example
Groove symmetry feature of the groove in Example 10 and 11: http://kakyoism.webhop.net/~kakyo/0.report/39.remove_sting/centroid-rci354-502-3.png
The next step would be to perform resampling and differentiation after fully applying this to the grooves before they are flattened.

Remove radial overlap caused by sting on grooves

2010-04-15T20:33:00.001-07:00

Previously, tiny bumps on groove edges could result in quite visible distortion in differentiated flattened groove radii. One source of error is in that edge detection could collect points around the stings so that wrong points are taken into account and made the signal longer than it really is. As in
http://kakyoism.webhop.net/~kakyo/0.report/37.flatten_sine/edge-fov1-r632-c368-i3-e2.png
The result of differentiation
http://kakyoism.webhop.net/~kakyo/0.report/37.flatten_sine/undudiff_radius_arc-fov632-368-3-2-fov631-369-4-2.png

These wrong points overlap in azimuth with the valid edge points. A simple treatment is then applied to the same image to remove the overlapped points: At each azimuth location of outer edge, reserve inner most edge point and for inner edge, outermost point. This way we ensure at teach azimuth, only one point is reserved. The result is immediately improved:
Raw flattened radius:
http://kakyoism.webhop.net/~kakyo/0.report/38.remove_sting/undu-fov632-368-3-2_631-369-4-2_radius_arc.png

Differentiated signal:
http://kakyoism.webhop.net/~kakyo/0.report/38.remove_sting/undu-fov632-368-3-2_631-369-4-2_diff.png

The source FOV treated after sting-removal
http://kakyoism.webhop.net/~kakyo/0.report/38.remove_sting/edge-fov1-r632-c368-i3-e2.png

This method is probably useful only to small stings, with larger bumps as in the same image. More sophisticated filtering should be used. Under investigation.

Flattened and differentiated sine from testLP

2010-04-13T14:10:00.001-07:00

The stereo sine signal scanned last is processed with our improved workflow. The sine channel is differentiated and looks smoother than what we had for ISMIR. I haven't tried to resample the signal before getting any opinions about the data.

Flattened groove of the sine wave (1kHz, 3.286 sec ~= 1.826 rounds)
Inner edge (silence
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undulation_radius_arc-fov668-281-2-1-fov524-45-6-1.png

Outer edge (sine)
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undulation_radius_arc-fov668-281-2-2-fov524-45-6-2.png

First 0.003 sec (about 3 periods for 1kHz), outer edge only
Flattened signal
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undulation_radius_arc-fov634-365-4-2-fov633-367-3-2.png

Differentiated signal (dx = 1, using a wavelet differentiator: http://www.mathworks.com/matlabcentral/fileexchange/13948-numerical-differentiation-based-on-wavelet-transforms)
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undudiff_radius_arc-fov634-365-4-2-fov633-367-3-2.png

First 0.01 sec
Flattened signal
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undulation_radius_arc-fov634-365-4-2-fov629-373-2-2.png

Differentiated signal
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undudiff_radius_arc-fov634-365-4-2-fov629-373-2-2.png

The corresponding FOVs to the 0.01 sec signal

The differentiated signal is scaled by 1000 to be well visible; the raw magnitude is about 0.15 (pixel).
Note that the distortion around 6.6~6.7x10^4 looks like this
Raw signal
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undulation_radius_arc-fov632-368-3-2-fov631-369-4-2.png
Differentiated signal
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/undudiff_radius_arc-fov632-368-3-2-fov631-369-4-2.png
Corresponding FOV
http://132.206.14.194/~kakyo/0.report/37.flatten_sine/edge-fov1-r632-c368-i3-e2.png

Looks like minor defect in raw signal could cause larger effect in differentiated signal.
So some filtering/resampling may be desired. Will try that later.

Against what do we do fitting and differentiation on a signal?

2010-04-04T20:51:00.001-07:00

In the last report, the x-axis that is used in radii-vs.-arc plots are wrong because multiplying angle with radius does not necessarily reflect correct time interval between consecutive data points as in the time-series of the recorded audio signal. The distortion introduced by using this arc as x-axis can cause the output signal to look time-reversed as in this plot:
http://132.206.14.194/~kakyo/0.report/36.flatten/undulation_radius_arc_reverse.png

It is crucial to derive the correct time intervals along the inward spiral of the groove. Without the correct time intervals we cannot resample the groove at correct audio rates.

Because the disc playback ensures that angular velocity is constant at all times, the angular progression can be seen as a reliable representation of the time progression. Fitting/Differentiating against the angles is the way to go. Previous approach by arc was wrong.

However, to plot the signal with correct scaling of x-axis and y-axis, i.e., by radii-vs.-arc, an average radius should be plotted aginast for each revolution instead of simply the multiplication of radii and angles point by point. The corrected radii-vs.-arc plot of the entire signal looks like this:
http://132.206.14.194/~kakyo/0.report/36.flatten/undulation_radius_arc_correct.png

Flattened 1D groove undulation signal

2010-04-03T20:37:00.001-07:00

Below are from a segment of flattened groove undulation signal and the original groove edges in images.
Entire inner-edge undulation, radii vs. arc:
http://132.206.14.194/~kakyo/0.report/36.flatten/undulation_radius_arc.png
Same signal, radii vs. arc:
http://132.206.14.194/~kakyo/0.report/36.flatten/undulation_raw_radius.png

Radii of a segment of signal (0.044007 ~ pi/45), radii vs. arc:
http://132.206.14.194/~kakyo/0.report/36.flatten/undulation_radius_arc_part.png
Same signal, with radii vs. data-point number:
http://132.206.14.194/~kakyo/0.report/36.flatten/undulation_raw_radius_part.png

Corresponding FOVs to the segment (in the order of their appearance in the output signal)

Note that in the FOVs,

The bounded red lines are the edges that are extracted.
For this segment of signal, the disc center is far above the image, i.e., those are the inner edges of the groove.
The selected segment starts in the middle of FOV #1 and ends in the middle of FOV #3.
FOV #2, and #3 look like they are missing the front part. It's because the edges are initially overlapped and are pieced together in pairs in the output signal. After calibration, the overlap part of the latter one in a pair is discarded.

In the entire signal:

There seems to be some error in the radii-vs-arc plot: There are visible signal overlap along the arc axis, which means the points are not exactly consecutive in time. But this could also be all fine because plotting this way will have the points all squeazed in a narrow figure.

Resampling problem

2010-03-30T22:58:00.000-07:00

After groove unwrapping, we now have "flattened" 1D signals from images. The equivalent sampling rate of the signal is usually much higher than industrial standard; also, due to the incompatibility between arbitrary groove orientation and matrix pixel rasteration, the signal cannot be seen as sampled at a constant rate across its range. The next step in our process would be to resample the signal at a constant audio sampling rate.
Previously I didn't test my resampling algorithm on signals other than the scanned data. A test on a generated sine wave showed that my previous algorithm yields seriously wrong result.

1. Input: http://132.206.14.194/~kakyo/0.report/35.resample/poly_order1/_test_fit_in.png
Output: polynomial fit with order-1: http://132.206.14.194/~kakyo/0.report/35.resample/poly_order1/_test_fit_out.png
order 2: http://132.206.14.194/~kakyo/0.report/35.resample/poly_order2/_test_fit_out.png
order 4: http://132.206.14.194/~kakyo/0.report/35.resample/poly_order4/_test_fit_out.png
spline: 2 http://132.206.14.194/~kakyo/0.report/35.resample/spline/_test_fit_out.png
The problem was that previously we resample only locally with a tiny window and we performed fitting for each window. It iterates across one pixel each time.
Standard resampling algorithms in Matlab seem to give better but still very inaccurate result, especially on variable-samplingrate signals.
See http://132.206.14.194/~kakyo/0.report/35.resample/resample/_test_fit_in.png
and the output http://132.206.14.194/~kakyo/0.report/35.resample/resample/_test_fit_out.png
Local fitting will see each segment of linear signal, so that lower order fitting will give as better result.
Matlab resampling algorithm needs to know raw input sampling rate for the specified segments.
Need to investigate more about resampling methods for our ask.

bottom thinning

2010-03-22T21:15:00.001-07:00

The raw groove bottom extracted is an narrow band of pixels, i.e., 2D. A single-pixel-wide 1D signal needs to be extracted from it.
Previously, bottom thinning was done after groove unwrapping and before resampling at audio rate. This was done by analyzing groove cross-section and treating either center or lowest points of the groove as the real bottom position.
A major drawback in this approach was that errors would be introduced when extracting groove cross-section along groove orientation from the image. Due to the fact that groove orientations are usually not aligned with matrix-based image pixel rasteration, in general, trying to extract cross-section by finding inner/outer edge point pair from the raw image would introduce error, whichever resampling technique is used.
I think the fair way in the context of our overall approach is to apply a viable 2D image thinning to get the 1D single-pixel bottom, in the same sense as we perform edge extraction to extract 1D undulation of inner and outer groove. Then the resampling can be performed to the 3 1D signals. Only after the three signals are at the same sampling rate can we analyze cross-section of the groove.

Major error in disc center.

2010-03-15T23:27:00.001-07:00

After edge extraction, we did phase unwrapping and groove unwrapping. For this 9 seconds of musical signal scanned in 2007, unfortunately, a major error in disc center estimation can be seen in extracted edges of individual FOVs, as shown in

http://132.206.14.194/~kakyo/0.report/34.merge_edge/undu_seg1_rcie313-118-4-1_313-119-4-1.png
and
http://132.206.14.194/~kakyo/0.report/34.merge_edge/undu_seg1_rcie313-118-4-1_313-119-4-1_eq.png

The FOV is supposed to be at the 6 o'clock position and thus should have been nearly horizontal given the small FOV (0.6 x 0.4 mm), however, after scaling the axis in correct units (both in pixel), it appears to be nearly vertical.

Another image will show things more clearly.
http://132.206.14.194/~kakyo/0.report/34.merge_edge/wrong_center.png
The figure shows the result of differentiating neighboring points' absolute arc lengths calculated from a common start of the scanned signal. Theoretically we should have seen nearly constant positive value. Now there are large portion of negative values, meaning along the audio signal time-line, there are "time-warps". This error most probably came from wrongly estimated disc center.

It's unknown why the center estimation was so off for this scanned disc. One solution to this is to assume the inner-most revolution is nearly silence and measure the pattern in the radii fluctuation for this cases, and finally interpolate based on empirical results of the center.

Material for meeting (will be explained during meeting)

2009-11-24T04:40:00.001-08:00

Deadline met: Finished new preprocessing

2009-11-18T05:11:00.001-08:00

Context

After stitching is complete, groove images need Preprocessing before edge-detection can be used for extracting undulation.
Preprocessing generally contains the following steps

Remove noises, i.e. false groove CCs contained by groove-spacing CCs).
Detach attached grooves (by connecting the groove-spacing CCs contained by the groove CCs).
Re-connect broken grooves.
Re-connect broken groove bottoms.

Our previous algorithm was not robust enough in the detaching step. It worked well on the sine-wave disc but the the other music disc. This turned out to be due to the fact that the presence of continuous groove bottoms had been an implicit prerequisite.

Solution

The workflow is adjusted to connect broken groove bottoms before doing detaching and reconnecting.
This is a re-write because previously, we rely on context created by the detached/re-connected grove images, but now we will have to re-connect much thinner bottoms with less references.
We perform a two-pass approach to re-connect broken bottoms:

In the 1st pass, we check broken bottoms that overlap in radius, treat them as in the same goove and connect them.
In the 2nd pass, we check broken bottoms that do not overlap in radius, but are close enough in direction and distance, and connect them.

After we know that all bottoms are continuous, we examine the FOV and see if there are any groove CCs containing more than one bottom; if so then the groove CC is an attached one. We then reconnect the CCs in between these two btttom.

Result

No time for uploading images, but the new algorithm works much more robust the previous ones.

New Weekly Task with Deadline

By the same time next week, I will make sure that the module of edge detection (after our preprocessing) should work.
If the above goal is met, then go on to make sure that the module of collect FOV chain for groove unwrapping should work, i.e., given a starting FOV and groove revolution, the program should be able to go along the groove revolution across correct FOV and groove segments in that FOV untill the groove ends at the boundary of scanned data.

stitching gap problem solved

2009-10-12T12:10:00.001-07:00

The previous stitching gap caused by asynchronous sub-grid stitching is solved by hard micro-correction of FOV positions in the offensive sub-grid, by:

At the end of 1st-run of grid stitching, detect boundary row gap between the last pair of grids.
micro_correction = gap / number_of_rows_of_upper_grid
for each FOV in the upper grid, FOV_position += micro_correction.

In our case, the micro-correction for each row is about 0.22 by 0.07 pixel

After this, all images are meshed in a visually correct manner.

Back to Square One...

2009-10-05T20:49:00.000-07:00

According to this two-weeks' work, and quantitative tests,
I corrected some former stitching bugs but ended up proved that systematic errors do exist in greedy image registrations and it seems no way to conquer without using a DP-like constraints or dynamic error correction along the way. See above images, in the top-down order,

the grid of the scanned FOVs around the disc label,
the stitching result of the last two rows of Grid3,
the stitching result of the last row of Grid-2 and the first row of Grid-4,
the result of stitching the last row of Grid-3 and the first row of Grid-4.

The inter-grid stitching was in the order of

Grid-1 vs. Grid-2 (top vs. left)
Grid-1 vs. Grid-3 (top vs. right)
Grid-2 vs. Grid-4 (left vs. bottom)

Exchanging #2 and #3 would cause the similar gap between the last row of Grid-2 and the first row of Grid4.

According to my stats of stored shifts, (I saved all the shifts between each stitching sub-process), when measuring the inter-row shifts within a grid, such shifts in Grid-2 and Grid-3 have a total discrepancy of
131.3538 pixels vertically, and -7.6996 pixels horizontally. This total gap averages to vertical-error of 0.1972 pixel/consecutive-row-pair, and horizontal-error of -0.0116 pixel/consecutive-row-pair. For most image registration results, there are no visible gap until the bottom row-pair shown above.

Given such a small mean-error of inter-row results, tweaking FOV-pair image registration with the same greedy-process probably wouldn't lead to a better result. One possible solution to this is to introduce a rule-based correction stage after inter-row stitching for the grid on the left/right side of the disc label:

Measure total row-shifts of left/right grids after intra-grid stitching.
If there are discrepancy between both grids, go to the next step.
Treat rows that shift most as rows that generate most inter-row error.
Compensate the errors between left/right grids by setting up a series of anchor-rows, compare the discrepancy in between each of these ranges, and finally apply inverted shifts according to the average error to FOV-rows that exceed custom shift threshold.

The proposed solution is pretty ad-hoc, but the idea is to at least fill the gap, thus permits us to have continuous groove unwrapping.

stuck at stitching/alignment logic

2009-09-22T05:30:00.001-07:00

total_shift(fov) = intrarow_shift(fov) + interrow_shift(fov)

interrow_shift = junc shift = pair_shift(junc, junc_up) + total_shift(junc_up) - intrarow_shift(junc)

A big mistake in my previous judgement about stitching

2009-09-16T20:50:00.001-07:00

In my new round of experiment, I refactored my stitching code and found that there was some bug in my code that caused the previous "huge gap" near the end row of the scanned grid. It turned out that even the raw unaligned data were not that far off. There really shouldn't be any gap between the images after the entire alignment, in a usual case.

I'm still in the middle of fixing the bug, but at least now it's clear that Dynamic Programming should be unnecessary under our experiment setup. This is a big relief. I'm so glad that I didn't rush to implement the DP version of stitching.

It is also clear that, during the later groove unwrapping, it's not the responsibility of the unwrapping module to do any 2D alignment, only vertical alignment needs to be done. All 2D misalignment should be corrected in the initial alignment.

Why do we need to work on initial stitching instead of simply correcting the unwrapping radial shifting error

2009-08-29T13:42:00.001-07:00

Summary

We previously talked about an obvious error about moving radially the edges during unwrapping.
This turns out to be a hard problem to correct in the unwrapping phase, because

In the unwrapping phase, we've lost the single image and work along the rings of tertiary edges (inner/outer/bottom).
To correct individual alignment of them has to affect all the other ones that used to be in the same iamge.
This is equal to doing an edge based alignment in the first place.

Therefore, we better do a 2-pass alignment in the beginning.

Stitch with edges

2009-08-29T13:20:00.001-07:00

Summary

Edge-based registration has a big problem when used on groove images: in the edge image, there is usually too little data in the overlap region (groove valley bad-data becomes dominant in edge images), and thus cripples the cross-correlation process.
A solution may be a 2-pass algorithm

Area-based cross-correlation.
Do edge detection.
Use custom heuristics: Match the edges on image boundary between two images, using custom rules such as "if 4 out 5 edge pairs are off by 3 pixles, then we translate one of them back to minimize such offset."

Image Alignment revisit

2009-08-24T23:23:00.001-07:00

Summary

Read some more surveys of image registration techniques, although I’ve read a few reviews of image registration/stitching literature.
The previous mentioned image registration accumulated errors, which may have caused the wrong groove width/depth ratio stats, should be eliminated before groove unwrapping. That’s to say, during unwrapping, it’s unreasonable to perform any 2D-translation type of pixel manipulation because we are solely in polar system.
Therefore, image alignment should give reliable results before groove unwrapping.
According to the surveys, area-based methods, e.g., cross-correlations and frequency-domain counter parts, are best suited to images suffered from translation-only deformations. In our case, the disc fixture ensures that we have translation only deformation, no rotation or other types of disturbance. So we should stick to what we have chosen, area-based cross-correlation.
However, image intensity based cross-correlation could be refined with edge-based cross-correlation, but in our problem domain, its effect is unknown; tests are needed.
Our problem domain makes it hard to create quantized alignment error metrics. Visual assessment is by far the most useful standard. With edge-based matching, we may come up with something useful.

Plan

Try edge-based registration right after CC analysis as a fine-level registration.

scanning progress

2009-07-28T05:45:00.001-07:00

Summary

Finished scanning the Mahler Symphony 7 segment with 20X.
Scanning the lead-out groove with the same setting on the same disc (for double checking center)
Prepare to scan the previous Mahler with 20X, hopefully our last batch.
Drift detected, under 20X, something I haven't thought of before now becomes clear: the stage drifts and the center location changes every once in a while (of course!!). Therefore, during image alignment although we aligned individual images, the center remains the initial values, this appratently creates wrong polar coordinates for all FOVs scanned after the stage drifts. See Detail.

Detail

How the center drift was detected: It was detected during the latest scan, in which the disc was divided into 6 parts. Since the center was calculated from 3 sample points on the leadout groove in the first place, I went back to check these three points when Part 6 was finished, in the intensity window under 20X, there was about 1/4 20X FOV size visible drift (Note, such drift can only be detected with eyes), i.e., ~= 0.08 x 0.06. mm. So we can realize that when scanning across different divisions of a grid, drifts like this happens all the time to FOVs and center as well. Therefore, aligning FOVs without sync the center during the course will produce wrong poloar coordinates.
How bad the drift per FOV: For a 20X scan of over 10,000 FOVs, such accumulated error is at sub-micron level per FOV.
Solution: There may be a need to reserve a calibration FOV in the grid and periodicly rescan it during the whole process, e.g., between sub-grids, and derive drift data out of it to provide metadata to image alignment, and determine the center location for the sub-grid.
Optionally, we can "correct" our polar coordinate calculation in favor of this finding: record drifts during alignment for each FOV; then when calculating polar coordinates, shift the center according to these drifting data for each FOV.

Hard decision to make: groove unwrapping

2009-07-12T14:24:00.001-07:00

Summary

The bug that caused the wrong depth/width data is found in theory.
It turns out to be a problem in the alignment of edges while unwrapping grooves:

Remember we tried to correct image misalignment by pixel-level image registration as the first step of the whole image process. This initial alignment inevitably leaves thin misalignment that leads to tiny gaps in 3D between edges from consecutive FOVs.
Such gaps need to be finely aligned in the 2D Cartesian system as in Step #1.
However, after converting Cartesian system to polar system, I wrongly used only radius for registration of edges, assuming the shifts are all in the radial direction. This is clearly wrong. The realignment should be in the same way as in the pixel-level, i.e., in 2D, except that this time we will have to use the edge continuity as a constraint in our registration.

We could also modify our initial pixel-level alignment to become a content-aware version, using all CC's edge alignment to ensure the high-quality in the first alignment.
Now it's a hard decision to make between #2.3 and #3. One thing for sure, is local greedy alignment with the help of some simple constraints are very likely to fail.

Bug detected in groove unwrapping

2009-07-11T15:54:00.001-07:00

Analysis

Previous depth gap prooves to be a bug again in my unwrapping algorithm.
There is an unfortunate dilemma in groove unwrapping (FOV alignment)

The goal of unwrapping is to connect and align edges. But why do we align again?
It's because pixel level alignment at the beginning of the whole image processing has inevitable errors, e.g., of 1-2 pixel scale laterally, and couple microns in the vertical dimensions; these errors need to be further minimized during aligning edges.

When aligning edges, we now have three sets of data that needs to be aligned: inner/outer edge and bottom (short to IOB).
The result we want here is in the aligned data, there is no distortion in the relative position between IOB, both laterally and vertically.
Unfortunately, it is proven that simply aligning each element of IOB will cause misalignment of the others, and the accumulated errors will grow out of control as we go along the groove.
Therefore, my current strategy is to have a hierarchical alignment:

Set one edge as master and align between FOVs for it.
Set the other two as slaves, and shift them using the same step resulted from the master alignment

Unfortunately, although this works fine for lateral cases, in the vertical direction, it caused the former "jumping" bottom we saw.
So I ended up aligned bottom separately, which eliminated the z-gap we saw a month ago.
But now it turned out that it distorted the depth.
I now suspect that the vertical hierarchical alignment should have a finer algorithm, and the bottomline is we never align more than one IOB element.

Stylus shape with depth calculated by using inner edge as top

2009-07-11T13:46:00.001-07:00

Summary
Previous tests are repeated except that the depth is calculated as the vertical distance between inner edge and bottom.
I won't waste time pasting images here. They look about the same in terms of the depth value range as the ones in previous posts.
This tells us that in the data we have:

Even though the groove width value ranges are pretty consistent across the groove, the disc is non-flat and the depth range varies.
Stylus shape is not consistent in this data, e.g., with somewhere width/depth ratio being around 2 and elsewhere around 6.

We need to do the same test with other datasets before we draw the conclusion.

Plan

Do the stylus shape test with different datasets we have.
Continue to get sound because we've cleared some serious bugs without re-testing the sound extraction.
Prepare for running a brand new experiment with new data scanned under 50X/20X.

Stylus shape (center bottom) analysis

2009-07-11T09:19:00.000-07:00

Analysis

Take Data set as an example. The depth curve in 1D bottom with the "groove center" algorithm is much smoother than the "groove deepest point" algorithm

Center bottom:http://132.206.14.194/~kakyo/0.report/32.stylus_shape/4/z_btm_flex.png

Deepest bottom: http://132.206.14.194/~kakyo/0.report/32.stylus_shape/2/z_btm_flex.png

The width/depth ratios are still noisy from both algorithms. This is due to the fact that although the value range of width is pretty stable across the groove, the value range of depth is not: in Dataset 1 the depth range is about 28~38um, while in Dataset 2 it is 11~21um.
The data in #2 is very suspicious. Depth is now computed as the distance between groove top and bottom, where top is the mean of z values of inner/outer edges. If both edges are noisy, the mean could exaggerate it, leading to inaccurate depth. Therefore, it's worth trying to use either inner or outer edge alone as the groove top z values.

Plan

Do the same experiment with the proposed depth metric in Analysis #3

Stylus shape (center bottom) Data set 2

2009-07-11T09:13:00.000-07:00

NOTE: groove width and z values of inner/outer edges are the same as in previous post on Data set 2.

1

2

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

Stylus shape (center bottom) Data set 1

2009-07-11T08:47:00.000-07:00

1

2

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

Summary

The same experiment as in the last post using a different bottom thinning algorithm: use the center of the groove valley as the 1D bottom.
The last plot of three edges looks less jagged as the previous bottom thinning algorithm based on deepest points.
NOTE: the groove width and z values of inner/outer edges are the same as the previous posts on Data set 1.

Stylus shape: Data set 2 - Part II

2009-07-06T20:25:00.000-07:00

Summary

Data set 2 uses the same algorithm for generating Data set 1.
Most part of Data set 2 is similar to Data set 1.
The major difference is that the width/depth ratio is different (See Figure 5), meaning that the overall width/depth ratio is noisy. Given that bottom doesn't look too off, this may suggest that width/depth ratio is not a qualified descriptor stylus shape, under current scan resolution.

Plan

Try the same thing with the lateral rule and bottom thinning.

Stylus shape: Data set 2 - Part I

2009-07-06T20:24:00.001-07:00

1

2

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

Stylus shape: Data set 1 - Part II

2009-07-06T18:37:00.000-07:00

Summary

The last post presents a series of groove/stylus shape information from a 600-point segment of unwrapped stereo-sine groove. From top to bottom, they are:

Width with flexible scale of both axes
Width with equal scale
Depth, flexible scale
Depth, equal scale
Width/Depth ratio
Z of inner edge, flexible scale
Same as #6, equal scale
Z of outer edge, flexible scale
Same as #8, equal scale
Z of bottom, flexible scale
Z of bottom, equal scale
Radii of outer edge, bottom, and inner edge (top down)

The shape of width and depth are pretty much sine, butthey are quite noisy. Width data has quantized jump between data, because the difference between neighboring data is hitting the horizontal resolution of the microscope (10X, 0.001 mm/pixel)
Figure 5 (ratio of width/depth) looks quite noisy, but it's mostly around 2. Which is the theoretical ratio of width / depth based on the 45-degree cutting scheme ( the cross-section is supposed to be an isosceles right triangle.
Figure 6-9 showed z values of inner and outer edge. From the equal scaled versions, the inner and outer edges are almost flat.
Figure 10-11 show z of bottom. The 1-D bottom is estimated with the deepest-rule: among the bottom points at the azimuth A, the deepest point is taken as the true bottom.
Figure 12 shows that the deepest rule is not accurate in that the radii of the 1D bottom are not smooth. Therefore, deepest rule alone either does not guarantee accuracy. It has to be regulated with certain lateral rules or lateral thinning algorithm.
We'll show the lateral rule in next set of posts. Lateral rule uses the center of the groove cross section as the true bottom position.

Stylus shape: Data set 1 - Part I

2009-07-06T18:36:00.000-07:00

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12

groove edge pairing: FOV backtrace

2009-07-05T16:01:00.000-07:00

Summary:

In previous post, I may have mistaken the sine wave undulation for a "jagged" signal; the plot was not scaled equally in x and y, which exaggerated the jagged situation.
The plot in the last post includes a couple tens of FOVs all stitched together.
The plots here show only a portion of the inner/outer/bottom edge plot in the last post.
The bottom plot shows the portion, the next image shows the backtraced inner edge in FOV. The top image shows the bottom in the same FOV.
The units are both mm for x and y dimension in the plot at the bottom.
The x and y axes in the plot is scaled differently for visual clarity.
I don't think it necessary to show the marked outer edge, because it's easy to see in the other two images of the same CC.
In the plots here, the 1D bottom is still off quite a bit. Quite a few points are off center due to our "deepest=bottom" decision.
Anther detail of the plot of the last post is that the envelope of the edges show a monotonous decrease, which is correct according to the inward spiral of LPs.

A major source of error in stylus shape stats

2009-07-05T09:56:00.000-07:00

Summary

Previously we try to plot varius groove variables (width, depth, ratio of width/depth, etc), however, a detail in algorithm is never brought up: the way we determine the inner/outer groove top edge pair every step along the groove. See Detail.
This algorithmic decision is much responsible for the local noisy width as we shown before, which should have been smooth.
A question: Should we interpolate and resample inner/outer edge and bottom, so that a common time-line is shared between all three parties, before pairing up them for the width and depth info?

Detail

See the plot at the top of this post. Looking top down, the three lines of points are segments of groove outer edge, bottom, and inner edge. Inner edge looks smooth, while the other two look extremely jaggy. See below for the cause.
After matching up raw edge data in windows (defined in the last post), the raw edge data are on their own floating-point time-lines (azimuths) that are not aligned with each other. Therefore, to get width/depth data, we need to pair up inner/outer edge, and extract the 1D bottom from the bottom band in the groove valley.
The way we match up them: We use the inner edge as the common time-line; at each azimuth, we search in the outer edge for the closest azimuth and use that point as a pair; if this point has been used by previous point, this pair is taken as a redundant pair and is discarded; After inner/outer edges pairs are extracted, at each pair's azimuth, we search in the 2D bottom band for the closest points that are inline with the pair; then we select the deepest point as the 1D bottom. The result is what's plotted above.
The problem with this algorithm is that since inner/outer edges and bottom don't share the same time-line, the pairing with nearest counterpart in one another generates errors, which is further messed up by the redundancy-removal algorithm.
A possible solution: resample each of the three party at an audio rate, before calculating groove stats via pairing them.

Bug fix and stylus stats (quick heads up)

2009-07-02T06:03:00.001-07:00

Summary

Found a bug in groove unwrapping, and previous "jump" in bottom depth is now cleared. See Detail #1
Removed another bug in groove unwrapping caused by the intermediate data windowing. See Detail #2.
A new problem arose: The width data showing some local static value, i.e., changes in consecutive points are either zero or a step of size 0.1mm. I assume it's another bug and working on it.
I'll work on #3 for a day or so before showing the entire image results.

Detail

In the first alignment before CC analysis, we align image on the pixel level. During unwrapping, we need to refine the alignment for the extracted edges.
Previously due to RAM limit, we can't downsample the entire groove all in one shot. Instead, we need to group a number of FOVs during unwrapping and make them a "window" as a super-FOV level; then we resample within the window before finally stitching the windows together. By working on super-FOV level instead of resampling and fitting for each FOV, it's easier to see longer signal during each step, otherwise we would have to stitching FOVs during each step just to see the results. However, previously I chose window size by a fixed number of FOVs for all inner, outer edges, and bottom. This caused data loss when having to truncate the heads and tails of the FOVs, because there usually is a size gap between the inner/outer edges and the bottom. So finally I changed the entire windowing scheme to using time (e.g., 0.04sec per window) as the window size and the depth discontinuity in bottom is cleared; and we can safely backward trace data from unwrapped groove to original FOVs.

Plot z coords of groove inner, outer edges and groove bottom

2009-05-31T23:19:00.000-07:00

Summary

Above shows the z coordinates of the groove inner, outer edge, and bottom of 500 points corresponding to the widht, depth and ratio of width/depth last time.
It's clear that inner and outer edges are at different absolution height.
There are fluctuations in all three signals, where inner and outer edges were really meant to be falt.
There is a z-jump in the bottom, which may be due to seriously wrong stylus shape stas or the technical detail.
z-coords of bottom should be corectly collected.

Updated width, depth, width/depth stats of unwrapped groove

2009-05-25T18:59:00.001-07:00

Summary

Previously width, depth, and width/depth stats collected from individual FOVs showed wrong trend, i.e., both width and depth had abrupt changes, no clear sinewave-like undulation was shown.
Updated stats from unwrapped groove show better results, as the images above, width, depth, ratio of width/depth to 500 points, from top to bottom respectively.

Analysis

Compared to previous individual FOV result, the width result shows reasonably sine-wave-like envelope. Occasional outliers are probably due to debris from groove detaching/reattaching process.
The depth result appears much noisy than it is supposed to be, i.e., it should have been sinewave-like as well. This error may arise from wrong groove bottom position estimation.
As the result of problematic depth, the width/depth ratio appears far from a constant.

Plan

Experiment with bottom position estimation by selecting a consistent position from across groove cross-section.
Start working on 50X version of the signal to see if any improvement can be achieved.

Stylus shape stats (width/depth ratio)

2009-05-15T18:54:00.001-07:00

Summary

* Histogram of the ratio of groove width to groove depth is shown in figure above.
* The result showing that the width/depth ratio is extremely stable for this piece of data.

Detail

* The data used are 3223 FOVs of the stereo sinewave (about 10 sec).
* In the 10-bin histogram (Matlab default), the most dominant bin is the ratio 0.290, with a percentage of 99.99987%, among 5497858 instances (azimuthal increments).
* In the 20-bin histogram, the most dominant bin is 0.126, with a percentage of 99.9999%

A more probable cause of the DC-shift-like "modulation" on radius/depth

2009-04-27T18:16:00.000-07:00

Summary:

We discovered a strange modulation in both lateral and vertical direction and appears to be out of phase in both dimensions.
I suspected that the modulation could have been from RIAA EQ; this was soon defied because what EQ would only modulate amplitude, but what we see in the previously posted plots are essentially DC shifts, which could not have been simple amplitude or frequency modulation.
I suddenly realized that a more probably cause is the systematic surface warp (concave) caused by the screw fit in the center hole of the record.

Analysis

The "modulation" we saw in previous depth/radius is a DC-shift error, not a
See the illustration at the top, because the screw has to be tightly fit to the hole to keep the disc from shifting, the disc surface will concave to the center. Since the direction of concave is usually not perpendicular to the vertical or horizontal axis, both radius and depth values of the groove position will distort; when this distortion is not evenly distributed, they will also lead to the center estimation error, rendering the entire polar system questionable.
Even more unfortunately, all our previous data was extracted from the last few grooves; being the closest grooves to the center screw, the center of the concave, they should have suffered more from this systematic warp.
See the illustration, because the groove tracing in our experiment starts from 6 o'clock position, the periodicity that we have seen in the depth/radius distortion is probably caused by a specific concave pattern: The 12 O'clock concaved to the deepest level while the 6 o'clock concaved the least; the 3 and 9 o'clock were under a roughly symmetrical concave. As a result, we see the unwrapped groove depth value sequence drops from 6 o'clock till the 12 o'clock, and then rise again symmetically back to where it used to be.
This is a pretty interesting discovery that may explain the similar modulation that Haber has experienced but couldn't explain in their paper.

Solution

On one hand, this is a pretty bad distortion source in that it warps both the disc center position and the grooves; however, from the fact that the audio output still sounds like 1K sine, means that this distortion doesn't introduce much spectral pollution. The DC-shift didnt seem to be too bad.
I don't think there is a proper software solution to conteract the concaving. We should really come up with a better fixture that minimize such systematic surface warp.
It's pretty bad that all our newly scanned data was done under the same fixture, so there is bound to be the same problem. In the last data I'm trying to scan (the 10 sec music), I will try to extract something on the outer grooves, and at the same time try to minimize the concaving.

Question

How should we present this in ISMIR paper? I really don't think stereo decoding using depth and lateral under this situation makes much sense however we try.

2009-04-26T16:06:00.000-07:00

Summary

In the extracted (stitched) undulation sequence of the stereo sine wave, a low frequency modulation can be seen.
The modulation is not only in the lateral direction, but also present an "out-of-phase" counterpart in the depth sequences. See images below.

Analysis

It is a reasonable phenomenon that the radii appear modulated because of the incorrect center estimation.
However, it is weird that depth presents such an "out-of-phase" modulation.
Regarding the possible source of such modulation, it's hard to imagine the disc surface warp be one, because this modulation is so "clean" that any random warp couldn't have created such a smooth trend.
Another possible source is the wrong estimation of edge of groove; but since the bottom appear modulated the same way, this wouldn't have been the cause.
Compared between #3 and #4, surface warp may be the more likely error source, because warp keeps the groove depth a constant, so the depth difference between bottom and top should be consistent, like we see in the plots below.

Solution

For the depth problem, assuming a perfect flat top edge, we can find the centroid of the top edge depths, and translate every point to this centroid, and then adjust the bottom in sync.

Plots of sine wave undulations

1. Depth of the groove bottom

2. Depth of the groove outer edge

1. Depth of the groove inner edge
4. Radius of the groove bottom
5. Radius of the groove outer edge
6. Radius of the groove inner edge

Audio extraction from music signal

2009-03-29T19:13:00.000-07:00

Summary

I've been trying to extract audio from music signal scanned 1 year ago. And now the signal is extracted but with strange shape. The output sound was just clicks, which is either a bug or the scanned area was not as expected. The expected audio should be brass note of the ending of a classical track.
The music signal was expected to be nearly 10 sec long but is unfortunately cut short to about 2 sec (1.05 cycles) due to a few "missing" FOV on the outermost revolution.
The missed out FOVs are due to the mis-calculation of the grid based on the assumtion that grooves are nearly perfect circle. Such an assumtion yielded an scanning area that is smaller than it needs to be to cover all portions of the groove of the same outer revolution.
The extracted signal appears to be modulated by a low-frequency signal, in the same way as we saw on the previous test sine signal. This now can be reasonably concluded to be the result of the inaccurate estimation of the disc center. See detail for the analysis. See below the image

Detail

The low-frequency modulation is due to the fact that the estimated disc center is bound to be closer to one half-circle while farther away from the other, along a specific diameter (let's call it division diameter); this way, imagine that we have a complete silence signal, i.e., smooth spirals around the center; if we follow this signal starting from the division diameter the calculated radius of each tangential position in the polar system will be fluctuating periodically as the angular increment proceeds further away from the division diameter and then returns to the same angular position.
This is probably why Haber used the sinusoidal term, and derived disc-dependent parameters in their center correction algorithm. So it's probably the most straightforward solution to our problem too.

Plan

Find the way to get the correct center estimiation, using a silence segment of the signal as our test data.
Go on figuring out the stereo decoding.
The current musical signal is still not long enough. We may consider scan more.

Stuck at stereo problem

2009-02-10T21:01:00.001-08:00

Summary

Last time, the output was actually without the bottom information; I made a mistake in my code.
Therefore, what we heard last time was differentiated radius data from both side, no depth info in there.
Simple conjugation of width and depth data doesn't do the trick either.
According to the 45degree cutting scheme, I also tried to extract the sidewall movement along the 45 degree direction (norm of the sidewalls). They generated weird data plotted as below:

Left channel:

Left sidewall's 45-degree movement show's monotonous decrease in value.

Right channel:

Right sidewall's 45-degree movement show's monotonous increase in value.
In my algorithm that reached this result, sidewall movement was interpreted as follows

Looking at the groove cross-section, at any moment t, the sidewall is a line in the Cartesian coordinate system, where x-axis is represented by radius (i.e., r), while y-axis by depth (i.e., z)
Then the left or right sidewall movement becomes the displacement of such a line between consecutive moments, i.e., line-to-line distance, which can be deducted from the r-z coordinate system.
However, since most of the sidewall is missing, the line has to be imagined from two vertices, i.e., the top edge point and the bottom point at time t, then the sidewall displacement accuracy depends on our estimation of the groove edge and bottom positions at each moment.
The line-to-line distance between two consecutive moments, e.g., t1 and t2. was further simplified to the distance between bottom(t1) and line(t2), which is the result of the above.

What do we see in the above image results: There must have been some opposite trend in the movements of left and right sidewall that are captured in this model.
Left and right sidewall do have opposite positive direction in the interpreted signal from the movement. See this image:

http://en.wikipedia.org/wiki/File:Plattenschrift_en.svg
and the one below

Controversy in a counter-example of the movement versus signal sign relationship: Pure horizontal movement should generate in-phase signal in left and right channels. We know that if the stylus moves to the left, then the left and right sidewall move to the left together, but the resulting signal should be decreasing on the left and right channel together, because they both move to the negative direction, in other words, in phase.
Therefore, we saw some out of phase signal, if they could be called signal here.
What did we expect as the correct result: We should have seen a straight line as the left channel and a wave on the right.
What are the available explanations: A possible problem in here is that, we fit the edge and extracted the differentiated top edges and the bottom first, then if we try to further obtain the sidewall movement, we would get something that's not faithful to the original contour. But that still doesn't explain the monotonous and opposite trend in the left and right channel.
So I got stuck at this point.

groove unwrapping finished

2009-01-21T19:31:00.001-08:00

Summary
The groove unwrapping finished successfully, except that due to the previously reported alignment problem, it had to stop at the alignment gap at about the 1-sec position (one revolution).

Now I'm working on the bottom-thinning (2D-to-1D single-pixel-wide bottom groove)
I had a couple of algorithms tried on single-FOV case, theoretically the best way is to take into account tangential and radial continuity, with the generalized stylus shape (width-to-depth ratio stats along the grooves). This again, appears to be a typical dynamic programming problem, with the observed stylus shape distortion being the global cost and the local continuities the local states, but I'm gonna first try simple thresholding before implementing DP for this.

Image alignment requires a DP-based redesign

2008-12-31T14:20:00.001-08:00

Problem

During groove unwrapping, gap appears between some successive FOVs near the bottom rows in the FOV grid, such that groove continuity was interrupted. It's non trivial to fill the gap without messing up the whole grid.
This is clearly caused by our greedy alignment algorithm in the beginning, which does a 1-vs.-1 image alignment at a time: It introduces only one new image into the whole picture, and thus only consider images that already introduced into the whole picture during alignment, ignoring those that are yet to be brought up.
The quality of greedy algorithm depends on the severity of stage drift during grid batch measurement. It worked well on one of our datasets before, so that I didn't bother to test another algorithm, based on Depth-Down research principle.
What makes our measurement a particular problem to greedy algorithm is that because the label area is not included in the grid scan, the grid rows with label included are horizontally divided into left and right parts, both of which have to be individually aligned. Therefore, both side have to be aligned with the the sub-grids above and below the label. Notice that different from the label-divided left/right parts, the top and bottom FOV subgrids are continuously distributed. Now if we go on align the left/right rows in the top-down manner, the greedy algorithm tends to introduce accumulated error to the point that one side of the discontiuous rows become disconnected with the bottom row, though visually perfectly aligned with the other rows.

Solution

Now that it becomes clear that greedy algorithm caused accumulated row-alignment error. The solution, according to my stitching bibliography, is to use dynamic programming, which finds optimal path across all FOVs, and seek the best overall scheme.
DP is extremely time consuming. Notice that our microscope does a row-by-row scan during the grid batch measurment, and the greatest possibility when drift is introduced is when it tries to move from the right end of current row all the way to the left end of the next; we thus can assume that greedy method is good enough in dealing with horizontal FOVs in the grid, and only uses DP for the inter-row alignment.

Plan

This is top priority, without which later processes cannot continue.
I'm not familiar with DP implementation. Will need a day or two to study it.

Brief update

2008-12-30T19:13:00.001-08:00

A presentation of my current progress and the entire audio extraction workflow was given at the group meeting two weeks ago.

As a most important discovery, we talked about the stitching. It turned out that stitching has to be done in both image and audio domains. It actually contains 3 steps. The image domain alignment (pixel-based 2D alignment) gives us reliable coordinates for polar coordinate system construction; the "audio" stitching, which is performed on groove undulations after edge detection, during groove unwrapping will further refine the alignment result; however, due to the sheer amount of data, we cannot stitch them during the unwrapping before we downsample the data; so as the final step, once we downsampled data according to industry standard, the audio will be stitched together to generate the sound.

FOV-chain building (the second step of the stitching and first step of groove unwrapping) is nicely done. The next step is to actually unwrap the groove in a windowning fashion.

Before this, I experienced a few quirks in previous processes and fixed them, leaving me a fairly robust workflow before groove unwrapping.

Once the new semester starts, I'll distribute my processes to more machines to speed them up.

Edge-bottom tertiary problem.

2008-12-03T15:12:00.001-08:00

Summary

When extracting the tertiary of inner-edge, outer-edge, and bottom groove from the "continuous" edge array, we encountered local tangential noise as Stotzer reported in his dissertation. See Detail #1-4.
Bottom thinning problem. Given the 2D-nature of the captured groove bottom, we need to extract a one-pixel-wide bottom array. However, this proved not trivial.See Detail #5.

Detail

When grouping up an inner-edge point with an outer-edge point plus the bottom, to preserve as much data as possible, we use the inner edge as the reference signal I(a1), where a1 refers to an azimuth, and we iterate through the signal; each point is supposed to have a unique outer-edge point pair; however, the locally noisy edge signal often creates overlaps in the pair-ed outer-edge point O(a2), i.e., I(a0), I(a1), and I(a2) could share the same O(a2); this happens to bottom paired-up signal B(a3) as well.
In Stotzer's dissertation, he realized the problem, and somehow combined this process with resampling, that is to say, he would discard any problematic edge-tertiary when doing edge detection. More importantly, his edge detection is 1D, meaning by virtue of their hardware unwrapping process, they only look at radial direction and extract the edge at each azimuth. This is a resampling process in nature.
It seems to me that a smoothing before doing polynomial fitting would be inevitable because of the tertiary building error described above from local overlap caued by noisy data. This, however, requires testing against the resulting sound.
At this point, I would remove nothing, but before polyfit I'd like to try smoothing it first.
Result of bottom thinning according to two rules(deepest point of the middle point of the valley at the azimuth) both presented jaggy result. This is different from usual edge thinning problem in that here it requires bottom's compatibility with two noisy edge arrays, meaning we are seeking compatibility (parallel pattern) among three NOISY signals. They in theory should parallel to each other but without a bit of smoothing, they don't do exactly.

Recent progresses

2008-11-27T16:15:00.001-08:00

A series progresses are made over the last month and they will be summarized in series. Here is a brief.

Summary

A refined audio extracting workflow is complete and fully implemented. Now it is under debugging.
Theory: Previously our focus of study was only on the groove valley in a scanned groove image; by analyzing a scanned image in terms of a tertiary unit of visible components, i.e., groove valley, groove top (spacing), and groove bottom, from the very beginning of our workflow, we have made pre-processing (filtering), edge detection, and other processes more robust and consistent. See Detail #1 and 2.
Edge detection is refined with a robust algorithm of controllable time-efficiency according to deeper understanding of our unique problem (it is different from a generic edge detection). Tested and its effectiveness verified. See Detail #2.
Sting removal (the debris from incomplete groove-detaching) is implemented by utilizing the shape consistency of a cutting stylus. Currently under testing. See Detail #3.
Filtering for neighboring FOVs: All filtering stages for an FOV now try to apply any changes in the overlapping area with neighboring FOVs to the corresponding areas of those. This help solve some really tricky problems of attached-grooves. Without this additional treatment, some attached-groove in narrow overlap region may cause the neighboring-FOV to suffer and very hard to detect.
Groove tracing via FOV concatenation and phase unwrapping: this has to be done in a windowing manner. See Detail #4.
Stitching workflow is finalized; We found that it does require efforts in both image and audio domain to complete the stitching. Initial alignment and groove unwrapping are done in image domain, and final stitching is done in audio domain. See Detail #5.

Detail

Previouly we had a hard time filtering out unwanted noise and complicated groove entangling by looking only at groove-valley-based CC analysis. By making full use of the physical relationship of all three categories of objects as a tertiary unit, i.e., groove valley, top, and bottom, all kinds of noises can be effectively filtered out:
1. The most robust algorithm for removing blobs uses the heuristics that "a non-groove object is contained by a groove top and has no groove bottom in it."
2. The most robust algorithm for detaching attached groove uses the heuristics that "a groove valley contains only a single chain of bottoms (if broken somehow)". This heuristics turn out to be much more robust in detaching attached grooves than other specific physical measures, e.g., groove width.
Edge detection for extracting groove undulation turns out to be non trivial in our problem domain.
1. Why edge detection as opposed to direct angular sampling: we would like to postpone resampling until we extract full optically-acquired groove information.
2. Where is the edge: CC analysis gives us groove valleys; however, the edges of groove valley belong to the bad data region resulted from the optical device's inability to capture sloppy surface, and thus don't have obtainable depth values for stereo decoding. Therefore, the edge should be the inner and outer edge of two groove tops that wrap the groove valley of focus.
3. Edge detection is different from the general edge detection: in our case, the edge has specific semantics instead of the simple pixel-level object edge, e.g. groove edge has to be divided into an inner/outer pair. We have two choices: 1) do a generic pixel-level edge detection and try to classify the obtained edge set into the inner/outer edge subsets. 2) use semantics to somehow detect inner/outer edge respectively.
4. Difficulties in generic edge detection: We tried to use low-level edge detection; It then turned out that it's very hard to break the edge point set into inner/outer subsets. We tried to use simple thresholding by polar radius, however, it's not robust to use a single mean/median value to separate the edges of a groove in even the single FOV, especially when there are "stings" and groove damages; likewise, more complicated histogram-based thresholding is still not robust enough to tackle the diversity of the groove physical conditions. Generic edge detection is not going to solve our problem nice and clean.
5. Better solution lies in the tertiary-unit: we now know that the true edge lies in the groove top, the second element of the tertiary-unit. We thus perform the CC analysis to valley and top respectively, and figure out which two tops are the "wrappers" of the valley-of-interest. We then perform a pixel-level neighbor analysis on the valley, to find those edge pixels from either wrapper groove top. Because they are indexed during CC analysis, there is no need to classify them anymore.
6. Time optimization: Algorithm from #5, requires analyzing the entire groove; tests show that with Matlab implementation, it takes almost 1 minute to complete edge detection for all grooves in an FOV under current optical configuration, which means it takes 2 days to extract edges of 10-sec signal (3000 FOVs). Apparently this is unacceptable. We then turn to do it with angular windows, and in each window we only perform neighbor analysis on the upper and lower portion of the valley. By only analyzing 1/2 of the region, the time is reduced to about 25-second per FOV. A future C implementation can make it even more efficient.
Groove unwrapping and phase unwrapping: Groove has to be unwrapped and stitched. In the later fitting stage, monotonously increasing time stamps have to be present for the groove; however, polar coordinates converted from Matrix coordinates and disc center can only account for the range of [0, 2*pi]; therefore phase unwrapping has to be performed during groove unwrapping across FOVs.
1. In Stotzer's approach, they conducted groove unwrapping during the second-level microfilm-scanning by using a turntable simulation hardware system and looked at a single groove within the FOV of their camera setting in their acquired digital images. In other words, in their digital images, the groove is already phase unwrapped via the hardward scanner.
2. Phase unwrapping in our approach can only be called upon after we figure out the FOV sequence in CC-based groove unwrapping. Before that in individual FOVs, the azimuths remain in the [0, 2*pi] range.
Stitching: The huge amount of data makes it impossible to performing any fitting and audio extraction on the entire range of groove data before downsampling; therefore groove unwrapping and fitting/differentiation still have to be done in small batches of FOVs as opposed to be done on a fully stitched array; the final stitching could only happen after downsampling through polynomial fitting. The stitching workflow now includes:
1. Image alignment to provide accurate 2D information for tracing grooves: prior to CC analysis and any filterings, align FOVs by adjusting their positions in the disc coordinate system (implemented before).
2. Groove unwrapping to give the FOV sequence along the audio signal;
3. Locally stitching an array of grooves in sequence acquired from Step 2 for fitting and downsampling to best utilize memory.
4. After downsampling at an acceptable sampling-rate compromise between quality and size, e.g., 96kHz, stitch the groove sequence into an entire audio stream and perform stereo decoding.

Plan

The coding for the entire workflow is complete; we'll go on testing and debugging till we get the sound.
Now that the microscope is back on. We will select a few album to scan. Now the question is which. What are on my mind are a 10-sec classical, a 10-sec jazz, and 10-sec rock or pop.

Microscope maintenance

2008-11-17T13:14:00.001-08:00

Summary

Tom came and solved variuos hardware and software problems that happened lately.
Stage drift problem is still under investigation at Veeco and the engineer promised that the future fix regarding this issue will be applied even after our free maintenance has expired.
Important knowledge about Vision and the microscope was gained.

Detail

Software: after efforts of debugging under instructions from the Veeco engineer, we found that the stage initialization failure was a software problem on the part of Vision instead of a stage hardware failure. This was solved by reinstalling original Vision software and its latest updates.
Software: Using PSI Hi-magnification filter from both the intensity
window and Vision configuration would significantly improve the groove
bottom capture capability, though still imperfect.
Software: the time-saving "Auto-scan" feature is not recommended, because it usually generates noisy result, although it can stop VSI after obtaining certain amount of useful data.
Hardware: A misunderstanding is solved: Our 5X lens plus 2X magnification solution is essentially using 5X and a FOV enlarger, so the optical performance of our scheme won't be as good as a real 10X lens; this largely explained why Veeco showed as better groove bottom result with a low-mag lens that we can't reach (although they used a 20X).
Hardware: previously I dicovered that playing with tip-tilt can improve the bottom capture; this is however unreliable solution, because due to the tilt, the captured result may not refelect the bottom but one side of the lowest sidewall.
Hardware: the lens were re-calibrated so that tip-tilt does not cause visible fringe drift.
Hardware: calibration can be done with wrenches to the head.

Fixing remainder noise caused by coarse groove detaching process

2008-10-14T15:48:00.001-07:00

Summary

While I'm running my current workflow on sinewave data on my lab machine, I realized in theory that the negative effect of our previous coarse groove detaching processis underestimated. See image below for the sting-like noises and see Detail for the explanation.
To fix such stings, a promising way is to make use of two useful information: 1) the consistent stylus shape leads to consistent groove/width numeric ratio; 2) the gap caused by dust and dirts are usually very thin. This way the correct shape of groove can be estimated and regenerated, or at least the sting-like noise can be suppressed to an extent.

Detail

How could "the stings" mess up the workflow? Remember that we take 2D edges out of the the groove CC image, and then flatten it as 1D audio undulations; the stings, however,will be taken into account as part of the groove edge, and when flattened, it could wrongly lengthen the data and create error in the "synchronicity" of the inner/outer edge data pair. Given that there is overall 10% FOVs of attached groove images, this could cause serious problem in the output signal.
From #1, we know that, before extracted edge points be stitched together, the stings have to be eliminated.
Unlike the shape discrepancy in a regular object, in theory, the stylus shape consistency ensures that groove crosssection field-angle should remain approximately constant, that is, the ratio of width/depth of the groove should be nearly constant; therefore, we can first take statistics of such ratio out of good data as the reference and measure the offensive grooves in those FOVs that passed coarse detaching process against the reference, then fixing the shape of the top edges by applying the correct width/depth ratio.
Note that the depth of the corrected edge will be set to a constant value, i.e., the mean depth of the groove edges, assuming that top edges are usually flat.
An interest lesson learned here is that the audio extraction workflow here includes nonlinear subprocesses: 1) Sometimes the filtering process is hardly complete without a further production procedure, e.g., the edge detection the groove width/depth computing have to be performed locally before we completely know how to fix the stings. 2) Also, once one FOV is fixed, if the updated data lie in the overlap region with neighbored FOVs, further iteration in those FOVs has to be made to reflect the related updates in our current focus FOV.

Plan

Making this refined detaching work has become our top priority before any groove unwrapping process is made to our data.

Post-restoration workflow

2008-10-07T20:57:00.001-07:00

Summary: after the groove restoration processes, i.e. detaching attached grooves and reattaching the broken ones, there is a series of work needed towards obtaining the audio. So far the coding for Step 1-10 is complete, thorough test is the next step. See details for notable aspects involved in each step.

Raw top edges extraction
Raw bottom extraction: all valid points in the groove valley
FOV chain creation: the true stitching
Main-thread: Stitching top edges + phase unwrapping
Main-thread: Stitching bottom + phase unwrapping
Calibrating edge angular ranges of inner and outer edge, to make both edges equally long.
* top edge fixing (stings as debris from restoration)
Bottom thinning: 1D from 2D, according to inner edge angular distribution
Fixing invalid data along bottom by exploiting groove width/depth correlation, i.e., constant cross-section field angle.
Resampling groove edges and bottom at audio rate and polynomial fitting.
Audio generation.

Detail

The top edges that contain valid depth data are actually the edges of the inverted image of our previous CC analysis, where CCs are the groove "valleys" full of invalid data. So to obtain the top edges, the correct way is to redo CC analysis on the inverted image before performing edge detection. NOTE: So far, pixel-level 8-neighbor analysis is pretty slow, 40 seconds per FOV; there needs to be a faster edge detection method in the future, a possible way is to divide a groove CC into segments, then by assuming the continuity of short segments, we can safely disregard most "inner" points with medium radii and only analyze those points with more extreme radii.
We only extract valid points as the raw bottom points for now, which is sufficient for creating the FOV chain for bottom, i.e., the stitched sequence of FOVs that leads to a continuous bottom thread after merging them. Note: These points are saved in a linear array.
Merging edge data from individual FOVs requires that we provide an FOV sequence. Because the three main threads: inner, outer top edges, and bottom can cross FOVs from slightly differnt directions, FOV sequences for all three of them could be different; they thus should be computed separatly by analyzing the "exit point" and its owner CC in successive FOVs. NOTE: Where there are multiple successor FOVs, we use them to calibrate the overlap region in the edge-merging stage, but only use the single one FOV that carries more "new" data compared against the overlap region as our next node to be stitched in the FOV chain.
Stitching top edges are straightforward, because there is no invalid data in them. So we just collect them along the FOV chain. However, our stitching here is different from a regular image stitching because it involves the unwrapping of the grooves. That's to say, the resulting data should be angularly continuous. When creating the polar coordinates for individual FOVs for our previous processing, we never have enough clue to create an angular continuum for all revolutions of grooves; as a result, the angular range in the initial polar coordinates is equally [0, 2*pi] for all of them. They thus have to be phase-unwrapped.
Stitching bottom is similar to stitching top edges, except that we leave invalid data as they are here. Phase unwrapping is also performed here.
Top edges may be of different lengths due to the non-orthogonal orientation of grooves as they stretch through an FOV. These discrepancy needs to be eliminated for bottom thinning and later fitting. To achieve this goal, we only preserve the common angular range of both edges, and the bottom thinning will refer to only this range.
* This process is not yet implemented, because it won't be trivial to eliminate all strange "stings" on those former attached grooves. Until we know how badly such "stings" affect the audio output, I'd postpone this effort.
To obtain groove depth, we must have a single-pixel bottom to evaluate at each azimuth. Raw bottom from #2 (essentially from our measurement) leaves 2D bottom (a band of data); thus only one point will be picked based on a few rules. Currently , the rules are: the deepest point within a range from the center of the cross-section is taken as the bottom; if no such point is present, mark this an invalid point. NOTE: the angular position is determined by inner edge, because it has a larger denser audio data density.
To achieve clean stereo audio, depth data have to be all valid, thus the invalid bottom data need to be corrected. Based on the stylus cutting technique, we currently believe that 1) the deeper the stylus goes, the wider the groove becomes; that's to say, there is a simple relationship between the groove width and depth. 2) the distribution of radial positions of the bad data run bear some resemblance with that of the valid data run immediattely precede it. We thus calculate the off-center ratio of good data and apply the median value to its immediate successor. NOTE: in good measurement results, missing bottom is not serious, so the effort of data correction is only for really bad situations.
Resulting audio data will be polynomially fitted at typical hi-quality audio rate (e.g., 96000Hz) here.
Output audio from the fitted data.

Note:
From #6 on, everything works on the stitched data, the extremely long data chain, there therefore has to be a periodical data saving mechanism in case of unpredictable interruption to the computing.

Resampling: inevitable when extracting groove bottom

2008-09-28T11:22:00.001-07:00

Description

Previously, we avoid any unnecessary resampling in the whole workflow of audio extraction.
However,
if we would like to have stereo information, i.e., to have both groove
top and bottom ready, it turns out that we have to sample all three
threads (inner, outer top edges, and bottom).

Why resampling?

Knowing that top edges can be extracted via image edge detection,
we didn't need to angularly sample the top edges simply for getting the
top alone; instead, we tried to get every edge point to minimize
possible data lost with sampling.
However, since the groove bottom can't simply be extracted as 1D
sequence; rather, the bottom shows itself as a narrow band of pixels
(the thin blue line) in the microscope-acquired image.
As a result, this bottom band needs to be reduced to a single point at each angular position along the revolving groove.
This
reduction has to refer to the position of the corresponding angular top
edges, e.g., assume the "true" bottom point is at the the center of the
cross-section of the groove at the position, we need to refer to the
top edges at the same position, in other words, bottom is dependent on top edges; hence the top edges have to be sampled prior to the process of bottom extraction.

Resampling has to be done globally after chain up (stitching) the FOVs' top edges.

If this sampling is to remain relatively accurate, interpolation should be introduced as opposed to nearest-neighbor approach.
However, interpolation should not just be performed in individual FOVs, because:

the
entire thread of edge points should be interpolated to equally-spaced
coordinate with a common zero, which is difficult to be done in an
individual FOV that knows little about the other FOVs along the groove
ring.
such interpolation could also affect the process of buiding the FOV chain along the ring (the last step of stitching), because it would modify the edge geometry.

Phase
unwrapping is needed before resampling. Previously, when creating the
polar coordinate system for individual FOVs, each ring of groove is
assigned with azimuths within 360 degrees; therefore, when unwrapped, the azimuths (phase) should be unwrapped into continuously increasing values as well.
Taking
into account #1-3, we need to first extract the full edge data and
stitch them up into the continuous line and then resample them from the
beginning to the end.

Groove bottom extraction has to be multi-stage: chain-up bottom band first; single-point reduction and resampling later

As we explained in previous section, single-point reduction of groove bottom has to be done after resampling the top edges. Now we have to decide whether to postpone the entire bottom extraction till we have resampled edge or not.
It
is not a good choice to postpone the bottom extraction because it means
to trace back to individual FOVs after we have extracted the entire top
edges. Tracing back from the continuous signal to FOV is hard, because

Polar
coordinates in individual FOV is without phase-unwrapping, making it
difficult to hash the unwrapped grooves with the original wrapped
version.
Doing a back-tracing requires that the continuous
signal be segmented and associated with the original FOVs, which is too
much work to maintain the correlation.

A compromise would be to make bottom extraction a multi-stage process:

Extract all candidate bottom points (2D band) in an FOV as a 1D vector and chain up all FOV data.
Perform resampling and single-point reduction to this pseudo-vector according to the resampling grid of unwrapped continuous top edges.

Caution: Bottom
is not always available at any spot of an FOV as the top edges are. We
know that it's difficult to perfectly extract bottoms in all parts of a
disc; resulting from this inability, insome FOVs, if the overlap region does not contain any bottom information, we need to come up with at least one data to determine its succssor FOVs.
Note: this approach means that the groove bottom extraction and stitching should be performed as individual processes from the top edge extraction.

Work during summer vacation: restoration, edge detection, and FOV topology

2008-09-17T22:01:00.001-07:00

Summary

Program of detaching attached groove and reconnecting broken grooves are thoroughly tested and improved. See Detail #1.
Groove edge detection was improved. See Detail #2.
Algorithm of chain up grooves accross FOVs are under development, and currently the module of finding next FOV of an arbitrary CC of an arbitrary FOV is finished. See Detail #3 and #4.

Detail

Detaching
program was run on the dataset of about 9 seconds of sinewave (2400
images), in which about 200 images have attached groove and less than
20 images have broken grooves. The result was encouraging:
only one false alarm, i.e., a normal groove was recorgnized as attached
groove, and all target images are successfully solved. Reconnecting
broken grooves was successful on all target images and no false alarms.
Edge
detection in MItAC includes two steps: finding groove edges, and
distinguish the inner and outer edges. The first step was done with a
pixel-level 8-neighbor
algorithm and it works well. The second step was original ly one using
a histogram filtering algorithm that proved not robust enough and was
redesigned.

The original algorithm based on the
assumption that a decision boundary in the radii of edge points can
effectively separate inner and outer edges of a groove. However, this
assumption only holds for groove segments that much resemble arcs of a
perfect circle,
where radius-based analysis apply to the contour of edges directly via
the radii of polar coordinates; to groove with large undulations
however, the assumption is not applicable: e.g., parts of the outeredge
can be of similar radius as the inner edge (image examples to come).
The
new algorithm thus does not try to globally segment inner and outer
edge but gets down to pixel level. The rough idea was: For each edge
point P, find all points within the same CC along the same radius, if P is of the longest radius, then it is from the outer edge, and if it is the shortest, then it is from the inner edge.
However,
this idea suffers from the problem related to the rectangular
tesellation dillema. We realize that the required angular
sampling has its limited precision and points that are not
perfectly lined up along the same radius, that is, from neighboring
radii group can be mixed in, some of which may turn out to be of a
shorter or longer radius than P.
Thus, we modify our new algorithm to: For each edge
point P, find all points of shorter radii than P, denoted as S, and those of longer ones as L. If size(S) > size(L), then P is on the outer edge; otherwise P is on the inner edge.
This modified new algorithm works well.

We have developed single-FOV
based all kinds of algorithms for filtering and audio extraction. Now
the one last step is to connect thousands of FOVs to result in the
audible audio signal. To this end, there are a few challenges to face:

The groove directions differ across different FOVs, so the FOV topology regarding the complete audio signal is FOV-specific, and CC specific.
Further more, we are only interested in the inner, outer edge, and the groove bottom whthin a groove CC; therefore, we have to focus on the FOV topology for three of them,
which are not necessarily consolidated. That is to say, the topology is
line-specific, if we consider edges and groove bottoms as lines.
Because of the overlap scheme, multiple neighbors in the rectangular grid of FOVs can share the same segment of groove CC, thus the "next FOV" could be multiple.

The module for finding the next FOVs works ok after limited test; it works as follows

For each edge of each CC in the FOV of interest, denoted as F, take its last point, i.e., the one of max angle in the edge set, and see in all the CCs among F's 8-neighbors, which one contains this point in polar-coordinate sense.

Plan

Once
the module of finding the next FOVs passes test, start testing the edge
consolidating module, which generates the single edge that takes into
account the discrepancy in edge data amon the overlapping FOVs.
Bug fix: because previously, polar coordinates were derived on
the basis of single FOV, the azimuth unwrapping for polar coordinates
of different rings of grooves was not implemented. It has to be fixed
during FOV connection.
Groove bottom has segments where there
are no measured points due to the optical limination in microscope
acquisition. They have to be generated using geometrical relationships
in phonograph geometry; on the other hand, a single point among a lot
at any groove cross-section has to be picked as the true bottom in audio extraction.

[continue] Improved groove bottom capture ability

2008-07-12T11:59:00.001-07:00

Description

To fully catpure the groove bottom means to discard groove top.
The tip-tilt setting is groove-dependent, i.e., each groove demands a special tip-tilt in order to fully capture the groove bottom, e.g., if with Tip-tilt setting A, the bottom of Groove A of the sinewave track at 3 o'clock can be fully captured, the setting A can't guarantee to apply to the same spot on another disc.
In manual scan, we are able to find a sweet spot for an individual FOV where the quality of groove capture can be optimized. However, in an automated scan, it is fairly difficult to ensure that tip-tilt work for each single groove in each single FOV.

Plan

Smartly divide the grid to have only one tip-tilt setting for each sub-grid so that the overall bottom capture would be better than using a global tiptilt for the entire grid.

[Continue] Improved groove bottom capture ability

2008-07-10T09:00:00.001-07:00

Description

I accidentally discovered that the groove bottom can still be captured with 10X magnification (Michelson interferometer).
Basically the groove bottom and top welcome different tip-tilt settings. Using a tip-tilt in favor of capturing the bottom, we can get seriously better result, see image below:
See image previously acquired at the same spot with the tip-tilt in favor of capturing the top
The trick is in the tip-tilt. See Detail.
As another issue, I found that the 10X lens is now with some mechanical problem, when the tilt is being adjusted, it will move relative to the stage too; this causes us serious calibration trouble especially to my multi-stage scanning and needs to be fixed. I'm contacting Veeco engineers.

Detail

During the manual initial focusing, we have to use fringes as visual cue to adjust the focus and tilt, with the principle being "keep the number of fringes in the intensity view as few as possible"; this principle, however, requires that the number of fringes can be easily perceptible to human vision, which leaves little choice to us but to focus exclusively on the groove top because the bottom would be too thin for us to observe the number of fringes.
Then because the groove bottom is essentially the end of the sidewalls, the optimal tip-tilt that ensures the best-capture of the top would be at an angle of about 45 degrees or greater with the optimal tip-tilt to the sidewall, and hence at a similar angle with the bottom.
Therefore, to ensure a better capture the groove bottom, at any groove angular position, the turret tip-tilt should be fairly off the optimal tip-tilt of the groove top.
It would be difficult to quantify a suitable tip-tilt for different groove topology; empirically, I found that keep the fringes parallel to the groove lines usually lead to better result.

Done: retach broken grooves

2008-07-06T14:26:00.001-07:00

Description

Before tracing grooves across FOVs, other than fixing the attached grooves, one more thing to do is to fix the broken grooves so that groove CCs are all in place to be traced.
This is done using the similar algorithm in previous post about detaching attached CC, except that in this case we aim at connecting CCs instead of holes.
To detect broken CCs, we simply examine a CC to see if, in polar coordinate system, it touches the bounding box of the FOV within the same radius range relative to the disc center; if on of the two ends does not, then it is a broken groove CC.
This algorithm proved successful in fixing the 2 FOVs (in total 2400 FOVS) we found in the original data; the occurence of groove breaking is far less frequent than groove attaching in our data at hand.

Plan

Work on groove tracing, i.e., starting from an arbitrary groove in an arbitrary FOV (angular position in that revolution), build a linked FOV-CC list across the FOV grid to lead us through the same groove till its end, taking FOV overlap into account.
Work on audio stitching of the audio sequence obtained from the FOV linked list.

Done: detaching attached groove

2008-07-03T13:22:00.001-07:00

Description

The new algorithm for detaching attached grooves is complete and tested with 36 images of various forms of groove-attaching. The algorithm succeeded for all of them.
See detail for the workflow of the updated algorithm.

Detail

Detect attached grooves by applying a heuristic-based non-linear parametric classification function. The function uses the proportion of the area of the holes in the area of the host groove CC, and the width of the groove CC as heuristics.

Red bounding frame shows the attached groove CC (in blue); the yellow ones show the typical holes in the CC.

Align holes in grooves into chains in angular order; the true chains will be used as sector to separate attached grooves.

The holes in blue is the true sector chain of holes, while the ones in yellow bounding frame are noises.

Remove noises in each chain; noises are holes that angularly overlap with bigger holes in the same chain.

The
holes in blue bounding frames are noises that are useless in connecting the holes angularly in the chain because there are other holes angularly overlap with them.

Remove noise chain if the sum of angular spans of the holes in the chain is too short.

The chain in yellow bounding frame in Figure #2 above is a noise chain and will be removed.

Thickening holes in each chain and fill the porous structure by examining the thickness and its hollowness at each angular cross-section of a hole.

This is the result of thickening and pore-filling process; compare this with the same region in Step#3 before the process.

Connect consecutive holes in the same chain with sufficient connecting strength.

This is the result after reconnecting holes; the previously attached groove has been successfully detached.

Fill the new holes (the connected holes may contain noise that's not completely filled) and redo CC analysis to create new groove CC composition in the FOV.

Future work

A better algorithm for connecting holes so that the shape of the groove at the cut can be preserved and the "stings" as the side-product of a simple reconnection can be removed in place, because to remove the stings laterneeds a pattern recognition effort; in comparison, removing them when the hole structure is obvious could avoid the searching process.

Further scanning the broken sample with 50X lens

2008-06-26T15:29:00.001-07:00

Description

Ich pointed out two problems

Full color range is missing in one of the previous data view; that was due to saturation when using ramping intensity in order to get the bottom data, usually it shouldn't be that way, but I pushed it in this FOV because lots of parts of the bottom are missing.
Veeco used 20X, which is actually the combination of the 50X (the other lens) and a 0.55 magnification multiplier.

I then scanned a disc area with the 50x0.55 scheme where 10X lens (5X lens with 2X multiplier) couldn't get the bottom. See below.
It turns out that with the 50X lens can generally catch the bottom that 5X could not; it can even catch parts of the sidewalls. As we introduced before, 50X uses a Mirau interferometer which handles close-up object better than the Michelson interferometer does, which the 5X lens adopts.

Blue

With 10X

2D contour: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_4-1.png

The middle part where bottom is missing is my area of interest

Analysis: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_4-2.png

with 50x0.55X

Choice

Using Mirau-based 50X may give us better quality, but even with its lowest magnification, the 27.5X, it will take 2.75 times more time to finish.
As a side factor, the 50X lens requires closer focus, which only 2mm above the height of the screw. This really worries me to use it in practical batch scan.

Results on Veeco sample records

2008-06-26T13:28:00.001-07:00

Description

According our own measurement and visualization using the optimized measurement configuration introduced previously, we can achieve the similar quality result with Veeco engineer showed in their slides.
See following sections titled with "Blue", "Red" for results for both the disc pieces with the blue and red label, respectively.
I noticed that Veeco engineer used several tricks in their presentation:

1. They used grooves that are mostly silence, i.e., shallow and straight contour;
2. They scaled the image so that they look tall and steep.
3. In the slides, the second groove data they showed are actually a subregion of a FOV and thus visually scaled, it could not have been from the 50x according to my test because the result from a 50X lens would be even bigger than this;
4. All data are interpolated, from an interpolated image it's very hard to tell the broken part if there are actually good data, and in the analytical graph they only presented one cross-section, which is surely a good data spot.We also didn't realized that in Vision's analytical output, the z and x/y axis are not scaled with 1:1 ratio, rather, z:y~=1:5. This trick makes the groove valley looks deeper than it actually is.
See the last Detail section for a more analysis

Everything below was tested with various configurations to make sure they are the best I can get in terms of the bottom-capture capability.

Blue

Disc Area 1 (good)

2D contour: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_1-1.png
3D without interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_1-2.png
3D with interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_1-3.png
Analysis: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_1-6.png

The groove of interest has a half-field-angle of 43.63degrees.

This FOV is similar to the first one in Veeco slides.I got the similar result.

Disc Area 2 (not too good)

2D contour: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_2-1.png
3D without interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_2-2.png
3D with interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_2-2x.png
Analysis: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_2-6.png

The groove of interest has a vertical half-field-angle of 39.14degrees.

Disc Area 3 (bad)

2D contour: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_3-1.png
3D without interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_3-2.png
3D with interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_3-3.png
Analysis: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_3-5.png

The groove of interest has a vertical half-field-angle of 50.86degrees, at the missing bottom position.

Disc Area 3 sub-region (good)

3D contour: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_3-11.png
Analysis: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_blue_3-12.png
This image is visually scaled. The vertical half-field-angle is 46.80degrees

Red
Data Area 1 (good)
2D contour: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_red_1-1.png
3D without interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_red_1-2.png
3D with interpolation: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_red_1-3.png
Analysis: http://coltrane.music.mcgill.ca/mitac/data/62.bottom/broken_red_1-4.png
The groove of interest has a vertical half-field-angle of 46.87degrees
Detail
I noticed that the missing of bottom mostly happens when the groove width changes abruptly. Considering the stereo cutting, the lateral change of width relates to a vertical change of depth as well.
This way, in the tangential direction, there may appear to be a sudden decreasing of the field angle in the middle of the groove depth range, thus forming a steeper slope, or even a corner, at that point. Scanning may have may have a greater chance to miss the bottom on spots like this.
For a sinewave, such points appears most frequently at the slope between the Pi/2 and the -Pi/2 portion, i.e., the slope between the summit and the abyss. So it kinda makes sense in my previous results that these portions are the ones that got lost the most often.

Rethinking about missing bottom groove

2008-06-25T12:04:00.001-07:00

Description

even with ramp intensity, for certain disc we still cannot get the entire bottom groove, see picture below

Then we have other discs with which we can get the full content of the bottom, see picture below from a random music record we have.

Notice that when turret is flat relative to
the disc surface, the missing parts are almost always the part between
the highest portion (peak) and the lowest portion (valley) of the sine
wave, i.e., the part with relatively steeper slope. Also notice that the field angle of the sidewall is perpendicular to the "sidewall" of the part of sine wave, but they pose the exact same problem to the microscope. Thus they are
missing just like the sidewalls are because they have too great field
angles for the optical system to capture the detail. Tilting the turret
according to such situation may create better results but that's
impossible without the TCP/IP control.
Solution
For current research stage, always use a better disc for the scan. Test the disc to make sure the signal-of-interest has obtainable bottom and then start large-scale scanning.

Improved groove bottom capture ability

2008-06-25T09:31:00.001-07:00

Description
Previously for certain discs, large part of groove bottom tends to get lost during scanning even with enough depth.
Now I found that it was due to the fact that to ensure the same capture quality, the groove bottom requires higher intensity that exceeds the saturation limit of the groove top, i.e., previously when we ensured that the scan intensity doesn't saturate for the groove top, we virtually lowered the chance to get the bottom with the same quality.
Previous result with fixed intensity

The best solution I found to improving this is to use the Vision's "ramp intensity" function, which uses an increased intensity from a specified (hard-coded) range. This way, we can set the intensity to be higher than the saturation threshold to the groove top when scanning the bottom, so that more data could be captured.
Without ramp intensity, but using a higher intensity
Note that there is another option called "dual scan", which can perform two measurements at different depth range with independent intensity, and skip depth range in-between. This, however, appears to provide little improvement over ramp intensity method, and have the potential risk to miss the bottom range. See picture result
Tilt does appear to affect the bottom capture ability; an ill-tilted scan did yielded results that are different in the bottom shape from a properly tilted scan (see all above pictures). See picture of the ill-tilted result below. Note that in the missing part of bottom from both approaches are different. This may means to have a full capture bottom of certain discs, we need some kind of adaptive tilting during the scanning. I need to consult Veeco engineer about this. According to their previous comments, we need the TCP/IP option to do this.

Improved groove bottom capture ability

2008-06-25T09:24:00.001-07:00

Description
Previously for certain discs, large part of groove bottom tends to get lost during scanning even with enough depth.
Now I found that it was due to the fact that to ensure the same capture quality, the groove bottom requires higher intensity that exceeds the saturation limit of the groove top, i.e., previously when we ensured that the scan intensity doesn't saturate for the groove top, we virtually lowered the chance to get the bottom with the same quality.
Previous result with fixed intensity
The best solution I found to improving this is to use the Vision's "ramp intensity" function, which uses an increased intensity from a specified (hard-coded) range. This way, we can set the intensity to be higher than the saturation threshold to the groove top when scanning the bottom, so that more data could be captured.
Without ramp intensity, but using a higher intensity
Note that there is another option called "dual scan", which can perform two measurements at different depth range with independent intensity, and skip depth range in-between. This, however, appears to provide little improvement over ramp intensity method, and have the potential risk to miss the bottom range. See picture result
Tilt does appear to affect the bottom capture ability; an ill-tilted scan did yielded results that are different in the bottom shape from a properly tilted scan (see all above pictures). See picture of the ill-tilted result below. Note that in the missing part of bottom from both approaches are different. This may means to have a full capture bottom of certain discs, we need some kind of adaptive tilting during the scanning. I need to consult Veeco engineer about this. According to their previous comments, we need the TCP/IP option to do this.

scanning; detaching attached groove

2008-06-23T11:14:00.001-07:00

See WORD report here:
http://132.206.14.194/~kakyo/0.report/30.detach/080623.doc

iterative scanning; detaching attached grooves

2008-06-17T10:01:00.001-07:00

Description
The iterative scanning, a sampling based coarse-to-fine approach, went pretty smoothly except for a detail: because each new iteration deals with the failed measurements from one previous iteration, they form a tree structure as their relationships and traversing the tree under either depth-first or breadth-first is inevitable. It is desire to build such a history tree to give a convenient hint to human operator which branch to take after a certain iteration. It's under development. See Detail #1, #2
Detaching the attached grooves was not robust enough to handle even our data at hand. So it has been under redesign. See Detail #3, #4
Detail
Each iteration has its single parent iteration and multiple child iterations, each corresponding to one of the Type 1, 2, 3, 4, i.e., perfect, missing-top, missing-bottom, or missing-both; whenever an iteration is over, it branches to one or more of Type 1, 2, 3, 4. If all FOVs in the iteration result are Type 1, then it marks the end of current iteration, i.e., it becomes a leaf node of the history, and it notifies its parent node of this; the parent iteration then checks if all children iterations are done, if so, it marks itself done. We use auto-generation of folder structure to maintain the tree because accessing folders and files are more convenient at this point.
At this point, no automatic instruction about which branch to take next is given, because the operation made at each iteration node is completely manual, and the human operator should have freedom in selecting which branch as the next iteration because we assume they are independent to each other at the moment (not sharing groove top height). In short, we only indicate which ones are finished and then human operator can pick from those that are not.
Previously we use groove "width" as the only hint as to discover attached grooves, this turns out to be ambiguous when thousands of grooves show quite big a variety of possible width values. It is also not enough to define the attached grooves based on "holes" in it, i.e., the heterogeneous blobs inside a groove CC, because there tend to be lots of noises. We then combined multiple heuristics into a parametric classification function, which incorporated width, number of blobs, and their areas as the parameters; based on the output of the function, the grooves are classified. In here, widths are measured against stats from surrounding FOVs to make it adaptive to the local situation and thus robust.
Sometimes one attached groove can contain multiple grooves, we need to figure out how many and how to find the sector holes and merge them properly as sectors. Then we need to rule out aligned holes that are not sector holes, and noises that could cause a wrong trajectory of merging. This is under development.

Fixture

2008-06-11T15:51:00.001-07:00

Description
Due to the inevitable drift of disc during a collision that happened in stage initialization, a solid fixture that can ensure the stillness of disc during the stage movement is needed.
It has been proved that single screw fixture that goes through only the center hole of a disc does not prevent the drift from happening.
The casual platter that we used before introduced larger drift than without it, probably due to its hollow structure along the vertical dimension, leaving a large portion of the screw that goes though it in the air with nothing to hold on to.
Because the disc is larger than the stage, the part of disc that goes over the stage front edge is pulled down by gravity, causing a non-natural warping (bending), so that the part of disc always require a deep scan depth or a very low focus position. According to my empirical test, the warping caused the top edges to be 0.2mm lower than when they sit on the solid part of the stage in the natural way.
We planned a few things for the design of the fixture. See Detail.
Detail
The fixture should be created with professional manufacturer, either from mechanics department at McGill or other hardware factories.
The fixture should be solid (as opposed to hollow) and heavy, and have multiple screws going through it and onto the stage to ensure its own stillness
The disc and fixture should interface well so that the loading and unloading of disc is convenient enough, in the mean time, the disc should not drift after it is loaded.
The fixture should be big enough to hold the entire disc to avoid the gravitational warping.
The fixture and the stage together should guarantee a flat surface that introduces no warping to the disc.
The screws or any other widgets should have a head thin enough so leave sufficient margin between the lowest possible turret position and the heads of the screws, to avoid crashing.
As a remotely related factor, the exposed cable in the rear part of the microscope may be hit by the stage and needs to be fixed.
Progress and Plan
The stage flatness stats have been collected and sent to Darryl.
The required vertical margin to be reserved for designing the screws is also sent to Darryl. (3.7mm)
I've sent request for stage specification and waiting for the result.
We need someone good at CAD to draw the design for us, probably Antoine from CAML or someone that Darryl knows.
The collision should be mentioned again to the Veeco engineers and we may need a field engineer to come and see if the intensity of the collision can be reduced.
Go on with the multi-stage scan for our sine-wave signal before the fixture is ready.

Multi-stage scanning implemented and tested

2008-06-10T12:37:00.000-07:00

Description

The proposed multi-stage scanning with configurations optimized for minimum time consumption is implemented and tested. With faster rough scan and image analysis, the multi-stage scanning first takes samples from the the entire scan area, then estimate a finite number of scanning configurations (namely the groove top edge height) that are time-efficient for several subdivisions of the entire area, and finally applies such configurations to the subregions that the samples represent in a real scan. This method proves to be very effective and take much shorter time to finish for at least the test record at hand. See Detail for more.

Currently the process is semi-automatic, i.e., each re-measurement (iteration) has to be operated by hand. With the Matlab toolbox, the process of configuration update and re-measurement hopefully can be fully automated.

Detail

The sampling was very successful in estimating the entire depth distribution, that's to say, each of the resulting batch scans was a complete success in capturing the top edges and bottoms without human intervention, by using the same batch-specific scanning configuration.

Time cost comparison:

The test was on a quarter of a single groove revolution, under 10X magnification, which comprizes 704 FOVs; the fixed scan-depth is 350um, 1X vertical scan speed is 5um/sec.

In the sample-scan phase of the multistage method, a sample set of 178 FOVs was used (a quarter of the total FOVs); the result consists of 8 batches of FOVs, meaning that 8 manual measurement is needed on these batches in the fine scanning; and during the estimation, 8 iteration was needed, but all performed at 11X vertical scan speed, with fixed scan-depth of 100um.

Single-stage measurement (1X scan speed): time = n_frames * (Depth /vertical_scan_speed) = 704 * 350 / 5 /3600 = 13.60 (hours).

Multi-stage measurement: time = sigma(time_for_sampling_iteration) + sigma(time_per_batch_in_real_scan) = 514*100/(11*5)/3600 + 704*100/5/3600 = 4.16 (hours)

The multi-stage measurement takes only 1/3 time of the single-stage method, which matches our previous theory.

Tree history: it is worth mentioning that during the sampling and iterative coarse measurement, sometimes one of the failure groups (missing top, bottom or both) can generate another type of failure after a configuration updates; under such circumstances, making it necessary to branch out the configurations to deal with the new difference in failure types; we currently use a “depth first” approach continuously untill all failure branches are solved. This is best implemented with a history tree that carries all branching information, including error types, grid sub-division updates, and iteration index. But it appears too complicated to handle at this point when we only have less than 10 iterations in total. So I currently used a very simple automatic directory renaming (marking) technique to minimize the confusion of iterations for the human operator.

Vision TCP/IP and Matlab optinal packages

2008-05-29T12:47:00.001-07:00

Description
Vision has optional packages that allows external Matlab routines to control the instrument's behavior and build measurement-analysis-display workflow between Vision and Matlab.
Communication between Vision and Matlab can be built through a TCP/IP protocol, in which stage position, turret z-position, tilt can all be controled.
However, a few issues concerning the unattended batch scanning are not clarified in the document:
Whether or not the batch scanning is interruptable and resumable when Matlab analysis and control take over is unknown; if we need to analyze the result and determine the new turret position (focus), we need to suspend the batch scanning and then deliver the new parameters to the on-hold Vision process, and then let Vision resume the grid scheme without shutting down the ongoing batch.
Whether or not the custom parameters in the Matlab package communication can be updated without restarting Vision.
Could the parameters passed on to Vision be anything, e.g., unrelated to any Vision processes?

Ich meeting

2008-05-27T12:43:00.000-07:00

Graph should provide intuitive information that needs little verbal/text explanation, e.g., scale of the data should immediately convey the order of magnitude.
Test with various discs, starting with small regions, and keep all the records.

Adaptive batch scan implementation (1)

2008-05-27T11:50:00.001-07:00

Please refer to the document:
http://132.206.14.194/~kakyo/54.batch_scan/scan_grid_imp.doc

Optimization for grid-based batch scan

2008-05-20T00:28:00.001-07:00

Please see write-up here
http://kakyolab.xicp.net/0.report/29.batch/Towards%20the%20automated%20batch%20scan.doc

Fitting the raw edge

2008-05-13T11:49:00.001-07:00
Description
Spline and polynomial fits were investigated; it turned out that spline fit is essentially piece-wise polynomial fit with bounded error by setting up knots/breaks and order.
Previously there was a misunderstanding of mine that thinks the textbooks were trying to dismiss polynomial fitting. It turns out that they only dismiss global polynomial fitting, compared to spline fitting in the piece-wise polynomial sense. Therefore, piecewise polynomial fitting that Haber used is essentially valid.
I made several tests and comparisons between spline and polynomial fitting using Matlab. See report:http://kakyolab.xicp.net/0.report/27.fitting/0_screenshots_1.htm
See Detail
Detail
For both polyfit and spline fit, two different approaches are used:
For each point along the resampled edge angular position sequence, make each point the center and take a window around it, fit the real edge points that fall into the window to the resampled points, in a point-by-point fashion, shown in Row 2-5.
Divide the resampled edge angular position sequence into windows (with overlap) and fit the whole group of resampled points within each window to the real edge points in that window, shown in Row 6-9
It turned out that the fitted result from spline is very unlike sinewave, but pretty similar to the raw edge, meaning that spline actually has a better simulation and weak smoothing effect; polynomial, in comparison, has a better smoothing and gives us sine shape, but not necessarily preserve the original waveshape.
I'm still not sure which one should be used.

Current solution to Saturation

2008-05-13T11:44:00.000-07:00
Description
The saturation under the condition of long scan depth is temporarily solved by combining two measures
Increasing modulation threshold (rule out more invalid points).
Dividing the entire scanning surface into smaller areas, scan them one by one and adjust the measurement parameters individually.
The reason why threshold matters to the saturation is not understood yet.
The scan may take another 2-3 days to finish (taking into account any possible re-scanning of bad data)

Grid Batch Measurement Pitfall

2008-05-09T12:41:00.001-07:00

Grid Batch Measurement Pitfall
Description
New measurment of test record encountered a difficulty regarding the global scan depth settings.
Remember we had to apply a relatively large global depth to accommodate a wide range of depth gap due to the disc surface warp.
However,
it is discovered that such a setting causes scan saturation for quite a
lot of FOVs, i.e., acquired depth data were distorted. The exact reason
is not fully understood yet, although a few evidence was obtained
through repeated scanning with different parameters, such as scan depth
and intensity:
When this depth is large (e.g., 300um) and the
turret tilt is not optimized for the FOVs, in which the groove depth
range is located around the deepest portion of our scan depth range,
the resulting depth image tend to get saturated.
Given a FOV
that's naturally tilted relative to the turret. Let Scan #1 be a
reference scan (normal result) with its depth range adapted to the
target FOV's without tilt correction, Scan #2 a scan with long depth
range regarding the target groove without tilt correction, and Scan #3
with same depth range but with tilt correction; all three scans were
performed on the same FOV. A quick test reveals that the distortion of
depth data of #2 could be so large that the depth level of measured
groove top edges of #2 could be as low as that of the groove bottom of
#1. This is an obvious distortion. However, #3 generates the similar
result with #1.
By chaning the intensity to a lower value but without tilt correction didn't remove the saturation.
Scan #1: http://kakyolab.xicp.net/0.report/26.saturation/saturation_1.tif
Scan #2: http://kakyolab.xicp.net/0.report/26.saturation/saturation_2.tif
Scan #3: http://kakyolab.xicp.net/0.report/26.saturation/saturation_3.tif
Plan
Because
tilt setting is static during batch measurement and it is empirically
safe to assume depth consistency between surface areas that are close
to each other, the ways to avoid saturation would probably one of the
two approaches
Finely sub-divide the target region into smaller ones, and perform individual grid measurements on them:
Pros: this is the easiest way in terms of development
Cons: the surface situation is unpredictable; therefore the sub-division can hardly be designed systematically.
Dynamically
monitoring the scanning intensity window, do a fancy image recognition
to warn the scanning process about the absence of interference patterns
(moving stripes), then automate the GUI program of Vision to restart
the scanning.
Pros: the ideal way for mass production.
Cons: requires significant development effort, invoving image recognition and window process management.
For now, I would go with the subdivision for the current data.

scanning long sine wave: vos grid calculation fixed

2008-05-06T10:55:00.001-07:00

Description
Last week I was about to start scanning a long sine wave, using Vision's grid stitching function. My previous script to calculate the grid ended up giving me a weird starting stage position: the Stage always went to the rightmost or rear-most point at the beginning and never seemed to come back. After a while of debugging, I realized
This should be a bug of Visions grid function with a very large grid: by default the grid reference cell is the the grid top-left corner FOV; when setting up this corner as a reference cell, if this cell is not included (enabled) during the scanning, the stage will assume that the grid starts from wherever the stage was at the start of the scan. The solution is to always include and scan the grid top-left corner FOV in the scanning grid as the first FOV, even when it is meaningless to scan the corner FOV.
About the selection of the experimental disc, remember in the previous discussion with Ich on the same topic, I insisted using another older disc because it gave me better groove bottom measurements across wide disc surfaces areas (still loses data uner certain circumstances); however, after seeing the jaggy edge data, I realized that currently we don't care about the depth as much, and a newer disc may give us a better edge data for the lateral extraction.
Therefore I selected one newly purchased system disc by Ich.
The new problem of the disc is that the surface is quite warped, so that across the long stereo (right channel only) sine signal (1.8 second ), the depth variation could be as large as 300 microns, which is pretty appalling if we would like to apply a global depth to the whole scanning, although the build-in depth adaptation function may help, but what it does is just linearly raise or lower the turret, which may be a cause of lens' crash. So to scan the whole area of data, a global/systematic depth variation might be incomplete.
It's necessary to divide the disc surface into smaller areas to minimize the internal warp of that area, which may cause the overly large depth range.
The scanning has yet to start before we make sure that the signal and setup is ok.

Bibliography on Numerical Differentiation

2008-05-06T06:14:00.000-07:00

Description

Previously, it was confirmed that raw groove edge of the scanned sine wave is not as smooth as an ideal audio sine wave, after testing with interpolation at various sampling rates; therefore, certain smoothing should be performed somewhere in the workflow prior to the audio output.

Whether to perform smoothing before or after the differentiation is a question.

A few literature on numerical differentiation (ND) are visited.

See detail.

Detail

From what I read, common ND all use a function to fit the data first, and then obtain the ND to that function.

Smooth can be integrated with the UFO thing.

Bibliography

Engeln-Müllges, G, and F. Uhlig. 1996. Numerical Algorithms with C. Berlin: Springer-Verlag.

Indicated that among three common ND methods (interpolating polynomial, spline, Richardson extrapolation), the differentiation of an interpolating polynomial is least recommended. Note that Haber adopted polinomial interpolation.

The rating from the higher to the lower methods in terms of accuracy is Richardson extrapolation, spline, and polynomial.

Practical recipes of the first three methos are given.

Numerical quadrature leads to better result than ND does, due to roughening effect of differentiation.

Cheney, W., and D. Kincaid. 1999. Numerical Mathematics and Computing, 4^th ed. Brooks/Cole: Pacific Grove.

Talked about differentiation i the context of interpolation.

Indicate that the data for interpolation and differentiation usually contain noise.

Indiate that polynomial may overfit and create large variance. Spline is preferred over polynomial.

Gautschi, W. 1997. Numerical Analysis: An Introduction. Birkhäuser: Boston.

Starting from general formula of differention of unequally spaced points, explained that symmetical difference quotient is one order more accurate than the one-sided one is.

Explained that in practice, purturbed data usually causes increasing error, especially as the h parameter gets smaller, i.e., fewer point differentiation. This is called truncation error, i.e., the finite approximation throws out the error term in the Taylor formulae.

Maron, M. 1987. Numerical Analysis:A Practical Approach, 2^nd ed. New York: Macmillan.

Discussed approximation error in terms of truncation error (polynomial interpolation) and roundoff error, inversely proportional to the step-size h in 1^st-order derivatives, i.e., large h leads to large truncation error, but too small an h would cause roundoff error.

Discussed ND based on equispaced and unevenly spaced samples. Polynomial and Robinson extrapolation are efficient in the equispaced case; for unevenly cases, quadrature like Gauss quadrature and adaptive auadrature is preferred.

Sharma, J. 2004. Numerical Methods for Engineers and Scientists. Pangbourne: Alpha Science International.

Pointed out that ND is essentially fitting the data to a function and then obtaining the approximate analytical differentiation of that function.

Gave definition for quadrature.

Nakamura, S. 1991. Applied Numerical Methods with Software. Englewood Cliffs: Prentice-Hall.

Talked about forward, backward, and central difference approximation. Central ND is always more accurate than the other two, in the sense of Newton interpolation.

Talked about 3 approaches to deriving difference approximatios: Taylor expansion, difference operators, and differentiation of interpolating polynomials; their advantage and disadvantage are explained.

Rice J. 1993. Numerical Methods Software and Analysis, 2^nd ed. Harcour Brace, and Jovanovich: Acdemic Press

simultaneously smooth and estimate derivative in Chi1.

Quadrature is lagacy term of approximate interpotion.

Raw edge resampled at various sampling rates

2008-04-24T19:55:00.001-07:00

Description

The edge smoothing is dismissed because we would like to see how optical approach can have different information extracted as opposed to turntables, which skip information during stylus reading.

Results are at: http://kakyolab.xicp.net/0.report/25.interp_edge_raw/0_screenshots_1.htm

each column represents one resampled edge at an angular sampling rate derived from an audio sampling rate.

Differentiation updated

2008-04-23T14:53:00.001-07:00

Description

Previously two errors in plotted analytical results of the differentiation of the sine-wave groove edge were found. Previous result: http://kakyolab.xicp.net/0.report/23.interp_diff_edge/0_screenshots_1.htm

The horizontal distribution of the points are uneven

Under 3-point differentiator (skip one point) The radius variation (vertical axis) between close angular positions is too great, so that the graph looks nothing like a sine-wave but noise

These two problems have been solved. Result is at:http://kakyolab.xicp.net/0.report/24.interp_diff_edge/0_screenshots_1.htm, the first row shows from the raw input edge to the differentiated result; the 2nd row shows the results of differentiation at various point-settings.

The source of error were not from the data but from my plotting program, it wrongly took the "arc" (radius times angle) as its X axis, so that the interval of the data became irregular. By replacing the X-axis with angles, the horizontal data spacing are showed to be even.

By using higher number of points for the differentiator, the differentiated edge data appear smoother and smoother and much resemble a sine-wave shape.

Plan

Do some reading on numerical differentiation and prepare a bibliography, to figure out how to design a proper differentiator to achieve the desired sound according to the reference data.

Edge extraction and interpolation

2008-04-22T11:53:00.001-07:00

Description

We decided to use a specified audio rate to resample the original data, i.e, 96kHz from last meeting.

The experiment was performed on an FOV's one CC's one edge that contains a sinewave (1kHz).

The result is at: http://kakyolab.xicp.net/0.report/23.interp_diff_edge/0_screenshots_1.htm

The procedure

Low level groove edge detection by examining the neighbors (not the image processing routines, but by rules in our context).

Smooth the data with a moving window.

Interpolate the data at angular positions according to the specified audio sampling rate.

Numerically differentiate the data, by skipping only one point.

However, the result is noisy in display. With polynomial fitting, things would get much better.

By skipping more points in differentiation, it may improve, but I haven't tested it yet.

Bibliography: sampling and resampling

2008-04-12T09:35:00.001-07:00

Awcock, G, and R. Thomas. 1996. Applied image processing. New York: McGraw-Hill.

Talked about pixel array tessellation, including orthogonal and hexagonal schemes and their pros and cons in image representation.

Talked about non-uniform 2D sampling, e.g., log-scale

Ablameyko, S, and T. Pridmore. 2000. Machine Interpretation of Line Drawing Images. London: Springer-Verlag.

Discussed raster-based and vector image representation.

Goshtasby, A. 2005. 2D and 3D Image Registration. Hoboken: John Wiley & Sons.

Discussed image resampling with a very organized summary.

Baxes, G. 1984. Digital Image Processing: A Practical Primer. Englewood Cliffs: Prentice-hall.

Introduced resolution, factors that affect spatial resolution, and aliasing. Very plain and easy.

Jain, A. 1989. Fundamentals of digital image processing. Englewood Cliffs: Prentice-hall.

Discussed 2D sampling therem in the sense of sampling random field to minimize the mean square error.

Pratt, W. 2001. Digital Image Processing: PIKS Inside, 3rd ed. Hoboken: John Wiley & Sons.

Discussed sampling image as deterministic field and random field.

Jahne, B. 1997. Digital Image Processing: Concepts, Algorithms, and Scientific Applications, 4th ed. Berlin: Springer-Verlag.

Thoroughly covered 2D and 3D image processing from perspectives of representation, formation, processing, feature, and analysis.

Talked about sampling and interpolation, including interpolation in frequency domain.

Gonzales, R. 2002. Digital image processing, 2nd ed. Upper Saddle River: Prentice-hall.

Classical textbook, but only included minor info on sampling, and no disccusion on resampling and interpolation.

Talked about pixel adjacency and distance measure.

Adaptive maximum angular sampling rate

2008-03-31T14:05:00.001-07:00

Description

The raw groove edge points contain a lot of local disturbance captured with the high scanning resolution, which is not necessarily useful to the audio output. They need to be properly smoothed and then evenly sampled without perceptable distortion to the audio content.

For each FOV, the angular velocity (related to RPM) is constant, thereofore the linear velocity, i.e., the spatial distance that the stylus covers within a unit duration, is determined by the integration of the radii of the points along the stylus movement over the angle span of the unit duration.

Because raw edge points are not necessarily angularly spaced at a regular interval, they need to be interpolated so that Then the number of edge points that we skip during the angular sampling is determined by the angle span of the CC bounded by the FOV, and the number of points we want to preserve.

The angular sampling rate (ASR, a.k.a, angle per sample) is determined as follows:

Let the angle span of the CC #i in the FOV be angle_span(i); Let the number of points that we use in the sampled data be n_point;

ASR(i) = angle_span(i) / n_point.

Angle span of the CC is derived from calculating the angles of the boundary points of the CC edge: if we denote the angle of the entry point as A(a), and the exit point A(b), then angle_span = A(b) - A(a).

The angles are calculated from polar coordinates relative to the disc center.

As of now, n_point = the number of the raw edge points.

With the ASR obtained, the edge data from the previous smoothing step is interpolated at the evenly spaced sample positions. See Column #3 (interpolation):http://kakyolab.xicp.net/0.report/22.interp_diff_edge/0_screenshots_1.htm

Interpolation, sampling, and differentiation

2008-03-26T13:32:00.001-07:00

Description

On top of the smoothing, new interpolation and sampling that ensure highest possible sampling resolution are implemented, see Detail #2.

Polynomial fitting after interpolation is removed, a numerical differentiation with every other point is used, however, it generates chaotic results, indicating that with highest resolution, the local disturbance is quite large, although the dynamic range is narrow (less than 2 pixels). At this point, no artificial sampling rate is going to be used.

Detail

The result: http://kakyolab.xicp.net/0.report/22.interp_diff_edge/0_screenshots_1.htm

The sampling rate is now determined by the original pixel resolution so that the evenly spaced sample points after interpolation are no fewer than the original edge points.

Interpolation, Polynomial fitting, differentiation

2008-03-25T02:55:00.001-07:00

Description

A bug in the previous coordinate derivation (at the parser level) was found and corrected. This bug, however, didn't prove to be the source of the previous error. See Detail #1.

Based on the previous smoothing result, linear interpolation was used based on a specified audio sampling rate, to obtain edge contour at the even sampling positions. See Detail #2.

Analytical polynomial fitting and differentiation were used. Differentiation result shows pretty nice sinewave.

It seems that the previous jaggy results were from the combination of visual illusion of the aspect-ratio distortion and the lack of smoothing and interpolation.

Detail

In OPD files, the FOV stage position is saved in mm. In the previous OPD file parser, when the stage position, i.e., the FOV position in the world coordinate, was extracted and converted into pixel, the floating point portion was truncated, which may have caused coordinate errors. After the correction, now it is preserved. According to test, this correction did not improve the visually jaggy edge contour.

The raw, smoothed, interpolated, poly-fitted, and the differentiated outer edge (sine wave) of the groove CC is shown here, by rows: http://kakyolab.xicp.net/0.report/21.interp_polyfit_diff_edge/0_screenshots_1.htm

Row 1: Not correctly scaled full-views of the outer edge data

Col 1: Raw edge

Col 2: Smoothed edge (time-window=1/50 angle range)

Col 3: Linearly interpolated edge

Col 4: Polynomially-fitted edge, window-size = 40 points, order = 2

Col 5: Analytically differentiated edge.

Row 2: the scaled version of Row 1 to correct the aspect-ratio of the data plots.

Row 3~6: The "zoomed-in" subplots (snapshots) of the segments of the edge data.

Plan

Proceed to audio extraction from the differentiated sine waves.

Smooth edge

2008-03-22T12:57:00.001-07:00

Description

The raw edge points of the sine-wave grooves contained a lot of sudden jumps and the attempts to find logical errors in my edge extraction and polar-system code didn't lead to any firm conclusion.

We decided to smooth the edge radii (distances between the edge points and the disc center) to see what would happen.

Two ways of window-based smoothing were used:

Fixed window size: Use a window with the size of a specified number of neighboring points, regardless the angular distance between the points. See Detail #1

Variable window size: Use a window with the size based on a specified angular span that would result in different number of window points depending on the particular angle values of these points.

#2 generates visually smoother points, probably because it is more grounded approach, because the angle-span based smoothing is closely related to time, while point-number based windowing is more random.

I haven't try weighted windowing such as Gaussian window. These will be attempted only after confirming that the above two methods don't work too well in terms of the generated audio.

Matlab plot scaling problem (only a few printable paper types are avaiable) causes the figures are ill-scaled; as a remedy, I show the scaled full-view of the data, and break down the full-length data into multiple aspect-ratio-adjusted subplots in the image reports.

Detail

See report page: http://kakyolab.xicp.net/0.report/19.smooth_edge_fixed_window/0_screenshots_1.htm

The data was arranged by rows

Row 1: scaled the full views of the sinewave groove's outer edge, scaled with image scaling of the ouput Matlab figure

Col 1: raw edges

Col 2: smoothed with window-size 3 (points)

Col 3: smoothed with window-size 5 (points)

Col 4: smoothed with window-size 7 (points)

Col 5: smoothed with window-size 9 (points)

Col 6: smoothed with window-size 11 (points)

Row 2: subplots of the smoothed edge with window-size 3 (points)

Row 3: subplots of the smoothed edge with window-size 5 (points)

Row 4: subplots of the smoothed edge with window-size 7 (points)

Row 5: subplots of the smoothed edge with window-size 9 (points)

Row 6: subplots of the smoothed edge with window-size 11 (points)

See report page: http://kakyolab.xicp.net/0.report/20.smooth_edge_var_window/0_screenshots_1.htm

The data was arranged by rows

Row 1: scaled the full views of the sinewave groove's outer edge, scaled with image scaling of the ouput Matlab figure

Col 1: raw edges

Col 2: smoothed with window-size of 0.005 of the CC's total angle span

Col 3: smoothed with window-size of 0.01 of the CC's total angle span

Col 4: smoothed with window-size of 0.0125 of the CC's total angle span

Col 5: smoothed with window-size of 0.02 of the CC's total angle span

Row 2: subplots of the smoothed edge with window-size of 0.005 of the CC's total angle span

Row 3: subplots of the smoothed edge with window-size of 0.01 of the CC's total angle span

Row 4: subplots of the smoothed edge with window-size of 0.0125 of the CC's total angle span

Row 5: subplots of the smoothed edge with window-size of 0.02 of the CC's total angle span

Plan

If this looks ok, proceed to polynomial fitting and sampling.

Edge and polar coordinates

2008-03-12T23:13:00.001-07:00

Description

After a whole-day debug, I still couldn't find the culprit of the jaggy edge radii to the disc center.

I printed out the edge points and manually calculated the radii, according to the center I measured, and the stage position of the FOV that's in the OPD file.

Now I'm totally confused.

Detail

A few possible sources of error were examined:

inaccurately estimated disc center, an error like this does not explain why the radii did not present more monotonous variation, i.e., if the center were off to a certain direction, the radii would still show local continuity and only present an offset on a larger scale. On the contrary, the result shows lots of local periodic variations.

wrongly angularly-ordered edge points, the idea is that if the edge points were not properly ordered before being plotted, then some previous shorter radii would be mis-placed to a later position, resulting the jumpy radii contour; however, according to my careful point-by-point tracing the points, this error does not exist.

incorrect polar coordinates calculation, the calculation was like this: the world-coordinates of the vertices of the FOV was derived when reading the OPD data file; these vertices were then centered to the disc center; finally, when doing the cartesian-to-polar conversion, the polar coordinates relative to the disc center of any points inside the FOV are derived through the top-left vertex of the FOV. According to my manual calculation, this step was correct as well.

precision degradation by metrc-to-pixel conversion, the stage position at an FOV, which is saved in the OPD file of an FOV determines all the coordinates of the FOV; the stage position is saved in metric unit (mm), and it has to be converted to the pixel unit to perform later calculation. This introduces precision loss. But after I did a one-pixel compensation, the jaggy edge is still there.

display problem, the matlab plot may have exaggerated the jaggy situation; however, the sudden jump is as large as 10-times the previous difference of the continuous group of radii, although the amount of jump is only of around 1-pixel distance.

Groove edge extraction: the old and the new way

2008-03-11T10:09:00.001-07:00

Description

Two ways of extracting the groove edges were implemented. But they currently both result in irregular point-to-point transitions.

Method #1: based on polar coordinates

Basis: The outer and inner edges can be defined as the radially farthest and nearest points of the groove CC.

Procedure: for a CC

Relative to the disc center, convert the cartesian matrix coordinates to polar ones. This gives a whole set of polar coords, depicted as P

From a desired audio sampling-rate (e.g., 384kHz), calculate the quantized image angular sampling-rate, i.e., how much angle, in rad, spans a sample along the angular direction. This generates a constant quantization step:angle_per_sample.

Sort all points in P by angle.

Divide the sorted points into angular groups A using angle_per_sample from Step #2.

For each angular group A(i), take the point with the longest radius as the outer edge point at the angle A(i), and the shortest radius as the inner edge point at the angle A(i).

Pitfalls

If the sampling-rate isn't high enough, the grouping method will take in too thick portion along the groove CC; when taking the extreme points, it can take only one for each end, in which way we lose points.

Method #2: based on cartesian matrix coordinates

Basis:

by looking at the neighboring pixels of an edge point of the groove CC, we should easily see 1 or more pixels of different CC index; whenever heterogeneous neighbors are found, the point of interest can be taken as an edge point.

Occasionally some "holes" inside the groove can be seen as edge by the strategy above, but they can be filtered out separately.

Procedure

For each point in a CC, mark those whose 4-neighbor area includes pixels with value other than the CC as edge. Note that 8-neighbor tends to collect overlapped points.

Separate the inner and outer edge points groups by using a 2-bin histogram that analyzes the radii of their polar coordinates.

For each edge group, sort the points by angle. Note that at this point, there is no quantization for this approach.

This approach needs a following fitting or interpolation to quantize it.

Somehow in the generated graph, the same irregularity still shows itself. I'm not sure whether it was just a display problem, because the data showed the gaps between adjacent points are only 1~2 pixels wide.

Angular sampling, fitting

2008-03-04T11:36:00.001-08:00

Description

I realized that the previous edge point sampling method was not entirely based on explicit audio sampling, so I updated the sampling method; now the method takes a control parameter of audio sampling rate and converts it into proper image sampling rage; However, there are other potential data loss issues. See Detail 1.2.

Before the sampling method changed, to avoid using sampling, I tried to extract all edge points of a groove use edge detection methods, trying to bypass the complexity and possible data loss with sampling; it turned out that the conventional edge detection methods all have difficulty in catching all edge points, regardless what analytical resolutions (thresholds and so on) they are working at. See Detail 1.1.

With the stereo sinewave, the undulation extraction, polynomial fitting, and differentiation were performed incrementally with individual results shown in Detail 2, 3, 4.

Improved the groove contour graph; now the value ranges of both top edges are normalized to the same range of the whole set of the top edge data, i.e., there won't be data that looks jaggy while its variation is actually tiny in value.

Detail

There are two ways of taking the groove edge points: 1) in cartesian coordinate system, look at the groove as a 2D glyph and extract the edge using edge detection, and then sample them angularly according to the disc-center polar coordinate system; 2) using the polar coordinate system in the first place, at an angular sampling rate, incrementally extract the radius extreme points at each angular sample points, and serialize them.

Edge detection tends to generates errors, see images , the red points are the detected edges, the light blue area is the rest of the groove, navy is the background.

http://kakyolab.xicp.net/work/14.edge_detection/0_screenshots_1.htm

angular sampling catches more points, but when taking the extreme points of the angular group, there will be edge points that will get discarded. When sampling angularly, a parameter controlling the thickness of the group should be carefully determined, otherwise, more points across the groove will be lost, no systematic solution to it yet. The audio sampling rate used here is 384kHz.

http://kakyolab.xicp.net/work/15.angular_sampling/0_screenshots_1.htm

The undulations extracted are here:

http://kakyolab.xicp.net/work/16.undulation/0_screenshots_1.htm

Column 1: lateral radii of the inner, outer edges, all points of the bottom;

Column 2: vertical depths of the top edges, and the ones for between the mid-points of the bottom and the mean depth of both top edges.

The polynomial fitted data, using previous found optimal parameters (windows size 40, order 2), the sinewave is clearly seen in the fitting.

http://kakyolab.xicp.net/work/17.polyfit/0_screenshots_1.htm

The differentiation looks jaggy. We need real numerical differentiation to replace the current polyfit-coefficient-based method .

http://kakyolab.xicp.net/work/18.diff/0_screenshots_1.htm

Plan

Numerical differentiation to achieve better sine wave like output.

improving the image report code to add more automatic image captions.

Ich meeting notes 2008-1~2008-2-12

2008-02-13T08:20:00.001-08:00

MItAC

bottom selection: literature 2D smoothing, interpolation; stylus modeling

sampling rate:

angular sampling rate should decrease from outer groove revolutions to inner ones;

the sampling rate calculation should be adaptive to any portion of groove on any revolution;

the radius changes on each angular increment, so does the sampling rate.

differentiation: numeric method using skip-point average (reading needed); for now, use the simplest one.

groove width: use it as an additional verification of the groove data

Don't use averaging to represent the undulation before it is justified.

Make sure that no data be discarded due to unjustiable sampling.

General Research

show every step, don't skip anything before it's justified: e.g., polyfit before differentiation

remove anything users don't want: the unwanted graph for bottom groove.

Differentiation

2008-02-12T10:24:00.001-08:00

Description

Haber's polynomial fitting and differentiation was implemented with several parameter sets tested; the results agreed with his paper that certain order of polynomial fit with a proper size of window generates better (smoother) results than others, see results:

Window size: 15, Order: 2

Lateral:http://kakyolab.xicp.net/work/6.diff_lateral_w15_o2/0_screenshots_1.htm

Vertical:http://kakyolab.xicp.net/work/7.diff_vertical_w15_o2/0_screenshots_1.htm

Window size: 40, Order: 2

Lateral:http://kakyolab.xicp.net/work/8.diff_lateral_w40_o2/0_screenshots_1.htm

Vertical:http://kakyolab.xicp.net/work/9.diff_vertical_w40_o2/0_screenshots_1.htm

Window size: 15, Order: 4 (Haber's setting)

Lateral:http://kakyolab.xicp.net/work/10.diff_lateral_w15_o4/0_screenshots_1.htm

Vertical:http://kakyolab.xicp.net/work/11.diff_vertical_w15_o4/0_screenshots_1.htm

Window size: 40, Order: 4

Lateral:http://kakyolab.xicp.net/work/12.diff_lateral_w40_o4/0_screenshots_1.htm

Vertical:http://kakyolab.xicp.net/work/13.diff_vertical_w40_o4/0_screenshots_1.htm

See Detail #1

I attempted to test Stotzer's digital linear differentiator approach; however, probably due to the lack of knowledge of differentiator design, I couldn't achieve a linear one, instead, I got a frequency response of logarithmic shape with filter band of 3 segments.

Detail

The fitting method

Regarding [radius, angle] pair, assume that radius is the function of angle, and fit an n-th order polynomial to this polar coordinate pair.

Differentiate the fitted coefficients, using the result as the coefficient to evaluate the angles as input with polynomial fit, which generates the output value in the graphs

Plan

Go on trying the Haber's method on Sine wave

Read about digital differentiator literature and implement Stotzer's approach