Changes between Version 14 and Version 15 of GsocDSMGenerationToolForOSSIM

Timestamp:

06/27/14 16:51:25 (11 years ago)

Author:

martidi

Comment:

--

GsocDSMGenerationToolForOSSIM

@@ -185 +185 @@
 
 I am having some issues with automatic TPs collection and orthorectification on particular imagery I am testing.
+
+=== Weekly Report 6 (2014, June 27) ===
+
+'''Week 6:'''
+
+WHAT I GET DONE THIS WEEK:
+
+Generally speaking, I've done some tests in order to find a better solution for the quasi-epipolar image generation.
+
+I have solved the issue I had with automatic TPs collection and orthorectification on particular morphologically relevant imagery I am testing.
+
+I have continued to improve the Semi Global Matching procedure implemented, such in a way that it could be used for any kind of images; for this reason I have used a stereo pair with a relevant mountain morphology in which it is achieved an height difference bigger than 1500 m. As expected, it results that a simple shift it is not sufficient to achieve an epipolar geometry and, following the paper by Wang et al. about epipolar resampling, I am implementing the transformation necessary for bring the projected images (actually on a constant ellipsoidical height) in the epipolar geometry. 
+
+I have solved some little issues related to SGM implementation (Disparity Map visualization and shift refinement) and I have improved the Disparity Map resulting from the same GeoEye stereo pair used for the first tests (see attached).
+
+[[Image(SGM Disparity.png)]]
+
+[[BR]]
+WHAT I PLAN ON DOING NEXT WEEK:
+
+To solve the problem on which I am stuck.
+
+To continue working on epipolar images generation and to integrate the developed code in an ossim app.
+
+To test and control implementation efficacy – discuss results with mentors.
+
+[[BR]]
+SOMETHING ON WHICH I AM BLOCKED:
+
+I’m having some difficulties in finding the correct image transformation for epipolar generation. I have seen that using the affine transformation (estimated with the opencv api) the disparity between the objects is not well preserved. Actually, I think that I found a possible solution estimating a roto-translation without scale. 
+(https://github.com/martidi/OSSIM-GSoC-2014/tree/master/TEST_AFFINE).
+