What I Have Done in Hawpu | Eddie’s Blog

Reason: The program makes the image data subtract the black_level at the beginning. According to my experience of debugging, the data of one pixel is 16-bit binary data. The binary data will be converted to decimal data. If the binary data is negative after subtraction, the first digit of the binary data is 1. When converted to decimal data, the digit "1" will let the decimal data be above 32768, which makes the slope which is coded as "fitme" bizarre.

The edge slope is so high that the linearized slope which is coded as "fitme" is quite small, which makes the numerator of the "nlin1" equal 0. Consequently, the image data coded as "a" will be empty during the following calculation.

The SFR data is greater than 1, which is caused by the new "deriv1.m". [ Arduous ]

The "barray" has zeros following some huge number at the end, which makes the "point" have zeros at the end too. In MATLAB code the indexes of the zeros of "barray" are near the location of "nn+start" which is at the end of the "barray". And the indexes of the zeros of "point" in near the location of "nn" which is also at the end of "point". This may not be a problem, for the reason that a lot of normal data has similar characteristics during the calculation. I deem the slope which is programmed as "fitme" is not the problem.

Screenshots of "barray" & "point" (Left: New. Right: Old)

The last "barray" index is "i+start". The last "barray" is 0.

"point" which also has zero at the end :

After calculating the derivative, the vector "c" has a dramatic number change at the end. The numbers change from digits around 10 to large negative digits. According to my understanding, the vector "c" calculated by "deriv1.m" is the derivative of the vector "point", which stands for the extent of the change of the numbers of "point". It also seems to be normal.

Screenshots of vector "c" (Left: New. Right: Old)

As "c" has more negative numbers at the end, the "sumx" is a drastically huge negative number which leads the loc to be equal to 0 in "centroid.m". Here is where the problem starts that I consider. The "mid" which is equal to "loc" which is equal to 0 is the origin of the following errors.
After being shifted by the "cent.m", the "temp" has lots of zeros at the beginning followed by some slight numeral turbulence. If the old "deriv1.m" is used, I could almost see an entire window with both upward as well as downward trends at the end of "temp". But if the new "deriv1.m" is applied, there only exists a line going upwards. Because the "mid" which is equal to 0 is not the actual centroid location of the vector "c".

Screenshots of "temp" & Schematic Hand Drawing (Left: New. Right: Old)

Even though the data are being filtered by a Hamming window, the shape and the comparative altitude of the number still exist.

Screenshots of "c" which is filtered by the FIR filter. (Left: New. Right: Old)

The reason for the sharp sudden curve upward changes, the peak amplitude of the FFT result in the new MATLAB program is not the direct-current component. In the MATLAB code, the MTF is the amplitude of the FFT data divided by the amplitude of the direct-current component. As a consequence, the MTF has lots of digits that are above 1, which causes the above-1 SFT data to come into being. Notwithstanding there is a wave in the old program, the wave is intact, which derives good results.

Screenshot of FFT results. (Left: New. Right: Old) And hand drawing.

Schematic hand drawing about "deriv1.m"

Schematic diagrams

Leveled?: The target shall be oriented so that the horizontal edge of the chart is approximately parallel to the horizontal camera frame line.

Distance from the camera to the chart: The approximate distance between the camera and the test chart should be reported along with the measurement results.