Talyor series의 이해

학술 2011. 2. 16. 15:54 Posted by 양고

Dr.Byoun으로부터 테일러시리즈에 관한 질문을 받고 아는척 둘러대었으나 사실 나도 제대로 모르고있다는 사실을 깨닫고 정리해보았다.

닥터변으로부터의 미션: f(x) = x^0.5 즉 루트(x)를 테일러 전개하라. 단 x=4 에서.
그럼 f(4) = 4^0.5 = 2.
f'(4) = 0.5 * x^(-0.5).
1차까지만 전개하면 f(x) = f(4) + f'(4)/1!(x-4) = 4^0.5 + (x-4) * 0.5*4^(-0.5)

이를 그래프로 나타내면


즉 f(x) = x^0.5를 x=4 주변에서 직선(1차미분)으로 근사한 것이다.
이를 위한 매트랩 코드는 다음과 같다.

ezplot('y=x^0.5', [0 10 0 5]);
hold on
ezplot('y=4^0.5+(x-4)*0.5*4^(-0.5)', [0 10 0 5]);

즉, 테일러 급수는 한 포인트에서 함수값, 1차 미분값, 2차 미분값, .... 을 알고 있을 때, 그로부터 전체 함수모양을 추정하는 방법이 되겠다. 맼로린 급수는 그 포인트가 x=0일 때를 말한다.

GPU 기반 스테레오

학술 2011. 2. 1. 14:22 Posted by 양고

Real-time global stereo matching using hierarchical BP
BMVC 2006
Kentucky Univ.

내용
Hierarchical BP를 GPU로 구현. 16fps with 320x240 and 16 disparity levels.
결과는 상당히 좋음.
BP 기본 내용을 참고하려 했으나 문장이나 수식이 보기에 영 불편함. 원래 2003 TPAMI Stereo Matching using Belief Propagation 논문을 봐야겠음.

Real-time accurate stereo with bitwise fast voting on CUDA
ICCW 2009
Zhang Ke, ..., Luc Van Gool, 벨기에 가톨릭 대학?
임의 모양의 윈도 / CUDA
윈도 모양을 정하는 것은 상당히 휴리스틱함. 두 개 연속 큰 코스트가 나오면 윈도 확장을 멈추는 식.
어쨌거나 결과는 좋음. 12fps with 64 disparity levles.
IJCV 2002
Daniel Scharstein and Richard Szeliski

논문 개요
  1. matching cost, aggregation, optimization에 따라 분류
  2. RMS보다 bad pixel percentage에 의한 평가
  3. truncation(M-estimator와 비슷한)과 같은 변수를 바꿔 가며 엄청난 양의 실험을 했으나 사실 크게 와닿는 것은 없다는...
  4. middlebury 사이트를 개설한 것이 가장 큰 contribution임


Classification and evaluation of cost aggregation methods for stereo correspondence
CVPR 2008
Tombari, ..., Stefano @ Bologna Univ. Italy.

내용
WTA에서 cost aggregation만 비교.
이것도 별 참고할 만한 내용은 없는...;;
segmentation 사용한 경우 (자기들 논문) 가장 정확한 결과를 얻음.
 

근 15년 만에 스테레오로 돌아온 기념으로 간단한 SAD 테스트 코드

cvFindChessboardCorners 원리

학술 2010. 12. 16. 20:15 Posted by 양고
from http://tech.groups.yahoo.com/group/OpenCV/message/26317

Re: cvFindChessboardCorners() uses what??


1. Dilation of the white squares by 1 pixel, so that the black squares
don't touch (it might be the oter way, i'm not shure).
2. Thresholding with a value beneath the medium intensity
3. Contour extraction and approximation to a rectangle. This extract
the black (i suppose) squares.
4. selection of the inner corners by rejecting the points which don't
belong to two extracted rectangles.

I noticed that this is not working very well for images taken using a
camera with a flash, due to non uniform illumination.
But i managed to extract the correct corners by running the contour
extraction several times, using several different thresholds, even
adaptive thresholding, different combinations of Dilate/Erode and
rejecting duplicate rectangles prior to step 4.

G�nter

--- In OpenCV@yahoogroups.com, S�kr� OZAN <perdesiz@y...> wrote:
>
>
> I wonder what kind of algorithms does FindChessBoardCorners uses to
> find out the corresponding corners... any ideas?



waitKey(0)가 작동하지 않는다면?

학술 2010. 12. 6. 19:13 Posted by 양고

OpenCV의 waitKey는 최소 하나의 창이 오픈돼있을 때만 작동한다고 한다.
창이 있어야 키를 입력 받을 수 있다는 어쩌면 당연한 사실~!

이미지 센서 크기

학술 2010. 11. 18. 16:19 Posted by 양고
2/3" 이미지센서는 진짜 2/3 inch * 25.4 mm/inch = 약 16.9 mm 일까?

유감스럽게도 그렇지 않다. 2/3" 이미지센서의 대각선 길이는 그보다 1.5배 정도 작은 11mm이다.
이 바보같은 "인치" 시스템이 붙인 크기는  1980년 이전의 비디오 카메라에 쓰이던 비디오카메라튜브의 유리 외경을 말하는 것이다.

http://en.wikipedia.org/wiki/Image_sensor_format#Table_of_sensor_sizes
http://www.dcinside.com/study/ccd_realsize.htm



센서가 클수록 화질이 좋은 이유는 무엇인가?

이 문제도 전에는 '광량이 많아서'라고 생각했다. 그러나 다시 한 번 생각해보면 광량은 전적으로 화각에 달린 것이지 센서 크기와는 무관하다.
답은 센서가 클수록 photon well이 커져서 dynamic range가 커지기 때문이다... 라는데 단노출에는 차이가 없을 것 같은데... 음;

http://www.21stcenturyshoebox.com/essays/sensorsizes.html

놔뒀다 다시 읽어봐야지... -_-

Connect to remote graph가 안 될 때

학술 2010. 11. 15. 16:45 Posted by 양고

cmd> regsvr32 quartz.dll

이것만으로 해결했다. 진작에 좀 찾아볼 girl~!!!

출처: http://www.eggheadcafe.com/software/aspnet/30608048/graphedit-cant-connect-to-remote-graph-anymore.aspx

다음은 캡처 프로그램을 돌리고 spying한 결과이다.

spy한 그래프 - 하는 일에 비해 꽤 복잡한데 Afreeca UVUY to YUY2 filter가 의심스럽다.


Afreeca 필터를 제거하니 Conexant Color Format Converter가 붙었다. 해당 프로세스의 CPU 점유율은 처음보단 좀 낮아진 것 같다 (10~30% 사이). SampleGrabber의 콜백에서는 바로 리턴했을 때의 수치이다.

DeckLink 필터그래프

학술 2010. 11. 8. 16:36 Posted by 양고


YUV4:2:2 --> RGB conversion.
 for(int y = 0; y < 1080; y += 2) // discard the odd line
 for(int x = 0; x < 3840; x += 4) // 4byte 두 픽셀마다 -> 4byte 한 픽셀로
 {
  U0 = pbFrame[y*3840 + x + 0];
  Y0 = pbFrame[y*3840 + x + 1];
  V0 = pbFrame[y*3840 + x + 2];
  Y1 = pbFrame[y*3840 + x + 3];
  Y = (Y0+Y1)/2;
  frame[(1080-y)*1920 + x + 0] = min(Y + 1.772*(U0-128), 255);     // B
  frame[(1080-y)*1920 + x + 1] = min(Y - 0.344*(U0-128) - 0.714*(V0-128), 255); // G
  frame[(1080-y)*1920 + x + 2] = min(Y + 1.402*(V0-128), 255);     // R
 }
문제는 심각한 연산 시간 (45ms) ㅠㅠ


DeckLink Capture

학술 2010. 11. 4. 18:13 Posted by 양고
예상 외로 imshow 따위에서 CPU를 점유하는 것으로 밝혀짐.


향후 진행:
GetBytes -> YUV422-BGR 변환 ㄷㄷ

Shot Boundary Detection

학술 2010. 10. 27. 21:50 Posted by 양고


   double comp = compareHist(mHistPrev, mHist, CV_COMP_CORREL);
   if(comp < 0.85)
   ...