[Elphel-support] [Elphel-support-Eyesis] Please (stereo) rectify me ...

Luc Deschenaux luc at miprosoft.com
Tue Nov 26 10:39:50 PST 2013


On 26/11/13 02:29, support-list-eyesis wrote:
> Luc,
>
> We did not use the 2 bottom cameras for panoramas,
Yeah I know. From the bottom cameras I was trying to estimate pixel 
azimuth in the panorama coordinate system, and elevation in the channel 
coordinate system.

> but they are treated exactly the same and I remember them showing on 
> the overlap maps correctly. Can you be more specific on "unrelated"
With "unrelated" I mean azimuth for a matched pixel is different in top 
and bottom channels for far objects using the

  azimuth = ( XPosition + x ) * 360 / ImageFullWidth

method you mentioned before.

Also, Y Position is equal for channels 10 and 24 in the eqr-tiff files:

10.eqr-tiff properties:
<XPosition>9578</XPosition>
<YPosition>*2321*</YPosition>

24.eqr-tiff properties:
<XPosition>9639</XPosition>
<YPosition>*2321*</YPosition>

14.eqr-tiff properties:
<XPosition>2480</XPosition>
<YPosition>2277</YPosition>

25.eqr-tiff properties:
<XPosition>2542</XPosition>
<YPosition>2252</YPosition>

> or even place all images as layers in gimp using those two values and 
> send the composite image?
>
Here are the composite image parts for channels 24 and 25, placed over 
the full panorama (in difference mode).

I was expecting the same azimuth in both channels for far objects.

> As for processing image pairs - there is some code in ImageJ plugin (I 
> made couple years ago) that can map 2 images on a common plane (common 
> defined as average of the two normal vectors) and oriented so 
> disparity is strictly horizontal.
>
Seems me it's the "Create Plane Map" I spotted before I'll dig it thanks.


Luc

> Andrey
>
> ---- On Mon, 25 Nov 2013 16:38:24 -0800 *Luc 
> Deschenaux<luc at miprosoft.com>* wrote ----
>
>     Hello Andrey,
>     /
>     ///For channels 24 and 25, the XPosition and YPosition properties
>     seems unrelated to the upper channels panorama coordinate system.
>
>     Then to estimate azimuth for pixels in channel 24, i tried to use
>     XPosition and YPosition from channel 10, then to add
>     /channel[24].azimuth - channel[10].azimuth/, with more or less
>     precision.
>
>     I believe that because of the horizontal rotation between top and
>     bottom cameras, for near objects there's a small horizontal
>     disparity as well as vertical disparity.
>
>     What do you have in mind to achieve proper rectification of the
>     two stereo pairs in order to align epipolar lines with the
>     baseline and to compute distances at short range from matched
>     pixel coordinates*?*
>
>     After reading/"Stereo rectification of calibrated image pairs
>     based on geometric transformation//
>     //"
>     /(http://www.mecs-press.org/ijmecs/ijmecs-v3-n4/IJMECS-V3-N4-3.pdf) I
>     believe if it's worth trying this method which boils down to
>     compute two projection planes coplanar and parallel to the
>     baseline and reprojecting pixels on them (and I do try to
>     implement it). What do you think about it *?*
>
>     In the same vein, for a matched pixel in two equirectangular
>     images, after estimating relative azimuth and elevation with
>     respect to the equirectangular image center, i believe it is
>     possible to map the given vectors coordinates relatively to the
>     baseline in order to estimate depth but i did not succeed yet...
>
>     ...so i wonder: Is there is a scale factor or something that makes
>     the focal length (in pixels units) no longer equal to the
>     focal_length_mm / sensor_pixel_size_mm when working in the
>     equirectangular image coordinate system *?*..
>
>     Thanks in advance for your answers !
>
>     Luc
>
>     PS: In elphel-imagej/PixelMapping.java I see there's a "Create
>     Plane Map" procedure generating .plane-tiff and .intermap-tiff
>     files. I wonder what are those .plane-tiff and .intermap-tiff
>     files, and, if they are really useful for what i'm trying to do,
>     what are the required steps to generate them ?
>
>     --  Luc Deschenaux t: +41 788 266 366 v: +41 225 085 085 @ netvoip.ch
>
>     _______________________________________________
>     Support-list-eyesis mailing list
>     Support-list-eyesis at support.elphel.com
>     <mailto:Support-list-eyesis at support.elphel.com>
>     http://support.elphel.com/mailman/listinfo/support-list-eyesis_support.elphel.com
>
>
>


-- 
Luc Deschenaux

t: +41 788 266 366
v: +41 225 085 085 @ netvoip.ch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20131126/f174d3b0/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 24.jpg
Type: image/jpeg
Size: 376840 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20131126/f174d3b0/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 25.jpg
Type: image/jpeg
Size: 286287 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20131126/f174d3b0/attachment-0001.jpg>


More information about the Support-list mailing list