Save mismatch correction parameters between camera1 and camera2 images to .imagine file

[kdw503]

As @Cody-G proposed, we need to save mismatch correction parameters between camera1 and camera2 images to .imagine file. So we need to decide field name of those parameters. How about this below?

[mismatch correction] x translation= 10 y translation= 20 rotation angle in degree=1.2

[timholy]

Are the units on x and y pixels?

[kdw503]

Yes.

[Cody-G]

My guess is that using pixel units is OK. I can't think of a significant advantage of using microns instead. But I think it would be good to include the unit in the field name. What about "x translation in pixels"

I also think we should make sure that "x" and "y" correspond to what we call "x" and "y" in the "pixel order" field.

I'm not sure how you're encoding the transformation, but somewhere we should also document that the transformation maps the image of camera 2 onto the image of camera 1 (?), the rotation is about the center (?) of the image of camera 2 (?) and that the rotation is applied before (?) the translation.

On Fri, Oct 6, 2017 at 12:28 PM, Dae Woo Kim notifications@github.com wrote:

Yes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/HolyLab/Imagine/issues/54#issuecomment-334819465, or mute the thread https://github.com/notifications/unsubscribe-auth/AE78hIYW6Zig3jLKZFLxJJDSMjew_xn3ks5spmNEgaJpZM4PwxrY .

[Cody-G]

Also, are we allowing the translation parameters to be fractional? i.e. x translation can equal 1.5 pixels?

On Fri, Oct 6, 2017 at 12:41 PM, Cody Greer codyjgreer@gmail.com wrote:

My guess is that using pixel units is OK. I can't think of a significant advantage of using microns instead. But I think it would be good to include the unit in the field name. What about "x translation in pixels"

I also think we should make sure that "x" and "y" correspond to what we call "x" and "y" in the "pixel order" field.

I'm not sure how you're encoding the transformation, but somewhere we should also document that the transformation maps the image of camera 2 onto the image of camera 1 (?), the rotation is about the center (?) of the image of camera 2 (?) and that the rotation is applied before (?) the translation.

On Fri, Oct 6, 2017 at 12:28 PM, Dae Woo Kim notifications@github.com wrote:

Yes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/HolyLab/Imagine/issues/54#issuecomment-334819465, or mute the thread https://github.com/notifications/unsubscribe-auth/AE78hIYW6Zig3jLKZFLxJJDSMjew_xn3ks5spmNEgaJpZM4PwxrY .

[kdw503]

To the camera2 image, I applied flip first and then rotation clockwise about the center and then translation. Translation is not fractional because we need fast speed. This detail algorithm could be changed later according to the following analysis algorithm most users conventionally using to match these images. Then, all agree with these field names below?

[mismatch correction] x translation in pixels=10 y translation in pixels=20 rotation angle in degree=1.2

[timholy]

The shift between the cameras presumably comes down to the physical alignment of the sensor within the optical path. If that distance were invariant, then getting a camera with bigger or smaller pixels would make that shift (in pixels) smaller or bigger, respectively. That might be viewed as an argument for expressing it in some kind of "unitful" length measure. However, I suspect those numbers would change even if you just unmount one of the cameras and re-mount it, so I think it's fine (even, best) to make it be in pixel units.

Do we have an established sign convention for the rotation angle? Which camera is advanced relative to the other?

[kdw503]

I just rotated a flipped camera2 image on the screen to clockwise(+) or counter-clockwise(-).

And about the translation, yes we need x, y, z translation but Cody and I just assumed that z translation would not be that big. Also rotation need 3 angles, but we just count one most important angle for the same reason.

[timholy]

Now that I think about it a little more, it seems hard to be fully explicit in the names, so perhaps we can leave them as you suggest. Somewhere we will need to document the actual transformation implied by these constants. E.g., is it shift(rotate_around_center(img, angle), offset) or rotate_around_center(shift(img, offset), angle) or something else?

[kdw503]

Actually, flip is also involved. But, when we adjust mismatch correction we always flip camera2 image. So, we just care about translation and rotation parameters. So final operation is look like shift(rotate_around_center(vertical_flip(camera2img), angle), offset).

[Cody-G]

This seems to work well. At some point we should document this somewhere.

[kdw503]

Ok.